#3. AWS Security Reference Architecture

이 그림은 AWS에서 보안 사고가 나면 자동으로 탐지 → 알림 → 포렌식 환경 생성 → 로그 아카이브까지 이어지는 멀티-계정 아키텍처이다.

---

0. 전체 시나리오 한 줄 요약

1. Monitored account에서 돌아가는 EC2/Lambda에 이상 행위 발생
2. 그 로그를 기반으로 GuardDuty가 Finding 생성 → Security Hub로 전달
3. Security Tooling account의 Security Hub가 모든 계정의 Finding을 모아서 관리
4. 특정 심각도 이상 Finding이 뜨면 EventBridge Rule이 포렌식 계정의 Step Functions를 트리거
5. Forensics account에서 임시 포렌식 EC2를 자동으로 띄우고, 디스크/로그 아티팩트를 S3에 수집
6. 모든 계정의 CloudTrail / VPC Flow Logs는 Log Archive account의 S3로 장기 보관

---

1. Monitored account – 실제 서비스 계정

여기는 실제로 서비스가 돌아가는 계정이다.

구성 요소:

• Amazon EC2 / AWS Lambda

  • 웹서버, API 서버, 백엔드 배치 등 실제 워크로드.

• AWS CloudTrail + VPC Flow Logs (Logs)

  • CloudTrail: 누가 어떤 API 호출을 했는지 기록
  • Flow Logs: 어떤 IP가 어느 포트로 들어왔는지 네트워크 트래픽 메타데이터

• Amazon GuardDuty

  • CloudTrail, VPC Flow Logs, DNS 로그 같은 걸 계속 분석해서
    “이상행위 같다” 하면 Finding을 생성.

• AWS Security Hub

  • GuardDuty Finding을 받아서 다른 보안 서비스 결과랑 함께 중앙에서 관리.

화살표 의미:

• EC2/Lambda → (로그) → CloudTrail/Flow Logs
• CloudTrail/Flow Logs → GuardDuty → Finding → Security Hub
• Monitored account의 Security Hub Finding이 Security Tooling account 쪽 Security Hub로 공유됨(그림의 가로 화살표).

파란 글씨 “Initiates collection and/or containment”:

• 어떤 심각한 Finding이 떴을 때,

  • 예: 보안 그룹이 갑자기 0.0.0.0:22 열림, 비정상 SSH 시도

• 이걸 트리거로 Lambda를 호출해서

  • 보안 그룹에서 0.0.0.0:22 막기(격리),
  • 스냅샷 찍기, 태그 달기 같은 자동 조치(Containment/Collection)를 수행하는 패턴을 의미

예시 시나리오

1. 공격자가 약한 패스워드를 이용해 EC2에 SSH 접속 시도
2. 이 시도는 VPC Flow Logs/CloudTrail에 기록
3. GuardDuty가 SSHBruteForce 같은 Finding 생성
4. Security Hub로 Finding 전달
5. (옵션) Lambda가 자동으로 해당 인스턴스의 SG를 막고 태그를 Quarantine=True로 변경

---

2. Security Tooling account – 보안 운영 중앙 계정

여기는 보안팀이 쓰는 중앙 관리 계정이다.

구성 요소:

• AWS Security Hub (중앙 Security Hub)

  • 여러 Monitored account에서 올라오는 GuardDuty, Config, 기타 보안 결과를 모아 보는 곳.

• Amazon GuardDuty

  • 필요하면 이 계정에도 GuardDuty를 켜서,
    이 계정 내 리소스(예: 보안 툴용 EC2, Lambda)에 대한 탐지도 함께 수행.

• Amazon EventBridge

  • Security Hub/GuardDuty Finding을 이벤트로 받아서
    “이 패턴이면 대응 자동화 실행해!” 라고 Rule을 설정하는 서비스.

• CloudTrail / Flow Logs

  • 이 계정에서 발생하는 API 호출, 네트워크 로그도 남겨서
    나중에 “보안 툴이 뭘 했는지” 추적 가능.

• AWS KMS

  • 이 계정에서 사용하는 로그, 이벤트, S3를 암호화하는 키.

흐름:

1. Monitored account의 Security Hub → Security Tooling account의 Security Hub로 Finding를 공유 (cross-account).
2. 중앙 Security Hub에서 특정 조건의 Finding(예: Severity>=High, GD_MaliciousIPCaller.Custom)을 필터링해서 EventBridge Rule로 보냄.
3. EventBridge Rule이 매칭되면, 오른쪽 Forensics account의 Step Functions를 “Initiates” 한다 (파란 글씨 “Initiates”).

즉,

“여러 계정에서 올라오는 보안 경보를 한 계정에서 모아서 보고,
진짜 심각한 건 포렌식/수집 자동화로 넘긴다” 구조.

---

3. Forensics account – 포렌식 전용 계정

여기는 사건이 났을 때만 잠깐 리소스를 생성해서 조사하는 계정이다.

구성 요소:

