SEC02-BP06 Employ user groups and attributes - Security Pillar
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, project, 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.

  • Using role chaining when using AWS IAM Identity Center sessions

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 with a principal, such as a user, group, role, or resource. You can scale permissions management by organizing permissions assignments (group, permissions, account) based on job-function, workload, and SDLC environment. 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 services like Amazon CloudFront within a development account. An AutomationDeveloper group may have some overlapping permissions with the WebAppDeveloper group. These common permissions can be captured in a separate policy and associated with 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. Consider using a hierarchical structure or naming conventions to organize groups effectively.

    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 you use 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 with the https://aws.amazon.com/SAML/Attributes/PrincipalTag attribute name. Refer to your identity provider's documentation for guidance on defining and configuring custom attributes.

    2. If you define roles within IAM Identity Center, enable the attribute-based access control (ABAC) feature, and define attributes as desired. Consider attributes that align with your organization's structure or resource tagging strategy.

If you require IAM role chaining from IAM Roles assumed through IAM Identity center, values like source-identity and principal-tags will not propagate. For more detail, see Enable and configure attributes for access control.

  1. 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.

    2. When defining ABAC policies, follow the guidance in the ABAC authorization best practices and examples.

    3. Regularly review and update your group and attribute structure as your organization's needs evolve to ensure optimal permissions management.

Resources

Related best practices:

Related documents:

Related videos: