#2. AWS Security Reference Architecture

cl0·2025년 11월 23일
AWS_SRA

AWS_SRA

목록 보기
3/19

1. “분산형 퍼리미터 보안”

  • 여전히 맨 바깥은 Organization (여러 AWS 계정 묶음)

  • Security OU / Infrastructure OU / Workloads OU 구조는 같아.

  • 차이점은:

    • 중앙형: CloudFront, WAF, Shield 같은 퍼리미터 리소스를 Infra OU의 Network account 한 곳에 몰아둠
    • 분산형: 그런 퍼리미터 리소스를 각 Workloads(애플리케이션) 계정 안에 분산 배치

이 그림은 “각 애플리케이션 계정이 자기 CloudFront/WAF/Shield를 갖는 구조”를 보여줌.

2. OU – Security (보안 전담 영역) – 중앙형과 거의 동일

2-1. Security Tooling account

  • Amazon GuardDuty
  • AWS Security Hub (CSPM)
  • AWS Firewall Manager

여러 계정에서 올라오는 보안 이벤트/설정을
한 계정(Security Tooling)에서 통합 관제/정책 배포.

2-2. Log Archive account

  • Central logs S3 버킷

  • 화살표로 들어오는 로그:

    • CloudFront access logs
    • Global Accelerator flow logs
    • AWS WAF logs

아래쪽 서비스들:

  • Security Hub CSPM
  • GuardDuty
  • Macie
  • Config
  • IAM Access Analyzer
  • Organization trail

요약: 로그 금고 계정 + 보안 기본 서비스.
중앙형 그림과 구조 동일, 다만 여기로 들어오는 로그의 출발지가 조금 달라짐.
(이제 Workloads 계정의 CloudFront/WAF/GA에서 로그가 온다고 보면 됨).

3. OU – Infrastructure (공용 인프라)

Network account 안

  • 중앙형에서 봤던

    • CloudFront
    • WAF
    • Shield Advanced
    • ACM
      전부 사라지고

  • 딱 하나:

    • Amazon Route 53 hosted zones 만 남아 있음.

그리고 아래 줄:

  • Security Hub CSPM
  • GuardDuty
  • EventBridge
  • Config
  • IAM Access Analyzer
  • Organization trail

즉,

Infra 계정은 이제 “DNS(도메인)만” 담당하는 아주 얇은 계층이 됨.

왜 이렇게 하냐?

  • 도메인 자체는 회사 전체에서 공유하는 자산이라

    • example.com 이라는 hosted zone 관리 계정 하나를 두고,

  • 실제 트래픽 처리는 각 애플리케이션 계정의 CloudFront/ALB로 넘겨버리는 패턴.

4. OU – Workloads (실제 서비스 계정) – 분산형의 핵심

4-1. VPC + ALB + EC2 (동적/정적 오리진)

  • VPC

  • Private subnet 안에 EC2 instances

  • Application Load Balancer

  • 아래 텍스트:

    • Dynamic origins (ALB/EC2 같은 동적 서버)
    • Static origins (S3 등 정적 콘텐츠)

이 부분은 중앙형과 동일.

4-2. 가운데 점선 박스: 각 애플리케이션 계정 안의 퍼리미터

이게 중앙형과 가장 크게 다른 부분.

점선 박스 안에 있는 것들:

  1. Amazon CloudFront

    • 에지 캐시 + CDN
    • 중앙형에서는 Infra 계정에 있었는데
      → 이제 Application account 안에 직접 존재.

  2. AWS Global Accelerator

    • TCP/UDP 기반 글로벌 엔드포인트 가속기.
    • 여러 리전에 걸친 애플리케이션으로 트래픽을 지능적으로 라우팅.
    • FLOW LOGS 라벨: GA 흐름 로그도 Log Archive로 보낸다는 의미.

  3. Amazon Route 53 health checks

    • 애플리케이션 헬스 체크용.
    • 특정 엔드포인트가 정상인지 감시,
      비정상이면 가용한 리전/엔드포인트로 라우팅 조정.

  4. AWS WAF

    • 웹 방화벽. CloudFront/ALB 앞단에서 L7 필터링.

  5. AWS Certificate Manager

    • TLS/SSL 인증서 발급/관리. CloudFront, ALB에 붙이는 인증서 관리.

  6. AWS Shield Advanced

    • DDoS 보호. CloudFront, ALB, GA 등에 대한 보호 활성화.

요약:
이 점선 박스 전체가 예전에는 Infra OU의 Network account에서 공용으로 운용하던 레이어인데,
이제는 각 Workloads 계정 안으로 내려와 “서비스별 전용 퍼리미터”가 된 것.

