#5. AWS Security Reference Architecture

• 온프레미스 ad 계정을 aws 쪽으로 끌어와서, IAM Identity Center로 통합 관리하는 패턴

---

1. 큰 흐름 한 줄 요약

1. 회사 건물 안에 On-premises Active Directory가 있음.

2. AWS 안에 AWS Directory Service를 만들어서, 온프 AD랑 양방향 트러스트(또는 AD Connector)로 연결.

3. AWS Directory Service가 갖고 있는 사용자/그룹 정보를
   IAM Identity Center 디렉터리로 Sync.

4. 사용자가 로그인할 때는 IAM Identity Center가 다시 Directory Service를 통해
   온프 AD에게 “이 사람 맞냐?” 하고 Authenticate를 맡김.

5. 인증이 끝나면 Identity Center가

   • 여러 AWS 계정,
   • 여러 애플리케이션(보안툴, 내부 포털 등)
     에 대한 접근 권한을 결정해서 SSO 화면으로 보여준다.

즉,

“사람 정보는 여전히 회사 AD가 주인,
권한(어디까지 들어갈지)은 AWS Identity Center가 주인”
인 구조야.

---

2. On-prem AD ↔ AWS Directory Service

2-1. On-premises Active Directory

• 회사 사무실에 있는 윈도우 도메인 컨트롤러들.
• 직원 계정, 그룹, GPO 등 다 여기 저장돼 있고,
  사내 PC 로그인, 파일서버 접근 등에 이미 쓰이고 있음.

2-2. AWS Directory Service

• AWS 안에서 돌리는 “AD 관련 서비스” 통칭.

• 여기서 두 가지 방식이 그림의 “Two-way trust / AD Connector”로 표현돼 있어:

  1. AWS Managed Microsoft AD + 양방향 트러스트

     • AWS가 대신 운영해주는 AD를 만들고, 온프 AD와 트러스트 관계 설정.
     • 클라우드 쪽에 AD 서버를 하나 더 둔 느낌.

  2. AD Connector

     • AD를 따로 만들지 않고, 그냥 “프록시” 역할만 하는 경량 서비스.
     • 인증 요청을 그대로 온프 AD로 중계.

둘 다 공통점은:

“AWS 안에 있는 서비스들이 온프 AD 계정을 그대로 쓸 수 있게 중간다리 역할을 한다”는 것.

---

3. IAM Identity Center와 연동

3-1. Sync (동기화)

• AWS Directory Service → IAM Identity Center 방향 화살표.

• 의미:

  • Directory Service에 보이는 사용자·그룹 목록을
    Identity Center 디렉터리로 가져와서 “거울”처럼 유지.

  • 예:

    • 온프 AD에 AWS-SecurityTeam 그룹을 만들고 도연을 넣으면,
      잠시 후 Identity Center에도 동일 그룹과 멤버가 생김.

3-2. Authenticate (인증)

• 반대 방향 화살표 Authenticate.

• 사용자가 SSO 포털에 로그인하려 하면:

  1. Identity Center가 Directory Service로 “이 사용자 인증해줘” 요청.
  2. Directory Service는 AD Connector/트러스트를 통해 온프 AD에게 Kerberos/NTLM 인증 요청.
  3. 온프 AD가 “비번 맞다 / MFA 통과했다” 확인해주면
  4. Identity Center가 최종 “로그인 성공”으로 판단.

이렇게 하면:

• 비밀번호, 잠금, MFA 정책은 전부 온프 AD 정책을 그대로 사용할 수 있고,
• AWS 쪽은 계정/권한만 관리하면 됨.

---

4. IAM Identity Center가 하는 일

1. Multi-account permissions

   • 여러 AWS 계정에 대한 권한을 한 번에 관리.

   • Permission set 정의 → 각 계정에 매핑.

   • 예:

     • Security-ReadOnly : 모든 운영 계정에 보안 읽기 권한
     • Incident-Responder : 포렌식 계정에만 스냅샷/로그 수집 권한

2. Application assignments

   • SAML/OIDC로 연동된 앱 접근 권한 관리.

   • 예:

     • CloudGuard, Splunk, Jira, 내부 IR Portal 등

“One place to manage permissions”
→ 권한을 여기서만 설정해도, 실제 인증은 AD가 해 준다는 의미.

---

5. 실제 접근 대상

• AWS accounts

  • 여러 계정에 대해 어떤 그룹이 어떤 Permission set으로 들어올지 정의.
  • 사용자는 SSO 화면에서 계정 타일을 보고 선택.

• AWS-managed / Customer-managed applications

  • QuickSight, Managed Grafana 같은 AWS 앱 +
    직접 만든 앱(보안 포털, 콘솔 등)을 하나의 SSO 포털에서 접근.

---

6. 예시 시나리오

배경

• 회사는 온프 AD를 이미 사용 중.

• AWS에 Shared Services account를 하나 만들어

  • 거기에 AWS Directory Service와 IAM Identity Center(Delegated)를 설치함.

• 온프 AD에는

  • Cloud-Sec 그룹에 user1이 들어가 있음.

설정 단계

1. On-prem AD ↔ AWS Directory Service

   • AD Connector 또는 Managed AD + 트러스트 설정.

2. Directory Service ↔ IAM Identity Center

   • Sync 설정 → Cloud-Sec 그룹과 사용자들이 Identity Center에 나타남.

3. Identity Center에서 Permission set 생성

   • Sec-RO : CloudTrail/Config/GuardDuty 보기
   • Sec-IR : 스냅샷/메모리 덤프, S3 로그 조회 권한

4. Multi-account assignment

   • Cloud-Sec 그룹:

     • Prod-1, Prod-2 계정에는 Sec-RO
     • Forensics 계정에는 Sec-IR

5. Application assignment

   • Cloud-Sec 그룹:

     • CloudGuard 앱, IR-Portal 앱 접근 허용.

user1이 실제로 로그인할 때

1. 브라우저에서 AWS SSO URL 접속 → IAM Identity Center 포털로 이동.

2. 포털이 “이 사용자 인증해야지” 하고
   AWS Directory Service를 통해 온프 AD 로그인 페이지(혹은 도메인 로그인)로 리다이렉트.

3. user1이 회사 AD 계정/비번 + MFA로 로그인 → AD가 OK 반환.

4. Identity Center가 도연의 그룹(Cloud-Sec)을 보고:

   • 이 사람이 볼 수 있는 AWS 계정 목록,
   • 사용할 수 있는 앱 목록을 SSO 화면에 보여줌.

5. user1이 Forensics (Sec-IR) 계정 타일을 클릭 →
   STS 임시 자격증명으로 Forensics 계정 콘솔에 자동 로그인.

6. 이후 CloudGuard 앱 타일도 클릭해서 추가 툴 접속.

user1 입장에서는:

• 회사에서 쓰던 AD 계정 그대로 쓰고,
• 비밀번호·MFA도 기존 정책 그대로 따르면서,
• AWS와 각종 보안툴에 “로그인 한 번으로 드나드는” 경험을 얻는 것.

---