SEC02-BP06 Employ user groups and attributes - AWS Well-Architected Framework
Implementation guidanceResources

SEC02-BP06 Employ user groups and attributes

Defining permissions according to user groups and attributes helps reduce the number and complexity of policies, making it simpler to achieve the principle of least privilege.  You can use user groups to manage the permissions for many people in one place based on the function they perform in your organization.  Attributes, such as department or location, can provide an additional layer of permission scope when people perform a similar function but for different subsets of resources.

Desired outcome: You can apply changes in permissions based on function to all users who perform that function.  Group membership and attributes govern user permissions, reducing the need to manage permissions at the individual user level.  The groups and attributes you define in your identity provider (IdP) are propagated automatically to your AWS environments.

Common anti-patterns:

  • Managing permissions for individual users and duplicating across many users.

  • Defining groups at too high a level, granting overly-broad permissions.

  • Defining groups at too granular a level, creating duplication and confusion about membership.

  • Using groups with duplicate permissions across subsets of resources when attributes can be used instead.

  • Not managing groups, attributes, and memberships through a standardized identity provider integrated with your AWS environments.

Level of risk exposed if this best practice is not established: Medium

Implementation guidance

AWS permissions are defined in documents called policies that are associated to a principal, such as a user, group, role, or resource.  For your workforce, this allows you to define groups based on the function your users perform for your organization, rather than based on the resources being accessed. For example, a WebAppDeveloper group may have a policy attached for configuring a service such as Amazon CloudFront within a development account. An AutomationDeveloper group may have some CloudFront permissions in common with the WebAppDeveloper group. These permissions can be captured in a separate policy and associated to both groups, rather than having users from both functions belong to a CloudFrontAccess group.

In addition to groups, you can use attributes to further scope access. For example, you may have a Project attribute for users in your WebAppDeveloper group to scope access to resources specific to their project.  Using this technique removes the need to have different groups for application developers working on different projects if their permissions are otherwise the same.  The way you refer to attributes in permission policies is based on their source, whether they are defined as part of your federation protocol (such as SAML, OIDC, or SCIM), as custom SAML assertions, or set within IAM Identity Center.

Implementation steps

  1. Establish where you will define groups and attributes.

    1. Following the guidance in SEC02-BP04 Rely on a centralized identity provider, you can determine whether you need to define groups and attributes within your identity provider, within IAM Identity Center, or using IAM user groups in a specific account.

  2. Define groups.

    1. Determine your groups based on function and scope of access required.  

    2. If defining within IAM Identity Center, create groups and associate the desired level of access using permission sets.

    3. If defining within an external identity provider, determine if the provider supports the SCIM protocol and consider enabling automatic provisioning within IAM Identity Center.  This capability synchronizes the creation, membership, and deletion of groups between your provider and IAM Identity Center.

  3. Define attributes.

    1. If using an external identity provider, both the SCIM and SAML 2.0 protocols provide certain attributes by default.  Additional attributes can be defined and passed using SAML assertions using the https://aws.amazon.com/SAML/Attributes/PrincipalTag  attribute name.

    2. If defining within IAM Identity Center, enable the attribute-based access control (ABAC) feature and define attributes as desired.

  4. Scope permissions based on groups and attributes.

    1. Consider including conditions in your permission policies that compare the attributes of your principal with the attributes of the resources being accessed.  For example, you can define a condition to allow access to a resource only if the value of a PrincipalTag condition key matches the value of a ResourceTag key of the same name.

Resources

Related best practices:

Related documents:

Related videos: