[security] GuardDuty

One-Line Summary

Amazon GuardDuty는 로그를 자동으로 분석해 계정·워크로드의 위협(악성 활동·이상 행동)을 탐지하는 지능형 위협 탐지 서비스다. 에이전트·인프라 설치 없이 클릭 한 번으로 켜면, CloudTrail·VPC Flow Logs·DNS 로그 등을 백그라운드에서 읽어 침해된 인스턴스, 비정상 API 호출, 크립토마이닝, 데이터 유출 시도 등을 찾아낸다. 시험에서는 "탐지(detection) 서비스" / 무엇을 분석하나(데이터 소스) / Inspector·Macie·Config와의 차이 / EventBridge 연동 자동 대응 / 조직 단위 관리 가 핵심이다.

뭔지 (What / Why)

침해는 대부분 로그에 흔적을 남긴다 — 낯선 국가에서의 루트 로그인, 갑작스런 대량 데이터 전송, 알려진 악성 IP와의 통신, 크립토마이닝 도메인 조회 등. 문제는 이 로그가 너무 많아 사람이 다 못 본다는 것이다.

GuardDuty는 이 로그들을 대신 상시 분석한다. 위협 인텔리전스(알려진 악성 IP·도메인 피드)와 머신러닝·이상 탐지를 결합해 "이건 위협이다" 싶은 것을 **Finding(발견 항목)**으로 올려준다.

[CloudTrail] [VPC Flow Logs] [DNS 로그] [EKS/S3/RDS 등] 
        │  (GuardDuty가 백그라운드에서 읽음 — 로그 활성화·저장 불필요)
        ▼
   [GuardDuty]  = 위협 인텔 + ML 이상탐지
        ▼
   Finding(심각도 Low/Med/High) ─▶ EventBridge ─▶ Lambda/SNS 자동 대응

가장 중요한 성격 3가지 (여기서 시험이 갈림)

탐지(detection) 전용 — 막는(prevention) 서비스가 아니다. "이상하다"를 알려줄 뿐, 차단은 EventBridge로 이어붙인 자동화(Lambda/WAF/SG)가 한다.
에이전트리스·비침투적 — 로그를 읽기만 한다. 워크로드에 에이전트 설치나 로그 파이프라인 구성이 필요 없고, 원본 로그를 따로 켜거나 저장할 필요도 없다.
기존 로그를 소비 — CloudTrail 등 소스를 GuardDuty가 직접 가져다 본다(내가 S3에 로그를 모아둘 필요 없음).

무엇을 분석하나 — 데이터 소스 (빈출)

소스	잡아내는 위협 예시
CloudTrail 관리 이벤트	비정상 API 호출, 루트 사용, 보안설정 무력화 시도
CloudTrail S3 데이터 이벤트	비정상적 S3 접근·유출
VPC Flow Logs	악성 IP와의 통신, 포트 스캔, 비정상 아웃바운드
DNS 로그	크립토마이닝·C2 도메인 조회, DNS 데이터 유출
EKS 감사 로그 / 런타임	쿠버네티스 침해, 컨테이너 이상 행동
Malware Protection	EC2/컨테이너 EBS 볼륨 스캔으로 멀웨어 탐지
RDS 로그인 활동	Aurora 등에 대한 비정상 로그인·브루트포스
Lambda 네트워크 활동	함수의 악성 통신

포인트: VPC Flow Logs·DNS 로그를 내가 켜두지 않아도 GuardDuty는 독립적으로 접근해 분석한다. "로그 설정 없이 위협 탐지" = GuardDuty의 강점.

대표 Finding 예시 (감이 잡히게)

UnauthorizedAccess:EC2/SSHBruteForce — 내 EC2에 SSH 브루트포스
CryptoCurrency:EC2/BitcoinTool.B — 침해된 EC2가 크립토마이닝 도메인과 통신
Recon:EC2/PortProbeUnprotectedPort — 열린 포트 스캔 정찰
UnauthorizedAccess:IAMUser/MaliciousIPCaller — 알려진 악성 IP에서의 API 호출
Exfiltration:S3/AnomalousBehavior — 비정상적 S3 데이터 유출 패턴

각 Finding엔 심각도(Low/Medium/High), 관련 리소스, 근거가 붙어 우선순위를 정할 수 있다.

자동 대응 — EventBridge 연동 (빈출·실무 핵심)

GuardDuty의 진짜 가치는 탐지 → 자동 대응으로 이어붙일 때 나온다. Finding은 EventBridge 이벤트로 발행되므로 여기에 대응을 건다.

