微服务安全

介绍¶

微服务架构越来越多地用于在基于云的和本地基础设施、大规模应用程序和服务中设计和实现应用程序系统。在应用程序设计和实施阶段需要解决许多安全挑战。在设计阶段必须解决的基本安全要求是身份验证和授权。因此，对于应用程序安全架构师来说，理解和正确使用现有架构模式在基于微服务的系统中实现身份验证和授权至关重要。本备忘单的目标是识别此类模式，并为应用程序安全架构师提供有关使用它的可能方式的建议。

边缘级授权¶

在简单的场景中，授权只能发生在边缘级别（API 网关）。API 网关可用于集中执行所有下游微服务的授权，无需为每个单独的服务提供身份验证和访问控制。在这种情况下，NIST 建议实施缓解控制，例如相互身份验证，以防止与内部服务的直接匿名连接（API 网关绕过）。需要注意的是，边缘层的授权有以下限制：

• 在具有许多角色和访问控制规则的复杂生态系统中，将所有授权决策推送到 API 网关会很快变得难以管理；
• API网关可能成为单点决策，违反“纵深防御”原则；
• 运营团队通常拥有 API 网关，因此开发团队无法直接进行授权更改，由于额外的通信和流程开销而减慢了速度。

在大多数情况下，开发团队在两个地方都实施授权——在边缘级别，在粗略的粒度级别和服务级别。验证外部实体边缘可以使用通过 HTTP 标头（例如“Cookie”或“授权”）传输的访问令牌（引用令牌或自包含令牌）或使用 mTLS。

服务级别授权¶

服务级别授权为每个微服务提供了更多控制权来执行访问控制策略。为了进一步讨论，我们使用符合NIST SP 800-162的术语和定义。门禁系统的功能组件可分为以下几种方式：

• Policy Administration Point (PAP) 提供了一个用于创建、管理、测试和调试访问控制规则的用户界面；
• 策略决策点 (PDP) 通过评估适用的访问控制策略来计算访问决策；
• 策略执行点 (PEP) 执行策略决策以响应主体请求访问受保护对象的请求；
• 策略信息点 (PIP) 用作属性的检索源，或策略评估所需的数据，以提供 PDP 做出决策所需的信息。

NIST ABAC 框架

服务级别授权：现有模式¶

去中心化模式¶

开发团队直接在微服务代码级别实现 PDP 和 PEP。所有访问控制规则以及需要实现该规则的属性都定义并存储在每个微服务上（步骤 1）。当微服务收到（步骤 2）请求以及一些授权元数据（例如，最终用户上下文或请求的资源 ID）时，微服务对其进行分析（步骤 3）以生成访问控制策略决策，然后执行授权（步骤 4）。

去中心化模式HLD

现有的编程语言框架允许开发团队在微服务层实现授权。例如，Spring Security 允许开发人员在资源服务器中启用范围检查（例如，使用从传入 JWT 中提取的范围）并使用它来强制授权。在源代码级别实现授权意味着无论何时开发团队想要修改授权逻辑，都必须更新代码。

具有单一策略决策点的集中式模式¶

在该模式中，访问控制规则被集中定义、存储和评估。访问控制规则使用 PAP 定义（步骤 1）并交付给集中式 PDP 以及需要实施该规则的属性（步骤 2）。当主体调用微服务端点（步骤 3）时，微服务代码通过网络调用调用集中式 PDP，PDP 通过根据访问控制规则和属性评估查询输入来生成访问控制策略决策（步骤 4）。基于 PDP 决策微服务强制授权（步骤 5）。

具有单个策略决策点 HLD 的集中式模式

