🔥 IAM Identity Center: 사람 계정을 관리하는 현대적 방법

트리 안의 사람은 누가 묶지? Organizations가 계정 묶음을 정리하고 나면 곧장 따라오는 질문이다.

처음 시도한 답은 단순했다. 개발·스테이징·프로덕션 계정에 새로운 동료가 들어올 때마다 세 계정에 IAM User를 똑같이 만들고, MFA를 걸고, 똑같은 그룹에 넣는다. 한 명일 때는 견딜 만하다. 다섯 명, 열 명이 되면 나는 누가 어디에 어떤 권한을 갖는지 더 이상 추적하지 못한다. 더 무서운 건 퇴사자가 생겼을 때다. 세 계정에서 빠뜨리지 않고 지웠다고 어떻게 확신하지?

Organizations와 SCP: 조직 전체 권한 제어가 계정 전체 권한 경계를 다뤘다면, IAM Identity Center는 사람과 권한의 매핑을 맡는다. 같은 계정 다중화 문제의 다른 면이다.

Identity Center가 풀려고 하는 문제

문제는 두 개다. 첫째, 사람의 단일 출처. 회사에는 이미 사람을 관리하는 시스템이 따로 있다. Active Directory거나 Okta거나 Microsoft Entra ID거나. AWS가 또 자기만의 사용자 목록을 만들면 두 개를 평생 동기화해야 한다. 둘째, 권한의 다중 계정 배포. 동일한 "데이터 분석가"라는 역할을 데브·스테이징·프로덕션 세 계정에 동일하게 적용해야 한다. IAM User로 풀려면 계정마다 따로 만들고, Policy: JSON으로 권한을 표현하는 법에서 본 정책을 따로 붙여야 한다.

IAM Identity Center는 이 두 문제를 한 번에 푼다. 사람은 외부 IdP나 내장 디렉터리 한 곳에서 관리하고, 권한은 Permission Set이라는 추상으로 정의해서 어떤 사용자/그룹에게 어떤 계정에서 그 Permission Set을 줄지 매트릭스로 지정한다. 매트릭스 한 칸이 채워질 때마다 Identity Center가 그 계정에 IAM Role을 자동으로 만들어 둔다.

이 서비스는 처음에는 AWS Single Sign-On(AWS SSO)이라는 이름으로 2017년 12월 7일 us-east-1 한 리전에 등장했다. 2022년 7월 26일에 AWS IAM Identity Center로 이름이 바뀌었지만 API 네임스페이스(sso, identitystore)는 호환을 위해 그대로 둔다. 그래서 지금도 콘솔에서는 Identity Center라고 보이고 CLI에서는 aws sso login을 친다.

4개의 벽돌

Identity Center의 구조를 그리면 네 벽돌이 드러난다.

• Identity source: 사람이 어디에서 오는가. 조직당 하나만 고를 수 있다.
• User / Group: Identity source 안의 사람과 그 묶음.
• Permission Set: 권한 묶음. IAM Policy 문법을 그대로 쓰지만, 실체는 어느 계정에서든 이 정책으로 IAM Role을 만들어 줘라는 템플릿이다.
• Account assignment: 사용자(또는 그룹) × 계정 × Permission Set 삼중 매트릭스. 한 칸이 채워지면 그 사용자가 그 계정에서 그 권한으로 들어갈 수 있다.

User, Group, Role: 세 가지 주체의 차이에서 본 IAM의 4벽돌과 닮았지만 미묘하게 다르다. Identity Center는 Role을 별도 1급 객체로 두지 않는다. Role은 Permission Set이 대상 계정마다 자동으로 만들어 주는 결과물이기 때문이다.

사용자 → Permission Set → Role의 백엔드 경로

