如何在微服务架构中实现安全性——阅读笔记15

原文链接：https://mp.weixin.qq.com/s/jZ0wi_xDZPge5nXBjzJHKg

 

微服务架构是分布式架构。每个外部请求都由 API Gateway 和至少一个服务处理。例如，考虑 getOrderDetails() 查询。API Gateway 通过调用多个服务来处理此查询，包括 Order Service、Kitchen Service 和 Accounting Service。每项服务都必须实现安全性的某些方面。例如，Order Service 必须只允许消费者查看他们自己的订单，这需要结合身份验证和访问授权。为了在微服务架构中实现安全性，我们需要确定谁负责验证用户身份以及谁负责访问授权。

在微服务应用程序中实现安全性的一个挑战是我们不能仅仅从单体应用程序借鉴设计思路。这是因为单体应用程序的安全架构的一些方面对微服务架构来说是不可用的

处理身份验证有两种不同的方法。一种选择是让各个服务分别对用户进行身份验证。这种方法的问题在于它允许未经身份验证的请求进入内部网络。它依赖于每个开发团队在所有服务中正确实现安全性。因此，出现安全漏洞的风险和概率都很大。

在服务中实现身份验证的另一个问题是不同的客户端以不同的方式进行身份验证。纯 API 客户端使用基本身份验证为每个请求提供凭据。其他客户端可能首先登录，然后为每个请求提供会话令牌。但我们要避免在服务中处理多种不同的身份验证机制。

更好的方法是让 API Gateway 在将请求转发给服务之前对其进行身份验证。在 API Gateway 中进行集中 API 身份验证的优势在于只需要确保这里的验证是正确的。因此，出现安全漏洞的可能性要小得多。另一个好处是只有 API Gateway 需要处理各种不同的身份验证机制。这使得其他服务的实现变得简单了。

在微服务架构中实现安全性时，你需要确定 API Gateway 应使用哪种类型的令牌来将用户信息传递给服务。有两种类型的令牌可供选择。一种选择是使用不透明（无可读性）的令牌，它们通常是一串 UUID。不透明令牌的缺点是它们会降低性能和可用性，并增加延迟。因为这种令牌的接收方必须对安全服务发起同步 RPC 调用，以验证令牌并检索用户信息。

另一种消除对安全服务调用的方法是使用包含有关用户信息的透明令牌。透明令牌的一个流行的标准是 JSON Web 令牌（JWT）。JWT 是在访问双方之间安全地传递信息（例如用户身份和角色）的标准方式。JWT 的内容包含一个 JSON 对象，其中有用户的信息，例如其身份和角色，以及其他元数据，如到期日期等。它使用仅为 JWT 的创建者所知的数字签名，例如 API Gateway 和 JWT 的接收者（服务）。该签名确保恶意第三方不能伪造或篡改 JWT。