• AWS Step Functions

  • 사고 대응 플레이북(워크플로우)을 코드로 정의한 상태 기계.
  • 예: Start → 격리 확인 → 스냅샷 생성 → 포렌식 EC2 기동 → 볼륨 붙이기 → 아티팩트 수집 → 종료

• AWS Lambda

  • Step Functions 각 단계에서 실제 API 호출을 하는 작은 함수들.
  • 예: CreateSnapshot, ModifyInstanceAttribute, CopyObject 등을 수행.

• AWS KMS

  • 포렌식 S3 버킷, EBS 스냅샷 등을 암호화하는 키.

• Amazon EC2 (Temporary forensic EC2 instance)

  • “Spins up temporary forensic EC2 instance” 라고 적혀 있지?

  • Step Functions가 사건마다 일시적인 포렌식 전용 인스턴스를 띄워.

    • Hardened AMI (포렌식 툴 설치된 이미지)
    • 조사 완료 후 종료/삭제

• Amazon S3 (Artifacts)

  • 디스크 이미지, 메모리 덤프, 로그 번들 같은 증거(Artifacts)를 저장하는 버킷.

• CloudTrail / Flow Logs

  • “포렌식 계정에서 어떤 API가 호출됐는지” 자체도 나중에 증거가 되니까 로그를 남기고 아래 Log Archive로 보냄.

흐름:

1. Security Tooling account의 EventBridge가
   Forensics account의 Step Functions를 Invoke(“Initiates”).

2. Step Functions 시나리오 예:

   1. Lambda 호출 → Monitored account에서 의심 인스턴스 정보 조회
   2. CreateSnapshot API로 해당 인스턴스의 모든 EBS 볼륨 스냅샷
   3. 포렌식 AMI로 EC2 인스턴스(“temporary forensic EC2”) 기동
   4. 스냅샷에서 볼륨 생성 → 포렌식 EC2에 read-only로 attach
   5. EC2 내부에서 디스크 이미지(dd), 타임라인 분석 등 수행
   6. 결과 아티팩트를 Amazon S3(Artifacts 버킷)에 업로드
   7. 필요하면 조사 끝나고 EC2 종료, 스냅샷/볼륨 정리

현실적인 예시

• GuardDuty가 “RDP Brute Force 성공 가능성” Finding 생성

• EventBridge Rule:
  if Severity >= High AND ResourceType == EC2 THEN trigger ForensicWorkflow

• ForensicWorkflow(=Step Functions) 실행:

  • 의심 인스턴스를 IsolateSecurityGroup Lambda가 격리 SG로 교체
  • SnapshotVolumes 상태에서 모든 EBS 스냅샷
  • StartForensicInstance 상태에서 “DFIR-Tool-AMI”로 EC2 기동
  • AttachVolumes에서 스냅샷 볼륨을 forensic EC2에 부착
  • CollectArtifacts에서 메모리 덤프/디스크 이미지 수집 → S3에 저장
  • NotifyAnalyst 상태에서 SNS로 “수집 완료” 알림

---

4. Log Archive account – 장기 로그 보관 계정

여기는 로그만 모아서 오래, 변경 불가능하게(Immutable) 보관하는 계정이다.

구성 요소:

• Amazon S3 (Log archive bucket)

  • 다른 계정들(Monitored, Security Tooling, Forensics)의 CloudTrail / Flow Logs가
    전부 이 버킷으로 cross-account로 전송됨.

  • 보통은

    • 버전관리(Versioning) 켜고
    • S3 Object Lock(Write Once Read Many) 설정해서
      “증거 로그를 실수로/악의적으로 삭제 못하게” 만드는 패턴을 사용.

흐름:

• 각 계정의 CloudTrail 설정에서
  로그 대상 S3 버킷을 Log Archive account의 버킷으로 지정.
• VPC Flow Logs도 같은 방식으로 중앙 버킷으로 수집.

이렇게 하면:

• “사고가 난 계정에서 공격자가 CloudTrail 로그를 삭제해버렸다”
  → 그래도 Log Archive account에 복제된 로그는 안전하게 남아 있음.

• 포렌식 분석할 때,

  • Log Archive S3에 있는 CloudTrail/VPC Flow를 Athena/Glue/ES 등으로 분석.

---

5. 계정별 역할 요약

• Monitored account

  • 실제 비즈니스 워크로드 계정
  • GuardDuty & Security Hub 설치
  • 1차 탐지, 기본 로그 수집

• Security Tooling account

  • 보안 운영 계정
  • 여러 Monitored account에서 올라오는 Finding을 중앙 Security Hub에서 통합
  • EventBridge로 자동 대응 트리거 관리

• Forensics account

  • 포렌식·조사 전용 계정
  • Step Functions + Lambda로 IR 플레이북 실행
  • 임시 포렌식 EC2 기동, 아티팩트 S3 저장

• Log Archive account

  • 장기 로그 보관 계정
  • 모든 계정의 CloudTrail / Flow Logs S3로 수집
  • Object Lock으로 증거 보존

---