通过双向TLS保护微服务

一开始，有单体式网络应用程序。然后，随着应用程序的增长和扩展变得越来越困难，各个部分开始拆分为单独的服务。微服务已成为一种越来越流行的架构选择，用于分离关注点，同时加快开发和部署。然而，安全性仍然是一个关键但很少被谈论的部分。微服务显著增加了攻击面，因为这些服务通过网络来回发送消息，而不仅仅是在一台计算机上进行进程。微服务或任何面向服务/网络的体系结构的安全性包括两个组件：传输层和应用程序层。

传输层

强化传输层至关重要，尤其是在 AWS 或 Rackspace 等共享环境中，您无法准确确定网络流量的去向或谁可能正在监听。传输层安全性 （TLS），有时仍被错误地称为 SSL（TLS 的前身），仍然是加密和验证连接的基石之一。即使您的服务不与 HTTP（S） 或 RESTful API 通信，您仍然可以使用 TLS 包装网络套接字。

使用TLS保护所有网络流量通常是谨慎的，尽管工程师似乎经常对这样做有疑虑。如果您担心 TLS 会降低性能，负载均衡器可以提供专用硬件来有效地终止客户端 TLS 连接，同时保持对后端服务的持久 TLS 连接处于打开状态。这种持久的后端连接减少了与每个请求握手的新 TLS 连接的开销。

TLS 的一个经常被忽视的功能是身份验证。虽然 TLS 可以保证在数据在网络中移动时对其进行加密，但它也提供了一种机制来强制客户端和服务器没有中间人监听。对于面向公众的服务，您必须始终依赖公共（付费）证书颁发机构。如果您有幸同时控制服务器和每个客户端，则可以滚动自己的证书颁发机构来签署证书。

在典型的TLS握手期间，客户端和服务器交换寒暄，并小心翼翼地开始设置安全隧道。在此过程中，客户端应检查服务器提供的证书是否由受信任的颁发机构（或颁发机构链）签名。此外，许多 TLS 库允许客户端验证证书的公用名是否与其尝试连接到的主机名匹配。这两种检查都允许客户端断言服务器实际上是客户端认为它的身份，并且通信没有被拦截。

应用层

除了传输安全之外，服务还需要验证谁在拨打电话，并确保他们有权这样做。方便的是，TLS 也提供了一种机制来执行此操作：客户端不仅可以验证服务器的证书在加密上是否有效，服务器也可以类似地对客户端进行身份验证。在握手期间，服务器从客户端请求证书，它可以提供该证书。通过镜像客户端，服务器根据受信任的证书颁发机构检查证书的有效性。但是，服务器随后可以从证书中提取客户端的详细信息，例如公用名，而不是检查主机名，而是使用应用层逻辑来验证客户端是否经过身份验证并被授权执行它们正在尝试执行的操作。这种双向 TLS 身份验证允许连接的双方断言他们正在与期望的另一方连接。

双向 TLS 不经常使用，可能是由于创建和管理许多证书以及关联的吊销列表的痛点。但是，管理一组允许的证书与管理一组允许的 API 密钥非常相似。一种方法是管理一组特定的吊销证书，充当排除列表。但是，如果客户端证书被视为 API 密钥，则可以通过已知的白名单管理允许的客户端。您可以获得加密保证，即您的客户就是他们所说的人，同时还确保您的通信是加密的。

结论

双向TLS可能并不适合所有情况，但它是一个有用的工具，可以在一个人的工具箱中拥有，并且可能有助于利用您已经在使用的技术。Tinfoil的扫描仪通过双向TLS进行身份验证，以及其他网络层和应用层身份验证方法。正如您不希望应用程序出现单点故障一样，您也不想依赖单一的安全方法。

审核编辑：郭婷