Permission Set의 가장 의외인 점은, 그 자체로는 권한을 행사하지 않는다는 것이다. 사용자가 access portal에서 "데이터 분석가" 권한 셋으로 프로덕션 계정에 들어간다고 클릭하면, 그 시점에 Assume Role: STS가 임시 자격증명을 내주는 순간에서 본 대로 STS가 임시 자격증명을 내준다. 다만 사용자가 직접 sts:AssumeRole을 호출하지는 않는다. Identity Center가 대행한다.

대상 계정에 미리 있는 IAM Role의 이름은 AWSReservedSSO_{PermissionSetName}_{고유 접미사} 형식이다 (공식 문서 예시는 16자 길이를 보여 준다). 콘솔에서 이 Role을 직접 수정하려고 하면 protected role이라는 메시지가 작업을 가로막는다. Identity Center가 소유주이고, Permission Set을 고치면 자기가 알아서 갱신한다. Permission Set을 어떤 계정에서 떼면 그 계정의 해당 Role을 자동으로 삭제하고, 다시 붙이면 새 접미사로 다시 만든다. 외부에서 ARN을 하드코딩해 둔 게 있다면 이 재생성 시점에 참조가 깨질 수 있다는 함정이 있다.

Identity source의 세 갈래

세 갈래가 있고, 조직당 하나만 고를 수 있다.

• Identity Center directory: 기본값. AWS 안에 사용자/그룹을 만든다. 외부 IdP가 없는 작은 팀에 맞다.
• AWS Managed Microsoft AD 또는 자체 관리 AD: 회사가 이미 AD를 운영 중일 때.
• 외부 IdP via SAML 2.0: Okta, Microsoft Entra ID, Google Workspace, PingFederate 등. 인증은 SAML로, 사용자/그룹 동기화는 SCIM 2.0으로 한다.

세 번째 길에서 가장 자주 비싸게 사는 부분은 SCIM 자동 동기화다. SCIM은 IdP가 사용자/그룹의 변화를 Identity Center로 푸시하게 만드는 표준이다. 동기화가 끊기면 IdP에는 이미 빠진 사람이 Identity Center에는 남아 있다는 시간차가 생길 수 있다. 내가 본 환경에서는 SAML 인증만 켜고 SCIM을 켜지 않은 채 사람을 수동으로 관리하다가 사고로 이어진 경우가 있었다.

두 종류의 세션

Identity Center에는 서로 다른 두 세션이 있다는 점이 초보자를 자주 혼란스럽게 만든다.

• Sign-in session(AWS access portal): 사용자가 access portal에 한 번 로그인한 뒤 다시 자격증명을 넣지 않고 머무는 시간. 2023년 9월 12일 변경 이후로 15분부터 90일까지 설정 가능하고, 디폴트는 8시간이다.
• Permission Set session: 그 사용자가 Permission Set을 골라 어느 계정에 들어간 뒤 그 안에서 임시 자격증명이 유효한 시간. 1시간(기본)부터 12시간(최대)까지, Permission Set 단위로 정한다.

CLI 사용자가 aws sso login으로 받은 자격증명이 1시간 만에 만료돼서 답답해하는 흔한 경험은 둘째 세션의 디폴트 1시간 때문이다. Permission Set의 session duration을 12시간으로 올리면 길어지지만, 보안 권장은 짧게 유지하는 쪽이다.

Organization instance vs Account instance: 2023년 11월에 나뉜 두 갈래

2023년 11월 17일에 AWS는 account instance를 추가로 발표했다. 그때부터 Identity Center 인스턴스 모델은 둘이다.

• Organization instance: Organizations 관리 계정에 하나, 조직 전체를 통제. 우리가 지금까지 이야기한 "다중 계정에 Permission Set을 펼친다"는 그림은 이쪽이다.
• Account instance: 한 멤버 계정 안에서만 동작하는 작은 인스턴스. 주로 Amazon CodeCatalyst 같은 Identity Center 통합형 AWS 관리 애플리케이션을 평가하거나 사용할 때 쓰려고 추가했다.

