IAM 教程:根据标签定义访问 Amazon 资源的权限
基于属性的访问控制(ABAC)是一种授权策略,该策略基于属性来定义权限。在 Amazon 中,这些属性称为标签。您可以将标签附加到 IAM 资源(包括 IAM 实体(用户和角色))以及 Amazon 资源。您可以定义策略,这些策略使用标签条件键来根据主体的标签向其授予权限。当您使用标签控制对 Amazon 资源的访问时,可通过对 Amazon 策略进行较少更改来实现团队和资源的增长。ABAC 策略比传统 Amazon 策略更加灵活,后者需要您列出每个单独的资源。有关 ABAC 及其相对于传统策略的优势的更多信息,请参阅什么是适用于 Amazon 的 ABAC?。
注意
您必须为每个会话标签传递一个值。Amazon Security Token Service 不支持多值会话标签。
主题
教程概述
本教程说明如何创建一个允许具有主体标签的 IAM 角色 角色访问具有匹配标签的资源的策略并测试该策略。当主体向 Amazon 发出请求时,将根据主体标签和资源标签是否匹配来授予其权限。此策略仅允许用户查看或编辑其作业需要的 Amazon 资源。
情况
假设您是一家名为 Example Corporation 的大公司的开发人员主管,同时也是一名经验丰富的 IAM 管理员。您熟悉 IAM 用户、角色和策略的创建和管理。您希望确保您的开发工程师和质量保证团队成员能够访问其所需的资源。您还需要一个随公司发展而扩展的策略。
您选择使用 Amazon 资源标签和 IAM 角色主体标签来为支持 ABAC 策略的服务实施该策略(从 Amazon Secrets Manager 开始)。要了解哪些服务支持基于标签的授权,请参阅使用 IAM 的Amazon服务。要了解可以在策略中使用哪些标记条件键以及每个服务的操作和资源,请参阅 Amazon 服务的操作、资源和条件键。您可以对基于 SAML 的身份提供程序或 Web 身份提供程序进行配置,将会话标签传递给 Amazon。当您的员工希望联合身份到 Amazon 中时,其属性将应用到 Amazon 中所得到的主体。然后,您可以使用 ABAC 来允许或拒绝基于这些属性的权限。要了解 SAML 联合身份中的会话标签与本教程的不同之处,请参阅IAM 教程:将 SAML 会话标签用于 ABAC。
您的工程和质量保证团队成员是 Pegasus 或 Unicorn 项目。您可以选择以下 3 个字符的项目和团队标签值:
-
access-project
=peg
(对于 Pegasus 项目) -
access-project
=uni
(对于 Unicorn 项目) -
access-team
=eng
(对于工程团队) -
access-team
=qas
(对于质量保证团队)
此外,您选择需要 cost-center
成本分配标签以启用自定义 Amazon 账单报告。有关更多信息,请参阅 Amazon Billing and Cost Management 用户指南 中的使用成本分配标签。
重要决策摘要
-
员工使用 IAM 用户凭证进行登录,然后代入其团队和项目的 IAM 角色 角色。如果您的公司拥有与自己的身份系统,则您可以设置联合身份验证以允许员工在没有 IAM 用户的情况下代入角色。有关更多信息,请参阅IAM 教程:将 SAML 会话标签用于 ABAC。
-
将向所有角色附加同一策略。根据标签允许或拒绝操作。
-
员工可以创建新的资源,但前提是员工必须将相同的标签附加到应用于其角色的资源。这将确保员工能够在创建资源后进行查看。管理员不再需要使用新资源的 ARN 来更新策略。
-
员工可以读取其团队拥有的资源,无论项目如何。
-
员工可以更新和删除其团队和项目拥有的资源。
-
IAM 管理员可以为新项目添加新角色。他们可以创建和标记新的 IAM 用户以允许访问相应的角色。管理员不需要编辑策略来支持新项目或团队成员。
在本教程中,您将标记每个资源,标记项目角色,并将策略添加到角色以允许前面所述的行为。生成的策略允许角色对使用同一项目和团队标签标记的资源进行 Create
、Read
、Update
和 Delete
访问。此策略还允许对使用同一团队标记的资源进行跨项目 Read
访问。

