Policies - AWS Secrets Manager
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅中国的 AWS 服务入门。

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

Policies

与在几乎所有 AWS 服务中一样，Secrets Manager 创建并附加权限策略以授予权限。策略具有两种基本类型：

  • 基于身份的策略 – 直接附加到用户、组或角色。该策略为附加的身份指定允许的任务。附加的用户自动且隐式地成为策略的Principal。您可以指定身份可以执行的 Actions 以及身份可以对其执行操作的 Resources。这些策略允许您执行以下操作：

    • 授予多个资源的访问权限以与身份共享。

    • 控制不存在的资源(如各种 APIs 操作)对 Create* 的访问。

    • 向资源授予对 IAM 组的访问权限。

  • 基于资源的策略 – 直接附加到资源—在本例中为密钥。策略指定密钥的访问权限以及用户对密钥执行的操作。附加的密钥自动且隐式地成为策略的Resource。您可以指定访问密钥的Principals以及委托人可以执行的Actions。这些策略允许您执行以下操作：

    • 为多个委托人 (用户或角色) 授予单个密钥的访问权限。请注意，您无法在基于资源的策略中将 IAM 组指定为委托人。仅用户和角色可以是委托人。

    • 通过在策略语句的 AWS 元素中指定账户 IDs 来授予对其他 Principal 账户中的用户或角色的访问权限。如果您需要密钥的“跨账户”访问权限，这可能是使用基于资源的策略的主要原因之一。

您应使用哪种类型？ 虽然它们的功能确实存在很多重叠，但在某些情况下，一种类型明显优于另一个类型，并且它们都应在您的安全策略中占有一席之地。当两种策略类型都可以使用时，选择可在人员进入和离开您的组织时简化策略维护的类型。

重要

在一个账户中的 IAM 委托人访问另一个账户中的密钥时，必须使用自定义 AWS KMS 客户主密钥 (CMK) 对该密钥进行加密。使用账户的默认 Secrets Manager CMK 加密的密钥只能由该账户中的委托人进行解密。来自其他账户的委托人必须被授予对密钥和自定义 AWS KMS CMK 的权限。

作为替代方案，您可以为用户授予跨账户访问权限，并在与密钥相同的账户中担任 IAM 角色。由于角色在与密钥相同的账户中存在，因此，角色可以访问使用账户的默认 AWS KMS 密钥加密的密钥。