#9. AWS Security Reference Architecture

1. 그림을 한 번에 보기 – “회사 건물 + AWS 별도 건물” 비유

• Corporate data center = 회사 본사 건물
  

• 여기에 사람(직원), PC, 서버, 그리고 온프레미스 Active Directory가 있음.

• Shared Services account + AWS Managed Microsoft AD = AWS 안에 새로 세운 “분원 건물”

  • 여기도 AD가 있는데, 이건 AWS가 대신 관리해주는 Managed AD.

가운데 자물쇠 + 화살표:

“두 건물이 서로를 신뢰(trust) 해서,
한 건물 출입증으로 다른 건물도 드나들 수 있게 할지 말지를 정하는 선”

---

2. 회사 온프레미스 AD가 실제로 하는 일

2-1. Active Directory 안에 뭐가 들어있나?

온프 AD(예: corp.local)는 회사의 “주민등록 시스템 + 출입 시스템” 역할을 동시에 한다.

• Users and groups

  • 사용자 계정: user01, it_admin, dev_lead …
  • 보안 그룹: Domain Admins, Developers, HR-Team …

• Computers / Servers

  • 도메인에 join된 PC, 노트북
  • 도메인 컨트롤러(DC), 파일 서버, 업무 시스템 서버 등

이 AD가 하는 가장 핵심 일 3가지:

1. 인증(Authentication)

   • 누군가 로그인하면 “이 비밀번호/MFA가 맞는지” 확인
   • Kerberos 티켓 발급 (kerberos : 인증 프로토콜)

2. 권한 부여(Authorization)

   • 사용자가 어떤 그룹에 속해 있는지 확인
   • “이 파일/시스템을 열 수 있는 사람인지” 결정

3. 정책 배포(Group Policy)

   • 비밀번호 정책, 화면잠금, 로컬 권한 같은 걸 PC에 자동 배포

---

3. AWS Managed Microsoft AD 를 왜 따로 쓰나?

3-1. 그냥 온프 AD만 쓰면 안 되나?

AWS 안에도 윈도우 서버, 파일 서버, SQL 서버 같은 걸 올리면
이 서버들도 어떤 AD에 join 해야 해.

선택지는 크게 둘:

1. 온프레미스 AD에 직접 join

   • AWS ↔ 온프 사이 네트워크(Direct Connect/VPN)가 항상 안정적이어야 하고
   • AD 트래픽(Kerberos, LDAP, DNS)을 모두 터널링해야 함

2. AWS 안에 별도의 AD를 하나 세우고 그걸 쓰기

   • 이게 AWS Managed Microsoft AD

3-2. AWS Managed Microsoft AD 특징

• 완전관리형:

  • AD 도메인 컨트롤러가 사실은 EC2 인스턴스인데,
    그 OS 패치, 백업, 모니터링, 복구를 AWS가 대신 해줌.

• 표준 AD와 거의 동일하게 사용:

  • 사용자/그룹/OU 만들고, GPO 적용하고, LDAP 쿼리하고,
    Windows 통합 인증 사용하는 대부분의 시나리오를 그대로 지원.

• 여기에 EC2, FSx for Windows File Server, RDS for SQL Server 등을 조인시켜서
  “클라우드 쪽 Windows/AD 의존 워크로드”를 수용

근데 계정을 또 여기서 따로 만들면?

• 온프 AD랑 ID가 이중 관리됨 (퇴사, 부서 이동 시 양쪽 수정해야 함)
• 패스워드도 온프/클라우드 따로 → 사용자 입장에서 귀찮고, 보안성도 떨어짐

그래서 나온 게 “trust” 패턴.

---

4. trust 선 – “AD끼리 서로 믿게 만드는 것”

4-1. trust가 없을 때

• 온프 AD와 AWS Managed AD는 완전히 별개 왕국임.
• 온프 사용자 alice@corp.local 은
  AWS Managed AD 도메인 (aws.corp.internal 같은) 의 리소스에 바로 접근할 수 없음.
• 마찬가지로 AWS에서 만든 app-svc@aws.corp.internal 계정은
  온프 서버에 바로 접근할 수 없음.

