IAM policies attached directly to a user

Review directly assigned user policies and manage shared permissions through groups or roles.

Description

Attaching IAM policies directly to users distributes permissions across individual accounts, which can make access inconsistent among people doing the same work. Direct attachment is supported, but accumulated exceptions can hide unnecessary permissions.

Manage shared permissions through groups and use roles with temporary credentials where possible. Moving a policy to a group or role does not by itself reduce its permissions.

Potential impact

  • Per-user exceptions make least privilege and audits harder to maintain.
  • Unnecessary direct permissions may remain after job changes or account cleanup.

Remediation

  1. Check the purpose and actual permissions of direct policies, then move shared permissions to groups or roles.
  2. Test required operations before removing the old user policies. Adding a new policy does not remove existing permissions.
  3. Limit migrated policies to necessary actions and resources, and review membership and permissions regularly.

Examples

The contents of admin_policy.json and the user and group definitions are omitted. Review the file's actual permissions and configure required group membership separately.

Before

yaml
- name: 사용자에 정책 연결
  community.aws.iam_policy:
    iam_type: user
    iam_name: administrators
    policy_name: Admin
    state: present
    policy_document: admin_policy.json

This attaches the policy directly to the user named administrators.

After

yaml
- name: 그룹에 정책 연결
  community.aws.iam_policy:
    iam_type: group
    iam_name: administrators
    policy_name: Admin
    state: present
    policy_document: admin_policy.json

This attaches the policy to the group with the same name. It does not automatically remove the old user policy; remove that separately as part of the migration.

References