# SEC09-BP03 对网络通信进行身份验证
<a name="sec_protect_data_transit_authentication"></a>

 使用传输层安全性协议（TLS）或 IPsec 等支持身份验证的协议来验证通信的身份。

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

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

 **常见反模式：**
+  工作负载中存在未加密或未经身份验证的流量。
+  在多个用户或实体之间重用身份验证凭证。
+  仅依赖网络控制作为访问控制机制。
+  创建自定义身份验证机制，而不是依赖行业通用身份验证机制。
+  VPC 中的服务组件或其它资源之间有过于宽松的流量流动。

 **建立此最佳实践的好处：**
+  限制未经授权访问工作负载某一部分的影响范围。
+  提供更高级别的保障，即操作只能由经过身份验证的实体执行。
+  通过明确定义和强制执行预期的数据传输接口，改善服务的解耦。
+  通过请求归因和明确定义的通信界面，增强监控、日志记录和事件响应。
+  通过将网络控制与身份验证和授权控制相结合，为您的工作负载提供深度防御。

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

## 实施指导
<a name="implementation-guidance"></a>

 您的工作负载的网络流量模式可分为两类：
+  *东西向流量*代表构成工作负载的服务之间的流量。
+  *南北向流量*代表您的工作负载和使用器之间的流量。

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

 例如，无论请求来自哪个网络，AWS 服务 API 都使用 [AWS 签名版本 4（SigV4）](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html)签名协议对调用方进行身份验证。这种身份验证可确保 AWS API 可以验证请求操作的身份，然后可以将该身份与策略结合起来，作出授权决策，以确定是否应该允许该操作。

 [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/access-management-overview.html) 和 [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html) 等服务允许您使用相同的 SigV4 签名协议，为自己的工作负载中的东西向流量添加身份验证和授权。如果您的 AWS 环境之外的资源要与服务进行通信，而服务需要基于 SigV4 的身份验证和授权，则您可以对非 AWS 资源使用 [AWS Identity and Access Management（IAM）Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 来获取临时 AWS 凭证。这些凭证可用于对使用 SigV4 的服务请求进行签名，以授权访问权限。

 验证东西向流量的另一种常见机制是 TLS 双向身份验证（mTLS）。许多物联网（IoT）、企业对企业应用程序和微服务都使用 mTLS，通过使用客户端和服务器端 X.509 证书来验证 TLS 通信两端的身份。这些证书可以由 AWS 私有证书颁发机构（AWS 私有 CA）颁发。可以使用 [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) 等服务，针对工作负载间或工作负载内的通信提供 mTLS 身份验证。[应用程序负载均衡器还支持将 mTLS](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html) 用于内部或外部工作负载。虽然 mTLS 为 TLS 通信的两端提供身份验证信息，但它不提供授权机制。

 最后，OAuth 2.0 和 OpenID Connect（OIDC）这两种协议通常用于控制用户对服务的访问，但如今在服务间流量中也变得越来越流行。API Gateway 提供了 [JSON Web 令牌（JWT）授权方](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html)，允许工作负载使用 OIDC 或 OAuth 2.0 身份提供商颁发的 JWT 来限制对 API 路由的访问。可依据 OAuth2 范围来作出基本授权决策，但授权检查仍需要在应用层实现，仅靠 OAuth2 范围无法支持更复杂的授权需求。

### 实施步骤
<a name="implementation-steps"></a>
+  **定义并记录您的工作负载网络流：**实施深度防御策略的第一步是定义工作负载的流量。
  +  创建数据流示意图，明确定义构成工作负载的不同服务之间如何传输数据。此示意图是强制这些流量通过经身份验证的网络渠道传输的第一步。
  +  在开发和测试阶段对您的工作负载进行检测，以验证数据流示意图是否准确反映了工作负载在运行时的行为。
  +  在执行威胁建模练习时，数据流示意图可能也很有用，如《[SEC01-BP07 使用威胁模型识别威胁并确定缓解措施的优先级](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html)》中所述。
+  **建立网络控制：**考虑使用 AWS 功能建立起与数据流相符的网络控制。虽然网络边界不应该是唯一的安全控制措施，但它们在深度防御策略中提供了一个安全层来保护您的工作负载。
  +  使用[安全组](https://docs.aws.amazon.com/vpc/latest/userguide/security-groups.html)来建立、定义和限制资源之间的数据流。
  +  考虑使用 [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) 与 AWS 以及支持 AWS PrivateLink 的第三方服务通信。通过 AWS PrivateLink 接口端点发送的数据保留在 AWS 网络主干内，而不通过公共互联网传输。
+  **在工作负载中实施跨服务的身份验证和授权：**选择极其适合在工作负载中提供经过身份验证的加密流量的一组 AWS 服务。
  +  考虑使用 [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html) 来保护服务间的通信。VPC Lattice 可以结合使用 [Sigv4 身份验证与身份验证策略](https://docs.aws.amazon.com/vpc-lattice/latest/ug/auth-policies.html)来控制服务间的访问。
  +  对于使用 mTLS 进行的服务间通信，请考虑使用 [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) 和[应用程序负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html)。[AWS 私有 CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) 可用于建立私有 CA 层次结构，该层次结构能够颁发与 mTLS 结合使用的证书。
  +  与使用 OAuth 2.0 或 OIDC 的服务集成时，可以考虑[使用 JWT 授权方的 API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html)。
  +  对于工作负载和物联网设备之间的通信，可以考虑使用 [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/client-authentication.html)，它提供多种网络流量加密和身份验证选项。
+  **监控未经授权的访问：**持续监控非预期的通信渠道、试图访问受保护资源的未授权主体以及其它不当访问模式。
  +  如果使用 VPC Lattice 来管理对服务的访问，请考虑启用和监控 [VPC Lattice 访问日志](https://docs.aws.amazon.com/vpc-lattice/latest/ug/monitoring-access-logs.html)。这些访问日志包括有关请求实体的信息、源和目的地 VPC 等网络信息以及请求元数据。
  +  考虑启用 [VPC 流日志](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)，以捕获网络流量的元数据并定期检查是否存在异常。
  +  有关规划、模拟和响应安全事件的更多指导，请参阅《[AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)》和 AWS Well-Architected Framework 安全性支柱的[“事件响应”部分](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html)。

## 资源
<a name="resources"></a>

 **相关最佳实践：**
+ [ SEC03-BP07 分析公共和跨账户访问 ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [ SEC02-BP02 使用临时凭证 ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [ SEC01-BP07 使用威胁模型识别威胁并确定缓解措施的优先级 ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html)

 **相关文档：**
+ [ Evaluating access control methods to secure Amazon API Gateway APIs ](https://aws.amazon.com/blogs/compute/evaluating-access-control-methods-to-secure-amazon-api-gateway-apis/)
+ [ Configuring mutual TLS authentication for a REST API ](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html)
+ [ How to secure API Gateway HTTP endpoints with JWT authorizer ](https://aws.amazon.com/blogs/security/how-to-secure-api-gateway-http-endpoints-with-jwt-authorizer/)
+ [ Authorizing direct calls to AWS services using AWS IoT Core credential provider ](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html)
+ 《[AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)》

 **相关视频：**
+ [AWS re:invent 2022: Introducing VPC Lattice ](https://www.youtube.com/watch?v=fRjD1JI0H5w)
+ [AWS re:invent 2020: Serverless API authentication for HTTP APIs on AWS](https://www.youtube.com/watch?v=AW4kvUkUKZ0)

 **相关示例：**
+ [ Amazon VPC Lattice Workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/9e543f60-e409-43d4-b37f-78ff3e1a07f5/en-US)
+ [ Zero-Trust Episode 1 – The Phantom Service Perimeter workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/dc413216-deab-4371-9e4a-879a4f14233d/en-US)