本文共 2670 字，大约阅读时间需要 8 分钟。

最近，Amazon Web Services（AWS）启用了IAM用户和角色标签，以简化IAM资源的管理工作。值得注意的是，这个版本还提供了基于属性的访问控制（ABAC）能力，并将AWS资源与IAM主体动态匹配，以“简化大规模的权限管理”。

最近，，以简化IAM资源的管理工作。值得注意的是，这个版本还提供了基于属性的访问控制（ABAC）能力，并将AWS资源与IAM主体动态匹配，以“简化大规模的权限管理”。

是主要的帐户级功能，用来安全地管理对AWS服务和资源的细粒度访问控制。IAM的核心是通过在策略中定义权限并将其附加到适用的主体（IAM用户和角色）来支持基于角色的访问控制（RBAC）。此外，除了支持基于身份和资源的策略之外，IAM还通过可选的条件策略元素和“使用了条件运算符的表达式（等于、小于，等等）”来支持基于属性的访问控制（ABAC），例如IP地址或时间。此外，还可以使用标签动态控制对支持基于标签授权的资源类型（相对较少的）的访问。

IAM产品经理Sulay Shah在一篇介绍性文章中详细地说明了AWS添加的IAM用户和角色标签功能，通过启用委托标记权限和执行标记schema来简化IAM实体的​​管理。，Shah接着说明了如何通过两个新的条件上下文键来启用“基于属性的访问控制（ABAC）来大规模简化权限管理”：

• aws:PrincipalTag/——这个将检查附加到发出请求的主体（用户或角色）的标记是否与指定的键名和值匹配。
• iam:ResourceTag/——这个将检查附加到请求中的目标标识资源（用户或角色）的标记是否与指定的键名和值匹配。
  新功能的一个主要使用场景是根据属性动态地授予IAM主体对AWS资源的访问权限。现在可以通过在一个条件中匹配AWS资源标签来实现——在以下的示例中，可以为每个团队的当前和未来实例和成员操作EC2实例，并且可以通过调整“team”标签值将实例和成员移动到另一个团队：

{  \u0026quot;Version\u0026quot;: \u0026quot;2012-10-17\u0026quot;,  \u0026quot;Statement\u0026quot;: [    {      \u0026quot;Effect\u0026quot;: \u0026quot;Allow\u0026quot;,      \u0026quot;Action\u0026quot;: [        \u0026quot;ec2:RebootInstances\u0026quot;,        \u0026quot;ec2:StartInstances\u0026quot;,        \u0026quot;ec2:StopInstances\u0026quot;      ],      \u0026quot;Resource\u0026quot;: \u0026quot;*\u0026quot;,      \u0026quot;Condition\u0026quot;: {        \u0026quot;StringEquals\u0026quot;: {          \u0026quot;ec2:ResourceTag/team\u0026quot;: \u0026quot;${aws:PrincipalTag/team}\u0026quot;        }      }    }  ]}

另一个重要的使用场景是允许IAM主体基于属性动态地假设IAM角色。虽然通过AWS Organizations进行多账户使用和基于策略的集中式账户管理变得越来越普遍（），但到目前为止，安全地管理底层跨账户IAM角色仍然是一个繁琐的过程。在添加新角色时，需要重复“AssumeRole”语句，并且IAM主体需要被授予访问权限，使用特定角色的ARN作为目标“Resource”。现在可以使用通配符“*”来表示所有的角色，这有利于在条件中对匹配的IAM资源标记进行细粒度访问控制——下面的示例表示只有当角色的“audit”标签值为“true”时才允许主体为每个角色假设一个安全审计：

{  \u0026quot;Version\u0026quot;: \u0026quot;2012-10-17\u0026quot;,  \u0026quot;Statement\u0026quot;: [    {      \u0026quot;Action\u0026quot;: \u0026quot;sts:AssumeRole\u0026quot;,      \u0026quot;Effect\u0026quot;: \u0026quot;Allow\u0026quot;,      \u0026quot;Resource\u0026quot;: \u0026quot;*\u0026quot;,      \u0026quot;Condition\u0026quot;: {        \u0026quot;Bool\u0026quot;: {          \u0026quot;iam:ResourceTag/audit\u0026quot;: \u0026quot;true\u0026quot;        }      }    }  ]}

微软的Azure资源管理器和谷歌的Cloud IAM主要支持RBAC，尽管Cloud IAM在一个私有测试版中（）提供了条件。Kubernetes是一个例外，它支持ABAC和RBAC授权模块。不过，一篇介绍Kubernetes对RBAC的支持的文章承认了ABAC功能强大，但“在Kubernetes中的实现却难以管理和理解”，并建议将RBAC作为首选方法。

AWS在最近的相关新闻中表示，他们已经提供了用来查看服务上次访问的数据的API，以便让用户自动执行权限分析，而这个操作在之前需要通过AWS管理控制台进行手动检查。仍然需要专用IAM用户而不是使用基于IAM角色和的身份联合的场景也将从通过“”页面进行凭证自我管理的可用性改进中受益。

IAM文档中包含了，包括IAM工作原理、策略评估逻辑以及AWS服务支持的IAM功能的专门章节，还包括有关IAM最佳实践和AWS标记策略的指导。用户可以通过身份和访问管理寻求支持。IAM是一项帐户级AWS功能，无需额外费用。

查看英文原文：

转载地址：http://ujvdm.baihongyu.com/