#8. AWS Security Reference Architecture

• “Identity account(전용 AWS 계정)를 하나 두고, 거기만 IdP와 연동한 다음 나머지 계정으로 퍼뜨리는 패턴”

---

1. 그림에 나오는 요소 정리

왼쪽 → 오른쪽으로 보면:

1. Users

   • 회사 직원들 (개발자, 운영자, 보안팀 등)

2. Identity provider (IdP)

   • 회사의 중앙 계정 시스템
   • 예: Azure AD, Okta, Google Workspace, AD FS 같은 SSO/디렉터리

3. Identity account (AWS 계정 하나)

   • “아이덴티티 전용 AWS 계정”
   • 이 계정만 IdP와 SAML/OIDC 등으로 직접 연동함
   • 여기서 다른 AWS 계정으로 “역할 전환(Switch Role)” 또는 SSO를 제공

4. Account 1, 2, … N (업무용 AWS 계정들)

   • Dev, Prod, Logging, Security, Sandbox 등 실제 리소스가 돌아가는 계정들
   • 이 계정들은 IdP와 직접 붙지 않고, Identity account만 신뢰함

도식으로 쓰면:

Users → IdP → Identity account → 여러 AWS 계정

---

2. Identity account란?

Identity account = “AWS계의 로비(리셉션) 계정”이라고 생각.

• 이 계정에는 실제 서비스 리소스(EC2, RDS, S3 등)를 최소화하고,

• 대신

  • IAM Role
  • IAM Identity Center(SSO)
  • 계정 전환 설정
    같은 인증·권한·계정 관리 기능만 모아두는 전용 계정이다.

회사 건물 비유를 해보면:

• 건물 입구의 출입 게이트/리셉션 역할 = Identity account
• 각 층의 부서 사무실 = Account 1, 2, … N
• 사원증 시스템 = IdP

사람들은 먼저 출입 게이트(Identity account)를 통과한 뒤,
거기서 “나는 개발팀이니까 7층(Dev 계정)으로 들어가겠다” 하고 이동하는 구조.

---

3. 실제 로그인 흐름 예시

상황 가정

• IdP: Azure AD

• Identity account: identity-prod (AWS 계정 ID 111111111111)

• 업무 계정:

  • dev (계정 ID 2222…)
  • prod (계정 ID 3333…)
  • logging (계정 ID 4444…)

3-1. 사전 구성 (관리자 관점)

1. IdP ↔ Identity account 연동

   • Identity account 쪽에 AWS SAML Provider 생성
   • Azure AD와 메타데이터 교환해서 신뢰 관계 수립

2. Identity account에 “중계용 Role 또는 SSO 구성”

   • 단순 Switch Role 패턴이면,

     • 이 계정에 Jump-Role 같은 Role 하나 만들어서
       로그인한 사용자가 이 Role로 세션을 얻도록 설정

   • Identity Center를 여기에 설치하는 경우,

     • Identity Center가 멤버 계정에 Permission Set을 배포하는 허브 역할

3. 각 멤버 계정(Account 1..N)에 Role 생성 & Trust 설정

   • 예:

     • Dev 계정: Dev-Admin, Dev-ReadOnly Role
     • Prod 계정: Prod-ReadOnly Role

   • 각 Role의 Trust Policy 에

     • “1111… (Identity account) 의 특정 Role만 sts:AssumeRole 가능” 이라고 설정
       → 즉, “난 Identity account에서 오는 사람만 받아줄게” 라고 명시

요약하면:

IdP는 Identity account만 신뢰
멤버 계정들은 Identity account만 신뢰

3-2. 사용자가 로그인할 때 (사용자 관점)

1. user1이 사내 포털 접속 → Azure AD에 로그인

2. 포털에서 “AWS” 애플리케이션 클릭

3. Azure AD가 user1을 인증하고,
   SAML Assertion을 Identity account 로 보냄

4. user1은 이제 Identity account에 세션을 가진 상태로 AWS 콘솔에 들어감

   • 콘솔 상단에 보면 계정 ID가 1111… (identity account)로 보임.

5. 이제 여기서 선택:

   • 단순 Switch Role 구성이라면

     • “Switch Role” 버튼을 눌러

       • Dev-Admin(2222…), Prod-ReadOnly(3333…) 같은 Role 목록 중 하나 클릭

   • Identity Center가 설치된 경우라면

     • SSO 포털에서 “Dev account – Admin”, “Prod – ReadOnly” 같은 타일을 클릭

6. 예를 들어 Dev-Admin Role을 선택하면:

   • Identity account의 Jump-Role 혹은 SSO가
   • Dev 계정의 Dev-Admin Role에 대해 sts:AssumeRole 호출
   • Dev 계정에 대한 새 세션이 생기고, 화면이 Dev 계정 콘솔로 전환됨

사용자는 “IdP → Identity account → 대상 계정” 순서로 자연스럽게 이동하지만,
중간의 SAML/STS/Role 트러스트 관계는 전부 백그라운드에서 자동으로 처리된다.

---

4. 바로 전 그림(SAML로 Account1..N 직결)과 차이점

4-1. 기존 패턴 (직접 SAML federation)

이전 그림은:

Users → IdP → (SAML) → Account 1
Users → IdP → (SAML) → Account 2
…

• 계정이 늘어날수록:

  • 각 계정에 SAML Provider, IAM Role, Trust Policy를 별도로 관리해야 함
  • IdP 쪽에서도 Account마다 별도 애플리케이션/Role mapping 필요

• 10개 계정, 20개 계정으로 늘어나면 설정/변경/운영이 복잡해짐

4-2. 지금 그림 패턴 (Identity account 허브)

Users → IdP → Identity account → Account 1..N

장점:

1. IdP와의 trust는 딱 한 계정(Identity account)만 가진다

   • 계정이 10개든 100개든, IdP 쪽 SAML 설정은 그대로

   • 새 AWS 계정을 하나 만들면:

     • 그 계정에서 “Identity account의 Role을 신뢰”하는 Role만 만들어주면 끝

2. 권한 설계/제어 지점이 중앙으로 모임

   • Identity account에서

     • “보안팀은 모든 계정의 ReadOnly Role Assume 가능”
     • “개발팀은 Dev 계정엔 Admin, Prod엔 ReadOnly”
       같은 정책을 한 번에 설계

   • 각 계정은 “내가 신뢰하는 Identity account Role만 받아줄게”라고만 정의

3. 보안 분리

   • Identity account는 리소스를 두지 않고 접근 제어 용도로만 운영 → 공격 표면 최소화
   • 만약 Dev 계정이 뚫려도, IdP/SSO/인증 체계와는 분리되어 있음

4. CloudTrail·보안 로그 관리에도 유리

   • 누가 어떤 Role로 어느 계정에 들어갔는지
     Identity account와 Org Trail만 잘 보면 추적이 쉬움

그래서 많은 레퍼런스 아키텍처(특히 AWS Landing Zone / Control Tower)에서
Identity account, Log archive account, Security account 같은 “전용 계정 패턴”을 강조한다.