행동의 분기점은 며칠 앞선 2023년 11월 15일이다. 그 이후에 새로 만든 Organization instance에서는 멤버 계정의 Account instance 생성이 기본 허용이지만, 그 이전부터 Identity Center를 쓰던 조직에서는 관리 계정이 명시적으로 허용해야 한다. 마이그레이션 시점에 누군가 "왜 멤버 계정에서 켤 수 없지?"라고 물으면 이 날짜를 의심한다.

관리형이 감추는 비용

Identity Center는 자체 사용료가 없다. 그런데 관리형은 비용을 없애지 않고 다른 항목으로 옮긴다.

• 외부 IdP의 라이선스 비용은 그대로 든다. Okta든 Entra ID든 PingFederate든.
• SCIM 동기화가 어긋났을 때 디버깅 비용이 만만찮다. IdP·SCIM·Identity Center 셋 중 어디에서 매핑이 어긋났는지 추적해야 한다.
• Permission Set 하나가 계정마다 IAM Role 한 개씩을 만들기 때문에, 계정당 IAM Role 한도에 영향을 준다. Permission Set을 무절제하게 늘리면 한도에 닿는다.
• Permission Set session duration을 짧게 유지하면 보안에는 좋지만 개발자가 하루에 자격증명을 여러 번 갱신하느라 작업 리듬에 자주 균열이 생긴다. 내가 본 곳에서는 8시간 정도가 자주 쓰이는 절충점이었지만, AWS 공식 권고는 "필요한 만큼만 짧게"다.

언제 이걸 쓰지 말아야 하는가

답이 항상 "쓰자"는 아니다. 운영 경험상 계정 1–2개에 사람 1–3명의 매우 작은 환경에서는 IAM User를 직접 만드는 편이 운영 부담이 더 적다. Identity Center는 외부 IdP 연동이나 다중 계정 배포라는 반복되는 비용을 줄이는 도구이지, 그 비용이 애초에 없는 환경에서는 지름길이 아니다. 다만 이 임계는 공식 권고가 아닌 경험칙이라는 점은 짚어둔다.

반대로, 사람이 5명 이상이거나 계정이 3개 이상으로 늘어날 조짐이 보이면 늦지 않게 옮기는 편이 낫다. 지금까지 만든 IAM User들을 SCIM이 가져가기 시작하면 그때부터는 두 시스템을 병행하는 어색한 시기를 견뎌야 하는데, 이 시기는 짧을수록 좋다.

정리

Identity Center는 IAM의 대체가 아니라 그 위에 얹히는 사람 관리 도구다. 외부 IdP나 내장 디렉터리가 사용자를 한 번 정의하고, Permission Set은 어느 계정에서나 IAM Role을 만들며, 사용자가 access portal에서 클릭하는 순간 Identity Center가 그 Role의 임시 자격증명을 받아 준다. 2017년의 SSO에서 2022년의 리브랜딩, 2023년의 account instance와 trusted identity propagation, 2026년 2월의 multi-region 정식 지원까지. 천천히 그러나 꾸준히 사람 계정 관리 도구로 꾸준히 커왔다.

섹션 1의 마지막 주제는 IAM 실수 모음이다. 앞선 아홉 강의의 개념이 어디에서 사고를 일으키는지 묶는다.

참고 자료

• What is IAM Identity Center? (AWS 공식 문서): Identity Center의 개요, 출시·리브랜딩 히스토리
• AWS Single Sign-On (AWS SSO) is now AWS IAM Identity Center: 2022-07-26 리브랜딩 발표
• IAM roles created by IAM Identity Center: AWSReservedSSO_ 접두사 Role의 동작
• Manage your identity source: 세 갈래 Identity source와 조직당 단일 제약
• Set session duration for AWS accounts: Permission Set session 1–12시간
• Understanding authentication sessions: Sign-in session vs role session
• Account instances of IAM Identity Center: 2023-11-15 분기점과 멤버 계정 활성화
• AWS IAM Identity Center now supports multi-Region replication: 2026-02-03 multi-region 정식 지원