要定义访问控制规则，开发/运营团队必须使用某种语言或符号。一个例子是可扩展访问控制标记语言 (XACML) 和下一代访问控制 (NGAC)，它是实现策略规则描​​述的标准。由于远程 PDP 端点的额外网络调用，这种模式会严重影响延迟，但可以通过在微服务级别缓存授权策略决策来缓解这种情况。值得一提的是，由于弹性和可用性问题，PDP 必须在高可用性模式下运行。应用程序安全架构师应将其与其他模式（例如，API 网关级别的授权）结合起来，以实施“纵深防御”原则。

具有嵌入式策略决策点的集中式模式¶

在该模式中，访问控制规则是集中定义的，但在微服务级别存储和评估。访问控制规则使用 PAP 定义（步骤 1）并交付给嵌入式 PDP 以及需要实施该规则的属性（步骤 2）。当主体调用微服务端点（步骤 3）时，微服务代码调用 PDP，PDP 通过根据访问控制规则和属性评估查询输入来生成访问控制策略决策（步骤 4）。基于 PDP 决策微服务强制授权（步骤 5）。

具有嵌入式策略决策点 HLD 的集中式模式

在这种情况下，PDP 代码可以实现为微服务内置库或服务网格架构中的 sidecar。由于可能的网络/主机故障和网络延迟，建议在具有微服务的同一主机上将嵌入式 PDP 实现为微服务库或 sidecar。嵌入式 PDP 通常将授权策略和与策略相关的数据存储在内存中，以最大限度地减少授权执行期间的外部依赖性并获得低延迟。与缓存方法的“单一策略决策点的集中模式”的主要区别在于授权决策不存储在微服务端，而是将最新的授权策略存储在微服务端。应该提到的是，缓存授权决策可能会导致应用过时的授权规则和访问控制违规。呈现的网络修复 (link , link ) 一个使用“Centralized Pattern with Embedded PDP”模式实现微服务级别授权的真实案例。

具有嵌入式策略决策点 HLD 的集中式模式

• 策略门户和策略存储库是基于 UI 的系统，用于创建、管理和版本化访问控制规则；
• 聚合器从所有外部来源获取访问控制规则中使用的数据并保持最新；
• Distributor 拉取访问控制规则（来自 Policy 存储库）和访问控制规则中使用的数据（来自 Aggregators），以在 PDP 之间分发；
• PDP（库）异步拉取访问控制规则和数据并使其保持最新以强制执行 PEP 组件的授权。

关于如何实施授权的建议¶

1. 为了实现可扩展性，不建议在源代码中硬编码授权策略（分散模式），而是使用特殊语言来表达策略。目标是将授权与代码外部化/分离，而不仅仅是使用充当检查点的网关/代理。服务级别授权的推荐模式是“具有嵌入式 PDP 的集中式模式”，因为它具有弹性和广泛采用。
2. 授权方案应该是平台级方案；专门的团队（例如平台安全团队）必须负责授权解决方案的开发和运营，以及在开发团队之间共享实现授权的微服务蓝图/库/组件。
3. 授权解决方案应基于广泛使用的解决方案，因为实施自定义解决方案具有以下缺点：
   • 安全或工程团队必须构建和维护自定义解决方案；
   • 有必要为系统架构中使用的每种语言构建和维护客户端库 SDK；
   • 有必要对每个开发人员进行自定义授权服务 API 和集成方面的培训，并且没有开源社区可以从中获取信息。
4. 有可能不是所有的访问控制策略都可以通过网关/代理和共享授权库/组件来执行，因此一些特定的访问控制规则仍然必须在微服务业务代码级别实现。为了做到这一点，建议微服务开发团队拥有和使用简单的问题/检查表来发现此类安全要求并在微服务开发期间正确处理。
5. 建议在以下方面实施“纵深防御”原则强制授权：
   • 粗粒度级别的网关和代理级别；
   • 微服务级别使用共享授权库/组件来执行精细授权的决策；
   • 微服务业务代码级别实现业务特定的访问控制规则。
6. 必须实施访问控制政策正式程序，如开发、批准、推出。

外部实体身份传播¶

