不断发展的云环境的云原生安全最佳实践

云安全一直有两个基本支柱。一是发现问题的可见性。另一个是有效修复威胁的能力——理想情况下，以主动的方式，这意味着在风险被积极利用之前降低风险。自从十多年前公司开始将工作负载转移到云中以来，这些支柱都没有改变。

然而，近年来发生了巨大变化的是企业实施云安全所需的工具和流程。随着组织从由虚拟机驱动的基本云环境转变为分布式、基于微服务的云原生环境，五到十年前就足够的云安全策略已不再足以领先于威胁行为者。

如今，确保云安全随着您的云战略和架构而发展至关重要。本文解释了这意味着什么以及企业应遵循哪些最佳实践来满足云原生安全要求。

从云安全到云原生安全

传统的云计算环境和云原生计算环境有很大的不同。推而广之，传统的云安全和云原生安全有很大的不同。

在传统的云环境中，您可以通过设置云防火墙和定义安全组来保护工作负载。您通过将代理加载到收集日志和指标的虚拟机上来实现​​安全可见性。您可能已经使用云提供商的本地安全工具（如 Amazon GuardDuty 或 Microsoft Defender）来解释该数据并检测威胁。您可能还定期审核您的云 IAM 设置以检测潜在的错误配置。也许您甚至将一些安全操作外包给了托管安全服务提供商 (MSSP)。

这些类型的工具和流程在云原生环境中仍然很重要。但是，仅靠它们还不足以应对云原生工作负载环境中出现的新的和独特的安全挑战。传统的云安全无法满足以下需求：

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

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

云原生安全最佳实践

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

将安全性融入您的开发管道

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

超越代理

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

实施分层安全

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

持续和实时审计

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

自动修复

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

驯服云原生安全的复杂性综上所述，即使您对保护传统云环境和工作负载的能力充满信心，您也可能在处理云原生安全风险方面面临一场艰苦的战斗。存在解决方案，但它们需要专业知识和对新的、快速发展的云原生架构和技术的深入了解。