IAM 教程：根据标签定义访问 AWS 资源的权限 - AWS Identity and Access Management
教程概述先决条件步骤 1：创建测试用户步骤 2：创建 ABAC 策略步骤 3：创建角色步骤 4：测试创建密钥步骤 5：测试查看密钥步骤 6：测试可扩展性步骤 7：测试更新和删除密钥Summary相关资源

IAM 教程：根据标签定义访问 AWS 资源的权限

基于属性的访问控制 (ABAC) 是一种授权策略，该策略基于属性来定义权限。在 AWS 中，这些属性被称为“标签”。您可以将标签附加到 IAM 资源（包括 IAM 实体（用户和角色））以及 AWS 资源。您可以定义策略，这些策略使用标签条件键来根据主体的标签向其授予权限。当您使用标签控制对 AWS 资源的访问时，可通过对 AWS 策略进行较少更改来实现团队和资源的增长。ABAC 策略比传统 AWS 策略更加灵活，后者需要您列出每个单独的资源。有关 ABAC 及其相对于传统策略的优势的更多信息，请参阅什么是适用于 AWS 的 ABAC？。

注意

您必须为每个会话标签传递一个值。AWS Security Token Service 不支持多值会话标签。

主题

教程概述

本教程说明如何创建一个允许具有主体标签的 IAM 角色 角色访问具有匹配标签的资源的策略并测试该策略。当主体向 AWS 发出请求时，将根据主体标签和资源标签是否匹配来授予其权限。此策略仅允许用户查看或编辑其作业需要的 AWS 资源。

场景

假设您是一家名为 Example Corporation 的大公司的开发人员主管，同时也是一名经验丰富的 IAM 管理员。您熟悉 IAM 用户、角色和策略的创建和管理。您希望确保您的开发工程师和质量保证团队成员能够访问其所需的资源。您还需要一个随公司发展而扩展的策略。

您选择使用 AWS 资源标签和 IAM 角色主体标签来为支持 ABAC 策略的服务实施该策略（从 AWS Secrets Manager 开始）。要了解哪些服务支持基于标签的授权，请参阅使用 IAM 的AWS服务。要了解可以在策略中使用哪些标记条件键以及每个服务的操作和资源，请参阅 AWS 服务的操作、资源和条件键。您可以对基于 SAML 的身份提供程序或 Web 身份提供程序进行配置，将会话标签传递给 AWS。当您的员工希望联合身份到 AWS 中时，其属性将应用到 AWS 中所得到的主体。然后，您可以使用 ABAC 来允许或拒绝基于这些属性的权限。要了解 SAML 联合身份中的会话标签与本教程的不同之处，请参阅IAM 教程：将 SAML 会话标签用于 ABAC。

您的工程和质量保证团队成员是 Pegasus 或 Unicorn 项目。您可以选择以下 3 个字符的项目和团队标签值：

  • access-project = peg（对于 Pegasus 项目）

  • access-project = uni（对于 Unicorn 项目）

  • access-team = eng（对于工程团队）

  • access-team = qas（对于质量保证团队）

此外，您选择需要 cost-center 成本分配标签以启用自定义 AWS 账单报告。有关更多信息，请参阅《AWS Billing and Cost Management 用户指南》中的使用成本分配标签。

重要决策摘要

  • 员工使用 IAM 用户凭证进行登录，然后代入其团队和项目的 IAM 角色 角色。如果您的公司拥有与自己的身份系统，则您可以设置联合身份验证以允许员工在没有 IAM 用户的情况下代入角色。有关更多信息，请参阅IAM 教程：将 SAML 会话标签用于 ABAC。

  • 将向所有角色附加同一策略。根据标签允许或拒绝操作。

  • 员工可以创建新的资源，但前提是员工必须将相同的标签附加到应用于其角色的资源。这将确保员工能够在创建资源后进行查看。管理员不再需要使用新资源的 ARN 来更新策略。

  • 员工可以读取其团队拥有的资源，无论项目如何。

  • 员工可以更新和删除其团队和项目拥有的资源。

  • IAM 管理员可以为新项目添加新角色。他们可以创建和标记新的 IAM 用户以允许访问相应的角色。管理员不需要编辑策略来支持新项目或团队成员。

