# IAM 教程：根据标签定义访问 AWS 资源的权限
基于属性的访问权限控制 (ABAC) 是一种授权策略，该策略基于属性来定义权限。在 AWS 中，这些属性被称为“标签”**。您可以将标签附加到 IAM 资源（包括 IAM 实体（用户和角色））以及 AWS 资源。您可以定义策略，这些策略使用标签条件键来根据主体的标签向其授予权限。当您使用标签控制对 AWS 资源的访问时，可通过对 AWS 策略进行较少更改来实现团队和资源的增长。ABAC 策略比传统 AWS 策略更加灵活，后者需要您列出每个单独的资源。有关 ABAC 及其相对于传统策略的优势的更多信息，请参阅[使用 ABAC 授权根据属性定义权限](introduction_attribute-based-access-control.md)。
**注意**
您必须为每个会话标签传递一个值。AWS Security Token Service 不支持多值会话标签。
**Topics**
+ [
## 教程概述
](#tutorial_attribute-based-access-control-overview)
+ [
## 先决条件
](#tutorial_abac_prereqs)
+ [
## 步骤 1：创建测试用户
](#tutorial_abac_step1)
+ [
## 步骤 2：创建 ABAC 策略
](#tutorial_abac_step2)
+ [
## 步骤 3：创建角色
](#tutorial_abac_step3)
+ [
## 步骤 4：测试创建密钥
](#tutorial_abac_step4)
+ [
## 步骤 5：测试查看密钥
](#tutorial_abac_step5)
+ [
## 步骤 6：测试可扩展性
](#tutorial_abac_step6)
+ [
## 步骤 7：测试更新和删除密钥
](#tutorial_abac_step7)
+ [
## 摘要
](#tutorial-abac-summary)
+ [
## 相关资源
](#tutorial_abac_related)
+ [
# IAM 教程：将 SAML 会话标签用于 ABAC
](tutorial_abac-saml.md)
## 教程概述
本教程说明如何创建一个允许具有主体标签的 IAM 角色 角色访问具有匹配标签的资源的策略并测试该策略。当主体向 AWS 发出请求时，将根据主体标签和资源标签是否匹配来授予其权限。此策略仅允许用户查看或编辑其作业需要的 AWS 资源。
**场景**
假设您是一家名为 Example Corporation 的大公司的开发人员主管，同时也是一名经验丰富的 IAM 管理员。您熟悉 IAM 用户、角色和策略的创建和管理。您希望确保您的开发工程师和质量保证团队成员能够访问其所需的资源。您还需要一个随公司发展而扩展的策略。
您选择使用 AWS 资源标签和 IAM 角色主体标签来为支持 ABAC 策略的服务实施该策略（从 AWS Secrets Manager 开始）。要了解哪些服务支持基于标签的授权，请参阅[使用 IAM 的 AWS 服务](reference_aws-services-that-work-with-iam.md)。要了解可以在策略中使用哪些标记条件键以及每个服务的操作和资源，请参阅 [AWS 服务的操作、资源和条件键](reference_policies_actions-resources-contextkeys.html)。您可以对基于 SAML 的身份提供程序或 Web 身份提供程序进行配置，将[会话标签](id_session-tags.md)传递给 AWS。当您的员工希望联合身份到 AWS 中时，其属性将应用到 AWS 中所得到的主体。然后，您可以使用 ABAC 来允许或拒绝基于这些属性的权限。要了解 SAML 联合身份中的会话标签与本教程的不同之处，请参阅[IAM 教程：将 SAML 会话标签用于 ABAC](tutorial_abac-saml.md)。
您的工程和质量保证团队成员是 **Pegasus** 或 **Unicorn** 项目。您可以选择以下 3 个字符的项目和团队标签值：
+ `access-project` = `peg`（对于 **Pegasus** 项目）
+ `access-project` = `uni`（对于 **Unicorn** 项目）
+ `access-team` = `eng`（对于工程团队）
+ `access-team` = `qas`（对于质量保证团队）
此外，您选择需要 `cost-center` 成本分配标签以启用自定义 AWS 账单报告。有关更多信息，请参阅《AWS 账单与成本管理 用户指南》**中的[使用成本分配标签](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)。
**重要决策摘要**
+ 员工使用 IAM 用户凭证进行登录，然后代入其团队和项目的 IAM 角色 角色。如果您的公司拥有与自己的身份系统，则您可以设置联合身份验证以允许员工在没有 IAM 用户的情况下代入角色。有关更多信息，请参阅 [IAM 教程：将 SAML 会话标签用于 ABAC](tutorial_abac-saml.md)。
+ 将向所有角色附加同一策略。根据标签允许或拒绝操作。
+ 员工可以创建新的资源，但前提是员工必须将相同的标签附加到应用于其角色的资源。这将确保员工能够在创建资源后进行查看。管理员不再需要使用新资源的 ARN 来更新策略。
+ 员工可以读取其团队拥有的资源，无论项目如何。
+ 员工可以更新和删除其团队和项目拥有的资源。
+ IAM 管理员可以为新项目添加新角色。他们可以创建和标记新的 IAM 用户以允许访问相应的角色。管理员不需要编辑策略来支持新项目或团队成员。
在本教程中，您将标记每个资源，标记项目角色，并将策略添加到角色以允许前面所述的行为。生成的策略允许角色对使用同一项目和团队标签标记的资源进行 `Create`、`Read`、`Update` 和 `Delete` 访问。此策略还允许对使用同一团队标记的资源进行跨项目 `Read` 访问。
![\[此图显示了两个项目，在这两个项目中，角色只能对其项目外的资源进行只读访问，而在其自己的项目中则拥有创建、读取、更新和删除资源的权限。\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/images/tutorial-abac-cross-project.png)
## 先决条件
要执行本教程中的步骤，您必须已具备以下内容：
+ 可使用用户身份登录的具有管理权限的 AWS 账户。
+ 您的 12 位账户 ID（用于在步骤 3 中创建角色）。
要使用 AWS 管理控制台查找 AWS 账户 ID 号，请在右上角的导航栏上选择 **Support (支持)**，然后选择 **Support Center (支持中心)**。账户号 (ID) 将显示在左侧的导航窗格中。
![\[显示账号的 支持 Center 页面。\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/images/account-id-support-center.console.png)
+ 体验在 AWS 管理控制台 中创建和编辑 IAM 用户、角色和策略。但是，如果您需要获得帮助以便记住 IAM 管理过程，请访问本教程提供的链接来查看分步说明。
## 步骤 1：创建测试用户
为了进行测试，请创建四个有权代入具有相同标签的角色的 IAM 用户。这可让您更轻松地向您的团队添加更多用户。在标记用户时，他们会自动获得访问权来代入正确角色。如果用户仅在一个项目和团队中工作，则无需将其添加到角色的信任策略中。
1. 创建以下名为 `access-assume-role` 的客户托管策略。有关创建 JSON 策略的更多信息，请参阅[创建 IAM 策略](access_policies_create-console.md#access_policies_create-start)。
**ABAC 策略：代入任何 ABAC 角色，但前提是用户和角色标签匹配**
以下策略允许用户在您的账户中代入任何带有 `access-` 名称前缀的角色。还必须使用与用户相同的项目、团队和成本中心来标记角色。
要使用此策略，请将示例策略中的*斜体占位符文本*替换为您的账户信息。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "TutorialAssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/access-*",
"Condition": {
"StringEquals": {
"iam:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
"iam:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
"iam:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
}
}
}
]
}
```
------
要将本教程扩展到大量用户，您可以将策略附加到一个组并将每个用户添加到该组。有关更多信息，请参阅[创建 IAM 组](id_groups_create.md)和[编辑 IAM 组中的用户](id_groups_manage_add-remove-users.md)。
1. 创建以下 IAM 用户，附加 `access-assume-role` 权限策略。确保选择**向用户提供对 AWS 管理控制台 的访问权限**，然后添加以下标签。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
## 步骤 2：创建 ABAC 策略
创建以下名为 **access-same-project-team** 的策略。您将在以后的步骤中将此策略添加到角色。有关创建 JSON 策略的更多信息，请参阅[创建 IAM 策略](access_policies_create-console.md#access_policies_create-start)。
有关可针对本教程调整的其他策略，请参阅以下页面：
+ [控制 IAM 主体进行的访问](access_iam-tags.md#access_iam-tags_control-principals)
+ [Amazon EC2：允许以编程方式和在控制台中启动或停止用户已标记的 EC2 实例](reference_policies_examples_ec2_tag-owner.md)
+ [EC2：基于匹配的主体和资源标签来启动或停止实例](reference_policies_examples_ec2-start-stop-match-tags.md)
+ [EC2：基于标签来启动或停止实例](reference_policies_examples_ec2-start-stop-tags.md)
+ [IAM：代入具有特定标签的角色](reference_policies_examples_iam-assume-tagged-role.md)
**ABAC 策略：仅在主体标签和资源标签匹配时访问 Secrets Manager 资源**
以下策略允许主体创建、读取、编辑和删除资源，但前提是已使用与主体相同的键/值对标记这些资源。当主体创建资源时，必须添加 `access-project`、`access-team` 和 `cost-center` 标签以及与主体的标签匹配的值。该策略还允许添加可选的 `Name` 或 `OwnedBy` 标签。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllActionsSecretsManagerSameProjectSameTeam",
"Effect": "Allow",
"Action": "secretsmanager:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
"aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
"aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"access-project",
"access-team",
"cost-center",
"Name",
"OwnedBy"
]
},
"StringEqualsIfExists": {
"aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}",
"aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}",
"aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}"
}
}
},
{
"Sid": "AllResourcesSecretsManagerNoTags",
"Effect": "Allow",
"Action": [
"secretsmanager:GetRandomPassword",
"secretsmanager:ListSecrets"
],
"Resource": "*"
},
{
"Sid": "ReadSecretsManagerSameTeam",
"Effect": "Allow",
"Action": [
"secretsmanager:Describe*",
"secretsmanager:Get*",
"secretsmanager:List*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}"
}
}
},
{
"Sid": "DenyUntagSecretsManagerReservedTags",
"Effect": "Deny",
"Action": "secretsmanager:UntagResource",
"Resource": "*",
"Condition": {
"ForAnyValue:StringLike": {
"aws:TagKeys": "access-*"
}
}
},
{
"Sid": "DenyPermissionsManagement",
"Effect": "Deny",
"Action": "secretsmanager:*Policy",
"Resource": "*"
}
]
}
```
------
**此策略有何作用？**
+ `AllActionsSecretsManagerSameProjectSameTeam` 语句允许对所有相关资源执行此服务的所有操作，但前提是资源标签与主体标签匹配。通过将 `"Action": "secretsmanager:*"` 添加到策略，策略将在 Secrets Manager 增长时扩展。如果 Secrets Manager 添加一个新的 API 操作，则您无需将该操作添加到语句。该语句使用三个条件块实施 ABAC。仅在所有三个块都返回 true 时允许该请求。
+ 如果资源上存在指定的标签键，并且其值与主体的标签匹配，则此语句的第一个条件块将返回 true。对于不匹配的标签或不支持资源标记的操作，此块返回 false。要了解此块不允许哪些操作，请参阅 [AWS Secrets Manager 的操作、资源和条件键](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html)。此页面指明对 [**Secret (密钥)** 资源类型](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-resources-for-iam-policies)执行的操作支持 `secretsmanager:ResourceTag/tag-key` 条件键。某些 [Secrets Manager 操作](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-actions-as-permissions)不支持该资源类型，包括 `GetRandomPassword` 和 `ListSecrets`。您必须创建额外语句才能允许这些操作。
+ 如果请求中传递的每个标签键都包含在指定列表中，则第二个条件块将返回 true。通过将 `ForAllValues` 和 `StringEquals` 条件运算符结合使用来执行此操作。如果没有传递键或一组键的子集，则条件返回 true。对于不允许在请求中传递标签的 `Get*` 操作，这将允许该操作。如果请求者包含列表中没有的标签键，则条件返回 false。请求中传递的每个标签键均必须与该列表的一个成员匹配。有关更多信息，请参阅 [多值上下文键的集合运算符](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys)。
+ 在以下情况下，第三个条件块将返回 true：请求支持传递标签；所有三个标签都存在；标签与主体标签值匹配。如果请求不支持传递标签，则此块也返回 true。这要归功于条件运算符中的 [`...IfExists`](reference_policies_elements_condition_operators.md#Conditions_IfExists)。如果在支持该块的操作期间未传递任何标签，或者标签键和值不匹配，则该块将返回 false。
+ `AllResourcesSecretsManagerNoTags` 语句允许 `GetRandomPassword` 和 `ListSecrets` 操作，而第一个语句不允许这两项操作。
+ 如果使用与资源相同的 access-team 标签来标记主体，则 `ReadSecretsManagerSameTeam` 语句允许只读操作。无论项目或成本中心标签如何，都允许此操作。
+ `DenyUntagSecretsManagerReservedTags` 语句拒绝从 Secrets Manager 中删除带有以“access-”开头的键的标签的请求。这些标签用于控制对资源的访问，因此删除这些标签可能会删除权限。
+ `DenyPermissionsManagement` 语句拒绝访问创建、编辑或删除 Secrets Manager 的基于资源的策略。这些策略可用于更改密钥的权限。
**重要**
此策略使用一种策略来允许服务的所有操作，但明确拒绝权限更改操作。拒绝操作将覆盖任何其他允许主体执行该操作的策略。这可能会产生意外结果。作为最佳实践，仅在没有允许该操作的情况下才使用显式拒绝。否则，允许各个操作的列表，默认情况下将拒绝不需要的操作。
## 步骤 3：创建角色
创建以下 IAM 角色并附加您在上一步中创建的 **access-same-project-team** 策略。有关创建 IAM 角色的更多信息，请参阅 [创建角色，向 IAM 用户授予权限](id_roles_create_for-user.md)。如果选择使用联合身份而不是 IAM 用户和角色，请参阅 [IAM 教程：将 SAML 会话标签用于 ABAC](tutorial_abac-saml.md)。
| 作业函数 | 角色名称 | 角色标签 | 角色描述 |
| --- | --- | --- | --- |
| 项目 Pegasus 工厂 | access-peg-engineering | access-project = `peg` access-team = `eng` cost-center = `987654` | 允许工程师读取所有工程资源以及创建和管理 Pegasus 工程资源。 |
| 项目 Pegasus 质量保证 | access-peg-quality-assurance | access-project = `peg` access-team = `qas` cost-center = `987654` | 允许 QA 团队读取所有 QA 资源以及创建和管理所有 Pegasus QA 资源。 |
| 项目 Unicorn 工程 | access-uni-engineering | access-project= `uni` access-team = `eng` cost-center = `123456` | 允许工程师读取所有工程资源以及创建和管理 Unicorn 工程资源。 |
| 项目 Unicorn 质量保证 | access-uni-quality-assurance | access-project = `uni` access-team = `qas` cost-center = `123456` | 允许 QA 团队读取所有 QA 资源以及创建和管理所有 Unicorn QA 资源。 |
## 步骤 4：测试创建密钥
附加到角色的权限策略允许员工创建密钥。仅在使用其项目、团队和成本中心标记密钥时允许这样做。通过在 Secrets Manager 中以用户身份登录、代入正确的角色并测试活动，确认您的权限按预期工作。
**测试创建带有和不带有所需标签的密钥**
1. 在您的主浏览器窗口中，仍以管理员用户身份登录，以便能在 IAM 中查看用户、角色和策略。使用浏览器无痕窗口或单独的浏览器来进行测试。在那里，以 `access-Arnav-peg-eng` IAM 用户的身份登录并打开 Secrets Manager 控制台，地址：[https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/)。
1. 尝试切换到 `access-uni-engineering` 角色。
此操作失败，因为 `access-project` 和 `cost-center` 标签值与 `access-Arnav-peg-eng` 用户和 `access-uni-engineering` 角色的不匹配。
有关在 AWS 管理控制台 中切换角色的更多信息，请参阅 [从用户切换到 IAM 角色（控制台）](id_roles_use_switch-role-console.md)。
1. 切换到 `access-peg-engineering` 角色。
1. 使用以下信息存储新密钥。要了解如何存储密钥，请参阅 *AWS Secrets Manager 用户指南*中的[创建基本密钥](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html)。
**重要**
Secrets Manager 会显示提醒，告知您没有权限使用与 Secrets Manager 配合使用的其他 AWS 服务。例如，要创建 Amazon RDS 数据库凭证，您必须有权描述 RDS 实例、RDS 集群和 Amazon Redshift 集群。您可以忽略这些提醒，因为您没有使用本教程中的这些特定 AWS 服务。
1. 在 **Select secret type (选择密钥类型)** 部分中，选择 **Other type of secrets (其他类型的密钥)**。在两个文本框中，输入 `test-access-key` 和 `test-access-secret`。
1. 为 **Secret name (密钥名称)** 字段输入 `test-access-peg-eng`。
1. 从下表添加不同的标签组合，并查看预期行为。
1. 选择 **Store (存储)** 以尝试创建密钥。当存储失败时，请返回之前的 Secrets Manager 控制台页面，并使用下表中的下一个标签集。允许使用最后一个标签集，并且将成功创建密钥。
下表显示了 `test-access-peg-eng` 角色的 ABAC 标签组合。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
1. 注销并针对以下每个角色和标签值重复此过程的前三个步骤。在此过程的第四步中，测试所选的任何一组缺少的标签、可选标签、不允许的标签和无效的标签值。然后，使用所需的标签创建具有以下标签和名称的密钥。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
## 步骤 5：测试查看密钥
您附加到每个角色的策略允许员工查看标记有其团队名称的所有密钥，而不管其项目如何。通过在 Secrets Manager 中测试您的角色来确认您的权限按预期工作。
**测试查看带有或不带有所需标签的密钥**
1. 以下列某个 IAM 用户身份登录：
+ `access-Arnav-peg-eng`
+ `access-Mary-peg-qas`
+ `access-Saanvi-uni-eng`
+ `access-Carlos-uni-qas`
1. 切换到匹配的角色：
+ `access-peg-engineering`
+ `access-peg-quality-assurance`
+ `access-uni-engineering`
+ `access-uni-quality-assurance`
有关在 AWS 管理控制台中切换角色的更多信息，请参阅[从用户切换到 IAM 角色（控制台）](id_roles_use_switch-role-console.md)。
1. 在左侧导航窗格中，选择菜单图标以展开菜单，然后选择 **Secrets (密钥)**。
1. 无论您当前的角色如何，都应在表中看到所有四个密钥。这是预期情况，因为名为 `access-same-project-team` 的策略允许对所有资源执行 `secretsmanager:ListSecrets` 操作。
1. 选择其中一个密钥的名称。
1. 在密钥的详细信息页面上，您的角色标签将确定您是否能查看页面内容。将您的角色名称与您的密钥名称进行比较。如果它们共享同一团队名称，则 `access-team` 标签匹配。如果它们不匹配，则访问将被拒绝。
下表显示每个角色的 ABAC 密钥查看行为。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
1. 从页面顶部的痕迹导航中，选择 **Secrets (密钥)** 以返回密钥列表。使用不同的角色重复此过程中的步骤来测试您是否能查看每个密钥。
## 步骤 6：测试可扩展性
在基于角色的访问控制 (RBAC) 上使用基于属性的访问控制 (ABAC) 的重要原因是可扩展性。当您的公司向 AWS 添加新的项目、团队或人员时，您无需更新 ABAC 驱动型策略。例如，假设 Example Company 正在资助一个代号为 **Centaur** 的新项目。一个名叫 Saanvi Sarkar 的工程师将成为 **Centaur** 的工程师主管，同时该工程师还参与了 **Unicorn** 项目。Saanvi 还将审查 **Peg** 项目的工作。此外，新聘用了几名工程师，其中包括 Nikhil Jayashankar，他仅参与 **Centaur** 项目。
**向 AWS 添加新项目**
1. 以 IAM 管理员登录，然后通过以下网址打开 IAM 控制台：[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。
1. 在左侧导航窗格中，选择 **Roles**（角色），然后添加名为 `access-cen-engineering` 的 IAM 角色。将 **access-same-project-team** 权限策略附加到角色并添加以下角色标签：
+ `access-project` = `cen`
+ `access-team` = `eng`
+ `cost-center` = `101010`
1. 在左侧导航窗格中，请选择**用户**。
1. 添加一个名为 `access-Nikhil-cen-eng` 的新用户，并附加名为 `access-assume-role` 的策略，然后添加以下用户标签。
+ `access-project` = `cen`
+ `access-team` = `eng`
+ `cost-center` = `101010`
1. 使用[步骤 4：测试创建密钥](#tutorial_abac_step4)和[步骤 5：测试查看密钥](#tutorial_abac_step5)中的过程。在另一个浏览器窗口中，测试 Nikhil 是否能创建 **Centaur** 工程密钥并且是否能查看所有工程密钥。
1. 在您以管理员身份登录的主浏览器窗口中，选择用户 `access-Saanvi-uni-eng`。
1. 在 **Permissions (权限)** 选项卡上，删除 **access-assume-role** 权限策略。
1. 添加以下名为 `access-assume-specific-roles` 的内联策略。有关将内联策略添加到用户的更多信息，请参阅[为用户或角色嵌入内联策略（控制台）](access_policies_manage-attach-detach.md#embed-inline-policy-console)。
**ABAC 策略：仅代入特定角色**
此策略允许 Saanvi 代入 **Pegasus** 或 **Centaur** 项目的工程角色。由于 IAM 不支持多值标签，因此有必要创建此自定义策略。不能使用 `access-project` = `peg` 和 `access-project` = `cen` 标记 Saanvi 用户。此外，AWS 授权模型不能同时与这两个值匹配。有关更多信息，请参阅 [在 IAM 和 AWS STS 中进行标记的规则](id_tags.md#id_tags_rules)。相反，您必须手动指定她可以代入的两个角色。
要使用此策略，请将示例策略中的*斜体占位符文本*替换为您的账户信息。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "TutorialAssumeSpecificRoles",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::111122223333:role/access-peg-engineering",
"arn:aws:iam::111122223333:role/access-cen-engineering"
]
}
]
}
```
------
1. 使用[步骤 4：测试创建密钥](#tutorial_abac_step4)和[步骤 5：测试查看密钥](#tutorial_abac_step5)中的过程。在另一个浏览器窗口中，确认 Saanvi 可以代入这两个角色。检查她是否只能根据角色的标签为项目、团队和成本中心创建密钥。此外，确认她能够查看有关工程团队拥有的所有密钥（包括她刚创建的密钥）的详细信息。
## 步骤 7：测试更新和删除密钥
附加到角色的 `access-same-project-team` 策略允许员工更新和删除任何标记有项目、团队和成本中心的密钥。通过在 Secrets Manager 中测试您的角色来确认您的权限按预期工作。
**测试更新和删除带有和不带有所需标签的密钥**
1. 以下列某个 IAM 用户身份登录：
+ `access-Arnav-peg-eng`
+ `access-Mary-peg-qas`
+ `access-Saanvi-uni-eng`
+ `access-Carlos-uni-qas`
+ `access-Nikhil-cen-eng`
1. 切换到匹配的角色：
+ `access-peg-engineering`
+ `access-peg-quality-assurance`
+ `access-uni-engineering`
+ `access-peg-quality-assurance`
+ `access-cen-engineering`
有关在 AWS 管理控制台中切换角色的更多信息，请参阅[从用户切换到 IAM 角色（控制台）](id_roles_use_switch-role-console.md)。
1. 对于每个角色，请尝试更新密钥描述，然后尝试删除以下密钥。有关更多信息，请参阅 *AWS Secrets Manager 用户指南*中的[修改密钥](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_update-secret.html)和[删除和还原密钥](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-restore-secret.html)。
下表显示每个角色的 ABAC 密钥更新和删除行为。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
## 摘要
您现在已成功完成将标签用于基于属性的访问控制 (ABAC) 所需的所有步骤。您已了解如何定义标记策略。您已将该策略应用于主体和资源。您已创建并应用一个为 Secrets Manager 强制实施该策略的策略。您还了解到，在添加新项目和团队成员时，ABAC 可以轻松扩展。因此，您可以使用测试角色登录 IAM 控制台，并体验如何在 AWS 中将标签用于 ABAC。
**注意**
您添加的策略仅允许在特定条件下执行操作。如果您将不同的策略应用于具有更广泛权限的用户或角色，则可能不会将操作限制为需要标记。例如，如果您使用 `AdministratorAccess`AWS 托管策略向用户授予完全管理权限，则这些策略不会限制该访问。有关在涉及多个策略时如何确定权限的更多信息，请参阅[AWS 执行代码逻辑如何评估允许或拒绝访问的请求](reference_policies_evaluation-logic_policy-eval-denyallow.md)。
## 相关资源
有关信息，请参阅以下资源：
+ [使用 ABAC 授权根据属性定义权限](introduction_attribute-based-access-control.md)
+ [AWS 全局条件上下文密钥](reference_policies_condition-keys.md)
+ [创建角色，向 IAM 用户授予权限](id_roles_create_for-user.md)
+ [AWS Identity and Access Management 资源的标签](id_tags.md)
+ [使用标签控制对 AWS 资源的访问](access_tags.md)
+ [从用户切换到 IAM 角色（控制台）](id_roles_use_switch-role-console.md)
+ [IAM 教程：将 SAML 会话标签用于 ABAC](tutorial_abac-saml.md)
要了解如何监控账户中的标签，请参阅[使用无服务器工作流程和 Amazon CloudWatch Events](https://aws.amazon.com/blogs/mt/monitor-tag-changes-on-aws-resources-with-serverless-workflows-and-amazon-cloudwatch-events/) 监控 AWS 资源的标签更改。
# IAM 教程：将 SAML 会话标签用于 ABAC
基于属性的访问权限控制 (ABAC) 是一种授权策略，该策略基于属性来定义权限。在 AWS 中，这些属性称为标签。您可以将标签附加到 IAM 资源（包括 IAM 实体（用户和角色））以及 AWS 资源。将实体用于向 AWS 发出请求时，实体成为主体并且包含标签。
您也可以在代入角色或联合身份用户时传递[会话标签](id_session-tags.md)。然后，您可以定义策略，这些策略使用标签条件键来根据主体的标签向其授予权限。当您使用标签控制对 AWS 资源的访问时，可通过对 AWS 策略进行较少更改来实现团队和资源的增长。ABAC 策略比传统 AWS 策略更加灵活，后者需要您列出每个单独的资源。有关 ABAC 及其相对于传统策略的优势的更多信息，请参阅[使用 ABAC 授权根据属性定义权限](introduction_attribute-based-access-control.md)。
如果您的公司使用基于 SAML 的身份提供程序 (IdP) 管理公司用户身份，则可以在 AWS 中使用 SAML 属性进行细粒度访问控制。属性包括成本中心标识符、用户电子邮件地址、部门分类和项目分配等。当您将这些属性作为会话标签传递时，可以根据这些会话标签控制对 AWS 的访问权限。
要通过将 SAML 属性传递给会话主体来完成 [ABAC 教程](tutorial_attribute-based-access-control.md)，请完成 [IAM 教程：根据标签定义访问 AWS 资源的权限](tutorial_attribute-based-access-control.md) 中的任务以及本主题中介绍的更改。
## 先决条件
要执行将 SAML 会话标签用于 ABAC 的步骤，您必须满足以下条件：
+ 对基于 SAML 的 IdP 的访问权限，您在其中可以创建具有特定属性的测试用户。
+ 能够以具有管理员权限的用户身份登录。
+ 体验在 AWS 管理控制台 中创建和编辑 IAM 用户、角色和策略。但是，如果您需要获得帮助以便记住 IAM 管理过程，请访问 ABAC 教程提供的链接来查看分步说明。
+ 在 IAM 中设置基于 SAML 的 IdP 的经验。要查看详细信息以及指向详细 IAM 文档的链接，请参阅 [使用 AssumeRoleWithSAML 传递会话标签](id_session-tags.md#id_session-tags_adding-assume-role-saml)。
## 步骤 1：创建测试用户
跳过[步骤 1：创建测试用户](tutorial_attribute-based-access-control.md#tutorial_abac_step1)中的说明。由于您在提供商中定义身份，因此无需为员工添加 IAM 用户。
## 步骤 2：创建 ABAC 策略
按照 [步骤 2：创建 ABAC 策略](tutorial_attribute-based-access-control.md#tutorial_abac_step2) 中的说明在 IAM 中创建指定的托管策略。
## 步骤 3：创建和配置 SAML 角色
为 SAML 使用 ABAC 教程时，您必须执行额外的步骤来创建角色、配置 SAML IdP 和启用 AWS 管理控制台 访问权限。有关更多信息，请参阅 [步骤 3：创建角色](tutorial_attribute-based-access-control.md#tutorial_abac_step3)。
### 步骤 3A：创建 SAML 角色
创建一个信任 SAML 身份提供程序和在步骤 1 中创建的 `test-session-tags` 用户的角色。ABAC 教程使用具有不同角色标签的单独角色。由于您从 SAML IdP 传递会话标签，因此只需要一个角色。要了解如何创建基于 SAML 的角色，请参阅[创建用于 SAML 2.0 联合身份验证的角色（控制台）](id_roles_create_for-idp_saml.md)。
将角色命名为 `access-session-tags`。将 `access-same-project-team` 权限策略附加到角色。编辑角色信任策略来使用以下策略。有关如何编辑角色的信任关系的详细说明，请参阅[更新角色信任策略](id_roles_update-role-trust-policy.md)。
以下角色信任策略允许您的 SAML 身份提供程序和 `test-session-tags` 用户代入该角色。在代入角色时，他们必须传递三个指定的会话标签。`sts:TagSession` 操作是允许传递会话标签所必需的。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSamlIdentityAssumeRole",
"Effect": "Allow",
"Action": [
"sts:AssumeRoleWithSAML",
"sts:TagSession"
],
"Principal": {"Federated":"arn:aws:iam::123456789012:saml-provider/ExampleCorpProvider"},
"Condition": {
"StringLike": {
"aws:RequestTag/cost-center": "*",
"aws:RequestTag/access-project": "*",
"aws:RequestTag/access-team": [
"eng",
"qas"
]
},
"StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"}
}
}
]
}
```
------
`AllowSamlIdentityAssumeRole` 语句允许工程和质量保证团队的成员在从示例公司 IdP 将身份联合到 AWS 中时代入此角色。`ExampleCorpProvider` SAML 提供商在 IAM 中定义。管理员已经设置 SAML 断言以传递三个必需的会话标签。断言可以传递额外的标签，但必须存在这三个标签。身份的属性可以具有 `cost-center` 和 `access-project` 标签的任何值。但是，`access-team` 属性值必须匹配 `eng` 或 `qas`，以指示位于工程或质量保证团队中的身份。
### 步骤 3B：配置 SAML IdP
配置您的 SAML IdP 以将 `cost-center`、`access-project` 和 `access-team` 属性作为会话标签传递。有关更多信息，请参阅 [使用 AssumeRoleWithSAML 传递会话标签](id_session-tags.md#id_session-tags_adding-assume-role-saml)。
要将这些属性作为会话标签传递，请在 SAML 断言中包含以下元素。
```
987654
peg
eng
```
### 步骤 3C：启用控制台访问
为联合身份 SAML 用户启用控制台访问权限。有关更多信息，请参阅 [使 SAML 2.0 联合主体能够访问 AWS 管理控制台](id_roles_providers_enable-console-saml.md)。
## 步骤 4：测试创建密钥
使用 `access-session-tags` 角色联合身份到 AWS 管理控制台中。有关更多信息，请参阅 [使 SAML 2.0 联合主体能够访问 AWS 管理控制台](id_roles_providers_enable-console-saml.md)。然后按照说明 [步骤 4：测试创建密钥](tutorial_attribute-based-access-control.md#tutorial_abac_step4) 创建密钥。使用不同的 SAML 身份，该身份的属性与 ABAC 教程中指示的标签匹配。有关更多信息，请参阅 [步骤 4：测试创建密钥](tutorial_attribute-based-access-control.md#tutorial_abac_step4)。
## 步骤 5：测试查看密钥
按照[步骤 5：测试查看密钥](tutorial_attribute-based-access-control.md#tutorial_abac_step5)中的说明查看在上一步中创建的密钥。使用不同的 SAML 身份，该身份的属性与 ABAC 教程中指示的标签匹配。
## 步骤 6：测试可扩展性
按照[步骤 6：测试可扩展性](tutorial_attribute-based-access-control.md#tutorial_abac_step6)中的说明测试可扩展性。要执行此操作，您可在基于 SAML 的 IdP 中添加具有以下属性的新身份：
+ `cost-center = 101010`
+ `access-project = cen`
+ `access-team = eng`
## 步骤 7：测试更新和删除密钥
按照[步骤 7：测试更新和删除密钥](tutorial_attribute-based-access-control.md#tutorial_abac_step7)中的说明更新和删除密钥。使用不同的 SAML 身份，该身份的属性与 ABAC 教程中指示的标签匹配。
**重要**
删除您创建的所有密钥以避免产生费用。有关 Secrets Manager 中定价的详细信息，请参阅 [AWS Secrets Manager 定价](https://aws.amazon.com/secrets-manager/pricing/)。
## 摘要
您现在已成功完成使用 SAML 会话标签和资源标签进行权限管理所需的所有步骤。
**注意**
您添加的策略仅允许在特定条件下执行操作。如果您将不同的策略应用于具有更广泛权限的用户或角色，则可能不会将操作限制为需要标记。例如，如果您使用 `AdministratorAccess`AWS 托管策略向用户授予完全管理权限，则这些策略不会限制该访问。有关在涉及多个策略时如何确定权限的更多信息，请参阅[AWS 执行代码逻辑如何评估允许或拒绝访问的请求](reference_policies_evaluation-logic_policy-eval-denyallow.md)。