#7. AWS Security Reference Architecture

• 외부 IdP + SAML 연동으로 여러 AWS 계정에 들어가는 구조

---

1. 그림에 나오는 요소들

왼쪽 → 오른쪽 순서대로 보면:

1. Users (사람들)

2. Identity provider (IdP)

   • 예: Azure AD, Okta, Google Workspace, AD FS 같은 회사의 SSO/계정 시스템

3. SAML federation

   • IdP ↔ 각 AWS 계정 사이를 이어주는 연동 방식(프로토콜)

4. Account 1, 2, … N

   • 여러 개의 AWS 계정들
   • 각 계정 안에 다양한 리소스(EC2, S3, RDS 등 – 그림의 네모·동그라미·세모)

즉,
사람 → 회사 IdP → SAML로 AWS 각 계정에 접속

---

2. IdP / SAML / Federation 개념

2-1. Identity Provider (IdP)

• “누가 누구인지”를 관리하는 주체

• 회사 입장에선:

  • 사번, 이메일, 팀, 직무, 직책, 재직 여부, MFA 등 사용자 계정 전체를 관리

• 예시:

  • Azure AD에서 123456789@company.com 계정을 관리
  • 이 계정이 “보안팀”, “개발팀” 같은 그룹에 소속

여기서 인증(로그인)까지 끝낸 후,
다른 서비스(AWS, Slack, GitHub 등)로 “이 사람 인증 끝났어”라고 알려주는 역할을 함.

2-2. Federation (페더레이션)

• 직역하면 “연합”
• 의미: 내 계정 시스템(IdP) 과 외부 서비스(AWS) 를 묶어서
  “각 서비스에 계정을 따로 만들지 않고도 로그인을 가능하게 하는 것”
• IdP가 사용자를 인증하고, 그 증명(토큰/Assertion)을 AWS에게 넘겨주면
  AWS는 그걸 신뢰하고 세션을 만들어 줌.

2-3. SAML

• Security Assertion Markup Language

• XML 기반의 SSO 표준 프로토콜

• SAML 메시지 안에는:

  • “누가 로그인했는지(사용자 ID)”
  • “어떤 그룹에 속하는지”
  • “어떤 AWS Role들을 사용할 수 있는지(ARN 목록)”
    같은 정보가 들어 있어.

AWS는 이 SAML Assertion을 받아서
STS(보안 토큰 서비스) 로 짧은 기간짜리 임시 자격증명(AccessKeyId, SecretAccessKey, SessionToken)을 발급해 줘.

---

3. 로그인 플로우

상황 가정:

• 회사에는 AWS 계정이 3개 있다:

  • Account 1: 개발계 (Dev)
  • Account 2: 운영계 (Prod)
  • Account 3: 로그/보안 계정 (Logging/Security)

• 회사 IdP는 Azure AD

3-1. 사전 설정 (관리자 관점)

관리자가 해놓는 작업:

1. Azure AD ↔ AWS SAML 연동 설정

   • Azure AD에 “AWS”라는 엔터프라이즈 애플리케이션을 하나 만들고
   • AWS 쪽에는 “SAML Provider”를 생성
   • 서로 메타데이터(XML) 교환해서 신뢰 관계(trust) 생성

2. 각 계정에 IAM Role 정의

   • Account 1 에서:

     • Dev-Admin Role
     • Dev-ReadOnly Role 등

   • Account 2 에서:

     • Prod-ReadOnly Role

   • Account 3 에서:

     • Security-Analyst Role

   • 각 Role의 Trust Policy 에
     “SAML Provider(Azure AD)에서 오는 SAML 인증서만 이 Role을 Assume 가능”
     이라고 적어둠.

3. IdP에서 그룹 ↔ Role 매핑

   • Azure AD 그룹:

     • AWS-Dev-Admins → Account1:Dev-Admin Role
     • AWS-Prod-Viewers → Account2:Prod-ReadOnly Role

   • 이런 식으로 그룹에 따라 어느 계정의 어느 Role을 쓸 수 있는지 정의

여기까지가 그림에서
IdP ↔ 각 Account로 이어진 SAML federation 화살표에 해당.

---

4. 장점

4-1. IAM User를 계정마다 안 만들어도 됨

• 옛날 방식:

  • Account 1, 2, 3에 모두 kimdoyeon 이라는 IAM User를 만들고
    비밀번호/AccessKey 따로 관리 → 완전 지옥

• SAML Federation 방식:

  • 계정에 User 없음

  • 오직 Role만 있고, 로그인은 전부 IdP 통해서 들어옴

  • 계정 삭제(퇴사)도 IdP에서만 하면 끝:

    • Azure AD에서 계정 비활성화 → 새 SAML Assertion이 안 나와서
      AWS 계정 전체 접근이 자동 차단

4-2. 중앙에서 MFA, 패스워드 정책 관리

• MFA(OTP, 휴대폰 푸시 등), 패스워드 규칙(길이, 복잡도)은
  전부 IdP에서 통합 관리
• AWS 쪽은 IdP가 “이미 인증한 사용자”라고 믿고 Role만 발급

4-3. 짧은 기간의 임시 자격증명

• AssumeRoleWithSAML 세션 기본 TTL(예: 1시간, 4시간 등)을 짧게 설정 가능
• 유출돼도 시간이 지나면 자동 만료 → 보안성 ↑