IAM 그룹으로 권한 관리하기: 사용자 직접 연결 vs 그룹 연결

신규 개발자가 입사할 때마다 S3, CodeCommit, CloudWatch 정책을 한 명씩 붙이다 보면, 어느 순간 누군가의 계정에만 정책이 빠져 있거나 퇴사자 계정에 권한이 남아 있는 상황을 마주하게 된다. IAM 그룹은 이 문제를 구조적으로 해결하는 가장 기본적인 수단이다.

TL;DR: IAM 그룹 vs 사용자 직접 연결

기준	사용자 직접 연결	IAM 그룹 연결
신규 사용자 온보딩	정책을 매번 수동 연결	그룹 추가만으로 완료
권한 변경	사용자 수만큼 반복 작업	그룹 정책 1회 수정으로 전파
퇴사자 처리	각 정책을 개별 분리	그룹 멤버십 제거로 권한 회수
감사(Audit)	사용자별 정책 목록 확인 필요	그룹 단위로 권한 범위 파악 가능
실수 가능성	높음 (누락, 중복 발생)	낮음 (그룹 정책이 단일 진실 공급원)

IAM 그룹이 작동하는 방식

IAM 그룹은 사용자의 컨테이너다. 그룹 자체는 자격 증명이 아니므로 로그인하거나 임시 자격 증명을 발급받을 수 없다. 그룹에 연결된 정책은 그룹의 모든 멤버에게 적용된다. 사용자가 여러 그룹에 속하면 각 그룹의 정책이 합산되어 평가된다.

한 사용자에게 직접 연결된 정책과 그룹을 통해 상속된 정책은 IAM 평가 엔진에서 동일하게 처리된다. 단, Explicit Deny는 어떤 경로로 Allow가 부여되었든 항상 우선한다.

graph LR G["Developers 그룹
정책 연결 지점"] --> P1["AmazonS3ReadOnlyAccess"] G --> P2["CloudWatchReadOnlyAccess"] U1["alice"] --> G U2["bob"] --> G U3["신규 사용자 추가 시
그룹 추가만으로 완료"] -.->|"그룹 멤버 추가"| G

Developers 그룹에 S3ReadOnly, CloudWatchReadOnly 정책을 연결한다.
신규 사용자 alice, bob을 그룹에 추가하면 두 정책이 즉시 적용된다.
그룹 정책을 수정하면 모든 멤버에게 동시에 반영된다.
사용자를 그룹에서 제거하면 그룹 기반 권한이 즉시 회수된다. 사용자에게 직접 연결된 정책은 별도로 관리해야 한다.

IAM 그룹 생성 및 정책 연결 실습

아래 절차는 'Developers' 그룹을 만들고 AWS 관리형 정책을 연결한 뒤 사용자를 추가하는 전체 흐름이다. 각 단계에서 CLI 출력으로 상태를 즉시 확인할 수 있다.

1단계: 그룹 생성

그룹 이름은 생성 후 변경할 수 없다. 역할(Role)이나 팀 기능을 기준으로 명명하는 것이 감사 시 가독성을 높인다.

aws iam create-group --group-name Developers

2단계: 정책 연결

AWS 관리형 정책 ARN을 사용한다. 관리형 정책은 AWS가 서비스 변경에 맞춰 업데이트하므로, 직접 인라인 정책을 유지하는 부담이 없다.

aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchReadOnlyAccess

3단계: 사용자를 그룹에 추가

사용자가 이미 IAM에 존재해야 한다. 그룹 추가 즉시 정책이 적용된다. 별도의 재시작이나 세션 갱신이 필요하지 않다 — 단, 이미 발급된 임시 자격 증명(STS 토큰)은 만료 전까지 기존 권한으로 동작한다는 점을 운영 시 고려해야 한다.

aws iam add-user-to-group \
  --group-name Developers \
  --user-name alice

aws iam add-user-to-group \
  --group-name Developers \
  --user-name bob

4단계: 그룹 멤버십 및 연결 정책 확인

온보딩 직후 또는 감사 시점에 그룹 상태를 검증하는 습관이 중요하다. 정책이 실제로 연결되었는지, 의도한 사용자가 포함되었는지 CLI로 즉시 확인할 수 있다.

# 그룹 멤버 목록 확인
aws iam get-group --group-name Developers

# 그룹에 연결된 정책 목록 확인
aws iam list-attached-group-policies --group-name Developers

고객 관리형 정책으로 세밀한 권한 제어

AWS 관리형 정책이 요구사항을 충족하지 않을 때는 고객 관리형 정책을 직접 작성해 그룹에 연결한다. 아래는 특정 S3 버킷에 대한 읽기 권한만 허용하는 예시다.

🔽 고객 관리형 정책 JSON 예시 (클릭하여 펼치기)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSpecificBucketRead",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-dev-bucket",
        "arn:aws:s3:::my-dev-bucket/*"
      ]
    }
  ]
}

정책 파일을 저장한 뒤 아래 순서로 생성하고 그룹에 연결한다.

# 고객 관리형 정책 생성
aws iam create-policy \
  --policy-name DevS3BucketReadOnly \
  --policy-document file://dev-s3-policy.json

# 생성된 정책을 그룹에 연결 (Account ID를 실제 값으로 교체)
aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::123456789012:policy/DevS3BucketReadOnly

퇴사자 처리: 그룹 멤버십 제거와 직접 연결 정책 분리

퇴사자 계정 처리에서 가장 흔한 실수는 그룹에서만 제거하고 끝냈다고 생각하는 것이다. 사용자에게 직접 연결된 정책이 있다면 그룹 멤버십 제거와 무관하게 권한이 남는다. 이 두 가지는 독립적으로 관리된다.

graph TD A["퇴사자 처리 시작"] --> B["그룹 멤버십 제거
그룹 기반 권한 회수"] B --> C["직접 연결 정책 확인
list-attached-user-policies"] C --> D{"직접 연결 정책 존재?"} D -->|"Yes"| E["정책 분리
detach-user-policy"] D -->|"No"| F["액세스 키 비활성화"] E --> F F --> G["콘솔 접근 비활성화
또는 계정 삭제"]

그룹 멤버십 제거로 그룹 기반 권한을 회수한다.
사용자에게 직접 연결된 정책을 별도로 확인하고 분리한다.
계정을 비활성화(콘솔 접근 비활성화, 액세스 키 비활성화)하거나 삭제한다.

# 그룹에서 사용자 제거
aws iam remove-user-from-group \
  --group-name Developers \
  --user-name alice

# 사용자에게 직접 연결된 정책 목록 확인
aws iam list-attached-user-policies --user-name alice

# 직접 연결된 정책 분리 (정책 ARN은 위 명령 출력 기준)
aws iam detach-user-policy \
  --user-name alice \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# 액세스 키 비활성화 (키 ID는 list-access-keys로 확인)
aws iam update-access-key \
  --user-name alice \
  --access-key-id AKIAIOSFODNN7EXAMPLE \
  --status Inactive

그룹 멤버십 제거는 그룹 기반 권한만 회수한다. 사용자 계정 자체와 직접 연결된 정책, 액세스 키는 별도로 처리해야 한다. 퇴사자 처리를 체크리스트 없이 수동으로 하면 반드시 빠지는 항목이 생긴다.

실제 운영에서 마주치는 문제: 정책 누락 진단

증상: 개발자가 특정 S3 버킷에 접근하지 못한다고 보고한다. 콘솔에서 해당 사용자의 권한 탭을 보면 정책이 있는 것처럼 보인다.

잘못된 첫 번째 판단: 정책이 연결되어 있으니 버킷 정책 문제일 것이다.

실제 원인: 사용자가 속한 그룹에 정책이 연결되어 있지만, 버킷 정책에 Explicit Deny가 있어 그룹 기반 Allow를 덮어쓰고 있었다. IAM 콘솔의 권한 탭은 Allow 정책 목록을 보여주지만, 버킷 정책의 Deny는 별도로 확인해야 한다.

진단 순서: IAM Policy Simulator로 실제 평가 결과를 확인하고, 버킷 정책을 직접 조회한다.

# 사용자의 실제 권한 평가 (IAM Policy Simulator CLI)
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/alice \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::my-dev-bucket/sample.txt

# 버킷 정책 확인
aws s3api get-bucket-policy --bucket my-dev-bucket

Explicit Deny는 어느 경로로 Allow가 부여되었든 항상 우선한다. 그룹 구조가 잘 잡혀 있어도 버킷 정책, SCP, 권한 경계(Permission Boundary)가 독립적으로 작동한다는 점을 항상 염두에 두어야 한다.

IAM 그룹 사용 시 주의사항

그룹은 중첩되지 않는다. 그룹 안에 그룹을 넣을 수 없다. 계층적 권한 구조가 필요하다면 역할(Role) 기반 설계를 검토해야 한다.
한 사용자가 속할 수 있는 그룹 수에는 한도가 있다. 정확한 한도는 AWS 공식 문서의 IAM 서비스 할당량 페이지에서 확인한다. 계정 기본값 변경이 필요하면 Service Quotas를 통해 조정 요청할 수 있다.
인라인 정책은 그룹에도 연결할 수 있다. 단, 인라인 정책은 재사용이 불가능하고 감사 시 개별 확인이 필요하므로, 관리형 정책을 우선 사용하는 것이 운영 부담을 줄인다.
그룹 이름은 변경할 수 없다. 처음부터 역할 기반 명명 규칙을 정하고 시작하는 것이 좋다.

IAM 그룹 기반 권한 관리 마무리 및 다음 단계

IAM 그룹은 사용자 수가 늘어날수록 직접 연결 방식 대비 운영 오류를 줄이는 효과가 명확하다. 그룹 단위로 정책을 관리하면 신규 온보딩, 권한 변경, 퇴사자 처리 모두 단일 지점에서 제어할 수 있다.

그룹 기반 관리를 도입한 뒤 다음 단계로 고려할 수 있는 주제:

권한 경계(Permission Boundary): 그룹 정책이 부여하는 권한의 최대 범위를 제한할 때 사용한다.
AWS IAM Identity Center(SSO): 다수의 AWS 계정과 사용자를 중앙에서 관리할 때 그룹 기반 권한 할당을 더 체계적으로 운영할 수 있다.
Service Control Policy(SCP): Organizations 수준에서 계정 전체에 적용되는 가드레일로, 그룹 정책과 독립적으로 작동한다.

공식 참고 문서: AWS IAM User Guide — IAM Groups

핵심 용어 정리

용어	설명
IAM 그룹	IAM 사용자의 집합. 그룹에 연결된 정책은 모든 멤버에게 적용된다. 자격 증명이 아니므로 로그인 불가.
관리형 정책	AWS 또는 고객이 독립적으로 생성하고 여러 엔티티에 재사용 가능한 정책. 인라인 정책과 구분된다.
인라인 정책	특정 사용자, 그룹, 역할에 직접 내장된 정책. 해당 엔티티 삭제 시 함께 삭제된다.
Explicit Deny	명시적 거부. Allow 정책의 출처와 무관하게 항상 우선 적용된다.
권한 경계	IAM 엔티티가 가질 수 있는 최대 권한 범위를 정의하는 고급 기능. 그룹 정책과 독립적으로 평가된다.

이 블로그 검색

SW BBANG K