先决条件
要执行本教程中的步骤,您必须已具备以下内容:
-
可使用用户身份登录的具有管理权限的 Amazon Web Services 账户。
-
您的 12 位账户 ID(用于在步骤 3 中创建角色)。
要使用 Amazon Web Services Management Console查找 Amazon 账户 ID 号,请在右上角的导航栏上选择 Support (支持),然后选择 Support Center (支持中心)。账户号 (ID) 将显示在左侧的导航窗格中。
-
体验在 Amazon Web Services Management Console 中创建和编辑 IAM 用户、角色和策略。但是,如果您需要获得帮助以便记住 IAM 管理过程,请访问本教程提供的链接来查看分步说明。
步骤 1:创建测试用户
为了进行测试,请创建四个有权代入具有相同标签的角色的 IAM 用户。这可让您更轻松地向您的团队添加更多用户。在标记用户时,他们会自动获得访问权来代入正确角色。如果用户仅在一个项目和团队中工作,则无需将其添加到角色的信任策略中。
-
创建以下名为
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 用户组中添加和删除用户。
-
创建以下 IAM 用户,附加
access-assume-role
权限策略,并添加以下标签。有关创建和标记新用户的更多信息,请参阅创建 IAM 用户(控制台)。ABAC 用户用户名称 用户标签 access-Arnav-peg-eng
access-project
=peg
access-team
=eng
cost-center
=987654
access-Mary-peg-qas
access-project
=peg
access-team
=qas
cost-center
=987654
access-Saanvi-uni-eng
access-project
=uni
access-team
=eng
cost-center
=123456
access-Carlos-uni-qas
access-project
=uni
access-team
=qas
cost-center
=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。要了解此块不允许哪些操作,请参阅 Amazon 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 工厂 |
|
|
允许工程师读取所有工程资源以及创建和管理 Pegasus 工程资源。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
项目 Pegasus 质量保证 |
|
|
允许 QA 团队读取所有 QA 资源以及创建和管理所有 Pegasus QA 资源。 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
项目 Unicorn 工程 |
|
|
允许工程师读取所有工程资源以及创建和管理 Unicorn 工程资源。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
项目 Unicorn 质量保证 |
|
|
允许 QA 团队读取所有 QA 资源以及创建和管理所有 Unicorn QA 资源。 |
步骤 4:测试创建密钥
附加到角色的权限策略允许员工创建密钥。仅在使用其项目、团队和成本中心标记密钥时允许这样做。通过在 Secrets Manager 中以用户身份登录、代入正确的角色并测试活动,确认您的权限按预期工作。
测试创建带有和不带有所需标签的密钥
-
在您的主浏览器窗口中,仍以管理员用户身份登录,以便能在 IAM 中查看用户、角色和策略。使用浏览器无痕窗口或单独的浏览器来进行测试。在那里,以
access-Arnav-peg-eng
IAM 用户的身份登录并打开 Secrets Manager 控制台,地址:https://console.aws.amazon.com/secretsmanager/。 -
尝试切换到
access-uni-engineering
角色。有关在 Amazon Web Services Management Console中切换角色的更多信息,请参阅切换到角色(控制台)。此操作失败,因为
access-project
和cost-center
标签值与access-Arnav-peg-eng
用户和access-uni-engineering
角色的不匹配。 -
切换到
access-peg-engineering
角色。有关在 Amazon Web Services Management Console中切换角色的更多信息,请参阅切换到角色(控制台)。 -
使用以下信息存储新密钥。要了解如何存储密钥,请参阅 Amazon Secrets Manager 用户指南中的创建基本密钥。
-
在 Select secret type (选择密钥类型) 部分中,选择 Other type of secrets (其他类型的密钥)。在两个文本框中,输入
test-access-key
和test-access-secret
。您必须拥有额外的权限才能保存特定的 Amazon 服务的凭证。例如,要创建 Amazon RDS 数据库凭证,您必须有权描述 RDS 实例、RDS 集群和 Amazon Redshift 集群。
-
为 Secret name (密钥名称) 字段输入
test-access-peg-eng
。 -
从下表添加不同的标签组合,并查看预期行为。
-
选择 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
标签。 -
-
注销并针对以下每个角色和标签值重复此过程的前三个步骤。在此过程的第四步中,测试所选的任何一组缺少的标签、可选标签、不允许的标签和无效的标签值。然后,使用所需的标签创建具有以下标签和名称的密钥。
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 中测试您的角色来确认您的权限按预期工作。
测试查看带有或不带有所需标签的密钥
-
以下列某个 IAM 用户身份登录:
-
access-Arnav-peg-eng
-
access-Mary-peg-qas
-
access-Saanvi-uni-eng
-
access-Carlos-uni-qas
-
-
切换到匹配的角色:
-
access-peg-engineering
-
access-peg-quality-assurance
-
access-uni-engineering
-
access-uni-quality-assurance
有关在 Amazon Web Services Management Console中切换角色的更多信息,请参阅切换到角色(控制台)。
-
-
在左侧导航窗格中,选择菜单图标以展开菜单,然后选择 Secrets (密钥)。
-
无论您当前的角色如何,都应在表中看到所有四个密钥。这是预期情况,因为名为
access-same-project-team
的策略允许对所有资源执行secretsmanager:ListSecrets
操作。 -
选择其中一个密钥的名称。
-
在密钥的详细信息页面上,您的角色标签将确定您是否能查看页面内容。将您的角色名称与您的密钥名称进行比较。如果它们共享同一团队名称,则
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
已允许 -
从页面顶部的痕迹导航中,选择 Secrets (密钥) 以返回密钥列表。使用不同的角色重复此过程中的步骤来测试您是否能查看每个密钥。
步骤 6:测试可扩展性
在基于角色的访问控制 (RBAC) 上使用基于属性的访问控制 (ABAC) 的重要原因是可扩展性。当您的公司向 Amazon 添加新的项目、团队或人员时,您无需更新 ABAC 驱动型策略。例如,假设 Example Company 正在资助一个代号为 Centaur 的新项目。一个名叫 Saanvi Sarkar 的工程师将成为 Centaur 的工程师主管,同时该工程师还参与了 Unicorn 项目。Saanvi 还将审查 Peg 项目的工作。此外,新聘用了几名工程师,其中包括 Nikhil Jayashankar,他仅参与 Centaur 项目。
向 Amazon 添加新项目
-
以 IAM 管理员登录,然后通过以下网址打开 IAM 控制台:https://console.aws.amazon.com/iam/
。 -
在左侧导航窗格中,选择 Roles(角色),然后添加名为
access-cen-engineering
的 IAM 角色。将access-same-project-team
权限策略附加到角色并添加以下标签:-
access-project
=cen
-
access-team
=eng
-
cost-center
=101010
-
-
在左侧导航窗格中,请选择用户。
-
添加一个名为
access-Nikhil-cen-eng
的新用户,并附加名为access-assume-role
的策略。 -
使用步骤 4:测试创建密钥和步骤 5:测试查看密钥中的过程。在另一个浏览器窗口中,测试 Nikhil 是否能创建 Centaur 工程密钥并且是否能查看所有工程密钥。
-
在您以管理员身份登录的主浏览器窗口中,选择用户
access-Saanvi-uni-eng
。 -
在 Permissions (权限) 选项卡上,删除 access-assume-role 权限策略。
-
添加以下名为
access-assume-specific-roles
的内联策略。有关将内联策略添加到用户的更多信息,请参阅为用户或角色嵌入内联策略(控制台)。ABAC 策略:仅代入特定角色
此策略允许 Saanvi 代入 Pegasus 或 Centaur 项目的工程角色。由于 IAM 不支持多值标签,因此有必要创建此自定义策略。不能使用
access-project
=peg
和access-project
=cen
标记 Saanvi 用户。此外,Amazon 授权模型不能同时与这两个值匹配。有关更多信息,请参阅在 IAM 和 Amazon 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" ] } ] } -
使用步骤 4:测试创建密钥和步骤 5:测试查看密钥中的过程。在另一个浏览器窗口中,确认 Saanvi 可以代入这两个角色。检查她是否只能根据角色的标签为项目、团队和成本中心创建密钥。此外,确认她能够查看有关工程团队拥有的所有密钥(包括她刚创建的密钥)的详细信息。
步骤 7:测试更新和删除密钥
附加到角色的 access-same-project-team
策略允许员工更新和删除任何标记有项目、团队和成本中心的密钥。通过在 Secrets Manager 中测试您的角色来确认您的权限按预期工作。
测试更新和删除带有和不带有所需标签的密钥
-
以下列某个 IAM 用户身份登录:
-
access-Arnav-peg-eng
-
access-Mary-peg-qas
-
access-Saanvi-uni-eng
-
access-Carlos-uni-qas
-
access-Nikhil-cen-eng
-
-
切换到匹配的角色:
-
access-peg-engineering
-
access-peg-quality-assurance
-
access-uni-engineering
-
access-peg-quality-assurance
-
access-cen-engineering
有关在 Amazon Web Services Management Console中切换角色的更多信息,请参阅切换到角色(控制台)。
-
-
对于每个角色,请尝试更新密钥描述,然后尝试删除以下密钥。有关更多信息,请参阅 Amazon 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
已允许
摘要
您现在已成功完成将标签用于基于属性的访问控制 (ABAC) 所需的所有步骤。您已了解如何定义标记策略。您已将该策略应用于主体和资源。您已创建并应用一个为 Secrets Manager 强制实施该策略的策略。您还了解到,在添加新项目和团队成员时,ABAC 可以轻松扩展。因此,您可以使用测试角色登录 IAM 控制台,并体验如何在 Amazon 中将标签用于 ABAC。
注意
您添加的策略仅允许在特定条件下执行操作。如果您将不同的策略应用于具有更广泛权限的用户或角色,则可能不会将操作限制为需要标记。例如,如果您使用 AdministratorAccess
Amazon 托管策略向用户授予完全管理权限,则这些策略不会限制该访问。有关在涉及多个策略时如何确定权限的更多信息,请参阅确定是允许还是拒绝账户内的请求。
相关资源
有关 IAM 用户指南 中的相关信息,请参阅以下资源:
要了解如何监控账户中的标签,请参阅使用无服务器工作流程和 Amazon CloudWatch Events