SEC02-BP06 使用用户组和属性
根据用户组和属性来定义权限，可以减少策略的数量和复杂性，这样就更容易实现最低权限原则。您可以通过用户组，根据用户在企业中履行的职能，从一个位置管理多个用户的权限。当用户履行类似的职能但面向的是不同资源子集时，可以利用部门、项目或位置等属性来提供额外的一层权限范围。
期望结果：您可以将基于职能的权限更改应用到履行该职能的所有用户。利用组成员资格和属性管控用户的权限，减少在单个用户级别管理权限的需求。您在身份提供者（IdP）中定义的组和属性会自动传播到您的 AWS 环境。
常见反模式：
-
分别管理每个用户的权限，然后在多个用户之间复制。
-
定义过于宽泛的组，授予过于宽泛的权限。
-
定义过于精细的组，造成成员重复和混淆。
-
对不同资源子集使用具有重复权限的组，但其实可以改为使用属性来进行控制。
-
在管理组、属性和成员资格时，没有使用与您的 AWS 环境集成的标准化身份提供者。
-
使用 AWS IAM Identity Center 会话时使用角色链
在未建立这种最佳实践的情况下暴露的风险等级：中
实施指导
在称为策略 的文档中定义 AWS 权限，这些策略与某个主体关联，例如用户、组、角色或资源。可以根据工作职能、工作负载和 SDLC 环境来组织权限分配（组、权限、账户），从而扩展权限管理。对于员工团队，通过这种方法，您可以根据用户在企业中履行的职能来定义组，而不是根据所访问的资源来定义。例如，WebAppDeveloper 组可能附有策略，用于在开发账户中配置 Amazon CloudFront 等服务。AutomationDeveloper 组可能与 WebAppDeveloper 组具有一些重叠的权限。可以将这些共有的权限放置在单独的策略中并与这两个组关联，而不是将来自这两个职能部门的用户都放在同一个 CloudFrontAccess 组中。
除了使用组之外，您还可以使用属性来进一步限定访问范围。例如，您可以为 WebAppDeveloper 组中的用户设置“项目”属性，用来限定对其项目特定资源的访问权限。使用这种技巧，您就无需为处理不同项目的应用程序开发人员设置不同的组，因为他们除了项目不同外，所需的权限其实并无不同。在权限策略中引用属性的方式取决于权限的来源，这些权限可能包含在联合身份验证协议（例如 SAML、OIDC 或 SCIM）中，可能是自定义的 SAML 断言，也可能是在 IAM Identity Center 中设置。
实施步骤
-
确定要在何处定义组和属性：
-
按照 SEC02-BP04 依赖集中式身份提供者中的指南，您可以确定是要在身份提供者中或 IAM Identity Center 中定义组和属性，还是在特定账户中使用 IAM 用户组。
-
-
定义组：
-
根据职能和所需访问权限范围来确定组。考虑使用分层结构或命名约定来有效地整理组。
-
如果在 IAM Identity Center 中定义，则创建组并使用权限集关联所需的访问权限级别。
-
如果在外部身份提供者中定义，请确定该提供者是否支持 SCIM 协议，并考虑在 IAM Identity Center 中启用自动预置。此功能可在您的提供者和 IAM Identity Center 之间同步组的创建、成员指派和删除。
-
-
定义属性：
-
如果使用外部身份提供者，则默认情况下，SCIM 和 SAML 2.0 协议都提供一些属性。使用
https://aws.amazon.com/SAML/Attributes/PrincipalTag属性名称，可以通过 SAML 断言来定义并传递其它属性。有关定义和配置自定义属性的指南，请咨询身份提供者的文档。 -
如果在 IAM Identity Center 中定义角色，请启用基于属性的访问权限控制（ABAC）功能，然后根据需要定义属性。考虑符合组织的结构或资源标签策略的属性。
-
如果您需要从通过 IAM Identity Center 代入的 IAM 角色中获得的 IAM 角色链，则诸如 source-identity 和 principal-tags 的值将不会传播。有关更多详细信息，请参阅启用并配置访问控制属性。
-
根据组和属性限定权限范围：
-
考虑在权限策略中加入条件，将主体的属性与所访问资源的属性进行比较。例如，您可以定义一个条件，仅当
PrincipalTag条件键的值与相同名称的ResourceTag键的值匹配时，才支持访问资源。 -
定义 ABAC 策略时，请遵循 ABAC 授权最佳实践和示例中的指导。
-
随着组织需求的发展，请定期审核和更新组和属性结构，以确保最佳的权限管理。
-
资源
相关最佳实践：
相关文档：
相关视频：