要在微服务级别做出精细授权决策，微服务必须了解调用者上下文（例如用户 ID、用户角色/组）。为了允许内部服务层强制执行授权，边缘层必须将经过身份验证的外部实体身份（例如，最终用户上下文）连同对下游微服务的请求一起传播。传播外部实体身份的最简单方法之一是重用边缘接收到的访问令牌并将其传递给内部微服务。应该提到的是，由于可能存在外部访问令牌泄漏，这种方法非常不安全，并且可能会减少攻击面，因为通信依赖于基于专有令牌的系统实现，并且内部微服务必须了解外部访问令牌。这种模式也不是外部访问令牌不可知的，即

身份传播：现有模式¶

将外部实体身份作为明文或自签名数据结构发送¶

在这种方法中，调用微服务从传入的请求中提取外部实体身份（例如，通过解析传入的访问令牌），创建带有上下文的数据结构（例如 JSON 或自签名 JWT），并将其传递给内部微服务。在这种情况下，接收者微服务必须信任调用微服务——如果调用微服务想要违反访问控制规则，它可以通过将任何用户/客户端 ID 或用户角色设置为 HTTP 标头来实现。该方法适用于高度可信的环境，其中每个微服务都是由可信的开发团队根据安全的软件开发实践开发的。

明文 ID 传播

使用由受信任的发行者签名的数据结构¶

在此模式中，在边缘层的身份验证服务对外部请求进行身份验证后，代表外部实体身份的数据结构（例如，包含的用户 ID、用户角色/组或权限）由受信任的颁发者生成、签名或加密并传播到内部微服务。

签名 ID 传播

Netflix 展示了一个使用该模式的真实案例：名为“Passport”的结构包含用户 ID 及其属性，并且在边缘级别为每个传入请求创建受 HMAC 保护的结构，传播到内部微服务并且从不暴露于外部：

1. 边缘身份验证服务 (EAS) 从密钥管理系统获取密钥。
2. EAS 从传入的请求中接收访问令牌（例如可能在 cookie、JWT、OAuth2 令牌中）。
3. EAS 解密访问令牌，解析外部实体身份并将其发送到签名的“Passport”结构中的内部服务。
4. 内部服务可以提取用户身份，以便使用包装器执行授权（例如实现基于身份的授权）。
5. 如有必要，内部服务可以将“Passport”结构传播到调用链中的下游服务。

Netflix ID 传播方法

应该提到的是，模式与外部访问令牌无关，并且允许将外部实体及其内部表示解耦。

关于如何实施身份传播的建议¶

1. 为了实现与外部访问令牌无关且可扩展的系统，将针对外部实体发布的访问令牌与其内部表示分离。使用单一数据结构在微服务之间表示和传播外部实体身份。边缘级服务必须验证传入的外部访问令牌，发布内部实体表示结构并将其传播到下游服务。
2. 使用由受信任的发行者签名的内部实体表示结构（对称或非对称加密）是社区采用的推荐模式。
3. 内部实体表示结构应该是可扩展的，以允许添加更多可能导致低延迟的声明。
4. 内部实体表示结构不得暴露在外部（例如，浏览器或外部设备）。

服务到服务身份验证¶

现有模式¶

相互传输层安全¶

在 mTLS 方法中，除了实现传输数据的机密性和完整性之外，每个微服务都可以合法地识别它与谁交谈。部署中的每个微服务都必须携带一个公钥/私钥对，并使用该密钥对通过 mTLS 对接收方微服务进行身份验证。 mTLS 通常使用自托管的公钥基础设施来实现。使用 mTLS 的主要挑战是：密钥配置和信任引导、证书撤销和密钥轮换。

基于令牌¶

基于令牌的方法适用于应用层。Token 是一个容器，可能包含调用者 ID（微服务 ID）及其权限（范围）。调用者微服务可以通过使用自己的服务 ID 和密码调用特殊的安全令牌服务来获取签名令牌，然后将其附加到每个传出请求，例如通过 HTTP 标头。被调用的微服务可以提取令牌并在线或离线验证它。

