# SEC02-BP06 使用用户组和属性
<a name="sec_identities_groups_attributes"></a>

 根据用户组和属性来定义权限，可以减少策略的数量和复杂性，这样就更容易实现最低权限原则。您可以通过用户组，根据用户在企业中履行的职能，从一个位置管理多个用户的权限。当用户履行类似的职能但面向的是不同资源子集时，可以利用部门、项目或位置等属性来提供额外的一层权限范围。

 **期望结果：**您可以将基于职能的权限更改应用到履行该职能的所有用户。利用组成员资格和属性管控用户的权限，减少在单个用户级别管理权限的需求。您在身份提供者（IdP）中定义的组和属性会自动传播到您的 AWS 环境。

 **常见反模式：**
+  分别管理每个用户的权限，然后在多个用户之间复制。
+  定义过于宽泛的组，授予过于宽泛的权限。
+  定义过于精细的组，造成成员重复和混淆。
+  对不同资源子集使用具有重复权限的组，但其实可以改为使用属性来进行控制。
+  在管理组、属性和成员资格时，没有使用与您的 AWS 环境集成的标准化身份提供者。
+  使用 AWS IAM Identity Center 会话时使用角色链 

 **在未建立这种最佳实践的情况下暴露的风险等级：**中 

## 实施指导
<a name="implementation-guidance"></a>

 在称为*策略* 的文档中定义 AWS 权限，这些策略与某个主体关联，例如用户、组、角色或资源。可以根据工作职能、工作负载和 SDLC 环境来组织权限分配（组、权限、账户），从而扩展权限管理。对于员工团队，通过这种方法，您可以根据用户在企业中履行的职能来定义组，而不是根据所访问的资源来定义。例如，WebAppDeveloper 组可能附有策略，用于在开发账户中配置 Amazon CloudFront 等服务。`AutomationDeveloper` 组可能与 `WebAppDeveloper` 组具有一些重叠的权限。可以将这些共有的权限放置在单独的策略中并与这两个组关联，而不是将来自这两个职能部门的用户都放在同一个 `CloudFrontAccess` 组中。

 除了使用组之外，您还可以使用*属性*来进一步限定访问范围。例如，您可以为 `WebAppDeveloper` 组中的用户设置“项目”属性，用来限定对其项目特定资源的访问权限。使用这种技巧，您就无需为处理不同项目的应用程序开发人员设置不同的组，因为他们除了项目不同外，所需的权限其实并无不同。在权限策略中引用属性的方式取决于权限的来源，这些权限可能包含在联合身份验证协议（例如 SAML、OIDC 或 SCIM）中，可能是自定义的 SAML 断言，也可能是在 IAM Identity Center 中设置。

### 实施步骤
<a name="implementation-steps"></a>

1.  确定要在何处定义组和属性：

   1.  按照 [SEC02-BP04 依赖集中式身份提供者](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)中的指南，您可以确定是要在身份提供者中或 IAM Identity Center 中定义组和属性，还是在特定账户中使用 IAM 用户组。

1.  定义组：

   1.  根据职能和所需访问权限范围来确定组。考虑使用分层结构或命名约定来有效地整理组。

   1.  如果在 IAM Identity Center 中定义，则创建组并使用权限集关联所需的访问权限级别。

   1.  如果在外部身份提供者中定义，请确定该提供者是否支持 SCIM 协议，并考虑在 IAM Identity Center 中启用自动预置。此功能可在您的提供者和 IAM Identity Center 之间同步组的创建、成员指派和删除。

1.  定义属性：

   1.  如果使用外部身份提供者，则默认情况下，SCIM 和 SAML 2.0 协议都提供一些属性。使用 `https://aws.amazon.com/SAML/Attributes/PrincipalTag` 属性名称，可以通过 SAML 断言来定义并传递其它属性。有关定义和配置自定义属性的指南，请咨询身份提供者的文档。

   1.  如果在 IAM Identity Center 中定义角色，请启用基于属性的访问权限控制（ABAC）功能，然后根据需要定义属性。考虑符合组织的结构或资源标签策略的属性。

 如果您需要从通过 IAM Identity Center 代入的 IAM 角色中获得的 IAM 角色链，则诸如 `source-identity` 和 `principal-tags` 的值将不会传播。有关更多详细信息，请参阅[启用并配置访问控制属性](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)。

1.  根据组和属性限定权限范围：

   1.  考虑在权限策略中加入条件，将主体的属性与所访问资源的属性进行比较。例如，您可以定义一个条件，仅当 `PrincipalTag` 条件键的值与相同名称的 `ResourceTag` 键的值匹配时，才支持访问资源。

   1.  定义 ABAC 策略时，请遵循 [ABAC 授权](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)最佳实践和示例中的指导。

   1.  随着组织需求的发展，请定期审核和更新组和属性结构，以确保最佳的权限管理。

## 资源
<a name="resources"></a>

 **相关最佳实践：**
+  [SEC02-BP04 依赖集中式身份提供程序](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html) 
+  [SEC03-BP02 授予最低访问权限](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html) 
+  [COST02-BP04 实施组和角色](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_groups_roles.html) 

 **相关文档：**
+  [IAM 最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [在 IAM Identity Center 中管理身份](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html) 
+  [什么是适用于 AWS 的 ABAC？](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
+  [在 IAM Identity Center 中使用 ABAC](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html) 
+  [ABAC 策略示例](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_abac.html) 

 **相关视频：**
+  [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)