#0. AWS Security Reference Architecture

cl0·2025년 11월 23일

AWS_SRA

목록 보기

2/19

1. AWS Organizations / Account / OU / SCP 개념

1-1. Account (계정)

우리가 보통 쓰는 그 AWS 계정.
청구서·권한·리소스가 완전히 분리된 독립 공간.
한 계정이 털려도, 다른 계정까지 바로 털리지는 않게 분리하는 게 목적.

비유: 하나의 회사 건물 안에 있는 독립된 회사 한 개가 Account.

1-2. AWS Organizations

여러 개의 AWS Account를 한 회사 / 그룹으로 묶어 관리하는 서비스.
여기서:
- 계정 생성/삭제
- 공통 정책 배포
- 조직 전체 결제 통합(billing)
  등을 할 수 있음.

비유: 여러 회사를 거느린 그룹 지주사.

1-3. OU (Organizational Unit)

Organization 안에서 계정들을 폴더처럼 묶는 단위.
보통 이렇게 나눔:
- Security OU : 보안·로그 전담 계정들
- Infrastructure OU : 공용 네트워크/도메인 계정
- Workloads OU : 실제 서비스 운영 계정
- Sandbox OU : 개발·실험용 계정
OU 단위로 정책(SCP)을 한 번에 걸어버릴 수 있음.

비유: 그룹사 안에서
“보안팀 계열사 묶음”, “서비스 운영 계열사 묶음” 같은 사업부 폴더.

1-4. SCP (Service Control Policy)

Service Control Policy = 조직 최상위에서 거는 “상한선” 규칙.
중요한 특징:
- IAM 정책이 허용해도, SCP에서 막으면 절대 못 함.
- 반대는 아님. SCP에서 허용해도 IAM이 막으면 못 함.
예시:
- “Workloads OU 에서는 루트 계정이라도 서울 리전(ap-northeast-2) 말고는 아무 리전도 못 쓴다.”
- “Sandbox OU는 RDS 생성 금지 (돈 많이 나가니까).”

비유:

IAM 정책 = 팀장이 팀원에게 주는 업무·권한

SCP = 회사에서 정한 회사 차원의 룰
(회사에서 “야근 금지”라고 하면, 팀장이 “야근해라” 해도 못 하는 것과 같음)

2. CloudTrail, Config, GuardDuty, Security Hub 관계

이 네 개는 보안·감사 기본 4대장이라고 보면 된다.

2-1. AWS CloudTrail – “누가, 언제, 무엇을 했는지 기록”

AWS API 호출 로그.
- 예: kimdoyeon 이라는 IAM 사용자가
  - 2025-11-22 21:03에
  - ec2:TerminateInstances 를
  - 어떤 인스턴스 ID에 실행했는지
- 이런 것을 전부 남김.
감사/포렌식의 기본 재료.

키워드: “행위” 기록, API audit log

2-2. AWS Config – “환경 상태·변화 이력 기록”

“지금 우리 계정에 어떤 리소스가 있고, 설정이 어떻게 되어 있는지”를 계속 추적.
그리고 변경 이력까지 저장.
- 보안 그룹에 허용 포트가 어떻게 바뀌었는지
- S3 버킷이 언제 Public으로 바뀌었는지
컴플라이언스 룰도 걸 수 있음:
- “모든 S3 버킷은 암호화 되어 있어야 한다” ⇒ 아니면 NON_COMPLIANT 알림.

키워드: “상태 & 설정 변화 이력”

2-3. Amazon GuardDuty – “이상행위 탐지”

CloudTrail, VPC Flow Logs, DNS 로그 등의 행위/트래픽을 분석해서
- 이상한 API 호출
- 비정상적인 IP로의 통신
- 의심스러운 Recon 활동
  등을 “위험도(Severity)”와 함께 Finding으로 올림.
스스로 룰·머신러닝을 돌려서 탐지해주기 때문에
- 사용자는 로그를 직접 다 분석할 필요 없음.

키워드: “행위 기반 위협 탐지, IDS 비슷한 역할”

2-4. AWS Security Hub – “보안 종합 대시보드 (CSPM 역할)”

GuardDuty, Config, Macie, Inspector, WAF, 서드파티 등에서 올라오는
보안 Findings를 한곳에 모아서 보여주는 허브.
기능:
- 계정·리전 전체 보안 점수 (Security Score)
- CIS, PCI, NIST 등 컴플라이언스 기준으로 평가
- Finding들을 통합 정렬/필터링/자동 대응 룰 설정

키워드: “결과 모으는 허브, CSPM 대시보드”

2-5. 네 개의 관계 요약 (그림으로)

[사용자/공격자 → AWS 리소스들에 뭔가 함]

       ↓ (API 호출, 설정 변경, 네트워크 트래픽)

CloudTrail  ---->  GuardDuty (이상행위 탐지)
     │
     └-->  Config (설정 상태/변화 추적)

GuardDuty Findings ┐
Config 규정 위반 ┐ │
Macie/Inspector … │ ├─> Security Hub (통합 보안 현황판)
3rd-party 도구들 ┘ │
                   ┘

CloudTrail: “무슨 행동이 있었는지”
Config: “리소스 상태가 어떻게 바뀌었는지”
GuardDuty: “행동이 수상한지”
Security Hub: “전체적으로 지금 위험도가 어떠한지”

3. Route 53 → CloudFront → WAF → ALB → EC2 트래픽 흐름

사용자가 웹 서비스를 호출할 때 실제로 어떤 경로를 거치는지 순서대로 보자.

3-1. 전체 흐름 그림

User Browser
     │ 1. DNS 질의
     ▼
Route 53 (DNS)
     │ 2. CloudFront 도메인 응답
     ▼