4-3. 이 계정의 보안 서비스들

  • Security Hub CSPM
  • GuardDuty
  • IAM Access Analyzer
  • EventBridge
  • Config
  • Macie
  • Organization trail

Workloads 계정에서도 기본 보안·감사 서비스는 그대로 켜두고,
결과는 Security OU로 집계.

5. 중앙형 vs 분산형

5-1. 구조 비교 한 줄 요약

  • 중앙형(Centralized)

    • CloudFront / WAF / Shield / ACM / (경우에 따라 ALB) 를
      Infra OU – Network account 한 곳에 모아서 운영.
    • 모든 애플리케이션이 이 Network account의 리소스를 공유.

  • 분산형(Distributed)

    • 각 Workloads Application account 안에
      CloudFront / WAF / Shield / ACM / GA / 헬스 체크를 둠.
    • 애플리케이션마다 자기 퍼리미터를 소유.

5-2. 분산형의 장점

  1. 서비스별 완전한 격리

    • App A CloudFront/WAF 설정을 건드려도
      App B에는 영향 없음.
    • 사고 나도 해당 Workload 계정 범위에서 끝날 확률 ↑.

  2. 팀별 자율성

    • “각 서비스 팀이 자기 계정에서 CloudFront/WAF 룰을 직접 운영” 가능.
    • 공용 Network 팀을 거치지 않아도 빠르게 설정 변경.

  3. 멀티테넌트/규제 분리

    • 고객별, 사업부별로 계정을 나누고
      각 계정에서 자체 퍼리미터를 운영하면
      규제/계약 상 격리 요구사항 충족하기 쉬움.

5-3. 분산형의 단점 (중앙형 대비)

  1. 정책 일관성 관리가 어려움

    • CloudFront/WAF/Shield가 각 계정에 흩어져 있으니
      “회사 표준 룰”을 유지하려면
      Firewall Manager 같은 중앙 도구로 강제해야 함.
    • 안 그러면 서비스마다 제각각 설정.

  2. 운영 비용↑

    • CloudFront, WAF, Shield Advanced를
      계정·서비스별로 별도 가입/설정해야 해서
      운영·비용 관리 포인트가 늘어남.

  3. 전사 단위 인프라 팀이 있으면 오히려 불편

    • Infra 팀이 한 계정에서 모든 퍼리미터를 관리할 수 없고,
      각 Workload 계정을 순회하면서 관리해야 함.

6. 트래픽 & 로그 흐름

6-1. 요청 흐름

  1. 사용자 브라우저 → 도메인

    • www.service-a.com 입력

  2. Route 53 (Infra – Network account)

    • 해당 도메인을 이 Workload 계정의
      CloudFront 또는 Global Accelerator 엔드포인트로 매핑.

  3. Global Accelerator / CloudFront (Workload account)

    • GA: 전 세계 엣지 네트워크에서 가장 좋은 엔드포인트 선택, L4 가속.
    • CloudFront: CDN 캐시 + AWS WAF와 연동.
    • 둘 다 Shield Advanced 보호 대상일 수 있음.

  4. AWS WAF

    • SQLi, XSS, 봇 차단.
    • 차단/허용된 요청에 대한 로그 기록.

  5. ALB → VPC 내부 EC2

    • 정상 요청을 Application Load Balancer가 받고,
    • Private subnet의 EC2 인스턴스로 분산.

  6. 응답 경로는 역방향으로 브라우저까지 전달.

6-2. 로그 흐름

  • 이 Workload 계정에서 생성된:

    • CloudFront access logs
    • Global Accelerator flow logs
    • WAF logs

  • → 크로스 계정 S3 정책으로
    Security OU – Log Archive account 의 Central logs 버킷에 전송.

그 뒤:

  • GuardDuty, Macie, Config, IAM Access Analyzer 등이
    각 계정에서 정보를 수집·분석하고,
  • Security Hub가 Security Tooling account에서 결과를 통합해 보여준다.

7. 언제 어떤 모델을 쓸까?

  • 중앙형이 어울릴 때

    • 인프라 팀 하나가 대부분 서비스의 네트워크/퍼리미터를 대신 운영.
    • 서비스 수가 많지 않거나, 구조가 단순.
    • “공용 WAF 룰” 하나 만들어서 다 같이 쓰기 좋아할 때.

  • 분산형이 어울릴 때 (지금 그림)

    • 서비스/계정 수가 많고, 팀별로 독립 운영.
    • 고객/조직별로 강한 격리가 필요.
    • 특정 서비스만 튜닝된 CloudFront/WAF/Shield 구성이 필요한 경우.
profile
cl0
이전 포스트

#0. AWS Security Reference Architecture

다음 포스트

#3. AWS Security Reference Architecture

0개의 댓글