针对不断发展的云计算环境的云原生安全优秀实践

云安全一直有两个基本支柱：一是发现问题的可见性，另一个是有效修复威胁的能力。在理想情况下是以主动的方式进行保护，这意味着在风险被攻击者利用之前降低风险。自从十多年前一些企业开始将工作负载转移到云平台中以来，这两个支柱都没有改变。 然而，企业实施云安全所需的工具和流程近年来发生了巨大的变化。随着企业从由虚拟机驱动的基本云环境转变为分布式、基于微服务的云原生环境，在五到十年前采取的云安全策略如今已不能有效应对威胁行为者。 如今，随着云计算战略和架构的发展，确保云安全显然至关重要。以下对云安全意味着什么以及企业应遵循哪些最佳实践来满足云原生安全要求进行了解释。

从云安全到云原生安全

传统云计算环境和云原生计算环境之间有着很大的区别。从广义上讲，传统的云计算安全和云原生安全有很大的不同。 在传统的云计算环境中，企业可以通过设置云计算防火墙和定义安全组来保护工作负载。企业通过将代理加载到收集日志和指标的虚拟机上来实现安全可见性。可能已经使用云计算提供商的云原生安全工具(如Amazon GuardDuty或Microsoft Defender)来解释该数据并检测威胁。企业可能还定期审核其云计算IAM设置以检测潜在的错误配置，甚至将一些安全操作工作交给托管安全服务提供商(MSSP)。 这些类型的工具和流程在云原生环境中仍然很重要。但是，仅靠它们还不足以应对云原生工作负载环境中出现的独特的安全挑战。传统的云计算安全无法满足以下需求：

识别IaaS之外的风险：云原生攻击面超出了传统的基础设施和应用程序。例如，Kubernetes RBAC配置错误可能会造成安全风险，仅监控虚拟机或应用程序不会提醒用户注意它们。 管理不断变化的配置：现代的云原生环境可能包括数十个用户和工作负载，有数千个访问控制规则定义了谁可以做什么，并且其设置在不断变化。在这种快速变化的动态环境中，定期审计不足以主动检测威胁。 多云安全需求：当企业需要保护跨多个云平台运行的工作负载时，云计算供应商提供的云原生安全工具在功能方面是不够的。 纠正根本原因：知道存在风险并不总是足以在复杂的云原生架构中快速修复它。例如，检测应用程序中的代码注入漏洞并不一定意味着企业可以快速将问题追溯到触发它的特定微服务或代码提交。

因此，虽然传统的云安全仍然是云原生安全基础的一部分，但它本身并不是一个完整的基础。要全面保护云原生工作负载，企业需要扩展现有的安全工具和流程来保护传统云工作负载。

云原生安全最佳实践

要实现云原生工作负载的完全安全性， 需要努力遵循以下实践。

(1)将安全性融入开发管道

在云原生世界中，不要等到部署应用程序后才考虑风险。与其相反，通过将安全测试融入到持续集成(CI)/持续交付(CD)管道中，最大限度地提高在部署前发现和修复问题的机会。在理想情况下，企业将执行一系列测试——从测试源代码开始，然后在预生产环境中针对二进制文件运行测试。

(2)超越代理

虽然基于代理的安全性可能足以保护虚拟机等简单的云计算工作负载，但在某些情况下(例如，当企业使用无服务器功能时)无法部署代理来实现安全可见性。 与其相反，企业需要通过确保其应用程序公开检测威胁所需的数据，而不依赖代理作为中介，从而在代码本身中增加安全可见性。

(3)实施分层安全

云原生环境包括许多层，例如基础设施、应用程序、编排、物理和虚拟网络等，因此需要确保每一层的安全。这意味着除了捕获传统的云安全风险(如IAM错误配置)之外，还需要部署能够检测风险的工具和安全分析流程，例如，通过配置Kubernetes部署的方式或从容器映像内部检测风险。

(4)持续和实时审计

同样，定期审核或验证云计算配置不足以确保企业可以实时检测和修复威胁。与其相反，应该部署可以持续监控所有配置并立即提醒注意风险的工具。

(5)自动修复

在可能的情况下，还应该部署可以立即隔离或缓解威胁的自动修复工具，而无需人工参与。这种方法不仅可以减轻企业对IT和安全团队的负担，而且还允许尽可能快速和主动地修复漏洞。