CloudFront (CDN)
     │ 3. WAF + Shield 적용
     ▼
AWS WAF (L7 방화벽)
     │ 4. ALB로 전달
     ▼
Application Load Balancer (ALB)
     │ 5. 대상 그룹(Target Group)으로 라우팅
     ▼
EC2 인스턴스들 (웹/API 서버)

3-2. 각 단계 설명

Route 53
- 사용자가 www.example.com 접근
- 브라우저가 DNS 질의 → Route 53이 CloudFront 배포 도메인으로 응답.
CloudFront
- 전 세계 엣지 로케이션에서 가장 가까운 곳이 요청을 받음.
- 정적 컨텐츠 캐시 되어 있으면 여기서 바로 응답.
- 없으면 Origin(보통 ALB나 S3) 로 요청을 전달.
- 이때 CloudFront access log 생성.
AWS WAF
- CloudFront 또는 ALB 앞단에 붙어 있음.
- 요청의 헤더·바디·쿼리스트링을 보고
  - SQL Injection
  - XSS
  - IP 차단, Rate limiting
    등을 수행.
- 룰에 걸리면 요청 차단하고, 로그 남김.
Application Load Balancer (ALB)
- L7 로드밸런서.
- URL Path, Host 헤더 등으로 여러 Target Group으로 분기 가능.
- 여러 EC2 인스턴스에게 부하 분산.
EC2 인스턴스
- 실제 웹/애플리케이션 서버.
- 응답을 ALB → CloudFront → 사용자에게 되돌림.

이 구조의 핵심 포인트:

인터넷과 바로 붙는 건 Route 53, CloudFront, WAF, ALB 정도.
EC2는 Private Subnet 에 두고, 직접 인터넷에서 못 들어오게 막는 게 일반적인 보안 패턴.

4. S3 로그 아카이브 패턴 (Log Archive account)

4-1. 왜 별도 Log Archive 계정을 쓰나?

운영 계정(Workloads, Infra)은
- 사고가 나면 계정 자체가 털릴 수 있음.
그 계정 안에만 로그를 저장하면:
- 공격자가 로그를 지워버릴 수도 있음.
그래서 “로그만 따로 모으는 계정(Log Archive)” 을 만들어서
- 다른 계정에서 오는 로그를 크로스 계정 S3 버킷으로 모은다.

포렌식 관점: “Evidence는 분리된 금고에 넣어라.”

4-2. 기본 구조

[Workloads Account]         [Infra Account]
   CloudTrail logs  ┐
   ALB/EC2 logs     │
   CloudFront logs  │          [Security OU - Log Archive Account]
   WAF logs         │   ────>   S3 버킷: central-logs-<org>  (Write-only)
   VPC Flow logs    ┘

각 계정/리전에서 생성되는 로그:
- S3 bucket, CloudWatch Logs 등에서
- S3 Replication / KMS 권한 / Bucket policy를 사용해
  Log Archive 계정의 S3 버킷으로 전송.
Log Archive 쪽 버킷은:
- Write-only 비슷하게 설계 (운영 계정은 PutObject만, Delete 불가)
- 버전 관리 + MFA Delete + Glacier 장기 보관 등.

4-3. 어떤 로그를 모으나? (대표 예시)

CloudTrail (관리 이벤트, 데이터 이벤트)
VPC Flow Logs
ALB / NLB Access Logs
CloudFront Access Logs
WAF Logs
Route 53 DNS Query Logs
애플리케이션 로그 (필요 시)

이렇게 모아두면:

보안 사고 발생 시
- 운영 계정 상태와 상관없이
- Log Archive 계정에서 증거를 안전하게 분석할 수 있음.

5. Firewall Manager, Shield Advanced 역할

5-1. AWS Firewall Manager

“여러 계정·리전에 퍼져 있는 WAF/SG/네트워크 보안 정책을 중앙에서 한 번에 관리하는 서비스.”

무엇을 중앙 관리하나?
- AWS WAF 룰셋
- VPC Security Group 규칙
- AWS Shield Advanced 보호 리소스
- Route 53 Resolver DNS Firewall 룰 등
기능 예:
- “조직 내 모든 CloudFront에 공통 WAF 룰셋 적용해라”
- “모든 계정의 보안 그룹에서 0.0.0.0/0 SSH(22) 열려 있으면 자동으로 수정해라”

핵심: 여러 계정에 분산된 보안 정책을
한 곳에서 템플릿처럼 정의하고 뿌리는 도구

5-2. AWS Shield Advanced

DDoS 보호 서비스(고급형)

Standard는 무료지만, Advanced는 유료 + 더 강력.
어디를 보호하나?
- CloudFront
- ALB / NLB
- Global Accelerator
- Route 53 등
제공 기능:
- L3/L4 DDoS 방어 강화
- 공격 이벤트 모니터링 & 레포트
- 월별 DDoS 비용 보호(Credit)
- WAF 통합 룰 자동 생성 등.

즉, 외부에서 “트래픽 폭탄”을 맞았을 때
네트워크 레벨에서 버티도록 도와주는 방패.

5-3. 둘의 관계

Shield Advanced = 실제 DDoS 방어 기능.
Firewall Manager =
“이 Shield를 어떤 계정·리소스들에 반드시 적용하도록 강제할지”를
조직 차원에서 관리하는 관리자.

조합 예:

Shield Advanced를 활성화할 수 있는 central security 계정을 정함.
Firewall Manager에서 Policy 생성:
- “조직 내 모든 CloudFront 배포는 Shield Advanced 보호 대상이어야 한다.”
새 계정/CloudFront 배포가 생기면:
- Firewall Manager가 감지하고 Shield Advanced 보호를 자동으로 붙임.

cl0

이전 포스트

#1. AWS Security Reference Architecture

다음 포스트