SEC09-BP03 对网络通信进行身份验证 - AWS Well-Architected 框架
实施指导资源

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

SEC09-BP03 对网络通信进行身份验证

使用支持身份验证的协议来验证通信的身份，例如传输层安全 (TLS) 或IPsec。

将您的工作负载设计为在服务和应用程序之间通信或与用户通信时，使用经过身份验证的安全网络协议。使用支持身份验证和授权的网络协议，可以加强对网络流量的控制，并减少未授权访问的影响。

期望结果：工作负载具有明确定义的数据面板和控制面板，它们控制流量在服务之间的流动。在技术上可行的情况下，流量将使用经过身份验证和加密的网络协议。

常见反模式：

  • 工作负载中存在未加密或未经身份验证的流量。

  • 在多个用户或实体之间重用身份验证凭证。

  • 仅依赖网络控制作为访问控制机制。

  • 创建自定义身份验证机制，而不是依赖行业通用身份验证机制。

  • 服务组件或其他资源之间的流量过于宽松。VPC

建立此最佳实践的好处：

  • 限制未经授权访问工作负载某一部分的影响范围。

  • 提供更高级别的保障，即操作只能由经过身份验证的实体执行。

  • 通过明确定义和强制执行预期的数据传输接口，改善服务的解耦。

  • 通过请求归因和明确定义的通信界面，增强监控、日志记录和事件响应。

  • 通过将网络控制与身份验证和授权控制相结合，为您的工作负载提供 defense-in-depth支持。

在未建立这种最佳实践的情况下暴露的风险等级：低

实施指导

您的工作负载的网络流量模式可分为两类：

  • 东西向流量代表构成工作负载的服务之间的流量。

  • 南北向流量代表您的工作负载和使用器之间的流量。

对南北向流量进行加密是常见做法，而使用经过身份验证的协议保护东西向流量则不太常见。现代安全实践建议，仅靠网络设计并不足以在两个实体之间建立可信关系。当两项服务可能位于公共网络边界内时，极佳做法仍然是对这些服务之间的通信进行加密、身份验证和授权。

例如，无论请求来自哪个网络， AWS 服务都APIs使用AWS 签名版本 4 (Sigv4) 签名协议对调用者进行身份验证。这种身份验证可确保 AWS APIs可以验证请求操作的身份，然后可以将该身份与策略结合起来，做出授权决定，以确定是否应允许该操作。

诸如 Amazon VPC Lattice 和 Amazon Gat API e way 之类的服务允许您使用相同的 SigV4 签名协议为自己工作负载中的东西向流量添加身份验证和授权。如果 AWS 环境之外的资源需要与需要基于 Sigv4 的身份验证和授权的服务通信，则可以在非AWS 资源上使用 AWS Identity and Access Management (IAM) Anywhere 角色来获取临时证书。 AWS 这些凭证可用于对使用 SigV4 的服务请求进行签名，以授权访问权限。

对东西向流量进行身份验证的另一种常用机制是TLS相互身份验证 (m)。TLS许多物联网 (IoT)、 business-to-business应用程序和微服务使用 m TLS 通过使用客户端和服务器端 X.509 证书来验证TLS通信双方的身份。这些证书可以由 AWS Private Certificate Authority (AWS Private CA) 颁发。您可以使用诸如 Amazon API Gateway 之类的服务 AWS App Mesh，为工作负载间或工作负载内的通信提供 m TLS 身份验证。虽然 m TLS 为TLS通信双方提供身份验证信息，但它不提供授权机制。

最后，OAuth2.0 和 OpenID Connect (OIDC) 是两个通常用于控制用户对服务的访问的协议，但现在在 service-to-service流量方面也越来越受欢迎。APIGat JSONeway 提供了 Web Token (JWT) 授权器，允许工作负载使用由OIDC或 OAuth 2.0 身份提供商JWTs颁发的身份提供商限制对API路由的访问。OAuth2作用域可用作基本授权决策的来源，但授权检查仍需要在应用层实现，仅靠OAuth2作用域无法支持更复杂的授权需求。

实施步骤

  • 定义和记录您的工作负载网络流：实施 defense-in-depth策略的第一步是定义工作负载的流量。

    • 创建数据流示意图，明确定义构成工作负载的不同服务之间如何传输数据。此示意图是强制这些流量通过经身份验证的网络渠道传输的第一步。

    • 在开发和测试阶段对您的工作负载进行检测，以验证数据流示意图是否准确反映了工作负载在运行时的行为。

    • 在执行威胁建模练习时，数据流图也很有用，如 SEC01-BP07 使用威胁模型识别威胁并确定缓解措施的优先顺序中所述。

  • 建立网络控制：考虑建立与您的数据流一致的网络控制 AWS 的能力。虽然网络边界不应是唯一的安全控制措施，但它们在保护工作负载的 defense-in-depth策略中提供了一个层面。

    • 使用安全组来建立、定义和限制资源之间的数据流。

    • 考虑使用AWS PrivateLink与两者 AWS 以及支持的第三方服务进行通信 AWS PrivateLink。通过 AWS PrivateLink 接口端点发送的数据保留在 AWS 网络主干中，不会通过公共互联网。

  • 在@@ 工作负载中跨服务实施身份验证和授权：选择最适合在工作负载中提供经过身份验证的加密流量的一组 AWS 服务。

  • 监控未经授权的访问：持续监控非预期的通信渠道、试图访问受保护资源的未授权主体以及其它不当访问模式。

    • 如果使用VPC莱迪思管理对服务的访问权限，请考虑启用和监控VPC莱迪思访问日志。这些访问日志包括有关请求实体的信息、网络信息（包括源和目的地VPC）以及请求元数据。

    • 考虑启用VPC流日志以捕获网络流的元数据，并定期查看异常情况。

    • 有关规划、模拟和响应AWS 安全事件的更多指导，请参阅 Well-Architecte AWS d Framework 安全支柱的《安全事件响应指南》和《事件响应》部分。

资源

相关最佳实践：

相关文档：

相关视频：

相关示例：