GuardDuty Finding ─▶ EventBridge 규칙 ─▶ 대응 자동화
   예) 침해 EC2 → Lambda가 SG 격리 / 스냅샷 후 종료
       악성 IP  → Lambda가 WAF IP set·NACL deny에 추가
       알림     → SNS로 보안팀 통지, Slack
       티켓     → Security Hub / Systems Manager

시험 트리거: "위협 탐지 시 자동으로 격리/알림" → GuardDuty + EventBridge + Lambda/SNS.

조직 단위 운영 (Multi-Account)

AWS Organizations와 통합해 위임 관리자(delegated admin) 계정에서 모든 멤버 계정의 GuardDuty를 일괄 활성화·집계한다.
신규 계정 자동 등록 → 계정이 늘어도 커버리지 유지. 대규모 환경의 표준 구성.

다른 보안 서비스와의 차이 (자주 헷갈림 — 핵심)

서비스	한 문장	질문
GuardDuty	로그 분석으로 위협·악성 활동 탐지	"지금 공격/침해가 일어나고 있나?"
Inspector	EC2/컨테이너/Lambda의 취약점(CVE)·노출 점검	"내 워크로드에 알려진 취약점이 있나?"
Macie	S3의 민감정보(PII) 발견·분류	"내 S3에 개인정보가 노출돼 있나?"
Config	리소스 구성의 규정 준수 평가·기록	"설정이 규칙을 지키나? 언제 바뀌었나?"
Security Hub	위 발견들을 집계·표준화한 대시보드	"전체 보안 상태를 한눈에"
Detective	발견의 근본 원인 분석·조사(그래프)	"왜/어떻게 일어났나 조사"

외우는 축: GuardDuty=위협 탐지(활동), Inspector=취약점(CVE), Macie=S3 민감정보, Config=구성 준수, Security Hub=집계, Detective=조사.

실무 활용 사례

사례 1. 침해 인스턴스 자동 격리

SSHBruteForce/크립토마이닝 Finding → EventBridge → Lambda가 해당 EC2를 격리 SG로 교체 + 스냅샷 후 조사.

사례 2. 악성 IP 실시간 차단

MaliciousIPCaller → Lambda가 WAF IP set 또는 NACL deny에 IP 추가.

사례 3. 조직 전체 상시 모니터링

Organizations 위임 관리자에서 전 계정 GuardDuty 활성화 → Findings를 Security Hub로 집계.

사례 4. 데이터 유출 조기 탐지

Exfiltration:S3/...·비정상 아웃바운드 → 즉시 알림·자동 대응.

Common Wrong Directions

오답 방향	왜 부족한가
GuardDuty가 공격을 차단한다고 봄	탐지 전용 → 차단은 EventBridge+자동화
취약점(CVE) 스캔에 GuardDuty	그건 Inspector
S3 민감정보 탐지에 GuardDuty	그건 Macie
구성 규정 준수 평가에 GuardDuty	그건 Config
쓰려면 VPC Flow Logs/DNS 로그를 먼저 켜야 한다고 봄	GuardDuty가 독립적으로 접근(설정 불필요)
계정마다 수동 활성화	Organizations 위임 관리자로 일괄
여러 서비스 Finding을 각각 관리	Security Hub로 집계

Exam Triggers

문제에서 이런 표현이 나오면	떠올릴 것
"detect malicious activity / compromised instances / anomalies"	GuardDuty
"analyze CloudTrail·VPC Flow·DNS logs for threats, no setup"	GuardDuty
"crypto mining / SSH brute force / known bad IP calls"	GuardDuty
"automatically respond to a threat finding"	GuardDuty + EventBridge + Lambda
"enable across all accounts in the org"	GuardDuty + Organizations(위임 관리자)
"scan for software vulnerabilities/CVEs"	Inspector (GuardDuty 아님)
"discover sensitive data (PII) in S3"	Macie (GuardDuty 아님)
"assess resource configuration compliance"	Config (GuardDuty 아님)
"aggregate findings from many security services"	Security Hub

Memory Sentence

GuardDuty는 CloudTrail·VPC Flow·DNS 로그 등을 에이전트 없이 상시 분석해 위협을 Finding으로 탐지(차단은 아님)하고, EventBridge로 Lambda/SNS 자동 대응에 연결한다. 취약점은 Inspector, S3 민감정보는 Macie, 구성 준수는 Config, 집계는 Security Hub. 조직 전체는 Organizations 위임 관리자로 일괄 활성화.