SCP와 권한 세트를 설계하는 모범 사례에 대한 정리 - 2
안녕하세요 클래스메소드의 이수재입니다.
지난 1편에서는 AWS Organizations의 구조와 SCP 설계의 모범 사례에 대해 정리했습니다.
이번 2편에서는 실제로 사용자가 AWS 계정에 접근하는 관문인 IAM Identity Center에 초점을 맞춰 정리해보겠습니다.
이번 글에서는 아래 내용을 다룹니다:
- IAM Identity Center 개요
- 유저 그룹 및 권한 세트 설계의 모범
- 유저 그룹 및 권한 세트 설계의 안티 패턴
1. IAM Identity Center 개요
IAM Identity Center란?
IAM Identity Center(구 AWS SSO)는 멀티 어카운트 환경에서 중앙에서 사람의 접근을 관리하는 서비스입니다.
AWS 조직 아래에 있는 AWS 계정에 접근하는 이미지입니다. AWS IAM Identity Center 내에 사용자를 생성하고 관리합니다. IAM 사용자와는 달리, 전용 “AWS 액세스 포털 사이트”를 통해 접근합니다.
주요 구성 요소는 다음과 같습니다:
| 구성 요소 | 설명 |
|---|---|
| Identity Store / 외부 IdP | 사용자 정보를 저장하거나 Okta, Azure AD 등 외부 IdP와 연동 |
| 유저 & 그룹 | 사용자를 역할에 맞게 묶는 단위 |
| 권한 세트(Permission Set) | "이 역할은 이런 권한을 가진다"는 IAM 정책 템플릿 |
| 계정 할당(Account Assignment) | "이 그룹에게 이 계정에서 이 권한 세트를 허용"하는 연결 설정 |
인스턴스 유형: 조직 인스턴스 vs 계정 인스턴스
IAM Identity Center에는 두 가지 인스턴스 유형이 있습니다.
멀티 어카운트 환경을 다루는 이 글의 맥락에서는 조직 인스턴스가 전제입니다.
| 구분 | 조직 인스턴스 | 계정 인스턴스 |
|---|---|---|
| 활성화 위치 | AWS Organizations 관리 계정 | 단일 AWS 계정 |
| AWS 계정 접근 관리 | 지원 | 미지원 |
| SAML 2.0 애플리케이션 | 지원 | 미지원 |
| 위임된 관리자 설정 | 가능 | 불가 |
| 용도 | 멀티 어카운트 통합 접근 관리 | AWS 관리형 앱(예: QuickSight) 전용 |
계정 인스턴스는 2023년 11월에 추가된 유형으로, 단독 계정에서 Amazon QuickSight 등 AWS 관리형 애플리케이션 접근만 필요한 경우에 사용합니다. 멀티 어카운트 접근 관리가 목적이라면 반드시 조직 인스턴스를 사용해야 합니다.
ID 소스(Identity Source) 유형
사용자 정보를 어디서 가져올지에 따라 세 가지 방식을 선택할 수 있습니다.
| ID 소스 | 설명 | 특징 |
|---|---|---|
| Identity Center 디렉토리 | IAM Identity Center 자체 내장 사용자 저장소 | 별도 IdP 없이 바로 사용 가능. 소규모 또는 초기 설정에 적합 |
| Active Directory | AWS Managed Microsoft AD 또는 AD Connector 연동 | 기존 온프레미스 AD를 그대로 활용 가능 |
| 외부 IdP (SAML 2.0) | Okta, Microsoft Entra ID, Google Workspace 등 연동 | 기업 IdP를 중앙 인증 소스로 유지 가능 |
외부 IdP 연동 시 사용자/그룹 동기화 방식도 두 가지입니다:
- 자동 프로비저닝 (SCIM): IdP에서 사용자·속성이 IAM Identity Center로 자동 동기화됩니다. 조직 규모가 크거나 멤버 변동이 잦은 경우에 적합합니다.
- 수동 프로비저닝: IdP와 동일한 사용자를 IAM Identity Center에 수동으로 생성합니다. 소규모이거나 연동 설정이 복잡한 경우에 선택하는 방식입니다.
권한 세트란?
액세스 설정에는 크게 AWS 계정, 사용자 그룹, 사용 권한 세트(권한)의 세 가지 요소가 있습니다.
이 중 권한 세트는 AWS 계정에 대한 접근 권한을 정의하는 리소스 입니다.
액세스하려는 AWS 계정에 대해 어떤 사용자 그룹에 어떤 권한을 부여할지 설정하는 것에 따라 사용자가 사용 가능한 조작이 결정됩니다.
SCP와 권한 세트의 관계
이전 장에 설정했던 OU의 SCP와 헷갈릴 수 있는 부분인데
1편에서 정리했듯이 SCP는 "이것만큼은 절대 안 된다" 는 조직 단위의 가드레일이고,
IAM Identity Center의 권한 세트는 "이 사람(그룹)은 이 조작을 할 수 있다" 는 개인/그룹 단위의 허용 범위입니다.
두 레이어가 함께 동작하면서 다계층 방어를 형성합니다.
2. 유저 그룹 및 권한 세트 설계의 모범 사례
1. 개인이 아닌 그룹에 권한을 할당하라
사용자 한 명 한 명에게 권한 세트를 직접 할당하면, 구성원이 바뀔 때마다 수작업이 필요합니다.
그룹에 권한을 할당하면 온보딩/오프보딩이 그룹 멤버십 변경만으로 해결됩니다.
2. 직무(Job Function) 기준으로 그룹과 권한 세트를 설계하라
직무별로 그룹과 권한 세트를 대응시키면, 어떤 사람이 어떤 권한을 갖는지 한눈에 파악할 수 있습니다.
3. 환경(dev/stg/prod)에 따라 권한 수준을 분리하라
같은 "개발자" 역할이라도 dev 계정에서는 유연한 권한을 줄 수 있지만,
prod 계정에서는 최소 권한 원칙을 엄격하게 적용해야 합니다.
| 그룹 | dev 계정 | stg 계정 | prod 계정 |
|---|---|---|---|
| Developer | PowerUser | ReadOnly | ReadOnly |
| Ops | PowerUser | PowerUser | LimitedAdmin |
| Security | SecurityAudit | SecurityAudit | SecurityAudit |
4. 권한 세트는 AWS Managed Policy를 우선 활용하라
커스텀 인라인 정책은 관리 부담이 큽니다.
PowerUserAccess, ReadOnlyAccess, SecurityAudit 등 AWS 관리형 정책을 기반으로,
필요한 경우에만 Customer Managed Policy로 보완하는 전략이 유지보수에 유리합니다.
권한 세트는 아래 4가지 요소로 구성할 수 있습니다:
| 구성 요소 | 설명 |
|---|---|
| AWS 관리형 정책 | AWS가 관리하는 미리 정의된 정책 |
| 고객 관리형 정책 | 직접 작성한 계정 내 IAM 정책 |
| 인라인 정책 | 권한 세트에 직접 포함된 정책 (권한 세트 삭제 시 함께 삭제) |
| 권한 경계(Permission Boundary) | 이 권한 세트가 허용할 수 있는 최대 권한 상한선 |
특히 권한 경계는 권한 세트에 아무리 넓은 정책을 붙여도 경계 밖의 권한은 실제로 행사할 수 없게 제한하는 안전장치입니다. 예를 들어 개발자에게 PowerUserAccess를 부여하면서도, 권한 경계로 특정 리전이나 서비스만 허용하도록 좁히는 데 활용할 수 있습니다.
주의: IAM Role 정책 첨부 한도에 제한받는다
권한 세트에 연결하는 정책은 IAM Identity Center 측의 상한과 실제 프로비저닝되는 IAM Role 측의 상한 두 레이어의 제약을 동시에 받습니다.
| 제한 레이어 | 관리형 정책 수 | 인라인 정책 크기 | 증설 가능 |
|---|---|---|---|
| Permission Set 측 | 최대 25개 | 10,240자 (공백 제외) | ❌ 불가 |
| IAM Role 측 (기본값) | 최대 10개 | 10,240자 (공백 제외) | ✅ 가능 |
| IAM Role 측 (최대값) | 최대 25개 | 10,240자 (공백 제외) | — |
Permission Set이 관리형 정책을 최대 25개까지 허용하더라도, 권한 세트를 프로비저닝할 때 대상 계정에 생성되는 IAM Role의 기본 상한이 10개이므로 사실상 10개가 실질적인 한도가 됩니다. 11개 이상의 관리형 정책을 연결하면 프로비저닝 자체가 실패합니다.
5. 권한 세트의 세션 시간을 환경에 맞게 설정하라
prod 계정일수록 세션 시간을 짧게 설정하여 자격 증명 탈취 리스크를 줄이는 것이 좋습니다.
| 환경 | 권장 세션 시간 |
|---|---|
| dev | 8시간 |
| stg | 4시간 |
| prod | 1시간 |
6. 위임 관리자를 사용할 경우 관리 계정용 권한 세트를 분리하라
IAM Identity Center는 보안상 관리 계정 이외의 계정(예: 보안 전용 계정)에 관리 권한을 위임할 수 있습니다.
그러나 위임된 관리자에게는 두 가지 중요한 제한이 있습니다.
제한 1. 위임 관리자는 관리 계정에 이미 프로비저닝된 권한 세트를 수정할 수 없습니다.
(AWS 원문: "The delegated administrator can't alter permission sets provisioned in the management account.")
제한 2. 관리 계정용 권한 세트에는 그룹이 아닌 개인 사용자만 직접 할당해야 합니다.
그룹을 할당하면 IdP 관리자나 AD 관리자가 그룹 멤버십을 변경하는 것만으로 관리 계정 접근 권한을 의도치 않게 확대할 수 있기 때문입니다.
이 두 제한을 고려하면, 관리 계정용 권한 세트와 일반 멤버 계정용 권한 세트를 처음부터 분리해 두는 것이 운영상 훨씬 단순해집니다.
| 권한 세트 범주 | 할당 방식 | 관리 주체 |
|---|---|---|
| 관리 계정용 권한 세트 | 개인 사용자만 직접 할당 | 관리 계정 관리자만 수정 가능 |
| 멤버 계정용 권한 세트 | 그룹 기반 할당 권장 | 위임 관리자 계정에서 관리 가능 |
3. 유저 그룹 및 권한 세트 설계의 안티 패턴
안티 패턴 1. 개인에게 직접 권한 할당
"이 사람만 특별히..."라는 예외 처리가 쌓이면 전체 권한 구조 파악이 불가능해집니다.
예외가 많아질수록 온보딩/오프보딩 시 누락 사고로 이어질 위험이 높습니다.
반드시 그룹을 통해 할당하는 것을 원칙으로 세우세요.
안티 패턴 2. 권한 세트 남발 (Permission Set Sprawl)
비슷한 권한 세트를 미세하게 다르게 만들어 계속 추가하면,
어느 순간 어떤 권한 세트가 무엇을 위한 것인지 알 수 없게 됩니다.
권한 세트는 명확한 네이밍 규칙과 함께 최소한의 종류만 유지하는 것이 중요합니다.
안티 패턴 3. 전 계정에 AdministratorAccess 남용
"일단 편하게 작업하려고" 모든 사람에게 관리자 권한을 주는 경우가 있습니다.
이는 SCP로 아무리 가드레일을 잘 설계해도, 결국 내부에서 모든 것을 허용하는 구조가 되어버립니다.
최소 권한 원칙은 편의보다 보안을 우선시하는 조직 문화에서 시작됩니다.
안티 패턴 4. OU 구조와 권한 세트 할당이 맞지 않음
OU로 계정을 dev/stg/prod로 나눠놨지만,
권한 세트 할당은 계정별로 개별 관리하는 경우 운영 복잡도가 급격히 증가합니다.
OU 구조와 권한 세트 할당 전략이 서로 일치할수록 운영이 단순해지고, 사고 발생 시 원인 파악도 빨라집니다.
마무리
이번 2편에서는 IAM Identity Center의 개요와 유저 그룹 및 권한 세트 설계의 베스트 프랙티스 및 안티 패턴에 대해 정리해봤습니다.
1편의 SCP 설계와 2편의 IAM Identity Center 설계가 함께 맞물릴 때, 멀티 어카운트 환경의 보안과 운영 효율성을 모두 잡을 수 있다고 생각합니다.
처음부터 완벽하게 적용하기는 어려운 것이 현실이지만,이 글이 설계 방향을 잡는 데 조금이나마 도움이 되셨으면 좋겠습니다.
긴 글 읽어주셔서 감사합니다.
오탈자나 내용에 관한 지적은 must01940 지메일로 보내주시면 감사합니다.
