SSM Automation과 EventBridge로 완성하는 사고 대응 자동화와 자동 격리
_Category: Incident Response_
보안 사고는 예고 없이 찾아옵니다. GuardDuty 알림이 뜨는 순간 담당자가 없을 수도 있고, 자정일 수도 있습니다. 현대 클라우드 보안에서 자동화는 선택이 아닌 필수입니다. 사람이 개입하기 전에 이미 격리가 완료되어 있어야 하고, 증거는 보존된 상태여야 하며, 팀원들은 이미 알림을 받은 상태여야 합니다. 탐지부터 격리·증거 수집·복구까지, AWS 사고 대응 자동화의 전체 흐름을 SCS-C03 시험 시나리오 중심으로 정리합니다.
---
클라우드 시대의 사고 대응 사고방식
온프레미스에서 보안 사고 대응은 물리적 접근과 수동 작업이 중심이었습니다. 서버에 직접 접속해 로그를 뒤지고 네트워크 케이블을 뽑는 과정은 몇 시간이 걸렸습니다. AWS 환경에서는 세 가지가 근본적으로 다릅니다.
첫째, 인프라는 코드입니다. EC2 격리, EBS Snapshot, 새 인스턴스 시작이 모두 API 한 번으로 가능합니다. Lambda가 수초 안에 자동으로 처리합니다. 둘째, 모든 것이 이벤트입니다. GuardDuty 위협, S3 퍼블릭 ACL 설정, IAM 키 비정상 사용 — 모두 EventBridge로 흘러 들어옵니다. EventBridge는 사건 발생 즉시 울리는 자동 알림 벨입니다. 셋째, 불변 인프라입니다. 침해된 인스턴스를 수리하지 않습니다. 격리하고 스냅샷을 찍어 증거를 보존하고 새 인스턴스로 교체합니다. 감염 환자를 격리실에 먼저 보내는 것과 같습니다.
---
NIST 기반 IR Lifecycle과 AWS 서비스 매핑
NIST SP 800-61은 사고 대응을 7단계로 정의합니다. AWS는 이 각 단계에 구체적인 서비스를 매핑해 두었습니다. 시험에서는 특정 단계에서 어떤 서비스를 선택해야 하는지 묻는 방식으로 출제됩니다.
| IR 단계 | 목표 | 핵심 AWS 서비스 | |---------|------|----------------| | Prepare (준비) | 도구·권한·Runbook 사전 구성 | Systems Manager Incident Manager, IAM Role, SSM Automation Runbook | | Detect (탐지) | 위협 식별·알림 생성 | GuardDuty, Security Hub, Macie, CloudTrail, Config | | Analyze (분석) | 영향 범위 파악·근본 원인 조사 | Detective, CloudTrail, CloudWatch Logs Insights, Athena | | Contain (격리) | 추가 확산 방지 | Quarantine SG, VPC Isolation, IAM Policy Revoke, EventBridge + Lambda | | Eradicate (제거) | 악성 요소 제거 | SSM Automation, Systems Manager Run Command, Lambda | | Recover (복구) | 서비스 정상화 | AWS Backup, AMI, CloudFormation StackSet | | Lessons Learned (회고) | 재발 방지 | Security Hub Findings 리뷰, Config Rule 강화, Runbook 업데이트 |
이 표는 시험 문제의 뼈대입니다. "침해 범위 파악" → Detective, "즉시 격리" → Quarantine SG + Lambda, "복구 자동화" → AWS Backup 또는 CloudFormation 패턴이 반복됩니다. Prepare 단계가 가장 중요합니다. Runbook이 없으면 사람이 판단해야 하고 시간이 걸립니다. SSM Automation Runbook을 미리 작성해 두면 전체 대응 속도가 달라집니다.
---
탐지 → 트리거: GuardDuty/Security Hub Finding과 EventBridge
자동화의 시작점은 탐지입니다. GuardDuty 위협, Security Hub Finding, CloudTrail 비정상 API 호출 등 모든 이벤트가 EventBridge로 흘러 들어옵니다. EventBridge는 이 이벤트들을 필터링해 Lambda, SSM Automation, Step Functions, SNS 등으로 라우팅합니다. 전형적인 흐름은 GuardDuty Finding → EventBridge Rule(타입/심각도 필터) → Lambda(격리 로직) → Quarantine SG 적용 + EBS Snapshot + SNS 알림입니다.
EventBridge Rule을 구성할 때는 GuardDuty의 모든 Finding에 반응하지 않도록 주의합니다. 오탐(False Positive)으로 불필요한 격리가 발생할 수 있습니다. 심각도 HIGH 이상이거나 특정 Finding Type( 등)에만 반응하도록 이벤트 패턴을 정교하게 작성해야 합니다. Security Hub의 Custom Actions는 완전 자동화와 수동 승인의 중간 단계를 제공합니다. 보안팀이 콘솔에서 Finding을 선택하고 "격리 시작"을 누르면 EventBridge → Lambda가 실행됩니다.
두 서비스를 혼동하지 않도록 비교합니다.
| 항목 | EventBridge | CloudWatch Events | |------|-------------|-------------------| | 관계 | EventBridge가 CloudWatch Events를 대체 | EventBridge 출시 전 이벤트 라우팅 서비스 | | 이벤트 버스 | 기본 버스 + 커스텀 버스 + 파트너 버스 지원 | 기본 버스만 | | 서드파티 통합 | Datadog, PagerDuty 등 SaaS 파트너 이벤트 수신 가능 | 불가 | | 권장 여부 | 신규 구성 시 EventBridge 사용 권장 | 레거시 |
"사고 탐지 이벤트 기반 자동 대응 트리거" 문제에서는 항상 EventBridge를 선택합니다. CloudWatch Events는 레거시이며 신규 아키텍처에서 권장되지 않습니다.
---
자동 격리 패턴 (Quarantine SG·IAM 회수·Snapshot 분리)
격리(Contain)는 시간이 가장 중요한 단계입니다. 인스턴스가 계속 외부와 통신하는 매 초가 추가 피해를 만듭니다.
Quarantine SG 패턴
Quarantine SG(격리 보안 그룹)는 감염 환자를 격리실에 가두는 것과 같습니다. 모든 인바운드·아웃바운드를 차단하는 보안 그룹을 미리 만들어 두고, Lambda에서 를 호출해 기존 SG 전체를 제거하고 Quarantine SG로 교체합니다. 단순히 추가하면 기존 규칙이 그대로 살아 있으니 반드시 교체여야 합니다. 원래 SG 목록은 복구 시 재적용을 위해 별도로 저장합니다. 포렌식팀 접근이 필요하다면 Quarantine SG에 forensics 서브넷 IP의 인바운드 규칙 하나만 허용합니다.
IAM Role/정책 회수
EC2 인스턴스에 연결된 IAM Role을 즉시 회수하거나 권한을 제한하는 인라인 정책을 추가하는 것도 격리의 일부입니다. IAM 액세스 키가 노출된 경우에는 키 비활성화가 최우선입니다. AWS는 노출된 자격 증명을 자동 감지하면 정책을 자동으로 연결합니다. 이 정책이 보이면 이미 AWS Trust & Safety 팀이 탐지한 상태이므로 정책을 삭제하면 안 되고, 키 비활성화 후 CloudTrail로 피해 범위를 조사해야 합니다. Stale Credentials(90일 이상 미사용 키)는 Access Analyzer와 IAM 자격 증명 보고서를 결합한 Lambda 정기 실행 패턴으로 자동 처리합니다.
EBS Snapshot 분리 및 포렌식 환경 구성
격리 직후에는 EBS Snapshot으로 증거를 보존합니다. 인스턴스를 종료하면 인스턴스 스토어 데이터가 영구 소실됩니다. Snapshot을 먼저 찍어야 합니다.
| 격리 방법 | 서비스 가용성 | 증거 보존 | 네트워크 차단 | |-----------|-------------|-----------|---------------| | Quarantine SG 적용 | 유지 (인스턴스 실행 중) | EBS 볼륨 보존 | 완전 차단 가능 | | 인스턴스 종료 | Auto Scaling이 새 인스턴스 시작 | 인스턴스 스토어 소실 | 완전 차단 |
ASG 소속 인스턴스라면 먼저 ASG Detach(종료 없이 ASG 관리에서만 제거 → ASG가 새 인스턴스 자동 시작)한 후 Quarantine SG를 적용합니다. 포렌식 분석 시에는 스냅샷에서 새 EBS 볼륨을 생성해 전용 분석 인스턴스에 마운트합니다. 원본에 직접 접근하면 증거 무결성이 훼손됩니다.
!자동 격리 패턴 3가지
SSM Automation과 Lambda로 Runbook 코드화하기
SSM Automation은 표준 운영 절차서(SOP)를 YAML 문서로 작성해 자동으로 실행하는 시스템입니다. EC2 격리 Runbook을 예로 들면 1단계 EBS Snapshot 생성 → 2단계 Quarantine SG 적용 → 3단계 SNS 알림 구조로 작성하며, 각 단계 실패 시 롤백 또는 건너뜀도 정의할 수 있습니다.
Lambda와 SSM Automation의 역할은 다릅니다. Lambda는 빠른 단일 작업(SG 교체, 키 비활성화)에 적합하고, SSM Automation은 순차적 멀티스텝 워크플로우에 적합합니다. 둘을 조합해 EventBridge → Lambda(빠른 격리) → SSM Automation(포렌식 수집·알림) 순서로 구성하면 속도와 완성도를 모두 잡을 수 있습니다. 병렬 실행·오류 처리·재시도가 필요한 고복잡도 시나리오에는 Step Functions가 더 유연합니다.
---
Systems Manager Incident Manager와 협업·Engagement
Systems Manager Incident Manager는 운영 장애와 보안 사고 전반을 여러 팀이 협업해서 처리할 수 있는 구조를 만들어 주는 서비스입니다. 세 가지 핵심 개념만 알면 시험 문제를 풀 수 있습니다.
Response Plan은 사고 발생 시 역할 분배·실행할 Runbook·소통 채널을 미리 정의한 계획서입니다. 사고가 발생하면 자동으로 활성화됩니다. Engagement는 온콜 담당자에게 SNS, PagerDuty, OpsGenie로 에스컬레이션하는 기능이며, 응답이 없으면 자동으로 다음 담당자에게 넘어갑니다. Chat Channels는 Slack 또는 Amazon Chime과 연동해 팀이 실시간으로 소통하면서 Runbook 진행 상태를 확인합니다.
시험에서 Incident Manager가 나오는 맥락은 "여러 팀 협업 필요" 또는 "절차 문서화+자동화"입니다. 단순 격리나 알림에는 EventBridge + Lambda가 더 적합합니다. Detective는 분석 단계에서 GuardDuty·CloudTrail·VPC Flow Logs를 그래프 DB로 연결해 침해 엔티티의 관계와 영향 범위를 시각화합니다. "침해 범위 파악" 또는 "관련 리소스 연결 분석" 키워드에서 Detective를 선택합니다.
---
시험에서 헷갈리는 사고 대응 시나리오
SCS-C03에서 반복되는 핵심 시나리오와 정답 패턴입니다.
시나리오 1 — S3 퍼블릭 ACL 즉시 탐지·제거: 키워드는 "즉시"와 "객체 수준"입니다. CloudTrail S3 데이터 이벤트 활성화 → EventBridge Rule → Lambda() → SNS 알림. AWS Config를 고르면 오답입니다. Config rule은 주기적 평가(수분 지연)이므로 즉각 탐지가 불가합니다. 즉시 탐지가 나오면 항상 CloudTrail + EventBridge + Lambda를 선택하세요.
시나리오 2 — GuardDuty 탐지 EC2 격리 (ASG 포함): 서비스 가용성 유지 + 격리 + 포렌식을 동시에 요구합니다. 정답 순서는 ASG Detach(가용성 유지) → Quarantine SG 적용(트래픽 차단) → EBS Snapshot(증거 보존)입니다. 인스턴스 즉시 종료는 인스턴스 스토어 데이터를 영구 삭제하므로 절대 선택하면 안 됩니다.
시나리오 3 — IAM 액세스 키 노출: Contain → Investigate → Remediate 원칙을 따릅니다. 키 즉시 비활성화(삭제 전 비활성화, 복구 가능) → CloudTrail로 소스 IP·실행 API·시간 전수 조사 → 키 삭제 및 신규 발급. GuardDuty를 먼저 확인하는 선택지는 오답이며, 즉각 차단이 먼저입니다.
시나리오 4 — AWS Abuse Notice: EC2가 스팸을 발송한다는 notice를 받으면 에 직접 회신합니다. AWS Support 케이스가 아닙니다. 회신(인지 + 조치 계획) + 인스턴스 조사·격리를 동시에 진행하며, 방치 시 계정 정지 위험이 있습니다.
시나리오 5 — Macie 민감 데이터 자동 대응: Macie Finding → EventBridge → Lambda(S3 퍼블릭 액세스 차단 또는 버킷 정책 수정). 수동 승인이 필요하면 Security Hub Custom Actions를 중간에 삽입합니다.
---
시험 핵심 정리
탐지·트리거 패턴: 실시간 자동 대응 → EventBridge + Lambda. S3 객체 수준 즉각 탐지 → CloudTrail 데이터 이벤트 + EventBridge + Lambda (Config는 수분 지연 → 오답). 수동 승인 포함 → Security Hub Custom Actions + EventBridge + Lambda. GuardDuty 자동 격리 → EventBridge Rule(심각도/타입 필터) → Lambda.
EC2 격리 패턴: ASG Detach(가용성) → Quarantine SG(차단) → EBS Snapshot(증거)가 황금 순서입니다. 인스턴스 즉시 종료는 포렌식 증거를 파괴하므로 절대 금지입니다. Quarantine SG는 인바운드+아웃바운드 전체 Deny, 포렌식팀 IP만 예외 허용합니다.
IAM 자격 증명 패턴: 키 노출 시 비활성화(먼저) → CloudTrail 조사 → 삭제 + 신규 발급. AWSExposedCredentialPolicy_DO_NOT_REMOVE는 AWS가 자동 연결하는 정책이므로 삭제 금지입니다. Abuse Notice는 abuse@amazonaws.com으로 직접 회신합니다(Support 케이스 아님). Stale Credentials는 IAM 자격 증명 보고서 + Access Analyzer로 주기 자동화합니다.
서비스 선택 가이드: 침해 범위 파악 → Detective. 멀티스텝 IR 워크플로우 → SSM Automation 또는 Step Functions. 팀 협업·온콜 에스컬레이션 → Systems Manager Incident Manager. 빠른 복원 → AWS Backup 또는 CloudFormation. 민감 데이터 노출 자동 대응 → Macie → EventBridge → Lambda.