AWS 접근 권한 지도

왜 헷갈리는가

IAM, IAM Identity Center, Organizations, STS는 각각 문서를 읽으면 이해가 된다. 그런데 막상 "개발자가 콘솔에 들어와 S3를 읽기까지" 같은 실제 흐름을 그려보려 하면 서비스 사이의 연결이 비어 있다.

헷갈리는 이유는 크게 세 가지다.

• "권한"이라는 말이 권한을 주는 장치(Identity · Resource 정책)와 권한을 깎는 장치(SCP · RCP · Boundary · Session 정책)에 섞여 쓰인다.
• 사람, CI, 애플리케이션이 모두 다른 방식으로 들어오는 것처럼 보이지만, 결국 전부 STS를 거쳐 Role 세션이 된다는 공통점이 문서마다 흩어져 있다.
• "나"가 개발자인지, 권한 체계를 관리하는 DevOps인지에 따라 같은 화면에서 하는 일이 완전히 다르다.

한 문장으로

사람 · CI · 앱은 모두 STS를 거쳐 Role 세션이 되고, 그 세션이 보내는 모든 API 요청은 8개의 평가 관문을 순서대로 통과해야 허용된다.

이 글의 나머지는 이 문장을 관계도 위에서 풀어 보는 것이다.

세 덩어리로 나눠 보기

1. 누가 (신원) — 개발자와 DevOps는 같은 Identity Center 포털로 들어와 다른 타일(계정 × Permission Set)을 고른다. GitHub Actions는 OIDC로, ECS 태스크는 서비스 트러스트로 Role을 빌린다. 장기 액세스 키를 가진 IAM User만 이 흐름에서 벗어나 있어서 지양한다.
2. 어디서 (계정 · 조직) — Organizations가 계정을 Root → OU → 계정 트리로 묶는다. 이 트리에 SCP · RCP · 선언적 정책을 붙여 계정 경계에 상한과 고정값을 건다.
3. 무엇을 (정책) — 요청은 명시적 Deny → RCP → SCP → Resource → Identity → Boundary → Session 순으로 평가된다. Allow를 만들어내는 건 Identity와 Resource 정책뿐이다.

이 글의 구성

예시 구성

설명은 계정 두 개짜리 작은 조직을 기준으로 한다.

• admin (111111111111) — Organizations 관리 계정. Identity Center와 도메인 호스팅 영역이 여기 있다.
• dev (222222222222) — 멤버 계정. 서비스 리소스와 배포 대상이 여기 있다.

계정 ID, 레포 이름, Permission Set 이름은 모두 예시값이다. 팀 규모가 커져도 구조는 그대로이고, 계정과 그룹 수만 늘어난다.

참고 문서

• IAM 정책 평가 로직
• IAM Identity Center 사용 설명서
• AWS Organizations 정책 관리
• AWS 보안 참조 아키텍처 — 관리 계정