最近,Amazon Web Services(AWS)启用了 IAM 用户和角色标签,以简化 IAM 资源的管理工作。值得注意的是,这个版本还提供了基于属性的访问控制(ABAC)能力,并将 AWS 资源与 IAM 主体动态匹配,以“简化大规模的权限管理”。
最近,Amazon Web Services(AWS)启用了IAM用户和角色标签,以简化 IAM 资源的管理工作。值得注意的是,这个版本还提供了基于属性的访问控制(ABAC)能力,并将 AWS 资源与 IAM 主体动态匹配,以“简化大规模的权限管理”。
AWS身份和访问管理(IAM)是主要的帐户级功能,用来安全地管理对 AWS 服务和资源的细粒度访问控制。IAM 的核心是通过在策略中定义权限并将其附加到适用的主体(IAM 用户和角色)来支持基于角色的访问控制(RBAC)。此外,除了支持基于身份和资源的策略之外,IAM 还通过可选的条件策略元素和“使用了条件运算符的表达式(等于、小于,等等)”来支持基于属性的访问控制(ABAC),例如 IP 地址或时间。此外,还可以使用标签动态控制对支持基于标签授权的资源类型(相对较少的)的访问。
IAM 产品经理 Sulay Shah 在一篇介绍性文章中详细地说明了 AWS 添加的 IAM 用户和角色标签功能,通过启用委托标记权限和执行标记 schema 来简化 IAM 实体的管理。在随后的文章中,Shah 接着说明了如何通过两个新的条件上下文键来启用“基于属性的访问控制(ABAC)来大规模简化权限管理”:
aws:PrincipalTag/——这个全局条件键将检查附加到发出请求的主体(用户或角色)的标记是否与指定的键名和值匹配。
iam:ResourceTag/——这个IAM条件键将检查附加到请求中的目标标识资源(用户或角色)的标记是否与指定的键名和值匹配。新功能的一个主要使用场景是根据属性动态地授予 IAM 主体对 AWS 资源的访问权限。现在可以通过在一个条件中匹配 AWS 资源标签来实现——在以下的示例中,可以为每个团队的当前和未来实例和成员操作 EC2 实例,并且可以通过调整“team”标签值将实例和成员移动到另一个团队:
另一个重要的使用场景是允许 IAM 主体基于属性动态地假设 IAM 角色。虽然通过 AWS Organizations 进行多账户使用和基于策略的集中式账户管理变得越来越普遍(之前的报道),但到目前为止,安全地管理底层跨账户 IAM 角色仍然是一个繁琐的过程。在添加新角色时,需要重复“AssumeRole”语句,并且 IAM 主体需要被授予访问权限,使用特定角色的 ARN 作为目标“Resource”。现在可以使用通配符“*”来表示所有的角色,这有利于在条件中对匹配的 IAM 资源标记进行细粒度访问控制——下面的示例表示只有当角色的“audit”标签值为“true”时才允许主体为每个角色假设一个安全审计:
微软的 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 功能,无需额外费用。
查看英文原文:https://www.infoq.com/news/2019/02/iam-tags-attribute-based-access
评论