Question

虽然本章介绍了 OAuth2 规范，以及如何使用 Spring Cloud Security 实现 OAuth2 验证服务，但 OAuth2 只是微服务安全难题的一部分。在构建用于生产级别的微服务时，应该围绕以下实践构建微服务安全。

（1）对所有服务通信使用 HTTPS/安全套接字层（Secure Sockets Layer，SSL）。

（2）所有服务调用都应通过 API 网关。

（3）将服务划分到公共 API 和私有 API。

（4）通过封锁不需要的网络端口来限制微服务的攻击面。

图 7-13 展示了这些不同的实践如何配合起来工作。上述列表中的每个编号项都与图 7-13 中的数字对应。

图 7-13 微服务安全架构不只是实现 OAuth2

让我们更详细地审查前面列表和图 7-13 中列出的每个主题领域。

1．为所有业务通信使用 HTTPS/安全套接字层（SSL）

在本书的所有代码示例中，我们一直使用 HTTP，这是因为 HTTP 是一个简单的协议，并且不需要在每个服务上进行安装就能开始使用该服务。

在生产环境中，微服务应该只通过 HTTPS 和 SSL 提供的加密通道进行通信。HTTPS 的配置和安装可以通过 DevOps 脚本自动完成。

注意

如果应用程序需要满足信用卡支付的支付卡行业（Payment Card Industry，PCI）的合规性要求，那么就需要为所有的服务通信实现 HTTPS。在构建服务时，要尽早就使用 HTTPS，这要比将应用程序和微服务部署到生产环境之后再进行项目迁移容易得多。

2．使用服务网关访问微服务

客户端永远不应该直接访问运行服务的各个服务器、服务端点和端口。相反，应该使用服务网关作为服务调用的入口点和守门人。在微服务运行的操作系统或容器上配置网络层，以便仅接受来自服务网关的流量。

记住，服务网关可以作为一个针对所有服务执行的策略执行点（PEP）。通过像 Zuul 这样的服务网关来进行服务调用，让开发人员可以在保护和审计服务方面保持一致。服务网关还允许开发人员锁定要向外界公开的端口和端点。

3．将服务划分到公共 API 和私有 API

一般来说，安全是关于构建访问和执行最小权限概念的层。最小权限是用户应该拥有最少的网络访问权限和特权来完成他们的日常工作。为此，开发人员应该通过将服务分离到两个不同的区域（即公共区域和私有区域）来实现最小权限。

公共区域包含由客户端使用的公共 API（EagleEye 应用程序）。公共 API 微服务应该执行面向工作流的小任务。公共 API 微服务通常是服务聚合器，在多个服务中提取数据并执行任务。

公共微服务应该位于它们自己的服务网关后面，并拥有自己的验证服务来执行 OAuth2 验证。客户端应用程序应该通过受服务网关保护的单一路由访问公共服务。此外，公共区域应该有自己的验证服务。

私有区域充当保护核心应用程序功能和数据的壁垒，它应该只通过一个众所周知的端口访问，并且应该被封锁，只接受来自运行私有服务的网络子网的网络流量。除此之外，私有区域应该拥有自己的服务网关和验证服务。公共 API 服务应该对私有区域验证服务进行验证。所有的应用程序数据至少应该在私有区域的网络子网中，并且只能通过驻留在私有区域的微服务访问。

私有 API 网络区域应该要被封锁到什么程度

许多组织采取的方法是，他们的安全模型应该有一个坚硬的外在中心，但拥有一个更柔软的内表面。这意味着，一旦流量进入私有 API 区域，私有区域中的服务之间的通信就可以不加密（不需要 HTTPS），也不需要验证机制。大多数时候，这都是为了方便和加快开发。拥有的安全性越高，调试问题的难度就越大，从而增加管理应用程序的整体复杂性。

我倾向于对这个世界抱有一种偏执的看法。（我在金融服务行业工作了 8 年，因此自然而然地变得多疑。）我宁愿牺牲额外的复杂性（可以通过 DevOps 脚本来减轻这种复杂性），强制在私有 API 区域中运行的所有服务都使用 SSL，并通过私有区域中运行的验证服务进行验证。读者需要问自己的问题是，是否愿意看到自己的组织因为遭受网络入侵而登上当地报纸的头版？

4．通过封锁不需要的网络端口来限制微服务的攻击面

许多开发人员并没有重视为了使服务正常运行而需要打开的端口的最少数量。请配置运行服务的操作系统，只允许打开入站和出站访问服务所需的端口，或者服务所需的一部分基础设施（监视、日志聚合）。

不要只关注入站访问端口。许多开发人员忘记了封锁他们的出站端口。封锁出站端口可以防止数据在服务本身被攻击者破坏的情况下从服务中泄露。另外，要确保查看公共 API 区域和私有 API 区域中的网络端口访问。