즉, 계정·권한이 완전히 분리되어 있음.

4-2. trust를 맺으면?

“내가 인증한 사용자/그룹은 네가 믿어도 돼”라고 서로 약속한다.

• One-way trust:
  A → B trust

  • A 도메인이 인증한 유저는 B 리소스로 갈 수 있음
  • B가 인증한 유저는 A로 못 들어옴

• Two-way trust:
  A ↔ B 서로 trust

  • 양쪽 유저가 서로의 리소스로 갈 수 있게 설정할 수 있음
  • 실제 허용 여부는 ACL/권한 설정에 따라 다름

이 그림에서는:

• 왼쪽: 온프 AD (예: corp.local)
• 오른쪽: AWS Managed AD (예: aws.corp.local)

둘 사이에 one-way 또는 two-way trust를 구성해놓고,
그 위에 각종 접근 시나리오를 올리는 거야.

---

5. 실제 사용 시나리오를 아주 구체적으로

5-1. 시나리오 A – 사내 계정으로 AWS 윈도우 서버 RDP 접속

1. 직원은 평소처럼 회사 노트북에
   corp.local 도메인 계정으로 로그인 (온프 AD가 인증)

2. 노트북에서 VPN으로 AWS VPC에 접속

3. AWS VPC 안에 있는 Windows EC2 인스턴스는
   aws.corp.local (Managed AD)에 join 되어 있음

4. 이 EC2에서 RDP 접속을 받을 때:

   • 사용자가 CORP\user01 으로 로그인 시도
   • 서버는 “이 계정은 어떤 도메인 유저지?” → corp.local로 인증 위임
   • corp.local AD가 “user01 인증 성공 + group 목록”을 Kerberos로 회신
   • aws.corp.local 은 trust를 통해 이 정보를 받아,
     로컬 권한/그룹과 매칭해서 로그인 허용

→ 사용자는 사내 계정 그대로 AWS 서버에 접속하지만,
서버 입장에선 “Managed AD에 조인된 멤버”라 GPO/권한을 AWS 쪽에서 관리할 수 있음.

---

5-2. 시나리오 B – AWS 앱이 온프 그룹 기반 권한 제어

가령:

• AWS에 있는 내부 웹앱(예: 내부 포털)이 있고,
• “corp.local 의 HR-Team 그룹만 접근 가능”으로 만들고 싶다.

구조:

1. 웹앱 서버는 aws.corp.local AD에 join
2. 두 AD 사이에는 two-way trust
3. 웹앱은 Windows 통합 인증(Integrated Windows Auth) 사용
4. 사용자가 온프 계정으로 접속 → Kerberos 토큰 안에 HR-Team 포함
5. Managed AD가 trust를 통해 corp.local 의 그룹 정보를 이해하고,
6. 웹앱은 “토큰에 HR-Team이 있냐?” 만 보고 접근 허용/거부

→ 앱은 AWS에 있어도, 권한 모델은 온프 그룹만 써도 됨.
계정/그룹은 계속 온프 AD 한 곳에서만 관리.

---

6. 요약 정리

1. ID 관리 체계는 온프 AD에 그대로 유지

   • 가입, 퇴사, 조직 변경, 비밀번호 정책, MFA 등은 온프 AD에서만 관리

2. AWS 안에는 ‘리소스를 위한 AD’ 만 운영

   • Windows 서버, 파일서버, RDS 등 AD가 필요한 것들은
     AWS Managed AD에 join

3. 둘 사이를 trust로 묶어 ‘계정은 하나, 리소스는 양쪽’ 구조 완성

   • 사용자 입장: 회사 계정 하나로 온프 + AWS 둘 다 사용
   • 운영 입장: 계정 무한 복제 안 해도 됨
   • 보안 입장: 계정 lifecycle, 정책이 한 군데에 모여 있음

4. 네트워크와 보안 설계가 중요

   • AD trust는 민감한 채널이기 때문에
     VPC–온프 간 네트워크, 방화벽 포트, DNS 포워딩, 라우팅,
     DR 시나리오까지 꼼꼼히 봐야 함.