签名 ID 传播

1. 线上场景：
   • 验证传入令牌微服务通过网络调用调用集中式服务令牌服务；
   • 可以检测到已撤销（受损）的令牌
   • 高延迟
   • 应该适用于关键请求
2. 离线场景：
   • 验证传入令牌微服务使用下载的服务令牌服务公钥；
   • 可能无法检测到已撤销（受损）的令牌
   • 低延迟
   • 应该应用于非关键请求在大多数情况下，基于令牌的身份验证通过 TLS 工作，提供传输中数据的机密性和完整性。

日志记录¶

基于微服务的系统中的日志服务旨在满足问责制和可追溯性的原则，并通过日志分析帮助检测操作中的安全异常。因此，对于应用程序安全架构师来说，了解并充分利用现有架构模式在基于微服务的系统中实现审计日志记录以进行安全操作至关重要。高级架构设计如下图所示，基于以下原则：

• 微服务使用标准输出（通过 stdout、stderr）将日志消息写入本地文件
• 日志代理定期提取日志消息并将它们发送（发布）到消息代理（例如，NATS、Apache Kafka）；
• 中央日志服务订阅消息代理中的消息，接收并处理它们。

记录模式

下面列出了对日志子系统架构及其基本原理的高级建议。

1. 微服务不应使用网络通信将日志消息直接发送到中央日志子系统。微服务应将其日志消息写入本地日志文件：
   • 这可以减轻由于攻击导致日志服务失败或合法微服务泛滥导致数据丢失的威胁：在日志服务中断的情况下，微服务仍会将日志消息写入本地文件（不会丢失数据），记录服务恢复日志后将可用于运输；
2. 应该有一个与微服务分离的专用组件（日志代理）。日志代理应收集微服务上的日志数据（读取本地日志文件）并将其发送到中央日志子系统。由于可能存在的网络延迟问题，日志代理应与微服务部署在同一主机（虚拟机或物理机）上：
   • 这可以减轻由于攻击导致日志服务失败或合法微服务泛滥而导致数据丢失的威胁
   • 在日志代理失败的情况下，微服务仍然会将信息写入日志文件，恢复后的日志代理会读取该文件并将信息发送给消息代理；
3. 对中央日志子系统日志代理的可能 DoS 攻击不应使用异步请求/响应模式来发送日志消息。应该有一个消息代理来实现日志代理和中央日志服务之间的异步连接：
   • 这允许在合法微服务泛滥的情况下减轻由于日志记录服务故障而导致数据丢失的威胁
   • 在日志服务中断的情况下，在日志服务恢复日志可以发货后，微服务仍会将日志消息写入本地文件（不会丢失数据）；
4. 日志代理和消息代理应使用相互身份验证（例如，基于 TLS）来加密所有传输的数据（日志消息）并对其自身进行身份验证：
   • 这允许减轻威胁：微服务欺骗、日志/传输系统欺骗、网络流量注入、嗅探网络流量
5. 消息代理应执行访问控制策略以减少未经授权的访问并实施最小权限原则：
   • 这可以减轻微服务特权提升的威胁
6. 日志代理应过滤/清理输出日志消息到敏感数据（例如，PII、密码、API 密钥）永远不会发送到中央日志子系统（数据最小化原则）。
7. 微服务应生成唯一标识每个调用链的相关 ID，并帮助分组日志消息对其进行调查。日志代理应在每条日志消息中包含一个相关 ID。
8. 日志代理应定期提供健康和状态数据以指示其可用性或不可用性。
9. 日志代理应以结构化日志格式（例如 JSON、CSV）发布日志消息。
10. 日志代理应附加带有上下文数据的日志消息，例如平台上下文（主机名、容器名）、运行时上下文（类名、文件名）。