Amazon KMS

> 文章作者：亚马逊云科技加油站/罗技123 #### **Amazon KMS Permissions and Key Policies** 正如您在使用不同的亚马逊云科技服务时可能熟悉的那样，您可以使用 IAM 策略控制对资源的访问，但控制谁有权访问您的 KMS 密钥略有不同。 尽管您可以使用基于资源的 IAM 策略来控制谁有权访问 KMS 密钥，但您必须首先允许在相应的 KMS 密钥策略中使用 IAM 策略作为访问控制方法。 如果不允许在此密钥策略中使用 IAM 策略，则 IAM 策略将无效，除非是“拒绝”访问。 那么什么是 KMS 密钥策略呢？ 密钥策略是从 KMS 服务内部创建的基于资源的策略，并与您的 KMS 密钥绑定。 每个密钥都不会超过一个密钥策略，它们指定是否允许 IAM 用户权限控制访问、谁可以管理密钥、谁可以访问密钥以执行加密操作以及谁可以创建授权来控制临时访问 到 KMS 密钥。 关键策略文档本身基于 JSON，文档语法与 IAM 策略非常相似。 它们包含资源、操作、效果、主体和可选条件等元素。 因此，它们通常如下所示。 #### 让我们从第一个 Statement ID 开始仔细研究一下这个策略。 正如我之前提到的，仅使用 IAM 无法授予和生成允许您访问和使用 KMS 密钥的权限，必须在您的密钥策略中允许 IAM 权限。 如果我们查看此示例密钥策略的第一个 “Sid”，我们可以看到这是如何实现的。 正如您所看到的，此语句允许根账户（代表拥有密钥的亚马逊云科技账户）对 KMS 进行完全访问。 重要的是要了解，这实际上并没有向任何委托人授予使用密钥本身的任何权限，它只是允许您通过使用 IAM 策略授予对密钥的访问权限。 如果您的密钥策略中没有此语句，任何允许访问密钥的 IAM 语句都将被忽略，除非它们用于拒绝访问。 在创建 KMS 密钥期间，无论您以编程方式创建还是通过亚马逊云科技管理控制台创建，此 Sid 都会输入到每个密钥策略中，因此如果您不想借助 IAM 策略来管理权限， 那么您需要确保在密钥策略中删除此条目。 让根主体访问 KMS 的另一个好处是，可以确保 KMS 密钥永远不会变得不可用，因为无法删除根帐户。 策略中的下一个语句 ID 是……。 允许关键管理员访问。 对于每个 KMS 密钥，您还应该识别您的密钥管理员。 这些可以是您在 IAM 中设置和配置的用户或角色。 这些主体只能管理 KMS 密钥，而不能使用它来执行任何使用该密钥的加密功能。 在选择密钥管理员的过程中，您还可以指定是否希望他们能够删除密钥。 需要记住的重要一点是，尽管这些密钥管理员无权使用 KMS 密钥，但他们确实有权更新关联的密钥策略。 因此，如果他们愿意，他们可以授予自己以密钥用户的身份使用 KMS 密钥的权限。 #### 使用前面显示的示例策略，以下条目显示密钥的密钥管理员。 在这里，我们可以看到用户 “CloudAcademy” 被添加为主体，用户可以对 KMS 密钥执行许多管理操作，例如更新、删除、启用、ScheduleKeyDeletion 等。 下一个语句 ID 是…… 允许使用密钥。 当然，密钥策略还必须定义谁可以使用密钥来执行加密功能，这些人称为密钥用户。 再次查看策略，我们可以看到这里的条目。 如图所示，我们有 2 个用户可以使用该密钥来执行许多操作，例如使用该密钥来加密和解密数据、重新加密数据（这将允许您更改用于加密数据的 KMS 密钥）、 从 KMS 密钥生成数据密钥，并描述密钥，这将提供有关密钥的详细信息。 正如您在我给出的关键管理员和关键用户示例中所看到的，如果需要，您可以在这两个部分中拥有相同的主体。 该策略的最后一个语句 ID 是…允许附加持久资源。 在密钥策略的最后部分，我们有一个条目允许您通过使用授权来控制访问。 授予允许您临时将密钥用户拥有的权限子集委托给另一个主体，而无需更新密钥策略来定义这些权限。 与 KMS 集成的不同亚马逊云科技服务也使用补助金。 需要时，亚马逊云科技服务将代表用户，执行所需的加密操作，然后删除授予。 与密钥策略非常相似，授权是另一种基于资源的 KMS 密钥访问控制方法。 授权本身需要使用 Amazon KMS API 创建。 无法使用亚马逊云科技管理控制台创建它们，然后这些授权将附加到 KMS 密钥，就像密钥策略一样。 在我们在这里看到的策略示例中，它显示允许 2 个用户在 GrantIsForAWSResource 的条件下创建、列出和撤销授权。 这意味着这些授权操作可以由与 KMS 集成的亚马逊云科技服务（例如 EBS）代表用户调用。 创建授权后，只能使用单个 KMS 密钥来使用该授权，该密钥可以位于您自己的帐户或其他帐户中。 被授权者主体（将使用授权的主体）可以是用户、角色或者联合用户或角色。 它不能是 IAM 组、亚马逊云科技组织或亚马逊云科技服务角色。 授予操作的关键策略中的语句仅适用于“允许”操作，不支持“拒绝”操作。 创建授权后，可能会出现延迟，直到操作达到最终一致性。 如果您想在创建授权后立即使用权限，那么您将需要使用授权令牌。 创建授权后，受授权者主体将能够获得受授权者指定的权限和所需的操作级别。 一旦授权生效，受授权者主体就可以根据授权中提供的访问级别以编程方式采用权限。 此外，在创建授权后，会发出 GrantToken 和 GrantID。 创建授权后，使用权限可能会出现延迟，这是因为必须实现最终一致性。 为了解决这个问题，您可以将 GrantToken 与某些 API 结合使用，这将允许受让人立即执行授权中指定的操作，而无需等待最终一致性完成。 #### Creating a New KMS Key with a New Key Policy 如何使用亚马逊云科技管理控制台创建新的 KMS 密钥，以及如何构建密钥策略以包含密钥管理员、用户和授权。 您需要从亚马逊云科技管理控制台的仪表板转到密钥管理服务。 从这里，除了任何客户管理的 KMS 密钥之外，您还可以在左侧看到任何已创建的亚马逊云科技托管 KMS 密钥（例如从 Lambda、RDS 和 EBS 等）。 从这里我们可以开始配置我们的密钥。 我们可以选择我们想要的密钥类型（对称或非对称密钥）以及我们想要使用该密钥的用途。 加密操作或用于生成和验证 HMAC 代码。 对于本示例，我将选择“对称”作为密钥类型，并选择“加密和解密”作为密钥类型。 如果我们向下移动到“高级”选项，我们还可以指定密钥材料来源，如果我们想要从 KMS 内部以外的其他来源提供密钥材料，以及如果我们想要生成此密钥 可以在多个地区使用。 同样，在本次演示中，我将采用默认的 KMS 作为密钥来源，并选择单区域密钥。 进入下一个屏幕，我可以设置一些基本元数据，包括密钥的别名，我将其称为 NewKey。 我将把这个演示的描述留空，但请随意添加任何有助于您理解密钥背后目的的信息。 最后，您还可以向您的 KMS 密钥添加一个标签，同样，为了演示，我将保留它。 转到下一个屏幕，我们可以开始了解如何定义密钥策略。 我们会看到一个屏幕，用于定义我们想要用作 KMS 密钥的密钥管理员的人，可以是 IAM 用户或角色。 请记住，密钥管理员只能对密钥执行管理操作，他们实际上不能将其用于加密操作。 使用复选框，只需选择密钥管理员即可。 对于此演示，我将选择 Cloud Academy 和 Stuart。 此外，在此屏幕的底部，您会注意到一个复选框，如果选中该复选框，也允许密钥管理员删除关联的密钥。 我将默认选择此选项。 转到下一个屏幕，我们可以定义密钥使用权限。 因此，我再次可以使用复选框来选择我希望能够使用密钥执行加密操作的用户或角色，这些用户可以位于我当前使用的帐户中，也可以来自另一个帐户 帐户。 如果我想从另一个帐户中选择用户，我需要添加该附加帐户的帐户 ID。 再次强调，为了让演示变得简单，我将在进入配置的最后一页之前保留 Stuart 的一个用户。 最后一页实质上显示了我在创建密钥之前从前面的屏幕中选择作为审查的所有选项。 我们可以查看密钥配置、别名和描述、标签，最后是密钥策略。 此屏幕使我们有机会更详细地查看密钥策略，如果需要，我们可以在创建密钥之前直接从此屏幕编辑密钥策略。 如果我们滚动浏览策略，如果我们想集中管理所有来自 IAM 的权限，我们可以看到默认条目允许通过 IAM 提供访问此 KMS 密钥。 再往下，我们还有显示哪些原则已被识别为我们的密钥管理员以及他们作为管理员的所有权限的条目，然后再往下，我们还有我们的密钥用户以及显示他们可以执行的加密操作。 最后，我们有显示谁可以发放赠款的条目。 您可能已经注意到，定义谁应该能够颁发授权并不是设置此密钥的配置过程的一部分，这是因为默认情况下，无论将哪个原则添加为密钥用户，它们也会添加为可以创建授权的原则。 当然，您可以直接从这里对密钥策略进行任何编辑，它是一个可编辑的文档。 当您对 KMS 密钥感到满意后，您可以单击“完成”。 然后，您将在此处的客户管理密钥列表下看到您的 KMS 密钥。 如果您单击新创建的密钥，它将显示该密钥的详细信息和信息。 在顶部，我们可以看到一些常规信息，例如别名、arn、状态、创建时间以及密钥是多区域还是仅用于单个区域。 在其下面有一堆选项卡，在密钥策略选项卡下，我们可以以易于阅读的格式查看密钥策略，向您显示为密钥管理员选择的主体，谁可以删除密钥，以及密钥的用户。 但是，也可以从 JSON 角度查看此屏幕再次，允许您根据需要编辑密钥策略。 “加密配置”选项卡将详细说明密钥类型、密钥的来源、确定密钥是对称还是非对称的密钥规范，以及用途。 标签选项卡正如您所期望的那样，是一个用于查看和创建密钥标签的区域。 密钥轮换选项卡允许您选择 KMS 密钥材料的自动轮换，这是对客户管理的密钥采用的良好做法。 最后，除了新创建的 KMS 密钥的亚马逊资源名称之外，Alias 还会向您显示密钥的名称。 在此屏幕的右上角有一个用于几个关键操作的选项。 在这里我们有禁用和计划密钥删除。 如果我们是具有正确权限的管理员，我们可以禁用该密钥，但这样做时请注意警告，因为它可能会使您的某些已使用此密钥加密的数据不可读。 如果您想安排删除 KMS 密钥，请再次注意，这将使使用该密钥加密的所有数据无法恢复！ 安排删除时，您可以设置 7 到 30 天之间的等待期。然后，您必须确认您愿意在该时间段后删除此密钥。 当我在此处的控制台中运行密钥策略等时，我只是向您展示我们可以继续查看 AWS 托管密钥的密钥策略，但是我们无法以任何方式更改或编辑它们。 在亚马逊云科技的管理下，我们所能做的就是查看这些密钥的一些元数据，并查看密钥策略。 因此，请记住，如果您有权编辑密钥策略，那么您正在编辑的将是客户管理的密钥。 #### KMS Access: Policy Evaluation Logic 了解谁有权访问 KMS 密钥可能会有点令人困惑，因为通过密钥策略、IAM 策略以及授权，可以通过三种潜在方式来访问和使用 KMS 密钥。 确定正确的访问级别意味着您需要了解这些访问方法如何相互结合使用。 让我们看一个简单的例子，以确保我们理解一些关键点。 在此场景中，我们有三个 KMS 密钥和四个用户。 在这里您可以看到适用于本示例的 KMS 密钥、用户和场景语句。 因此，我们有三个 KMS 密钥：KeyA、KeyB 和 KeyC，并且有四个用户：Alana、Danny、Carlos 和 Jorge。 **所以场景陈述是：** - Key-密钥策略允许使用 IAM 用户权限来管理访问。 - Key-B 密钥策略允许 Danny 和 Carlos 访问以执行加密操作。 尚未启用通过 IAM 控制访问。 - Key-C 密钥策略允许使用 IAM 用户权限来管理访问。 丹尼、卡洛斯的访问也被明确拒绝，但完全加密。 操作权限授予 Alana 和 Jorge。 豪尔赫还有权创建赠款。 - Alana 的 IAM 策略权限允许对 Key-A 和 Key-B 执行所有 KMS 操作。 - Danny 没有 IAM 策略权限。 - Carlos 的 IAM 策略权限允许 KMS 加密访问 Key-A。 - Jorge 的 IAM 策略权限允许对 Key-B 和 Key-C 执行所有 KMS 操作。 现在让我们看看每个用户的访问权限，看看他们是否可以执行加密操作（从 Alana 开始）。 Alana 对 Key-A 的访问是成功的，因为她的 IAM 策略权限允许针对 Key-A 的所有 KMS 操作，并且 Key-A 允许使用 IAM 策略来管理访问。 她对 Key-B 的访问被拒绝，因为该密钥的密钥策略不允许使用 IAM 策略。 Alana 对 Key-C 的访问是成功的，因为尽管她没有 IAM 策略相关权限，但密钥策略允许访问，访问权限纯粹是通过密钥策略授予的。 现在让我们来看看丹尼。 他对 Key-A 的访问被拒绝，因为密钥策略中没有用于 Danny 访问的显式条目，并且他没有关联的 IAM 策略权限。 他对 Key-B 的访问成功，因为密钥策略允许 Danny 访问，尽管他没有 IAM 策略权限。 由于密钥策略中的显式拒绝操作，Danny 对 Key-C 的访问被拒绝。 明确的“拒绝”将始终否决任何其他允许。 现在让我们看看卡洛斯的访问权限。 对于 Key-A，他仅具有通过其 IAM 策略权限授予的“加密”访问权限，并且允许使用 IAM 策略权限来管理访问。 对于 Key-B 来说，访问也是成功的，因为密钥策略允许他访问。 他的 IAM 策略权限无关紧要，因为密钥策略不允许使用 IAM 策略来管理访问。 由于密钥策略中的显式拒绝操作，他对 Key-C 的访问被拒绝，并且显式拒绝将推翻任何其他允许。 最后是豪尔赫的访问。 他无权访问 Key-A，因为密钥策略或他的 IAM 策略权限均不提供访问权限。 他无权访问 Key-B，因为该密钥的密钥策略不允许使用 IAM 策略。 因此，尽管在 IAM 策略级别授予了 Jorge 访问权限，但密钥策略不允许使用 IAM 策略，因此会忽略这一点。 除了创建授权的能力之外，还允许访问密钥 C 以进行 KMS 加密操作。 #### 总结 - 密钥策略是基于资源的策略，并与您的 KMS 密钥相关联。 - 关键策略基于 JSON，文档语法与 IAM 策略非常相似。 - 要使 IAM 权限作为一种有效的访问控制方法，您必须在密钥策略中启用它们。 - 如果您不启用 IAM 权限，则任何允许访问密钥的 IAM 策略都将被忽略，除非它们用于拒绝访问。 - 关键管理员可以是用户或角色。 - 密钥管理员只能管理 KMS 密钥，而不能使用它执行任何加密功能。 - 如果授予密钥管理员访问权限，则密钥管理员可以删除密钥。 - 密钥管理员可以执行更新、删除、启用、ScheduleKeyDeletion 等操作。 - 密钥用户定义谁可以使用密钥来执行加密功能。 - 密钥用户执行的操作包括加密和解密数据、重新加密数据、从 KMS 密钥生成数据密钥以及描述密钥。 - 授予允许您临时将密钥用户拥有的权限子集委托给另一个主体，而无需更新密钥策略。 - 与 KMS 集成的不同亚马逊云科技服务也使用 Grants 。 - 只能使用 CLI 创建 Grants 。 - 创建授权后，可能会出现延迟，直到操作达到最终一致性。 - 最后，介绍了策略评估逻辑，以解释当关键策略、IAM 策略和授予都用于授予访问权限时如何授予访问权限以及哪些权限会覆盖其他权限。 [](https://summit.amazoncloud.cn/2024/register.html?source=DSJAVfG2GS7gEk2Osm6kYXAa+8HnSEVdbCVjkuit7lE= )