微服务安全 DevOps

容器和微服务彻底改变了应用程序开发和基础设施管理。它们也引入了新的安全挑战，而旧的挑战仍然存在。有哪些新的安全挑战，以及您能做些什么来应对它们？

新技术，新挑战

微服务正在改变一切。不可变基础设施、无共享架构和容器化应用程序（微服务）是当今大多数企业路线图的重点。微服务提供了一种以小型、自主和自给自足的方式公开业务功能的方法，在给定的业务上下文范围内执行单元任务。这些通常以 API（应用程序编程接口）的形式公开，在虚拟机内、容器内甚至裸机上运行。

虽然容器化的优势是多方面的，但它也引入了一系列新的挑战。一些直接的挑战包括监控容器、容器蔓延、容器安全、微服务的跟踪与追溯以及镜像出处。

那么，微服务环境对安全有什么影响？单体应用程序环境中存在的安全挑战仍然存在，并且需要像往常一样解决。此外，我们需要考虑微服务和容器技术引入的其他安全挑战。

从安全的角度来看，与单体应用程序相比，在微服务世界中，攻击面现在大大增加。随着更多可部署单元和端点的暴露，攻击这些端点的安全攻击的可能性也随之增加，以及完整性问题。

此外，基础 Docker 镜像可能包含安全漏洞，这可能会损害微服务。因此，应管理 Docker 镜像出处，以确保基础 Docker 镜像的真实性。以最小的停机时间将安全更新和补丁传播到所有现有容器是另一个挑战。

DevOps 可能会给微服务世界中的安全需求带来更大的压力。持续构建和部署工具目前专注于简化交付流程，但对安全 DevOps 的关注度不够。

最佳实践

为了应对上述一些挑战，让我们看看以下最佳实践。作为有效 DevOps 战略的一部分，应将持续安全和审计步骤集成到 DevOps 管道中。持续测试应包括各种安全测试功能，镜像完整性验证应集成到管道中。此外，私有注册表可以确保镜像在企业内部是可信和受管理的。

应通过异常检测机制增强监控，以检测容器的任何虚假资源利用或异常事件，并且应通过基于代理和无代理的流程来加强所有监控功能。应更新和改进补丁管理，以确保容器使用最新的更新进行修补，同时确保最小的停机时间。

Docker 引入了一种名为 Notary 的镜像出处机制，该机制基于 TUF（更新框架，用于典型的软件分发和更新）。由于 Notary 仍处于发展阶段，因此目前没有很多容器编排器支持它。Notary 还需要企业中成熟的密钥管理流程。

微服务之间的安全性是可能发生渗透的另一个关键领域，API 网关可以在这种情况下得到有效利用。传统的基于 PKI 的消息安全不是可扩展的选项。相反，请考虑 JWT（JSON Web 令牌）方法。JWT 是一个编码令牌，其中包含一组关于请求者的断言策略。令牌通常由身份服务器签名，接收系统可以验证该签名。JWT 也可以进行数字加密，以维护断言的机密性和完整性（这被称为 JWE）。

通常，安全性是事后才考虑的（昂贵且困难的）。使其成为微服务基础设施的基本功能，以获得最佳的安全性和性能。