GuardDuty·Security Hub·Detective로 만드는 위협 탐지와 통합 운영
_Category: Threat Detection_
SCS-C03 시험에서 위협 탐지 도메인의 핵심은 세 서비스가 함께 어떻게 작동하는지 아는 것입니다. GuardDuty는 24/7 자동 침입 경보 시스템, Security Hub는 보안 관제 대시보드, Detective는 CCTV와 출입 기록을 추적하는 수사 도구입니다. 각자 잘하는 일이 다르고, 시험도 정확히 그 차이를 묻습니다.
---
위협 탐지의 흐름: 수집 → 탐지 → 우선순위 → 조사 → 대응
위협 탐지는 다섯 단계 흐름으로 이해하면 세 서비스의 역할이 명확해집니다.
첫 번째는 데이터 수집 단계입니다. CloudTrail, VPC Flow Logs, DNS Logs, S3 API 호출 기록, EKS Audit Logs, Lambda 네트워크 트래픽 등 다양한 로그가 원천 데이터가 됩니다. GuardDuty는 이 데이터를 소비하는 서비스이지, 로그를 별도로 저장해야 하는 서비스가 아닙니다. 에이전트 설치도 필요 없습니다.
두 번째는 탐지 단계입니다. GuardDuty가 머신 러닝과 위협 인텔리전스를 사용해 이상 행위를 감지하고 Findings를 생성합니다.
세 번째는 우선순위 결정 단계입니다. GuardDuty Findings는 심각도(Low/Medium/High)로 분류되어 Security Hub로 전달됩니다. Security Hub는 GuardDuty뿐 아니라 Macie, Inspector, Firewall Manager, IAM Access Analyzer 등 여러 서비스의 Findings를 ASFF(Amazon Security Finding Format)로 정규화해 집계합니다.
네 번째는 조사 단계입니다. Security Hub Finding에서 Amazon Detective로 연결해 해당 Finding을 심층 분석할 수 있습니다. Detective는 그래프 데이터베이스 기반으로 엔티티 간의 관계를 시각화해 이 IP가 언제부터 이 계정에 접근했는지를 추적합니다.
다섯 번째는 대응 단계입니다. GuardDuty Findings는 EventBridge로 자동 발행되어 Lambda, SNS, Step Functions 등을 트리거할 수 있습니다. Security Hub Automation Rules로 특정 Findings 패턴에 맞는 대응을 자동화할 수 있습니다.
---
Amazon GuardDuty: 자동 위협 탐지의 작동 원리와 데이터 소스
GuardDuty는 AWS 환경의 이상 행위를 24시간 자동으로 감시하는 관리형 위협 탐지 서비스입니다. 별도 에이전트 설치나 로그 전송 파이프라인 없이 GuardDuty를 활성화하는 것만으로 탐지가 시작됩니다.
GuardDuty 데이터 소스는 기능 단위로 구분됩니다.
| 데이터 소스 / 기능 | 탐지 대상 | 기본 활성화 여부 | |---|---|---| | CloudTrail 관리 이벤트 | IAM 자격 증명 이상 사용, 콘솔 로그인 이상 | 기본 포함 | | VPC Flow Logs | 포트 스캔, 비정상 아웃바운드 연결, C2 통신 | 기본 포함 | | DNS Logs | DNS 터널링, 알려진 악성 도메인 쿼리 | 기본 포함 (Route 53 Resolver 경유 시) | | S3 Protection | S3 버킷 비정상 접근, 대량 삭제·다운로드 | 별도 활성화 | | EKS Audit Logs | 컨테이너 이상 권한 사용, kubectl 이상 패턴 | 별도 활성화 | | Malware Protection | EC2/ECS 멀웨어 스캔 (EBS 볼륨 분석) | 별도 활성화 | | RDS Login Events | Aurora 데이터베이스 비정상 로그인 패턴 | 별도 활성화 | | Lambda Network Activity | Lambda 함수의 비정상 네트워크 통신 | 별도 활성화 |
GuardDuty의 DNS 탐지는 VPC 내부의 Route 53 Resolver를 통과하는 쿼리만 분석합니다. EC2 인스턴스가 커스텀 DNS 서버(외부 DNS 또는 온프레미스 포워더)를 사용하면 해당 쿼리는 GuardDuty 탐지 범위 밖입니다. Route 53 Resolver 쿼리 로그를 별도로 활성화해도 GuardDuty와 데이터를 공유하지 않습니다.
Multi-Account 환경에서는 AWS Organizations와 연동해 Delegated Administrator 계정에서 조직 전체의 GuardDuty를 중앙 관리할 수 있습니다.
---
GuardDuty Finding 카테고리와 자주 나오는 시나리오
GuardDuty Findings는 탐지된 위협의 성격을 나타내는 접두어(prefix) 체계로 분류됩니다.
Reconnaissance는 공격자가 환경을 탐색하는 행위를 탐지합니다. Recon:EC2/PortProbeUnprotectedPort가 대표 예시입니다. UnauthorizedAccess는 비정상 자격 증명 사용을 탐지하며 UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B처럼 비정상 위치에서의 콘솔 로그인 성공을 포함합니다. CryptoCurrency는 암호화폐 채굴 행위(CryptoCurrency:EC2/BitcoinTool.B), Backdoor는 C2 통신(Backdoor:EC2/C&CActivity.B)을 탐지합니다. Behavior는 IAM 자격 증명의 비정상 행동 패턴, Pentest는 침투 테스트 도구 사용 시 발생하는 Findings입니다.
오탐 처리 방법에서 시험 단골 개념이 있습니다. Trusted IP List는 특정 IP에서 발생하는 모든 Finding을 억제합니다. Suppression Rule은 Finding 유형 + IP 조건 + 리소스 태그 등을 조합해 특정 조건에 맞는 Finding만 선택적으로 아카이브합니다. 아카이브된 Finding은 콘솔에서 숨겨지지만 90일간 보존됩니다.
온프레미스 NAT 게이트웨이를 경유하는 정상 트래픽 때문에 InstanceCredentialExfiltration Finding이 반복 발생한다는 시나리오라면 Suppression Rule이 정답입니다. Trusted IP List를 쓰면 해당 IP에서 오는 실제 위협도 탐지되지 않기 때문입니다.
---
AWS Security Hub: Findings 통합과 Security Standards
Security Hub는 여러 AWS 보안 서비스와 서드파티 도구의 Findings를 한 곳에 집계하고 보안 규정 준수 상태를 지속적으로 평가하는 서비스입니다.
ASFF(Amazon Security Finding Format)는 모든 Findings를 동일한 JSON 스키마로 정규화하는 표준 포맷입니다. GuardDuty, Macie, Inspector 등 소스가 달라도 ASFF 형식으로 변환되어 통합 검색과 필터링이 가능합니다.
| Security Standard | 초점 | 주요 용도 | |---|---|---| | AWS Foundational Security Best Practices (FSBP) | AWS 서비스 수준 보안 모범 사례 | AWS 일반 보안 기준선 | | CIS AWS Foundations Benchmark | CIS(Center for Internet Security) 권고 | 업계 표준 하드닝 | | PCI DSS | 결제 카드 산업 보안 표준 | 카드 결제 처리 환경 | | NIST SP 800-53 | 미국 연방 정보 시스템 보안 | 공공기관·컴플라이언스 강화 환경 |
Insights는 공통 패턴을 가진 Findings를 그룹으로 집계하는 기능입니다. Automation Rules는 Findings가 Security Hub에 수신될 때 조건에 따라 자동으로 속성을 수정하거나 대응을 트리거합니다. Organizations 연동에서 Delegated Administrator를 지정하면 조직 전체 신규 계정에 Security Hub가 자동 활성화되고 멤버 계정의 Findings가 중앙 집계됩니다.
---
Amazon Detective: 그래프 기반 심층 조사
Detective는 GuardDuty나 Security Hub의 Finding을 받았을 때, 이 Finding이 실제로 얼마나 심각한가, 관련된 다른 이상 행위는 없는가를 파악하는 조사 도구입니다. 경찰이 범죄 현장에서 CCTV 영상과 출입 기록을 분석하듯이, Detective는 그래프 데이터베이스를 이용해 엔티티 간의 관계와 행동 패턴을 시각화합니다.
Detective가 분석하는 데이터는 CloudTrail 로그, VPC Flow Logs, GuardDuty Findings입니다. GuardDuty나 Security Hub에서 Finding을 확인하고 Investigate in Detective 버튼을 누르면 Detective 콘솔로 이동합니다. Detective는 해당 Finding과 관련된 IP, 계정, API 호출 이력을 타임라인으로 보여주고, 기준 행동 패턴(Baseline)과 현재 활동을 비교해 얼마나 이상한 행동인지 시각화합니다.
Detective는 GuardDuty 활성화가 전제 조건이며, 수동 조사 도구이므로 EventBridge 자동 처리나 실시간 알림 용도에는 맞지 않습니다. 여러 서비스의 Findings를 한 곳에 모아보고 싶다면 Security Hub, 특정 Finding을 심층 분석하고 싶다면 Detective로 구분하면 됩니다.
---
세 서비스의 역할 분담 비교표 + EventBridge 자동 대응
세 서비스의 역할을 한눈에 비교합니다.
| 비교 항목 | GuardDuty | Security Hub | Detective | |---|---|---|---| | 핵심 역할 | 위협 자동 탐지 | Findings 통합·규정 준수 평가 | 심층 조사·원인 분석 | | 비유 | 24/7 침입 경보 시스템 | 보안 관제 대시보드 | 수사·CCTV 도구 | | 입력 | CloudTrail, VPC Flow Logs, DNS, S3, EKS 등 | GuardDuty, Macie, Inspector, 서드파티 등 | GuardDuty Findings, CloudTrail, VPC Flow Logs | | 출력 | Findings (탐지 결과) | 통합 Findings, 규정 준수 점수 | 그래프 시각화, 타임라인 분석 | | 자동화 | EventBridge 이벤트 발행 | Automation Rules, EventBridge 연동 | 수동 조사 (자동화 미지원) | | GuardDuty 의존성 | 독립 | 독립 (GuardDuty 없어도 사용 가능) | GuardDuty 활성화 필수 |
EventBridge를 활용한 자동 대응 아키텍처는 SCS-C03에서 매우 자주 출제됩니다. GuardDuty는 Finding이 생성될 때마다 자동으로 EventBridge에 이벤트를 발행합니다. EventBridge 규칙에서 severity 값이 4 이상이면 Medium 이상으로 필터링할 수 있습니다. SNS 토픽으로 이메일 알림을 보내거나, Lambda를 트리거해 감염된 EC2 인스턴스를 자동으로 격리할 수 있습니다.
Security Hub Findings가 생성·업데이트될 때도 EventBridge 이벤트가 발행되므로, Macie나 Inspector에서 온 Findings에도 동일한 자동 대응 파이프라인을 적용할 수 있습니다. Macie + GuardDuty + Security Hub 통합 패턴에서는 S3 민감 데이터 탐지(Macie)와 비정상 접근 탐지(GuardDuty)가 모두 Security Hub 대시보드 한 곳에 집계됩니다.
!GuardDuty vs Security Hub vs Detective
시험에서 가장 헷갈리는 선택 기준
EC2 인스턴스가 알려진 악성 IP와 통신하는지 자동으로 탐지하고 싶다면 GuardDuty입니다. Security Hub는 탐지 서비스가 아닌 집계 서비스입니다.
GuardDuty, Macie, Inspector의 Findings를 한 화면에서 확인하고 규정 준수 상태를 보고 싶다면 Security Hub입니다.
GuardDuty Finding에서 IAM 사용자의 비정상 API 패턴을 시각적으로 분석하고 싶다면 Detective입니다.
GuardDuty Finding이 발생할 때마다 외부 시스템에 알림을 보내고 싶다면 GuardDuty + EventBridge + SNS(또는 Lambda)입니다. GuardDuty 콘솔의 필터는 UI 검색용이므로 외부 시스템 알림에 사용할 수 없습니다.
온프레미스 NAT IP에서 오는 정상 트래픽 때문에 InstanceCredentialExfiltration Finding이 반복 발생하지만, 같은 Finding 유형에서 실제 위협은 계속 탐지해야 한다면 GuardDuty Suppression Rule입니다. Trusted IP List를 쓰면 해당 IP의 모든 Finding이 억제됩니다.
EKS 클러스터에서 비정상 kubectl 패턴을 탐지하고 싶다면 GuardDuty EKS Audit Logs Protection입니다. 기본 활성화가 아니므로 별도로 활성화해야 합니다.
GuardDuty를 활성화했는데 DNS 기반 Findings가 생성되지 않는다면 커스텀 DNS 리졸버 사용이 원인입니다. Route 53 Resolver를 통과하지 않는 쿼리는 GuardDuty가 분석할 수 없습니다.
---
시험 핵심 정리
역할 분담: GuardDuty는 자동 탐지, Security Hub는 통합 집계 + 규정 준수 평가, Detective는 심층 조사. Detective는 GuardDuty 활성화가 전제 조건입니다.