퍼블릭 클라우드(AWS) 침해사고 대응 전략

퍼블릭 클라우드(AWS) 침해사고 대응 전략

사고는 "발생하면"이 아니라 "발생할 때"를 기준으로 준비해야 한다.

들어가며

온프레미스에서는 네트워크 장비 로그를 뒤지고 서버에 직접 접속하여 포렌식을 수행했다. 하지만 AWS 같은 퍼블릭 클라우드 환경에서의 침해사고 대응은 전혀 다른 접근이 필요하다. 물리 서버 대신 API가 있고, 네트워크 탭 대신 VPC Flow Logs가 있으며, 디스크 이미징 대신 스냅샷이 있다.

이 글에서는 27회 해킹방지워크샵에서 발표된 AWS 사고대응 전략을 기반으로, 클라우드 환경에서의 IR(Incident Response) 체계를 정리한다.

---

1. 클라우드 사고 대응(IR)이란?

의심되는 사이버 보안 사고에 대해 대비, 탐지, 억제 및 복구를 수행하는 데 활용되는 인력, 프로세스 및 기술 시스템이다.

이해관계자

주체	역할
Incident Responders	인프라 운영팀, 보안관제, 보안 담당자
침해사고 대응팀	전문 IR 수행, 포렌식, 근본 원인 분석
3rd Party	외부 보안 전문 업체, AWS 지원

권한과 책임추적성

• 조직 전체의 권한을 식별하고 문서화
• 애플리케이션 개발팀과 인프라팀 간 협조 관계 구성
• 신뢰성 높은 3rd Party 솔루션 파트너 확보

AWS가 제공하는 IR 지원

지원 서비스	설명
AWS Support	기술 지원 및 가이드
AWS CIRT	Customer Incident Response Team — 직접적인 사고 대응 지원
DDoS Response Support	Shield Advanced 고객 대상 DDoS 대응 지원
Security Incident Response (Agentic AI)	re:Invent 2025에서 발표된 AI 기반 사고 조사 및 복구 자동화 서비스

---

2. 프로세스 대비 — 사고가 터지기 전에

IR 계획의 필수 구성 요소

• 대응팀 구성 및 연락망
• 권한과 책임 추적성
• 공유 및 전파 프로세스
• 단계 및 조치 사항
• 심각도 및 우선순위 정의

문서화해야 할 것들

사고 발생 시 빠르게 파악해야 할 정보를 사전에 문서화해두어야 한다.

• AWS 계정 구조 및 소유자
• 구성된 AWS 서비스 목록
• 인증 및 권한 부여 체계
• 로깅 및 모니터링 구성 현황
• 네트워크 구성도
• 사용 중인 3rd Party 솔루션

플레이북(Playbook) 구성

예상되는 사고 유형별로 대응 절차를 사전에 정의한다.

플레이북에 포함할 내용:

• 개요 (어떤 유형의 사고인가)
• 전제 조건 (어떤 도구/권한이 필요한가)
• 이해관계자 (누가 관여해야 하는가)
• 대응 절차 (단계별 행동 지침)
• 예상 결과 (정상 대응 시 기대 결과)
• 외부 레퍼런스

모의 훈련

• 상세 계획 기반 훈련: 시나리오 기반 탁상 훈련
• 블루/퍼플팀: 방어 역량 검증
• 레드팀: 실제 공격 시뮬레이션

침투 테스트 시 AWS 침투테스트 정책 검토 필수

---

3. AWS 서비스를 활용한 위협 탐지

핵심 탐지 서비스

서비스	역할	데이터 소스
GuardDuty	이상 행위 및 악성 활동 탐지 + Extended Threat Detection(ETD)	CloudTrail, DNS, VPC Flow Logs, S3, EKS, EC2/ECS 런타임
AWS Config	리소스 구성 상태 및 규칙 준수 감사	리소스 구성 변경 기록
Amazon Inspector	소프트웨어 취약점 스캔	50+ 인텔리전스 소스 기반, 거의 실시간

Security Hub — 보안 탐지 결과 통합

Security Hub는 모든 보안 서비스의 탐지 결과를 단일 대시보드로 통합한다.

핵심 기능:

• 모든 로그에 대한 표준화된 데이터 정규화
• 모범 사례 기반 자동화된 보안 점검
• 모든 계정의 보안 탐지 결과 집계
• GuardDuty, Config, Inspector, 3rd Party 솔루션 결과 통합 필터링

---

4. 사고 대응을 위한 핵심 AWS 서비스 맵

로깅

서비스	수집 대상
CloudWatch	애플리케이션/인프라 메트릭 및 로그
AWS Config	리소스 구성 변경 이력
CloudTrail	모든 AWS API 호출 기록
VPC Flow Logs	네트워크 트래픽 기록
Route 53 DNS Logs	DNS 쿼리 기록

탐지 및 분석

서비스	역할
GuardDuty	위협 탐지
Inspector	취약점 스캔
Security Lake	보안 데이터 레이크
Athena	로그 쿼리/분석
Security Hub	결과 통합
Detective	근본 원인 분석

자동화

서비스	역할
EventBridge	이벤트 라우팅
Lambda	자동화된 대응 실행
Step Functions	복잡한 워크플로우 오케스트레이션
Systems Manager	인스턴스 원격 명령 실행

---

5. 사고대응 자동화 아키텍처 — 실전 구현

