作者 | KASHYAP VYAS
译者 | 张健欣
策划 | 褚杏娟
DevOps 原则和云原生应用程序开发流程的采用正在推动文化和技术变革，帮助企业变得更加灵活，加快市场开发速度。除了更快的开发，这些技术还提供了更好的用户体验、更灵活的管理、更高的可靠性和更低的成本。与使用云的应用程序相比，云原生应用程序是在云中构建和部署的。它们使用容器和微服务架构来提供更快的应用程序开发和交付，以及更大的灵活性。
IDC 预测，到 2022 年，90% 的新企业应用程序将使用云原生应用程序开发流程、敏捷方法论和 API 驱动架构。根据一份调查报告，全球有大约 650 万活跃的云原生开发者，约有 400 万开发者使用无服务器架构和云方法。现在 92% 的组织在生产环境中使用容器。
1
云原生架构引入新风险
虽然好处引人注目，但云原生架构也引入了各种新型安全风险和潜在的漏洞源。现有的应用程序安全性方法并不是针对新范式设计的。相反，DevOps 团队需要一种新的方法来帮助他们更好地识别潜在风险，并使它们能够将漏洞管理集成到开发和交付流程中。
早期，软件开发被认为是一个线性过程，但云原生架构的兴起导致了高度动态的应用程序环境。在这里，变化是唯一不变的。根据研究，61% 的组织认为他们的环境每分钟或者更短时间就改变一次。云原生、基于容器的环境的动态特性，以及跟上敏捷开发速度的需要，使得检测漏洞和管理应用程序安全更加困难。
根据一份调查报告，在 2020 年上半年期间，每天有 160 起针对蜜罐的攻击。其中 95% 的攻击旨在劫持资源，而 5% 的攻击旨在发起网络拒绝服务攻击。这个研究还表明，微服务、容器和 Kubernetes 为 89% 的 CISO 创建了应用程序安全盲点。
2
检测和管理漏洞的挑战
传统的安全实践根本不适合这种环境。事实上，云原生架构从根本上破坏了应用程序的安全性。传统的安全漏洞管理方法无法跟上这些动态环境，因为传统方法只能提供单一时刻的静态视图，这使得它们的效率越来越低，并且容易出现盲点。具体有如下几个原因。
1. 增量开发
云原生应用程序是使用不断更新并部署到环境中的连续代码流开发的。快速的软件开发周期允许微服务应用的每个组件都进行每日更新。这种增量开发为已知和未知的漏洞创建了一个大型的攻击面。安全团队可能会发现，在不降低发布周期的情况下保护这些部署是一项挑战。
2. 位置的无常性
传统应用程序总是有一个连接的服务器或虚拟机（VM），这使得应用程序始终保持相同的 IP 地址和位置。但是，云原生应用程序既没有如此持久的位置，也没有任何清晰的边界。
在传统应用程序中，多个软件功能或进程会运行在一台虚拟机上。而现在，每个进程或功能都被打包为一个单独的容器，从而使每个实体暴露在泄露的漏洞中。它需要在整个开发生命周期中得到保护。
3. 从持续运行到按需运行的转变
微服务的兴起见证了从持续运行应用程序到按需运行的快速转变。在这些环境中，根据使用情况，基础设施会开启和关闭来支持数字服务。
这些基础设施还允许每个组件独立地自动地调整。这虽然提高了应用程序的操作效率，但也使得用传统或手动方法来保护它们和管理漏洞变得几乎不可能。
4. 缺乏优先次序
保护应用程序安全的传统方法主要侧重于在代码漏洞被利用之前识别和缓解代码漏洞。例如，在将应用程序放到生产环境之前，安全策略可能需要修复所有关键漏洞，只有这样，你才能进行下一步。
但是，基于涉及的相对风险和数千个漏洞的严重性来评估云原生应用程序既耗时又困难。此外，在处理云原生供应链和基础设施中的漏洞激增时缺乏优先级，会减慢开发速度，也不会让 DevOps 团队降低整体风险。
5. 不全面的漏洞扫描
云原生应用程序中的漏洞扫描通常仅在预生产阶段进行。因此，错过生产阶段运行的内容会增加在云部署中运行有漏洞的库的风险。由于无法区分潜在漏洞和真实暴露，它们对每个可能的漏洞发出堆积如山的警报。由于假阳性的数量巨大，这增加了组织理解其暴露风险影响的难度。
6. 漏洞的唯一性
云原生系统包含大量公有云和私有云、应用程序架构和云服务。每种架构模式都可能有其不同的漏洞和安全需求。安全团队需要了解这些复杂的攻击面，并找到保护每种不同架构的解决方案。
3
云原生安全的最佳实践
当涉及云原生应用程序时，安全性不能是事后诸葛亮。安全性必须集成到持续集成和持续开发流程中，而不是依赖于固定的解决方案和方法。采用基于风险的方法至关重要，但这并不是完整的解决方案。
一个完整的解决方案将这与各种其它安全层结合在一起，这些安全层超越了检测和评估，而转向了补救或缓解。这些措施包括调整安全性、在功能和容器级别应用外围安全性、保护应用程序依赖、强制执行最小角色和权限，以及利用共享的安全责任。
基于风险的方法
这种集成的实用安全性的首批实现之一可以是采用基于风险的方法进行云原生开发。这使得 DevOps 团队能够检测、评估和修复工件管道中的漏洞，作为开发过程中的一个集成组件。它还允许你对容器部署后的行为进行持续监控。
基于风险的方法允许你确定优先级。这个方法对漏洞进行打分，以评估每个漏洞的危险程度。全面的基于风险的方法必须确保在允许代码投入生产环境之前对风险进行分析和缓解。因此，安全控制必须转移到开发管道中，重点应该放在工件管道上。这种变化可以最小化组织的运行时攻击面。
边界安全
云原生应用程序的系统分为多个可调用组件，这些组件接受来自不同来源的事件驱动触发器。这为攻击者提供了更多的目标选择和许多恶意活动的载体。防范此类攻击的一个重要实践是使用为云原生环境构建的 API 和应用程序安全工具。除此之外的一般方法是在功能级别加强外围安全。识别由异常源触发的功能，并监控事件触发器中的异常。
在容器化环境中，必须确保多层次的安全。这可以包括编排器控制面板、物理主机、容器和运行单元。Kubernetes 等编排器的最佳安全实践包括隔离节点、对 API 服务器使用第三方身份验证以及限制和监控容器间的流量。
分配最低权限
由于云原生资源之间存在大量且频繁的交互，因此为每个容器分配唯一的权限组的能力为增强安全性提供了极好的机会。因此，如果云原生框架中的任何元素被破坏，它将造成最小的损害，并防止权限扩大到其它组件。
保护应用程序依赖项
云原生应用程序代码通常包含具有依赖关系的包。为了保护应用程序的依赖性，你需要特定的自动化工具，包括一个全面的开源组件及其漏洞数据库。
你还需要能够在开发过程中触发应用程序安全活动的云原生编排工具。通过连续运行上述工具，可以防止在生产环境中运行的函数或容器中包含有漏洞的包。
4
云原生应用将何去何从？
随着云环境变得越来越动态，组织必须确保应用程序的最大覆盖率，来帮助避免盲点，实时监测漏洞，并获取信息以评估风险。从长远来看，需要一种新的安全方法。Palo Alto Networks 产品副总裁 John Morello 认为，这些新方法包括：
保护应用程序编程接口 (APIs)
探索新的云原生安全指标和文化
转向机器学习和开源软件
API 是连接微服务和容器的最常见的形式，而这正是黑客获取数据并将恶意软件引入系统的目标。不幸的是，API 本身是不安全的，并且会受到攻击，因为通过编程，它们很容易访问。因此，你需要一个好的安全模型和恰当的工具来保护这些微服务。
对于云原生架构的长期安全运行，Morello 强烈建议使用 DevOps 指标。因为从安全角度来看，最重要的指标不是环境中的漏洞数量，而是修补或修复这些漏洞所需要的时间。
检测和管理漏洞是一项复杂的劳动密集型任务。在一切都是代码的时代，安全自动化是一种强劲的趋势。它特别适用于检测错误配置和漏洞、升级组件、根据安全最佳实践自动进行代码评审，以及关闭受侵害的运行单元。
希望这些最佳实践能帮助你安全地过渡到云原生模型。
https://www.itbusinessedge.com/cloud/detecting-vulnerabilities-in-cloud-native-architectures/
