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

# 的身份和访问管理最佳实践 AWS KMS
<a name="access"></a>

要使用 AWS Key Management Service (AWS KMS)，您必须拥有 AWS 可用于对您的请求进行身份验证和授权的证书。除非明确提供了 KMS 密钥的权限，否则任何 AWS 委托人均无权访问 KMS 密钥，并且从不被拒绝。没有使用或管理 KMS 密钥的隐式或自动权限。本节中的主题定义了安全最佳实践，以帮助您确定应使用哪些 AWS KMS 访问管理控制来保护基础架构。

**Topics**
+ [AWS KMS 密钥策略和 IAM 策略](#access-policies)
+ [的最低权限权限 AWS KMS](#access-least-privilege)
+ [基于角色的访问控制 AWS KMS](#access-rbac)
+ [基于属性的访问控制 AWS KMS](#access-abac)
+ [的加密上下文 AWS KMS](#access-encryption-context)
+ [AWS KMS 权限疑难解答](#access-troubleshooting)

## AWS KMS 密钥策略和 IAM 策略
<a name="access-policies"></a>

管理 AWS KMS 资源访问权限的主要方法是使用*策略*。策略是用于描述哪些委托人可以访问什么资源的文档。附加到 AWS Identity and Access Management (IAM) 身份（用户、用户组或角色）的策略称为[基于身份](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_id-based)的策略。附加到资源的 IAM 策略称为[基于资源的策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based)。 AWS KMS KMS 密钥的资源策略称为[密钥策略](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)。除了 IAM 策略和 AWS KMS 密钥策略外，还 AWS KMS 支持[授权](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)。授权提供了一种灵活而强大的权限委托方式。您可以使用授权向您 AWS 账户 或其他的 IAM 委托人发放有时限的 KMS 密钥访问权限。 AWS 账户

所有 KMS 密钥都具有密钥策略。如果您不提供一个，请为您 AWS KMS 创建一个。 AWS KMS 使用的[默认密钥策略](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-default.html)会有所不同，具体取决于您是使用 AWS KMS 控制台还是使用 AWS KMS API 创建密钥。我们建议您编辑默认密钥策略，使其符合贵组织对[最低权限](#access-least-privilege)的要求。这也应与您将 IAM 策略与关键策略结合使用的策略保持一致。有关将 IAM 策略与一起使用的更多建议 AWS KMS，请参阅 AWS KMS 文档[中的 IAM 策略最佳实践](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies-best-practices.html)。

您可以使用密钥策略将 IAM 委托人的授权委托给基于身份的策略。您还可以将密钥策略与基于身份的策略结合使用来完善授权。无论哪种情况，均由密钥策略和基于身份的策略决定访问权限，以及任何其他适用于访问范围的适用策略，例如[服务控制策略 (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)、[资源控制策略 (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) 或[权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)边界。如果委托人与 KMS 密钥位于不同的账户中，则基本上只支持加密和授权操作。有关这种跨账户场景的更多信息，请参阅 AWS KMS 文档[中的允许其他账户中的用户使用 KMS 密钥](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html)。

您必须将基于 IAM 身份的策略与密钥策略结合使用，以控制对您的 KMS 密钥的访问。授权也可以与这些策略结合使用，以控制对 KMS 密钥的访问权限。要使用基于身份的策略来控制对 KMS 密钥的访问，密钥策略必须允许账户使用基于身份的策略。您可以指定[启用 IAM 策略的密钥政策语句](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-default.html#key-policy-default-allow-root-enable-iam)，也可以在密钥政策中明确[指定允许的主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#Principal_specifying)。

在编写策略时，请确保您有严格的控制措施，以限制谁可以执行以下操作：
+ **更新、创建和删除 IAM 策略和 KMS 密钥策略**
+ **为用户、角色和群组附加和分离基于身份的策略**
+ **从 KMS AWS KMS 密钥中附加和分离密钥策略**
+ **为您的 KMS 密钥创建授**权 — 无论您是仅通过密钥策略控制对 KMS 密钥的访问权限，还是将密钥策略与 IAM 策略结合使用，都应限制修改策略的能力。实施批准流程以更改任何现有政策。批准流程可以帮助防止以下情况：
  + **意外丢失 IAM 委托人权限** — 可以进行更改，从而阻止 IAM 委托人管理密钥或将其用于加密操作。在极端情况下，可以撤消所有用户的密钥管理权限。如果发生这种情况，您需要联系[AWS 支持](https://aws.amazon.com/contact-us/)以重新获得对密钥的访问权限。
  + 对 **KMS 密钥策略的未经批准的更改**-如果未经授权的用户获得了对密钥策略的访问权限，他们可以对其进行修改以将权限委托给非预期用户 AWS 账户 或委托人。
  + 对 **IAM 策略的未经批准的更改** — 如果未经授权的用户获得了一组有权管理群组成员资格的证书，则他们可以提升自己的权限并更改您的 IAM 策略、密钥策略、KMS 密钥配置或其他 AWS 资源配置。

仔细查看与被指定为您的 KMS 密钥管理员的 IAM 委托人关联的 IAM 角色和用户。这可以帮助防止未经授权的删除或更改。如果您需要更改有权访问您的 KMS 密钥的委托人，请确认新的管理员委托人已添加到所有必需的密钥策略中。在删除之前的管理委托人之前，请先测试他们的权限。我们强烈建议遵循所有 [IAM 安全最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)，使用临时证书而不是长期证书。

如果您在创建策略时不知道委托人的姓名，或者需要访问权限的委托人经常发生变化，我们建议您通过授权来发放有时限的访问权限。[被授权者委托人](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grantee-principal)可以与 KMS 密钥位于同一个账户中，也可以位于不同的账户中。如果委托人和 KMS 密钥位于不同的账户中，则除了授权外，您还必须指定基于身份的策略。授权需要额外的管理，因为您必须调用 API 来创建授权，并在不再需要时停用或撤销授权。

任何 AWS 委托人（包括账户根用户或密钥创建者）都没有对 KMS 密钥的任何权限，除非在密钥策略、IAM 策略或授权中明确允许且未明确拒绝这些权限。推而广之，你应该考虑如果用户获得使用 KMS 密钥的意外访问权限会发生什么，以及会产生什么影响。要降低此类风险，请考虑以下几点：
+ 您可以为不同类别的数据维护不同的 KMS 密钥。这可以帮助您分离密钥并维护更简洁的密钥策略，这些策略包含专门针对该数据类别的委托人访问权限的策略声明。这也意味着，如果无意中访问了相关的 IAM 证书，则与该访问相关的身份只能访问 IAM 策略中指定的密钥，并且前提是密钥策略允许访问该委托人。
+ 您可以评估意外访问密钥的用户是否可以访问数据。例如，使用亚马逊简单存储服务 (Amazon S3) Simple Service，用户还必须具有访问亚马逊 S3 中加密对象的相应权限。或者，如果用户意外访问了使用 KMS 密钥加密的卷的 Amazon EC2 实例（使用 RDP 或 SSH），则该用户可以使用操作系统工具访问数据。

**注意**  
AWS 服务 这种用途 AWS KMS 不会向用户公开密文（大多数当前的密码分析方法都需要访问密文）。此外，密文不能在 AWS 数据中心之外进行体检，因为根据 N SP8 IST 00-88 的要求，所有存储介质在停用时都会被物理销毁。

## 的最低权限权限 AWS KMS
<a name="access-least-privilege"></a>

由于您的 KMS 密钥可以保护敏感信息，因此我们建议遵循最低权限访问的原则。在定义密钥政策时，请委派执行任务所需的最低权限。仅当您计划使用其他基于身份的策略进一步限制权限时，才允许对 KMS 密钥策略执行所有操作 (`kms:*`)。如果您计划使用基于身份的策略管理权限，请限制谁能够创建 IAM 策略并将其附加到 IAM 委托人，并[监控策略的变化](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html#cloudwatch-alarms-for-cloudtrail-iam-policy-changes)。

如果您允许在密钥策略和基于身份的策略中执行所有操作 (`kms:*`)，则委托人同时拥有 KMS 密钥的管理权限和使用权限。作为安全最佳实践，我们建议仅将这些权限委托给特定的委托人。考虑一下如何向负责管理您的密钥的委托人和将使用您的密钥的委托人分配权限。为此，您可以通过在密钥策略中明确命名委托人或限制基于身份的策略所关联的委托人来实现。您也可以使用[条件键](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html)来限制权限。例如，如果发出 API 调用的委托人具有条件规则中指定的标签，则可以使用 aws[: PrincipalTag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag) 来允许所有操作。

要帮助了解中如何评估策略声明 AWS，请参阅 IAM 文档中的[策略评估逻辑](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)。我们建议您在撰写策略之前先阅读此主题，以帮助减少您的策略产生意外影响的可能性，例如向本不应拥有访问权限的委托人提供访问权限。

**提示**  
在非生产环境中测试应用程序时，请使用 [AWS Identity and Access Management Access Analyzer (IAM Access Analyzer)](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 来帮助您在 IAM 策略中应用最低权限权限。

如果您使用 IAM 用户而不是 IAM 角色，我们强烈建议您使用[AWS 多因素身份验证 (MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)) 来缓解长期证书的漏洞。您可使用 MFA 执行以下操作：
+ 要求用户在执行特权操作（例如安排密钥删除）前先使用 MFA 验证其凭证。
+ 将管理员账户密码和 MFA 设备的所有权分配给不同个人，进行授权拆分。

有关可帮助您配置最低权限权限的示例策略，请参阅文档[中的 IAM 策略示例](https://docs.aws.amazon.com/kms/latest/developerguide/customer-managed-policies.html)。 AWS KMS 

## 基于角色的访问控制 AWS KMS
<a name="access-rbac"></a>

基于角色的访问控制 (RBAC) 是一种授权策略，它仅为用户提供履行其工作职责所需的权限，仅此而已。这种方法可以帮助您实现最小权限原则。

AWS KMS 支持 RBAC。它允许您通过在密钥[策略中指定精细权限来控制对密钥](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)的访问。密钥政策指定授予密钥访问权限的资源、操作、效果、主体和可选条件。要在中实现 RBAC AWS KMS，我们建议将密钥用户和密钥管理员的权限分开。

对于密钥用户，仅分配用户所需的权限。使用以下问题来帮助您进一步完善权限：
+ 哪些 IAM 委托人需要访问密钥？
+ 每位主体需要使用密钥来执行哪些操作？ 例如，委托人是否只需要`Encrypt`和`Sign`权限？
+ 委托人需要访问哪些资源？
+ 这个实体是人类还是 AWS 服务？ 如果是服务，则可以使用 k [ms: ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/conditions-kms.html#conditions-kms-via-service) 条件密钥将密钥的使用限制在特定服务范围内。

对于密钥管理员，仅分配管理员所需的权限。例如，管理员的权限可能会有所不同，具体取决于密钥是在测试环境还是生产环境中使用。如果您在某些非生产环境中使用限制较少的权限，请在策略发布到生产环境之前实施一个流程来对其进行测试。

有关可帮助您为关键用户和管理员配置基于角色的访问控制的策略示例，请参阅相关的 [RBAC](https://docs.aws.amazon.com/kms/latest/developerguide/rbac.html)。 AWS KMS

## 基于属性的访问控制 AWS KMS
<a name="access-abac"></a>

[基于属性的访问控制 (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 是一种基于属性定义权限的授权策略。与 RBAC 一样，它是一种可以帮助您实现最小权限原则的方法。

AWS KMS 支持 ABAC，允许您根据与目标资源关联的标签（例如 KMS 密钥）以及与进行 API 调用的委托人关联的标签来定义权限。在中 AWS KMS，您可以使用标签和别名来控制对客户托管密钥的访问权限。例如，您可以定义使用标签条件密钥的 IAM 策略，以便在委托人的标签与与 KMS 密钥关联的标签匹配时允许操作。有关教程，请参阅 AWS KMS 文档中的[基于标签定义访问 AWS 资源的权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)。

作为最佳实践，使用 ABAC 策略来简化 IAM 策略管理。借助 ABAC，管理员可以使用标签来允许访问新资源，而不必更新现有策略。ABAC 需要的策略更少，因为您不必为不同的工作职能创建不同的策略。有关更多信息，请参阅 IAM 文档中的 [ABAC 与传统 RBAC 模型的比较](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html#introduction_attribute-based-access-control_compare-rbac)。

将最低权限权限的最佳实践应用于 ABAC 模型。仅向 IAM 委托人提供他们执行任务所需的权限。谨慎控制对标签的访问权限 APIs ，这将允许用户修改角色和资源的标签。如果您使用密钥别名条件键来支持 ABAC AWS KMS，请确保您还有强大的控制来限制谁可以创建密钥和修改别名。

您还可以使用标签将特定密钥链接到业务类别，并验证给定操作是否使用了正确的密钥。例如，您可以使用 AWS CloudTrail 日志来验证用于执行特定 AWS KMS 操作的密钥是否与正在使用的资源属于相同的业务类别。

**警告**  
不要在标签键或标签值中包含机密或敏感信息。标签未加密。许多人都可以访问它们 AWS 服务，包括计费。

在实施 ABAC 访问控制方法之前，请考虑您使用的其他服务是否支持这种方法。有关确定哪些服务支持 ABAC 的帮助，请参阅AWS 服务 IAM 文档中的 “[与 IAM 配合](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)使用”。

有关为实现 ABAC AWS KMS 以及可以帮助您配置策略的条件密钥的更多信息，请参阅 [ABAC](https://docs.aws.amazon.com/kms/latest/developerguide/abac.html) 的。 AWS KMS

## 的加密上下文 AWS KMS
<a name="access-encryption-context"></a>

所有使用对称加密 KMS 密钥的 AWS KMS 加密操作都接受[加密](https://docs.aws.amazon.com/kms/latest/developerguide/encrypt_context.html)上下文。*加密上下文*是一组可选的非秘密密钥值对，可以包含有关数据的其他上下文信息。作为最佳实践，您可以在`Encrypt`操作中插入加密上下文， AWS KMS 以增强对的解密 API 调用的授权和可审计性。 AWS KMS AWS KMS 使用加密上下文作为额外的身份验证数据 (AAD) 来支持[经过身份验证的加密](https://docs.aws.amazon.com/kms/latest/developerguide/kms-cryptography.html#symmetric-key-0ps)。加密上下文以加密方式绑定到加密文字，以便需要使用相同的加密上下文解密数据。

加密上下文不是密钥，且没有加密。它以纯文本形式出现在 AWS CloudTrail 日志中，因此您可以使用它来识别和分类您的加密操作。由于加密上下文不是秘密的，因此您应该只允许授权委托人访问您的 CloudTrail 日志数据。

您还可以使用 kms[:: context-key EncryptionContext 和 kms[: 条件EncryptionContextKeys ](https://docs.aws.amazon.com/kms/latest/developerguide/conditions-kms.html#conditions-kms-encryption-context-keys)密钥根据加密上下文](https://docs.aws.amazon.com/kms/latest/developerguide/conditions-kms.html#conditions-kms-encryption-context)控制对对称加密 KMS 密钥的访问权限。您也可以使用这些条件密钥来要求在加密操作中使用加密上下文。对于这些条件密钥，请查看有关使用`ForAnyValue`或`ForAllValues`设置运算符的指南，以确保您的策略反映了您的预期权限。

## AWS KMS 权限疑难解答
<a name="access-troubleshooting"></a>

在为 KMS 密钥编写访问控制策略时，请考虑 IAM 策略和密钥策略是如何协同工作的。委托人的有效权限是所有有效策略授予（但未明确拒绝）的权限。在账户内，KMS 密钥的权限可能会受基于 IAM 身份的策略、密钥策略、权限边界、服务控制策略或会话策略的影响。例如，如果您同时使用基于身份的策略和密钥策略来控制对 KMS 密钥的访问，则会评估与委托人和资源相关的所有策略，以确定委托人是否有权执行给定操作。有关更多信息，请参阅 IAM 文档中的[策略评估逻辑](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)。

有关详细信息和排除密钥访问故障的流程图，请参阅 AWS KMS 文档中的[密钥访问疑](https://docs.aws.amazon.com/kms/latest/developerguide/policy-evaluation.html)难解答。

**对拒绝访问错误消息进行故障排除**

1. 确认基于 IAM 身份的策略和 KMS 密钥策略允许访问。

1. 确认 IAM 中的[权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)没有限制访问。

1. 确认中的[服务控制策略 (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 或[资源控制策略 (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) AWS Organizations 未限制访问。

1. 如果您使用的是 VPC 终端节点，请确认[终端节点策略](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)是否正确。

1. 在基于身份的策略和密钥策略中，删除任何限制访问密钥的条件或资源引用。取消这些限制后，确认委托人可以成功调用之前失败的 API。如果成功，请逐一重新应用条件和资源引用，然后验证委托人是否仍具有访问权限。这可以帮助您确定导致错误的条件或资源参考。

有关更多信息，请参阅 IAM 文档中的对[拒绝访问错误消息进行故障排除](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_access-denied.html)。