가장 핵심적인 부분이다. 각 단계별 자동화 아키텍처를 상세히 살펴보자.

5-1. 탐지 단계 — 사고 감지 및 식별

GuardDuty → CloudWatch Events → SNS Topic
                                    ├── Lambda 트리거 → 분석 단계 실행
                                    └── Slack WebHook → 보안팀 알림

GuardDuty가 위협을 감지하면 CloudWatch Events를 통해 자동으로 Lambda 함수를 트리거하고, 동시에 Slack으로 보안팀에 알린다.

5-2. 격리 단계 — 초동 조치

Lambda → 감염된 EC2 인스턴스를 검역 Security Group으로 이동
      → 네트워크 격리 수행
      → Slack으로 격리 완료 알림

검역 Security Group: 인바운드/아웃바운드 트래픽을 모두 차단하되, 포렌식 팀의 접근만 허용하는 특수 Security Group.

5-3. 대응 및 분석 단계

메모리 덤프 수행:

Lambda → Systems Manager → Automation → RunCommand
      → 라이브 상태에서 메모리 덤프 캡처
      → 실시간 데이터 수집

스냅샷 기반 포렌식:

Lambda → EBS 스냅샷 생성
      → 포렌식 전용 EC2 인스턴스 생성 (분석 도구 사전 설치)
      → 스냅샷을 볼륨으로 변환하여 포렌식 인스턴스에 Attach

자동화된 상세 분석:

Lambda → Systems Manager → Automation Script
      → 실행 항목:
         ├── Disk Dump
         ├── Process Dump
         ├── Shell 파일 탐색
         ├── Strace Export
         ├── /var/logs 수집
         └── bash_history 수집
      → 분석 결과 → S3 Bucket (암호화 저장)

5-4. 데이터 추출 단계

분석 결과를 암호화하여 전용 S3 버킷에 저장한다.

5-5. 종료 단계

Systems Manager → Automation
├── GuardDuty Finding 정리
├── 격리된 인스턴스 정보 기록
├── 포렌식 결과 정리
├── 사고 인스턴스 중지/종료
└── 신규 인스턴스 복원

→ Slack 알림
  ├── 단계별 이슈 결과
  ├── 분석 결과 요약
  ├── 분석 내역 URL
  └── Private Channel 구성

---

6. 전체 자동화 파이프라인 요약

[탐지] GuardDuty 알림
         ↓
[격리] 검역 SG로 네트워크 격리
         ↓
[수집] 메모리 덤프 + EBS 스냅샷
         ↓
[분석] 포렌식 인스턴스에서 자동 분석
         ↓
[저장] 결과를 암호화하여 S3에 보관
         ↓
[복원] 사고 인스턴스 종료 + 신규 인스턴스 복원
         ↓
[알림] Slack으로 전 과정 결과 공유

이 전체 파이프라인이 사람의 개입 없이 자동으로 실행된다. 보안팀은 Slack 알림을 받고 분석 결과를 검토하기만 하면 된다.

---

7. 사고 대응 체계 구축 체크리스트

• [ ] IR 계획 문서화 완료
• [ ] 주요 사고 유형별 플레이북 작성
• [ ] CloudTrail 전 리전 활성화 + 로그 보호
• [ ] GuardDuty 활성화 + Security Hub 연동
• [ ] 검역용 Security Group 사전 생성
• [ ] 포렌식 전용 AMI 사전 준비 (분석 도구 포함)
• [ ] Lambda 기반 자동 격리 함수 배포
• [ ] Systems Manager Agent 전체 인스턴스 설치
• [ ] Slack/Teams 연동 알림 채널 구성
• [ ] 분기별 모의 훈련 실시

---

정리

클라우드 환경에서의 사고 대응은 자동화가 핵심이다. 수동으로 대응하면 데이터 유출이 완료된 후에야 조치를 시작하게 된다.

AWS가 제공하는 서비스(GuardDuty, Systems Manager, Lambda, EventBridge)를 조합하면 탐지 → 격리 → 수집 → 분석 → 복원의 전 과정을 자동화할 수 있다. 중요한 것은 사고가 발생하기 전에 이 파이프라인을 구축하고 테스트해두는 것이다.

---

2025년 업데이트: GuardDuty Extended Threat Detection (ETD)

2025년 GuardDuty에 추가된 ETD는 사고 대응의 패러다임을 바꿨다.

• 기존: 개별 이벤트마다 낮은 신뢰도의 개별 Finding 생성 → 알림 피로
• ETD: VPC Flow Logs, CloudTrail, EKS 감사 로그, 프로세스 런타임 행동, 네트워크 활동을 상관 분석하여 하나의 높은 신뢰도, Critical 심각도 공격 시퀀스 Finding 생성

ETD 지원 범위 (2025~):

• EKS 클러스터 (2025.06 GA)
• EC2 인스턴스 및 ECS 클러스터 (2025.12 GA)

또한 GuardDuty Malware Protection for AWS Backup (re:Invent 2025)이 추가되어, EC2/EBS/S3 백업을 자동 스캔하고 마지막으로 확인된 클린 백업을 식별하여 복구를 지원한다.

---

이 글은 제27회 해킹방지워크샵 'Track F. 클라우드 보안' 발표 내용을 기반으로 작성되었습니다. re:Invent 2025 발표 내용(Security Incident Response Agentic AI, GuardDuty ETD)을 반영하여 업데이트되었습니다. 클라우드 보안 시리즈 [7/10]