为了优先考虑敏捷性和可扩展性，安全往往被忽视。
译自 How to Ensure Cloud Native Architectures Are Resilient and Secure，作者 Akhil Mittal。
在当今快节奏的数字环境中，企业正在争先恐后地利用云原生技术进行创新和扩展。但根据我的经验，这种匆忙往往会付出代价，尤其是在安全性方面。在最近与一家金融服务公司的项目中，我亲眼目睹了将速度置于安全之上的做法如何暴露了关键漏洞。
乍一看，我合作的公司似乎是一个云原生成功的典范：微服务分布在多个区域，完全自动化的管道，以及频繁的功能发布。然而，在安全审计期间，我们发现其 API 通信方式存在严重漏洞，这使整个系统处于危险之中。该团队实施了广泛的 API 访问控制以简化 扩展，这无意中造成了重大的安全漏洞。只要一个服务被破坏，攻击者就可以横向移动到整个系统，从而可能访问敏感的财务数据。
根据我的经验，API 漏洞正成为攻击者常用的切入点，导致了我们今天看到的许多数据泄露事件。2023 年 Salt Labs 报告 显示，去年 94% 的企业都遇到了 API 安全问题，主要原因是配置错误和可见性差。这些数据强调了不安全的 API 对企业构成的重大风险。Gartner 预测，到 2025 年，近一半的企业 API 可能得不到管理，从而造成重大的安全漏洞。随着企业将重点放在速度和增长上，安全往往被抛在脑后。
微服务提供了灵活性并加快了更新速度，但也带来了复杂性，以及更多风险。在本例中，该公司已将其 平台拆分为数十个微服务，负责从用户身份验证到交易处理的所有事项。虽然这使得扩展更容易，但也增加了安全漏洞的可能性。由于有如此多的活动部件，监控 API 流量成为一项重大挑战，关键漏洞被忽视了。
如果没有适当的监督，这些盲点很快就会成为攻击者的重要切入点。
未经管理的 API 可能会在未来造成严重的漏洞。如果这些漏洞得不到解决，企业可能会在几年内面临重大威胁。
自动化通过 扫描代码和依赖项以查找安全 问题来帮助公司快速发布功能。虽然自动化最初有效，但它忽略了更严重的问题，例如过于宽泛的 API 设置。过度依赖自动化导致团队忽视了更深层次的设计缺陷。虽然自动化工具捕获了更多次要的代码问题，但它们未能检测到系统范围内的漏洞。
我注意到这个问题在云原生设置中越来越严重。团队经常过度依赖自动化，而没有意识到这些工具可能会错过一些细微但关键的问题，例如过于宽泛的 API 权限或配置更改。虽然自动化对于速度至关重要，但它还不够。手动审查和定期审计对于发现自动化可能错过的架构缺陷至关重要。
一旦我们确定了漏洞，很明显架构需要的不只是快速修复，而是需要彻底改造。以下是我们解决问题的方法：
- 强强制行 API 最小特权：我们审查了所有 API 交互并重新配置了访问控制，以遵循最小特权原则。仅向每个微服务授予所需的访问权限，从而显著缩小了攻击面。
- 严格限制访问控制策略：收紧了广泛的访问控制，确保每个服务仅具有必要的权限。这减少了内部和外部威胁，并创建了更透明的审计跟踪。
- 将自动化与手动审计相结合：虽然自动化仍然是必不可少的工具，但在开发和部署的关键点中，我们增加了手动审计。这些手动检查帮助我们发现了自动化遗漏的错误配置和设计缺陷。
- 实现了服务网格：为了加强服务之间的安全性，我们实现了服务网格，这使我们能够更好地控制 API 交互的方式，并且至关重要的是，它有助于我们密切关注通信模式。即使一个服务遭到破坏，服务网格也能防止横向移动，从而最大程度地减少损害。
- 采用混沌工程：我们使用混沌工程原理对架构进行压力测试，模拟故障和攻击。这帮助我们在它们被利用之前识别并修复薄弱点。
该项目经验教训广泛适用于使用云原生架构的任何组织。以下是保护基础架构的方法：
- 定期审计 API：确保所有 API 交互都遵循最小权限原则。过大的权限会造成严重漏洞，尤其是在微服务环境中。
- 强化访问控制策略：定期审查和收紧访问控制以降低风险。定期审计对于发现过大的权限至关重要。
- 自动化与人工审计相结合：自动化对于速度至关重要，但人工审查可以发现更深刻的架构缺陷。安排定期审计以发现错误配置和设计问题。
- 利用服务网格来实现 API 安全性：服务网格可以更严格地控制服务到服务之间的通信，并提高 API 交互的可见性。
- 采用混沌工程：通过模拟故障和攻击对架构进行压力测试，在弱点变得严重之前找出弱点。
随着越来越多的企业接纳云原生技术，为了实现优先的灵活性与可扩展性，常常将安全性放在次要位置。但这种权衡是不可持续的。到 2025 年，除非当今实施适当的控制，否则无法管理的 API 会将组织暴露于重大漏洞。
你的选择将决定你所属的系统是否可以抵御未来的威胁。不要让对速度和创新的追求成为一场安全灾难。弹性和安全性与灵活同等重要。