译者 | 布加迪

审校 | 重楼​

这几年，微服务革命席卷整个IT界，71%的组织声称2021年之前采用了这种架构。在讨论微服务时，我们常听到其优势在于可以灵活地向客户交付创新成果。但有一个方面却很少被人提及，那就是企业安全问题。​

【资料图】

在单体式应用程序时代，单单一个安全问题就可能意味着要花成百上千个小时从头重新构建应用程序。除了必须修补安全漏洞本身外，这还意味着DevOps团队和安全团队将不得不审查和重构应用程序以调整依赖项，有时不得不有效地对整个应用程序进行逆向工程处理。​

微服务颠覆了这种模式。它允许DevOps团队在不用担心破坏整个应用程序架构的情况下隔离安全漏洞或问题，并解决它们。这不仅意味着可以更迅速地开发出安全补丁，还意味着DevOps团队和IT架构整体上更有弹性、更高效。​

先有必要提醒一下什么是微服务架构：这是一组可以独立部署的服务，通过API等中介系统松散地联系在一起。这些单独的服务通常反映了应用程序最基本的构建模块。​

实际上，容器是用于交付微服务架构的技术。这些轻量级独立软件包将应用程序代码与轻量级操作系统、运行时环境、库和配置数据捆绑在一起。通过使用像Kubernetes这样的编排系统，各个容器可以彼此交换输出内容，使它们能够执行曾经通过单体式应用程序才能实现的总体任务。​

微服务架构通常由容器提供，通过设计来隔离许多安全风险。由于单个微服务仅通过编排它们的中介系统交换输出，单个微服务被破坏或攻击很难影响整个应用程序。​

在实践中，上述表述又意味着什么呢？以下是一个推演案例。​

几年前制造商发现，如果将日期改为1/1/1970，许多消费级设备就无法使用。想象一下：如果我们将该缺陷引入到用于企业环境中的日历应用程序。现在假设黑帽攻击者抢在安全团队之前发现了这个问题，随后进而获取某人的凭据，并将日历应用程序中的当前日期更改为1/1/1970。​

如果企业的DevOps团队在处理单体式应用程序，他们不得不做以下工作：​

首先，他们将不得不应对由攻击引起的一系列广泛的系统故障，除非解决了这个缺陷，否则他们无法修复这些问题。​

其次，假设他们发现了缺陷出在日历应用程序上，将不得不检查该应用程序的完整源代码，并手动找到问题所在。​

最后，他们将不得不检查整个日历应用程序的源代码，以更改引用与有漏洞的代码行相关的变量或语句的任何地方。​

如果同一个DevOps团队处理微服务架构，情况又会怎样呢？​

首先，一旦黑帽攻击者更改了日期，他们会注意到含有缺陷的特定微服务出现了故障。​

其次，假设他们在使用容器，他们的Kubernetes发行版会标记特定的容器并没有发送有效的输出数据。​

最后，团队只需将有问题的容器的设置恢复到恶意日期更改之前即可。​

一旦团队完成了最初的诊断并通过设置回滚来解决问题，他们可以修复导致漏洞的底层缺陷。综观整个过程，更广泛的日历应用程序以及依赖它的一切都保持在线状态。​

从上面的故事中可以得出一大启示：在微服务架构中，只需要替换或更新有缺陷的组件，而不是替换或更新整个应用程序。这意味着果真出现问题或漏洞时，停运时间更短，因为团队可以识别并恢复受损的单个微服务。此外，这为DevOps团队和安全团队减少了解决缺陷的工作量，因为他们只需要改动单个微服务，需要改动的应用程序代码必然比完整的单体式应用程序更少。​

此外，微服务让团队可以更积极主动。微服务通过防止攻击或级联漏洞的隔离机制来实现这种主动性。这种隔离机制让团队能够不断地改进单个微服务，不必考虑应用程序的其余部分。​

这意味着DevSecOps专业人员可以致力于留意漏洞或推出安全更新。不需要管理或后勤工作来阻止安全更新破坏应用程序中的另一个微服务。说到修复零日漏洞或保护应用程序免受新出现的威胁，这种灵活性和自由度大有益处。​

由于微服务，团队可以比以往任何时候更快速、更有效地响应安全威胁。说到主动性方面，微服务使团队能够以极快的速度加固系统。总之，这就是为什么说微服务已改变了企业IT安全界的面貌：它们让开发团队、运营团队和安全团队能够以前所未有的灵活性更快速地工作。​

原文标题：​​How microservices have transformed enterprise security​​，作者：Simon Wright