SEC09-BP03 对网络通信进行身份验证
使用传输层安全性协议(TLS)或 IPsec 等支持身份验证的协议来验证通信的身份。
将您的工作负载设计为在服务和应用程序之间通信或与用户通信时,使用经过身份验证的安全网络协议。使用支持身份验证和授权的网络协议,可以加强对网络流量的控制,并减少未授权访问的影响。
期望结果:工作负载具有明确定义的数据面板和控制面板,它们控制流量在服务之间的流动。在技术上可行的情况下,流量将使用经过身份验证和加密的网络协议。
常见反模式:
-
工作负载中存在未加密或未经身份验证的流量。
-
在多个用户或实体之间重用身份验证凭证。
-
仅依赖网络控制作为访问控制机制。
-
创建自定义身份验证机制,而不是依赖行业通用身份验证机制。
-
VPC 中的服务组件或其它资源之间有过于宽松的流量流动。
建立此最佳实践的好处:
-
限制未经授权访问工作负载某一部分的影响范围。
-
提供更高级别的保障,即操作只能由经过身份验证的实体执行。
-
通过明确定义和强制执行预期的数据传输接口,改善服务的解耦。
-
通过请求归因和明确定义的通信界面,增强监控、日志记录和事件响应。
-
通过将网络控制与身份验证和授权控制相结合,为您的工作负载提供深度防御。
在未建立这种最佳实践的情况下暴露的风险等级:低
实施指导
您的工作负载的网络流量模式可分为两类:
-
东西向流量代表构成工作负载的服务之间的流量。
-
南北向流量代表您的工作负载和使用器之间的流量。
对南北向流量进行加密是常见做法,而使用经过身份验证的协议保护东西向流量则不太常见。现代安全实践建议,仅靠网络设计并不足以在两个实体之间建立可信关系。当两项服务可能位于公共网络边界内时,极佳做法仍然是对这些服务之间的通信进行加密、身份验证和授权。
例如,无论请求来自哪个网络,AWS 服务 API 都使用 AWS 签名版本 4(SigV4)签名协议对调用方进行身份验证。这种身份验证可确保 AWS API 可以验证请求操作的身份,然后可以将该身份与策略结合起来,作出授权决策,以确定是否应该允许该操作。
Amazon VPC Lattice 和 Amazon API Gateway 等服务允许您使用相同的 SigV4 签名协议,为自己的工作负载中的东西向流量添加身份验证和授权。如果您的 AWS 环境之外的资源要与服务进行通信,而服务需要基于 SigV4 的身份验证和授权,则您可以对非 AWS 资源使用 AWS Identity and Access Management(IAM)Roles Anywhere 来获取临时 AWS 凭证。这些凭证可用于对使用 SigV4 的服务请求进行签名,以授权访问权限。
验证东西向流量的另一种常见机制是 TLS 双向身份验证(mTLS)。许多物联网(IoT)、企业对企业应用程序和微服务都使用 mTLS,通过使用客户端和服务器端 X.509 证书来验证 TLS 通信两端的身份。这些证书可以由 AWS Private Certificate Authority(AWS Private CA)颁发。可以使用 Amazon API Gateway 等服务,针对工作负载间或工作负载内的通信提供 mTLS 身份验证。应用程序负载均衡器还支持将 mTLS 用于内部或外部工作负载。虽然 mTLS 为 TLS 通信的两端提供身份验证信息,但它不提供授权机制。
最后,OAuth 2.0 和 OpenID Connect(OIDC)这两种协议通常用于控制用户对服务的访问,但如今在服务间流量中也变得越来越流行。API Gateway 提供了 JSON Web 令牌(JWT)授权方,允许工作负载使用 OIDC 或 OAuth 2.0 身份提供商颁发的 JWT 来限制对 API 路由的访问。可依据 OAuth2 范围来作出基本授权决策,但授权检查仍需要在应用层实现,仅靠 OAuth2 范围无法支持更复杂的授权需求。
实施步骤
-
定义并记录您的工作负载网络流:实施深度防御策略的第一步是定义工作负载的流量。
-
创建数据流示意图,明确定义构成工作负载的不同服务之间如何传输数据。此示意图是强制这些流量通过经身份验证的网络渠道传输的第一步。
-
在开发和测试阶段对您的工作负载进行检测,以验证数据流示意图是否准确反映了工作负载在运行时的行为。
-
在执行威胁建模练习时,数据流示意图可能也很有用,如《SEC01-BP07 使用威胁模型识别威胁并确定缓解措施的优先级》中所述。
-
-
建立网络控制:考虑使用 AWS 功能建立起与数据流相符的网络控制。虽然网络边界不应该是唯一的安全控制措施,但它们在深度防御策略中提供了一个安全层来保护您的工作负载。
-
使用安全组来建立、定义和限制资源之间的数据流。
-
考虑使用 AWS PrivateLink 与 AWS 以及支持 AWS PrivateLink 的第三方服务通信。通过 AWS PrivateLink 接口端点发送的数据保留在 AWS 网络主干内,而不通过公共互联网传输。
-
-
在工作负载中实施跨服务的身份验证和授权:选择极其适合在工作负载中提供经过身份验证的加密流量的一组 AWS 服务。
-
考虑使用 Amazon VPC Lattice 来保护服务间的通信。VPC Lattice 可以结合使用 Sigv4 身份验证与身份验证策略来控制服务间的访问。
-
对于使用 mTLS 进行的服务间通信,请考虑使用 API Gateway 和应用程序负载均衡器。AWS Private CA 可用于建立私有 CA 层次结构,该层次结构能够颁发与 mTLS 结合使用的证书。
-
与使用 OAuth 2.0 或 OIDC 的服务集成时,可以考虑使用 JWT 授权方的 API Gateway。
-
对于工作负载和物联网设备之间的通信,可以考虑使用 AWS IoT Core,它提供多种网络流量加密和身份验证选项。
-
-
监控未经授权的访问:持续监控非预期的通信渠道、试图访问受保护资源的未授权主体以及其它不当访问模式。
-
如果使用 VPC Lattice 来管理对服务的访问,请考虑启用和监控 VPC Lattice 访问日志。这些访问日志包括有关请求实体的信息、源和目的地 VPC 等网络信息以及请求元数据。
-
考虑启用 VPC 流日志,以捕获网络流量的元数据并定期检查是否存在异常。
-
有关规划、模拟和响应安全事件的更多指导,请参阅《AWS Security Incident Response Guide》和 AWS Well-Architected Framework 安全性支柱的“事件响应”部分。
-
资源
相关最佳实践:
相关文档:
相关视频:
相关示例: