Machine-to-machine 身份管理 - AWS 规范性指导
EC2 实例配置文件授予亚马逊 Cognito 客户证书mTLS 连接IAM Roles Anywhere

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

Machine-to-machine 身份管理

Machine-to-machine (M2M) 身份验证使在 AWS 上运行的服务和应用程序能够安全地相互通信以访问资源和数据。计算机身份验证系统不使用长期静态凭证，而是发布临时凭证或令牌来识别可信计算机。它们允许精确控制哪些机器可以在没有人为干预的情况下进入环境的特定部分。精心设计的计算机身份验证通过限制广泛的凭据泄露、启用动态撤销权限和简化凭证轮换，有助于改善您的安全状况。机器身份验证的典型方法包括 EC2 实例配置文件、授予的 Amazon Cognito 客户端证书、相互身份验证的 TLS (mTLS) 连接和 IAM Anywhere 角色。本节提供有关在 AWS 上实施安全且可扩展的 M2M 身份验证流程的指导。

EC2 实例配置文件

如果您在亚马逊弹性计算云 (Amazon EC2) 上运行的应用程序或服务需要调用 AWS APIs，请考虑使用 EC2 实例配置文件。实例配置文件允许在 EC2 实例上运行的应用程序安全地访问其他 AWS 服务，而无需使用寿命长的静态 IAM 访问密钥。相反，您应该为您的实例分配一个 IAM 角色，以便通过实例配置文件提供所需的权限。然后，该 EC2 实例可以自动从实例配置文件中获取临时安全证书，以访问其他 AWS 服务。 

下图阐明了此方案。

使用 EC2 实例配置文件进行 machine-to-machine身份管理

  1. EC2 实例上需要调用 AWS API 的应用程序会从实例元数据项iam/security-credentials/<role-name>中检索该角色提供的安全证书。 

  2. 应用程序会收到AccessKeyIdSecretAccessKey、和一个可用于签署 AWS API 请求的密钥令牌。

  3. 该应用程序调用 AWS API。如果角色允许 API 操作，则请求成功。

要了解有关在 AWS 资源中使用临时证书的更多信息，请参阅 IAM 文档中的在 AWS 资源中使用临时证书。

优点

  • 提高了安全性。此方法可避免向 EC2 实例分发长期证书。凭证是通过实例配置文件临时提供的。 

  • 易于集成。在实例上运行的应用程序无需任何额外的编码或配置即可自动获取证书。AWS SDKs 会自动使用实例配置文件证书。

  • 动态权限。您可以通过更新分配给实例配置文件的 IAM 角色来更改实例可用的权限。系统会自动获取反映更新后的权限的新证书。 

  • 旋转。AWS 会自动轮换临时证书，以降低凭证泄露的风险。 

  • 撤销。您可以通过从实例配置文件中删除角色分配来立即撤消证书。

设计注意事项

  • 一个 EC2 实例只能有一个附加的实例配置文件。

  • 使用权限最低的 IAM 角色。仅向实例配置文件的 IAM 角色分配应用程序所需的权限。从最低权限开始，然后根据需要添加更多权限。 

  • 在角色策略中使用 IAM 条件根据标签、IP 地址范围、一天中的时间等限制权限。这限制了应用程序可以访问的服务和资源。

  • 考虑一下您需要多少实例配置文件。在一个 EC2 实例上运行的所有应用程序共享相同的配置文件并具有相同的 AWS 权限。您可以将相同的实例配置文件应用于多个 EC2 实例，因此您可以通过在适当时重复使用实例配置文件来减少管理开销。

  • 监控活动。使用 AWS CloudTrail 等工具监控使用实例配置文件证书的 API 调用。注意可能表明凭据遭到泄露的异常活动。 

  • 删除不需要的凭证。从未使用的实例配置文件中删除角色分配，以防止使用证书。您可以使用 IAM 访问顾问来识别未使用的角色。 

  • 使用PassRole权限来限制用户在启动 EC2 实例时可以将哪个角色传递给实例。这可以防止用户运行的应用程序的权限超过授予该用户的权限。

  • 如果您的架构跨越多个 AWS 账户，请考虑一个账户中的 EC2 实例可能需要如何访问另一个账户中的资源。适当使用跨账户角色确保安全访问，无需嵌入长期 AWS 安全证书。

  • 要大规模管理实例配置文件，您可以使用以下选项之一：

    • 使用 AWS Systems Manager Automation 运行手册自动将实例配置文件与 EC2 实例关联。这可以在启动时完成，也可以在实例运行之后完成。

    • 使用 AWS CloudFormation 在创建时以编程方式将 EC2 实例配置文件应用于实例，而不是通过 AWS 控制台进行配置。

  • 最好使用 VPC 终端节点通过在实例上运行的应用程序私下连接到支持的 AWS 服务，例如 Amazon S3 和 Amazon DynamoDB。 EC2 

授予亚马逊 Cognito 客户证书

Amazon Cognito 是一项托管客户身份和访问管理服务。Amazon Cognito 提供 OAuth符合要求的身份验证流程，包括能够通过客户端证书授予类型对计算机或应用程序而不是用户进行身份验证。此项授权允许应用程序直接检索临时的 AWS 凭证以访问 AWS 服务。Amazon Cognito 客户端凭证是一种无需人工用户交互即可向应用程序提供 AWS 权限的安全方式。应用程序向 Amazon Cognito 令牌终端节点显示其客户端 ID 和客户端密钥。作为回报，他们会收到一个访问令牌，他们可以使用该令牌对各种资源和服务的后续请求进行身份验证。此访问的范围由与客户端 ID 关联的权限决定。收到请求的应用程序必须通过检查令牌的签名、到期时间戳和受众来验证令牌。在这些检查之后，应用程序通过验证令牌中的声明来验证请求的操作是否被允许。

下图说明了这种方法。

使用 Amazon Cognito 客户端凭证进行身份管理 machine-to-machine

  1. 想要从服务器（资源服务器）请求资源的应用程序（应用程序客户端）向 Amazon Cognito 请求令牌。

  2. Amazon Cognito 用户池会返回访问令牌。

  3. App Client 向资源服务器发送请求并包含访问令牌。

  4. 资源服务器使用 Amazon Cognito 验证令牌。

  5. 如果验证成功且允许执行请求的操作，则资源服务器将使用请求的资源进行响应。

优点

  • 计算机身份验证。此方法不需要用户上下文或登录。应用程序直接使用令牌进行身份验证。

  • 短期证书。应用程序可以先从 Amazon Cognito 获取访问令牌，然后使用限时访问令牌从资源服务器访问数据。

  • OAuth2 支持。由于该方法遵循既 OAuth2 定标准，因此可以减少不一致性并有助于应用程序开发。

  • 增强安全性。使用客户端凭证授予可以增强安全性，因为与 API 密钥授权机制不同，客户端 ID 和客户端密钥不会传输到资源服务器。只有在调用 Amazon Cognito 以获取限时访问令牌时，才会共享和使用客户端 ID 和密钥。

  • 通过作用域进行精细的访问控制。应用程序可以定义和请求范围和其他声明，以限制仅对特定资源的访问。

  • 审计跟踪。您可以使用收集的信息 CloudTrail 来确定向 Amazon Cognito 发出的请求、发出请求的 IP 地址、谁提出了请求、何时提出请求以及其他详细信息。 

设计注意事项

  • 仔细定义每个客户端 ID 的访问范围，并将其限制在所需的最小范围内。严格的范围有助于减少潜在的漏洞，并确保服务只能访问必要的资源。 

  • 使用诸如 AWS Secrets Manager 之类的安全存储服务来存储证书，从而保护客户端 IDs 和机密。请勿将凭据签入源代码。

  • 使用和等工具监控和审计令牌请求 CloudTrail 和使用情况 CloudWatch。注意可能表明存在问题的意外活动模式。 

  • 定期自动轮换客户机密钥。每次轮换时，都要创建一个新的应用程序客户端，删除旧客户端，然后更新客户端 ID 和密钥。在不中断服务通信的情况下为这些轮换提供便利。 

  • 对令牌端点请求强制执行速率限制，以帮助防止滥用和拒绝服务 (DoS) 攻击。 

  • 准备好在发生安全漏洞时撤销代币的策略。尽管代币的寿命很短，但受损的代币应立即失效。

  • 使用 AWS CloudFormation 以编程方式创建 Amazon Cognito 用户池和代表需要向其他服务进行身份验证的计算机的应用程序客户端。

  • 在适当情况下，缓存令牌以提供性能效率和成本优化。

  • 确保访问令牌的到期时间与组织的安全状况保持一致。

  • 如果您使用自定义资源服务器，请务必验证访问令牌以确保签名有效、令牌未过期且存在正确的范围。根据需要验证任何其他索赔。

  • 要大规模管理客户凭证，您可以使用以下选项之一：

    • 在一个集中式的 Amazon Cognito 实例中集中管理所有客户证书。这可以减少多个 Amazon Cognito 实例的管理开销，还可以简化配置和审计。但是，请务必做好扩展计划并考虑 Amazon Cognito 服务配额。

    • 将客户证书的责任交给工作负载账户，并允许使用多个 Amazon Cognito 实例。与集中式选项相比，此选项提高了灵活性，但会增加开销和整体复杂性。

mTLS 连接

双向 TLS (mTLS) 身份验证是一种机制，允许客户端和服务器在使用带有 TLS 的证书进行通信之前相互进行身份验证。mTLS 的常见用例包括监管严格的行业、物联网 (IoT) 应用和 business-to-business (B2B) 应用程序。除了现有的授权选项外，Amazon API Gateway 目前还支持 mTLS。您可以在自定义域名上启用 mTLS，以根据区域 REST 和 HTTP APIs 进行身份验证。可以使用 Bearer、JSON Web Tokens (JWTs) 对请求进行授权，也可以使用基于 IAM 的授权对请求进行签名。 

下图显示了在 EC2 实例上运行的应用程序和在 Amazon API Gateway 上设置的 API 的 mTLS 身份验证流程。

在实例上运行的应用程序的 mTLS 身份验证 EC2

  1. API Gateway 直接向 AWS Certificate Manager (ACM) 申请公开信任的证书。

  2. ACM 从其证书颁发机构 (CA) 生成证书。

  3. 调用 API 的客户端会出示带有 API 请求的证书。

  4. API Gateway 会检查您创建的 Amazon S3 信任存储存储桶。此存储桶包含您信任的用于访问您的 API 的 X.509 证书。要让 API Gateway 继续处理请求，证书的颁发者和直至根 CA 证书的完整信任链必须位于您的信任存储中。

  5. 如果客户的证书受信任，API Gateway 会批准请求并调用该方法。

  6. 关联的 API 操作（在本例中为 AWS Lambda 函数）处理请求并返回发送给请求者的响应。

优点

  • M2M 身份验证。服务之间直接进行身份验证，而不是使用共享密钥或令牌。这样就无需存储和管理静态凭证。

  • 防篡改保护。TLS 加密可保护服务之间传输的数据。第三方无法阅读或修改通信。 

  • 易于集成。mTLS 支持内置于主要的编程语言和框架中。服务只需最少的代码更改即可启用 mTLS。 

  • 精细权限。服务仅信任特定的证书，这允许对允许的呼叫者进行精细控制。 

  • 撤销。泄露的证书可以立即撤销，这样它们就不再可信了，从而阻止了进一步的访问。 

设计注意事项

  • 当你使用 API Gateway 时：

    • 默认情况下，客户端可以使用 API Gateway 为您的 API 生成的execute-api端点来调用您的 API。为确保客户端只能通过使用带有 mTLS 的自定义域名来访问您的 API，请禁用此默认端点。要了解更多信息，请参阅 API Gateway 文档中的禁用 REST API 的默认终端节点。

    • API Gateway 不会验证证书是否已被吊销。

    • 要为 REST API 配置 mTLS，您必须为 API 使用区域自定义域名，最低 TLS 版本为 1.2。私有版不支持 mTLS。 APIs

  • 您可以从自己的 CA 颁发 API Gateway 证书，也可以从 AWS 私有证书颁发机构导入证书。

  • 创建安全颁发、分发、续订和吊销服务证书的流程。尽可能自动发行和续订。如果您的 M2M 通信的一端是 API 网关，则可以与 AWS 私有 CA 集成。

  • 保护对私有 CA 的访问。入侵 CA 会损害对其颁发的所有证书的信任。

  • 安全地将私钥与证书分开存放。定期轮换密钥以限制泄露时的影响。

  • 当不再需要证书或证书被盗用时，请立即撤销证书。向服务分发证书吊销列表。 

  • 如果可能，应颁发仅用于特定目的或资源的证书，以便在受到威胁时限制其效用。

  • 为证书过期和 CA 或证书吊销列表 (CRL) 基础设施的中断制定应急计划。 

  • 监控您的系统是否存在证书故障和中断。注意可能表明存在问题的故障激增。

  • 如果您使用的是带有 AWS 私有 CA 的 AWS Certifice Manager (ACM)，则可以使用 AWS CloudFormation 以编程方式申请公有和私有证书。

  • 如果您使用的是 ACM，请使用 AWS Resource Access Manager (AWS RAM) 将证书从安全账户共享到工作负载账户。

IAM Roles Anywhere

当机器或系统需要连接到 AWS 服务但不支持 IAM 角色时，我们建议您使用 IAM Anywhere 角色进行 M2M 身份管理。IAM Roles Anywhere 是 IAM 的扩展，它使用公钥基础设施 (PKI) 通过临时安全证书授予对工作负载的访问权限。您可以使用 X.509 证书（可通过 CA 或 AWS 私有 CA 颁发）在 CA 和 IAM 角色之间建立信任锚点。与 IAM 角色一样，工作负载可以根据其附加到角色的权限策略访问 AWS 服务。 

下图显示了如何使用 IAM Anywhere 角色将 AWS 与外部资源连接起来。

在任何地方使用 IAM 角色进行 machine-to-machine身份管理

  1. 您可以创建信任锚来建立您的 AWS 账户与向本地工作负载颁发证书的 CA 之间的信任。证书由您在 IAM Roles Anywhere 中注册为信任锚点（信任根）的 CA 颁发。CA 可以是您现有公钥基础设施 (PKI) 系统的一部分，也可以是您通过 AWS 私有证书颁发机构创建并使用 ACM 管理的 CA。在此示例中，我们使用的是 ACM。

  2. 您的应用程序向 IAM Roles Anywhere 发出身份验证请求，然后发送其公钥（在证书中编码）和由相应私钥签名的签名。您的应用程序还会指定要在请求中扮演的角色。

  3. 当 IAM Roles Anywhere 收到请求时，它会首先使用公钥验证签名，然后验证证书是否由信任锚颁发。两次验证成功后，您的应用程序都将通过身份验证，IAM Roles Anywhere 通过调用 AWS Sec urity Token Service (AWS STS) 为请求中指定的角色创建新的角色会话。

  4. 您可以使用 IAM Roles Anywhere 提供的凭证帮助工具来管理使用证书创建签名的过程，并调用终端节点来获取会话证书。该工具以标准 JSON 格式将证书返回给调用进程。

  5. 通过在 IAM 和 PKI 之间使用这种桥接信任模型，本地工作负载使用这些临时证书（访问密钥、密钥和会话令牌）来担任 IAM 角色，无需长期证书即可与 AWS 资源进行交互。您也可以使用 AWS CLI 或 AWS 来配置这些证书 SDKs。

优点

  • 没有永久证书。应用程序不需要具有广泛权限的长期 AWS 访问密钥。 

  • 精细的访问权限。策略决定可以为特定实体担任哪个 IAM 角色。 

  • 情境感知角色。可以根据经过身份验证的实体的详细信息自定义角色。

  • 撤销。撤消信任权限会立即阻止实体担任角色。

设计注意事项

  • 服务器必须能够支持基于证书的身份验证。 

  • 最好锁定要使用的信任策略aws:SourceArn或已配置信任锚aws:SourceAccount的账户的信任策略。 

  • 主标签从证书详细信息中继而来。其中包括公用名 (CN)、主体备用名称 (SAN)、主体和发行人。

  • 如果您使用的是 ACM，请使用 AWS RAM 将证书从安全账户共享到工作负载账户。

  • 使用操作系统 (OS) 文件系统权限限制拥有者的读取权限。

  • 切勿在源代码管理中签入密钥。将它们与源代码分开存储，以降低意外将其包含在变更集中的风险。如果可能，请考虑使用安全的存储机制。

  • 确保您有轮换和吊销证书的流程。