在本教程中，您将标记每个资源，标记项目角色，并将策略添加到角色以允许前面所述的行为。生成的策略允许角色对使用同一项目和团队标签标记的资源进行 Create、Read、Update 和 Delete 访问。此策略还允许对使用同一团队标记的资源进行跨项目 Read 访问。

ABAC 教程权限设计

先决条件

要执行本教程中的步骤，您必须已具备以下内容：

  • 可使用用户身份登录的具有管理权限的 AWS 账户。

  • 您的 12 位账户 ID（用于在步骤 3 中创建角色）。

    要使用 AWS Management Console查找 AWS 账户 ID 号，请在右上角的导航栏上选择 Support (支持)，然后选择 Support Center (支持中心)。账户号 (ID) 将显示在左侧的导航窗格中。

  • 体验在 AWS Management Console 中创建和编辑 IAM 用户、角色和策略。但是，如果您需要获得帮助以便记住 IAM 管理过程，请访问本教程提供的链接来查看分步说明。

步骤 1：创建测试用户

为了进行测试，请创建四个有权代入具有相同标签的角色的 IAM 用户。这可让您更轻松地向您的团队添加更多用户。在标记用户时，他们会自动获得访问权来代入正确角色。如果用户仅在一个项目和团队中工作，则无需将其添加到角色的信任策略中。

  1. 创建以下名为 access-assume-role 的客户托管策略。有关创建 JSON 策略的更多信息，请参阅创建 IAM policy。

    ABAC 策略：代入任何 ABAC 角色，但前提是用户和角色标签匹配

    以下策略允许用户在您的账户中代入任何带有 access- 名称前缀的角色。还必须使用与用户相同的项目、团队和成本中心来标记角色。

    要使用此策略，请将示例策略中的斜体占位符文本替换为您的账户信息。

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "TutorialAssumeRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::account-ID-without-hyphens: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 用户组和 在 IAM 用户组中添加和删除用户。

  2. 创建以下 IAM 用户，附加 access-assume-role 权限策略。确保选择向用户提供对 AWS Management Console 的访问权限，然后添加以下标签。有关创建和标记新用户的更多信息，请参阅创建 IAM 用户（控制台）。

    ABAC 用户
    用户名称 用户标签键 用户标签值

    access-Arnav-peg-eng

    access-project

    access-team

    cost-center

    peg

    eng

    987654

    access-Mary-peg-qas

    access-project

    access-team

    cost-center

    peg

    qas

    987654

    access-Saanvi-uni-eng

    access-project

    access-team

    cost-center

    uni

    eng

    123456

    access-Carlos-uni-qas

    access-project

    access-team

    cost-center

    uni

    qas

    123456

步骤 2：创建 ABAC 策略

创建以下名为 access-same-project-team 的策略。您将在以后的步骤中将此策略添加到角色。有关创建 JSON 策略的更多信息，请参阅创建 IAM policy。

有关可针对本教程调整的其他策略，请参阅以下页面：

ABAC 策略：仅在主体标签和资源标签匹配时访问 Secrets Manager 资源

以下策略允许主体创建、读取、编辑和删除资源，但前提是已使用与主体相同的键/值对标记这些资源。当主体创建资源时，必须添加 access-project、access-team 和 cost-center 标签以及与主体的标签匹配的值。该策略还允许添加可选的 Name 或 OwnedBy 标签。

{
 "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 的操作、资源和条件键。此页面指明对 Secret (密钥) 资源类型执行的操作支持 secretsmanager:ResourceTag/tag-key 条件键。某些 Secrets Manager 操作不支持该资源类型，包括 GetRandomPassword 和 ListSecrets。您必须创建额外语句才能允许这些操作。

    • 如果请求中传递的每个标签键都包含在指定列表中，则第二个条件块将返回 true。通过将 ForAllValues 和 StringEquals 条件运算符结合使用来执行此操作。如果没有传递键或一组键的子集，则条件返回 true。对于不允许在请求中传递标签的 Get* 操作，这将允许该操作。如果请求者包含列表中没有的标签键，则条件返回 false。请求中传递的每个标签键均必须与该列表的一个成员匹配。有关更多信息，请参阅多值上下文键。

    • 在以下情况下，第三个条件块将返回 true：请求支持传递标签；所有三个标签都存在；标签与主体标签值匹配。如果请求不支持传递标签，则此块也返回 true。这要归功于条件运算符中的 ...IfExists。如果在支持该块的操作期间未传递任何标签，或者标签键和值不匹配，则该块将返回 false。

  • AllResourcesSecretsManagerNoTags 语句允许 GetRandomPassword 和 ListSecrets 操作，而第一个语句不允许这两项操作。

  • 如果使用与资源相同的 access-team 标签来标记主体，则 ReadSecretsManagerSameTeam 语句允许只读操作。无论项目或成本中心标签如何，都允许此操作。

  • DenyUntagSecretsManagerReservedTags 语句拒绝从 Secrets Manager 中删除带有以“access-”开头的键的标签的请求。这些标签用于控制对资源的访问，因此删除这些标签可能会删除权限。

  • DenyPermissionsManagement 语句拒绝访问创建、编辑或删除 Secrets Manager 的基于资源的策略。这些策略可用于更改密钥的权限。

重要

此策略使用一种策略来允许服务的所有操作，但明确拒绝权限更改操作。拒绝操作将覆盖任何其他允许主体执行该操作的策略。这可能会产生意外结果。作为最佳实践，仅在没有允许该操作的情况下才使用显式拒绝。否则，允许各个操作的列表，默认情况下将拒绝不需要的操作。

步骤 3：创建角色

创建以下 IAM 角色并附加您在上一步中创建的 access-same-project-team 策略。有关创建 IAM 角色的更多信息，请参阅 创建向 IAM 用户委派权限的角色。如果选择使用联合身份而不是 IAM 用户和角色，请参阅 IAM 教程：将 SAML 会话标签用于 ABAC。

ABAC 角色
作业函数 角色名称 角色标签 角色描述

项目 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/。

  2. 尝试切换到 access-uni-engineering 角色。

    此操作失败，因为 access-project 和 cost-center 标签值与 access-Arnav-peg-eng 用户和 access-uni-engineering 角色的不匹配。

    有关在 AWS Management Console 中切换角色的更多信息，请参阅 切换到角色（控制台）。

  3. 切换到 access-peg-engineering 角色。

  4. 使用以下信息存储新密钥。要了解如何存储密钥，请参阅 AWS Secrets Manager 用户指南中的创建基本密钥。

    重要

    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。

    2. 为 Secret name (密钥名称) 字段输入 test-access-peg-eng。

    3. 从下表添加不同的标签组合，并查看预期行为。

    4. 选择 Store (存储) 以尝试创建密钥。当存储失败时，请返回之前的 Secrets Manager 控制台页面，并使用下表中的下一个标签集。允许使用最后一个标签集，并且将成功创建密钥。

    test-access-peg-eng 角色的 ABAC 标签组合
    access-project 标签值 access-team 标签值 cost-center 标签值 其他标签 预期行为
    (无) (无) (无) (无) 已拒绝，因为 access-project 标签值与角色的 peg 值不匹配。
    uni eng 987654 (无) 已拒绝，因为 access-project 标签值与角色的 peg 值不匹配。
    peg qas 987654 (无) 已拒绝，因为 access-team 标签值与角色的 eng 值不匹配。
    peg eng 123456 (无) 已拒绝，因为 cost-center 标签值与角色的 987654 值不匹配。
    peg eng 987654 owner = Jane 已拒绝，因为策略不允许额外的标签 owner，即使所有三个所需标签都存在且其值与角色的值匹配也是如此。
    peg eng 987654 Name = Jane 已允许，因为所有三个所需标签都存在且其值与角色的值匹配。此外，允许您包含可选的 Name 标签。

  5. 注销并针对以下每个角色和标签值重复此过程的前三个步骤。在此过程的第四步中，测试所选的任何一组缺少的标签、可选标签、不允许的标签和无效的标签值。然后，使用所需的标签创建具有以下标签和名称的密钥。

    ABAC 角色和标签
    用户名称 角色名称 密钥名称 密钥标签

    access-Mary-peg-qas

    access-peg-quality-assurance

    test-access-peg-qas

    access-project = peg

    access-team = qas

    cost-center = 987654

    access-Saanvi-uni-eng

    access-uni-engineering

    		 test-access-uni-eng

    access-project = uni

    access-team = eng

    cost-center = 123456

    access-Carlos-uni-qas

    access-uni-quality-assurance

    test-access-uni-qas

    access-project = uni

    access-team = qas

    cost-center = 123456

步骤 5：测试查看密钥

您附加到每个角色的策略允许员工查看标记有其团队名称的所有密钥，而不管其项目如何。通过在 Secrets Manager 中测试您的角色来确认您的权限按预期工作。

测试查看带有或不带有所需标签的密钥

  1. 以下列某个 IAM 用户身份登录：

    • access-Arnav-peg-eng

    • access-Mary-peg-qas

    • access-Saanvi-uni-eng

    • access-Carlos-uni-qas

  2. 切换到匹配的角色：

    • access-peg-engineering

    • access-peg-quality-assurance

    • access-uni-engineering

    • access-uni-quality-assurance

    有关在 AWS Management Console中切换角色的更多信息，请参阅切换到角色（控制台）。

  3. 在左侧导航窗格中，选择菜单图标以展开菜单，然后选择 Secrets (密钥)。

  4. 无论您当前的角色如何，都应在表中看到所有四个密钥。这是预期情况，因为名为 access-same-project-team 的策略允许对所有资源执行 secretsmanager:ListSecrets 操作。

  5. 选择其中一个密钥的名称。

  6. 在密钥的详细信息页面上，您的角色标签将确定您是否能查看页面内容。将您的角色名称与您的密钥名称进行比较。如果它们共享同一团队名称，则 access-team 标签匹配。如果它们不匹配，则访问将被拒绝。

    每个角色的 ABAC 密钥查看行为
    角色名称 密钥名称 预期行为
    access-peg-engineering test-access-peg-eng 已允许
    test-access-peg-qas 已拒绝
    test-access-uni-eng 已允许
    test-access-uni-qas 已拒绝
    access-peg-quality-assurance test-access-peg-eng 已拒绝
    test-access-peg-qas 已允许
    test-access-uni-eng 已拒绝
    test-access-uni-qas 已允许
    access-uni-engineering test-access-peg-eng 已允许
    test-access-peg-qas 已拒绝
    test-access-uni-eng 已允许
    test-access-uni-qas 已拒绝
    access-uni-quality-assurance test-access-peg-eng 已拒绝
    test-access-peg-qas 已允许
    test-access-uni-eng 已拒绝
    test-access-uni-qas 已允许

  7. 从页面顶部的痕迹导航中，选择 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/。

  2. 在左侧导航窗格中，选择 Roles（角色），然后添加名为 access-cen-engineering 的 IAM 角色。将 access-same-project-team 权限策略附加到角色并添加以下角色标签：

    • access-project = cen

    • access-team = eng

    • cost-center = 101010

  3. 在左侧导航窗格中，请选择用户。

  4. 添加一个名为 access-Nikhil-cen-eng 的新用户，并附加名为 access-assume-role 的策略，然后添加以下用户标签。

    • access-project = cen

    • access-team = eng

    • cost-center = 101010

  5. 使用步骤 4：测试创建密钥和步骤 5：测试查看密钥中的过程。在另一个浏览器窗口中，测试 Nikhil 是否能创建 Centaur 工程密钥并且是否能查看所有工程密钥。

  6. 在您以管理员身份登录的主浏览器窗口中，选择用户 access-Saanvi-uni-eng。

  7. 在 Permissions (权限) 选项卡上，删除 access-assume-role 权限策略。

  8. 添加以下名为 access-assume-specific-roles 的内联策略。有关将内联策略添加到用户的更多信息，请参阅为用户或角色嵌入内联策略（控制台）。

    ABAC 策略：仅代入特定角色

    此策略允许 Saanvi 代入 Pegasus 或 Centaur 项目的工程角色。由于 IAM 不支持多值标签，因此有必要创建此自定义策略。不能使用 access-project = peg 和 access-project = cen 标记 Saanvi 用户。此外，AWS 授权模型不能同时与这两个值匹配。有关更多信息，请参阅在 IAM 和 AWS STS 中进行标记的规则。相反，您必须手动指定她可以代入的两个角色。

    要使用此策略，请将示例策略中的斜体占位符文本替换为您的账户信息。

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "TutorialAssumeSpecificRoles",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::account-ID-without-hyphens:role/access-peg-engineering",
                "arn:aws:iam::account-ID-without-hyphens:role/access-cen-engineering"
            ]
        }
    ]
}

  9. 使用步骤 4：测试创建密钥和步骤 5：测试查看密钥中的过程。在另一个浏览器窗口中，确认 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

  2. 切换到匹配的角色：

    • access-peg-engineering

    • access-peg-quality-assurance

    • access-uni-engineering

    • access-peg-quality-assurance

    • access-cen-engineering

    有关在 AWS Management Console中切换角色的更多信息，请参阅切换到角色（控制台）。

  3. 对于每个角色，请尝试更新密钥描述，然后尝试删除以下密钥。有关更多信息，请参阅 AWS Secrets Manager 用户指南中的修改密钥和删除和还原密钥。

    每个角色的 ABAC 密钥更新和删除行为
    角色名称 密钥名称 预期行为

    access-peg-engineering

    test-access-peg-eng

    		 已允许
    test-access-uni-eng 已拒绝
    test-access-uni-qas 已拒绝

    access-peg-quality-assurance

    		 test-access-peg-qas 已允许
    test-access-uni-eng 已拒绝

    access-uni-engineering

    		 test-access-uni-eng 已允许
    test-access-uni-qas 已拒绝

    access-peg-quality-assurance

    		 test-access-uni-qas 已允许

Summary

您现在已成功完成将标签用于基于属性的访问控制 (ABAC) 所需的所有步骤。您已了解如何定义标记策略。您已将该策略应用于主体和资源。您已创建并应用一个为 Secrets Manager 强制实施该策略的策略。您还了解到，在添加新项目和团队成员时，ABAC 可以轻松扩展。因此，您可以使用测试角色登录 IAM 控制台，并体验如何在 AWS 中将标签用于 ABAC。

注意

您添加的策略仅允许在特定条件下执行操作。如果您将不同的策略应用于具有更广泛权限的用户或角色，则可能不会将操作限制为需要标记。例如，如果您使用 AdministratorAccessAWS 托管策略向用户授予完全管理权限，则这些策略不会限制该访问。有关在涉及多个策略时如何确定权限的更多信息，请参阅确定是允许还是拒绝账户内的请求。

有关信息，请参阅以下资源：

要了解如何监控账户中的标签，请参阅使用无服务器工作流程和 Amazon CloudWatch Events 监控 AWS 资源的标签更改。