微服务面临的7个安全性挑战

大多数单体应用通常只有几个入口。在大多数单体应用中，安全性是集中实施的，除非有迫切的要求，否则各个组件不必担心执行额外的安全检查。

但是，微服务架构由于其固有性质，安全性极具挑战性。在此博客中，我们讨论了微服务面临的挑战，简单讨论了如何克服它们。在《微服务安全性在行动》一书中，我们讨论了应对这些挑战的多种方法。

1. 攻击面变广，攻击风险变高

在单体应用中，内部组件之间的通信在单个进程中进行–在Java应用程序中，例如，在同一Java虚拟机（JVM）中。在微服务架构下，这些内部组件被设计为单独的独立微服务，内部组件之间的那些进程内调用成为远程调用。而且，每个微服务现在都独立接受请求或拥有自己的入口点。

与具有很少入口点的单体应用相反，基于微服务的应用程序具有许多入口点，所有入口点都必须得到保护。

现在，你将拥有大量的入口点，而不是像在单体应用中那样几个入口点。随着系统入口点数量的增加，攻击面也会扩大。这种情况是为微服务构建安全设计的基本挑战之一。每个微服务的每个入口点必须以相同的强度得到保护。系统的安全性不比其最薄弱的环节强。

2. 多次安全检查，可能会导致性能不佳

与单体应用不同，微服务部署中的每个微服务都必须执行独立的安全检查。另外，在每个微服务处验证请求时，你可能需要连接到远程安全令牌服务（STS）。这些安全检查和远程连接可能会大大增加网络延迟，并大大降低系统性能。

有些人通过简单地信任网络，来避免对每个微服务进行安全检查。但是目前，网络信任已成为一种落后模式，行业正朝着网络零信任原则迈进。

3. 微服务间的信任变得复杂

除了安全性，在部署中管理10个，15个或数百个独立的微服务将有多困难？我们甚至已经开始看到微服务部署与成千上万的服务相互通信。

美国金融机构之Capital One在2019年7月宣布，其部署的微服务包括数千个容器上的数千个微服务以及数千个Amazon Elastic Compute Cloud（EC2）实例。另一家金融机构Monzo也提到，其正在运行1,500多个微服。

如果你不知道如何实现自动化，那么数千个微服务部署将非常困难。如果在容器概念不存在的时候出现了微服务概念，那么很少有人或组织有胆量采用微服务。幸运的是，事情并没有那样发生，这就是为什么我们认为微服务和容器是天造地设的一对。如果你不熟悉容器，或者不了解Docker是什么，请考虑将容器作为一种使软件分发和部署的方法。微服务和容器（Docker）在恰当的时机诞生，可以很好地相互补充。

微服务之间需要不断通信，通道中的每一个服务都必须受到保护。你有很多解决方案，但是假设你使用证书。

现在，必须为每个微服务提供一个证书（和相应的私钥），在服务到服务的交互过程中，它将用于向另一个微服务验证自己的身份。服务接收方必须知道如何验证证书。另外，你还需要能够注销证书（以防相应的私钥受到破坏）并轮换证书（定期更改证书，以最大程度地减少在不知不觉中丢失密钥的风险）。这些任务很繁琐，除非你找到一种使它们自动化的方法，否则它们在微服务部署中将是乏味的。

4. 跨多个微服务的请求更难追踪

可观察性，是根据系统的外部输出可以推断出系统内部状态的度量。日志，度量标准和跟踪被称为可观察性的三大支柱。

聚合一组日志可以产生指标。在某种程度上，指标反映了系统的状态。在安全性方面，例如，平均每小时的无效访问请求数是一个指标。较高的数值，可能表明系统受到攻击或防御能力很弱。你可以基于指标配置警报。如果对给定微服务的无效访问尝试次数超过预设的阈值，则系统可以触发警报。

跟踪也基于日志，但提供了系统的不同视角，可帮助你跟踪用户的请求。在微服务部署中，此过程变得具有挑战性。与单体应用不同，对微服务部署的请求可以通过一个微服务进入系统，并在离开系统之前跨越多个微服务。

在微服务之间的关联请求，需要依靠Jaeger和Zipkin等分布式跟踪系统。我们也可以使用Prometheus和Grafana监视微服务部署中的所有请求。

5. 服务器的不变性，导致访问控制策略更新复杂

在服务启动后不会更改服务状态的服务器称为不可变服务器。微服务最流行的部署模式是基于容器的。每个微服务都在其自己的容器中运行，并且作为最佳实践，容器必须是不可变的服务器。换句话说，在容器启动后，它不应更改其文件系统中的任何文件，也不应在容器本身内维护任何运行时状态。

期望服务器在微服务部署中是不变的，可以满足在任何时候，你都可以终止正在运行的容器并使用基本配置创建一个新容器，而不必担心运行时数据。例如，如果微服务上的负载越来越高，则需要更多服务器实例来水平扩展。因为没有一个正在运行的服务器实例维护任何运行时状态，所以你可以简单地启动一个新容器来分担负载。

不变性对安全性有何影响？为什么服务器的不变性使微服务的安全性面临挑战？

在微服务安全体系结构中，你需要维护可以访问给定微服务的白名单列表，并且需要一组访问控制策略。

这些白名单列表不是静态的，白名单中的客户端地址和访问控制策略都会随时更新。对于不可变的服务器，你无法在服务器的文件系统中维护此类更新。你需要一种方法，在服务器启动时从某种策略端点获取所有更新的策略，然后按照推或拉模型在内存中动态更新它们。在推送模型中，策略管理端将策略更新推送到微服务。在拉模型中，每个微服务都必须定期轮询策略管理端点以获取策略更新。

6. 微服务的分布式特征，使共享用户会话变得困难

在单体应用中，所有内部组件都共享同一Web会话，并且与请求方（或用户）相关的任何内容都能够从其中检索。

在微服务架构中，你无法享受那种便捷。微服务之间没有共享任何内容，并且必须将用户上下文从一个微服务显式传递到另一个微服务。挑战在于在两个微服务之间需要建立信任，以便接收从另一个微服务传递来的用户上下文。

使用JSON Web令牌（JWT）是在微服务之间共享用户上下文的一种流行方法。现在，你可以将JWT视为JSON消息，它以加密安全的方式将一组用户属性从一个微服务传递到另一个微服务。

7. 多语言架构(Polyglot),需要更多的安全专家

在微服务架构中，服务通过网络相互通信。它们不依赖于每个服务的实现方式，而是依赖于服务接口。这种情况允许每个微服务选择自己的编程语言和技术堆栈。

在多团队环境中，每个团队都开发自己的微服务集，每个团队都可以灵活地选择最适合其需求的技术堆栈。这种体系结构使系统中的各个组件能够选择最适合它们的技术堆栈，这种体系结构被称为多语言架构(Polyglot)。

多语言架构(Polyglot)使微服务安全性面临挑战。由于不同的团队使用不同的技术堆栈进行开发，因此每个团队都必须拥有自己的安全专家。这些专家需要负责实施最佳安全实践，为每个技术堆栈部署安全工具以进行静态代码分析和动态测试，并将这些工具集成到构建过程中。

译文链接：https://dzone.com/articles/challenges-of-securing-microservices