Amazon GuardDuty 보안 최적 실무 12가지 | 제이씨클라우드 블로그

Amazon GuardDuty는 머신러닝, 이상 탐지, 통합 위협 인텔리전스를 활용해 침해 사고가 발생하기 전에 위협을 식별하는 서비스입니다. 하지만 단순히 활성화만 해두면 잠재력의 절반도 활용하지 못합니다. 아래 12가지 실무활용방안은 GuardDuty를 실질적인 보안 방어선으로 만들기 위한 핵심 기준입니다.

자주 발생하는 잘못된 설정: 특정 리전에서만 GuardDuty 활성화 · 보호 플랜 일부만 켜기 · Runtime Monitoring에서 관리형 에이전트 미배포 · EventBridge 자동화 미설정 · Finding 과도한 억제(Suppression)

1 멀티 리전 배포 + 위임 관리자 설정 필수

위협은 리전 경계에 제한되지 않습니다. GuardDuty는 리전별로 독립적으로 동작하기 때문에 사용 중인 모든 AWS 리전에서 활성화해야 합니다. 서울(ap-northeast-2)만 활성화하고 버지니아(us-east-1)를 빠뜨리면 그쪽이 사각지대가 됩니다.

멀티 계정 환경에서는 Management Account(Payer)가 아닌 전용 Security Account를 위임 관리자(Delegated Administrator)로 지정하세요. Management Account는 비상 접근용으로만 남겨둡니다.

# Management Account에서 실행
aws guardduty enable-organization-admin-account \
  --admin-account-id <SECURITY_ACCOUNT_ID> \
  --region ap-northeast-2

CloudFormation StackSet을 사용하면 모든 리전에 GuardDuty Detector를 한 번에 배포하고 신규 계정이 Organizations에 추가될 때도 자동 적용됩니다.

2 모든 보호 플랜(Protection Plans) 활성화 필수

GuardDuty의 기본 활성화만으로는 전체 가시성을 확보할 수 없습니다. 아래 6가지 보호 플랜을 모두 활성화해야 합니다.

보호 플랜	탐지 대상	주요 데이터 소스
S3 Protection	S3 버킷 비정상 접근·유출	CloudTrail S3 데이터 이벤트
EKS Protection	컨테이너 탈출·권한 상승	EKS 감사 로그
Runtime Monitoring	프로세스·파일·네트워크 이상 행위	ECS/EKS/EC2 에이전트
Malware Protection (EBS)	EC2 EBS 볼륨 멀웨어	EBS 스냅샷 스캔
RDS Protection	데이터베이스 비정상 로그인	RDS 로그인 이벤트
Lambda Protection	Lambda 함수 비정상 네트워크 호출	Lambda 네트워크 활동 로그

# Organizations 전체에 모든 보호 플랜 자동 적용
aws guardduty update-organization-configuration \
  --detector-id <DETECTOR_ID> \
  --features '[
    {"Name":"S3_DATA_EVENTS","Status":"ENABLED"},
    {"Name":"EKS_AUDIT_LOGS","Status":"ENABLED"},
    {"Name":"EBS_MALWARE_PROTECTION","Status":"ENABLED"},
    {"Name":"RDS_LOGIN_EVENTS","Status":"ENABLED"},
    {"Name":"LAMBDA_NETWORK_LOGS","Status":"ENABLED"},
    {"Name":"RUNTIME_MONITORING","Status":"ENABLED","AdditionalConfiguration":[
      {"Name":"ECS_FARGATE_AGENT_MANAGEMENT","Status":"ENABLED"},
      {"Name":"EKS_ADDON_MANAGEMENT","Status":"ENABLED"},
      {"Name":"EC2_AGENT_MANAGEMENT","Status":"ENABLED"}
    ]}
  ]' \
  --region ap-northeast-2

3 Extended Threat Detection (AI 상관 분석) 활용 중요

Extended Threat Detection은 별도 설정 없이 자동으로 작동하는 AI/ML 기능으로, 개별 Finding을 넘어 여러 보안 신호를 시계열로 연관지어 공격 시퀀스를 탐지합니다. 예를 들어, "비정상 IAM 역할 생성 → 외부 IP 접근 → S3 대량 다운로드"를 단일 Critical Finding으로 묶어 제시합니다.

별도 구성 불필요 — GuardDuty 활성화 시 자동 적용
Critical 심각도 Finding 생성 → 즉각 대응 트리거 권장
MITRE ATT&CK 전술·기법 매핑 정보 포함

4 Runtime Monitoring — 관리형 에이전트 배포 중요

Runtime Monitoring은 경량 보안 에이전트를 통해 실시간 호스트 내부 행위를 관찰합니다. 탐지 항목:

프로세스 실행 (비정상 명령어, 쉘 스폰)
파일 접근 (루트 디렉토리·민감 경로 접근)
커맨드라인 인수 (리버스 쉘, 데이터 스테이징)
네트워크 연결 (알려진 C&C 서버, Tor 출구 노드)

ECS Fargate, EKS, EC2 모두 지원합니다. 관리형 에이전트(Managed Agent)를 선택하면 AWS가 에이전트 배포와 업데이트를 자동으로 처리합니다.

흔한 실수: Runtime Monitoring을 활성화했지만 관리형 에이전트 옵션을 켜지 않으면 에이전트가 실제로 배포되지 않아 런타임 탐지가 동작하지 않습니다. 콘솔 Coverage 탭에서 에이전트 상태를 반드시 확인하세요.

5 EventBridge를 이용한 자동 대응(Auto-Remediation) 필수

위협 탐지는 모든 보안위협탐지의 절반에 해당합니다. 탐지 후 대응까지의 시간(MTTC)을 시간 단위에서 초 단위로 줄이는 것이 핵심입니다. EventBridge + Lambda 조합으로 High/Critical Findings 발생 즉시 자동 격리를 구현합니다.

Finding 유형	자동 대응 예시
EC2 침해 의심	격리 전용 Security Group으로 교체 → SSM 세션 강제 종료
IAM 자격증명 유출	해당 IAM 사용자 비활성화 → 액세스 키 즉시 삭제
S3 비정상 접근	버킷 퍼블릭 액세스 차단 강제 → 버킷 정책 롤백

# EventBridge 규칙 — Critical/High Finding 자동 대응
aws events put-rule \
  --name guardduty-auto-remediate \
  --event-pattern '{
    "source": ["aws.guardduty"],
    "detail-type": ["GuardDuty Finding"],
    "detail": {
      "severity": [{"numeric": [">=", 7]}]
    }
  }' \
  --region ap-northeast-2

# Lambda 핵심 로직 예시 (EC2 격리)
import boto3

def lambda_handler(event, context):
    detail = event['detail']
    instance_id = (detail.get('resource', {})
                        .get('instanceDetails', {})
                        .get('instanceId'))
    if instance_id:
        boto3.client('ec2').modify_instance_attribute(
            InstanceId=instance_id,
            Groups=['sg-ISOLATE_ONLY']  # 모든 트래픽 차단 SG
        )

6 멀티 계정 Organizations 중앙화 관리 필수

위임 관리자(Security Account)는 다음을 한 곳에서 수행할 수 있습니다.

모든 멤버 계정의 Findings 통합 조회
보호 플랜을 조직 전체에 일괄 적용·강제
신규 계정 자동 등록 (Auto-Enable: ALL)
크로스 리전 Findings Aggregation으로 단일 뷰 확보

# 신규 계정 자동 등록 + 조직 전체 GuardDuty 강제 활성화
aws guardduty update-organization-configuration \
  --detector-id <DETECTOR_ID> \
  --auto-enable-organization-members ALL \
  --region ap-northeast-2

크로스 리전 집계: Security Account의 기준 리전(예: 서울)에서 Findings Aggregation을 활성화하면 us-east-1, eu-central-1 등 모든 리전 결과가 하나의 화면에 통합됩니다.

7 Finding 튜닝 — Suppression Rules & Trusted IP 권장

과도한 알림은 알림 피로(Alert Fatigue)를 유발해 진짜 위협을 놓치게 만듭니다. Suppression Rules와 신뢰할 수 있는 IP 목록으로 노이즈를 줄이되, 억제는 보수적으로 적용해야 합니다.

Suppression Rules: 알려진 취약점 스캔 서버 IP, 내부 자동화 툴 등 False Positive를 억제
Trusted IP 목록: 사무실 공인 IP, 점프서버 IP 등 신뢰 소스 등록
Threat IP 목록: 자체 보유한 악성 IP 인텔리전스를 GuardDuty에 직접 공급

주의: Suppression Rule은 Finding을 숨길 뿐 삭제하지 않습니다. 월 1회 이상 규칙을 검토해 더 이상 유효하지 않은 억제 규칙을 제거하세요. 과도한 억제는 규정 준수 심사 시 증적 공백으로 이어질 수 있습니다.

8 SIEM 연동 — Security Lake / Splunk / Datadog 권장

GuardDuty Findings를 독립적으로 관리하면 다른 보안 이벤트와의 상관 분석이 어렵습니다. 아래 방식으로 광범위한 보안 가시성을 확보하세요.

연동 방식	특징	추천 환경
Amazon Security Lake	OCSF 표준 포맷, S3 기반 장기 보관, Athena 쿼리	AWS 네이티브 환경, 비용 효율 중시
AWS Security Hub	GuardDuty·Inspector·Config 통합 대시보드, CIS 준수 점수	규정 준수 중심 운영
Splunk / Datadog	EventBridge → Kinesis → SIEM, 기존 플랫폼 통합	On-prem SIEM 병행 운영 환경

AWS Security Hub 연동 시 GuardDuty Findings가 자동으로 ASFF(Amazon Security Finding Format)로 전달되어 별도 변환 없이 통합 대시보드에서 확인할 수 있습니다.

9 커버리지(Coverage) 모니터링 및 사각지대 제거 권장

GuardDuty 콘솔의 Coverage 탭은 보호 대상 리소스가 실제로 모니터링되고 있는지 확인합니다. Runtime Monitoring 에이전트 미설치, 특정 서브넷의 VPC Flow Log 비활성화 등 보이지 않는 사각지대가 존재할 수 있습니다.

주 1회 이상 Coverage 탭에서 Healthy 상태가 아닌 리소스 확인
AWS Config Rule로 GuardDuty 비활성화 계정·리전 자동 감지
Usage 탭에서 기능별 예상 비용 및 처리량 모니터링

# GuardDuty가 비활성화된 리전 탐지 (모든 리전 순회)
for region in $(aws ec2 describe-regions \
    --query 'Regions[].RegionName' --output text); do
  count=$(aws guardduty list-detectors \
    --region $region --query 'DetectorIds | length(@)' \
    --output text 2>/dev/null)
  [[ "$count" == "0" ]] && echo "GuardDuty 비활성: $region"
done

10 Finding 보관 및 감사 추적 권장

GuardDuty Findings는 기본적으로 90일간 보관됩니다. ISMS-P, PCI DSS 등 규정 준수를 위해 장기 보관이 필요하다면 아래 방법을 사용하세요.

S3 내보내기(Export): GuardDuty → Settings → Findings export → S3 버킷 지정. Findings 발생 즉시 또는 6시간 단위로 S3에 JSON 내보내기.
S3 Lifecycle: 90일 후 Glacier 이동, 7년 보관 (ISMS-P 요구사항 대응)
Amazon Security Lake: OCSF 포맷으로 장기 보관 및 쿼리

11 GuardDuty 설정 자체의 변경 감지 권장

공격자가 탐지를 피하기 위해 GuardDuty를 비활성화하거나 Suppression Rule을 수정하는 경우가 있습니다. GuardDuty 설정 변경 자체를 감시해야 합니다.

# CloudTrail + EventBridge로 GuardDuty 비활성화 이벤트 감지
aws events put-rule \
  --name detect-guardduty-disable \
  --event-pattern '{
    "source": ["aws.guardduty"],
    "detail-type": ["AWS API Call via CloudTrail"],
    "detail": {
      "eventName": [
        "DeleteDetector",
        "DisassociateFromMasterAccount",
        "UpdateDetector",
        "CreateFilter",
        "DeleteIPSet"
      ]
    }
  }' \
  --region ap-northeast-2

12 정기적인 GuardDuty 테스트 및 검증 권장

GuardDuty가 실제로 작동하는지 주기적으로 검증해야 합니다. AWS는 샘플 Findings 생성 기능을 제공합니다.

# 샘플 Finding 생성 (모든 Finding 유형 테스트)
aws guardduty create-sample-findings \
  --detector-id <DETECTOR_ID> \
  --finding-types \
    "UnauthorizedAccess:EC2/SSHBruteForce" \
    "CryptoCurrency:EC2/BitcoinTool.B" \
    "Exfiltration:S3/AnomalousBehavior" \
  --region ap-northeast-2

분기별 1회 이상 샘플 Finding 생성 → 알림·자동화 동작 확인
신규 자동 대응 Lambda 배포 후 반드시 테스트 수행
Security Hub 연동 시 Finding이 대시보드에 정상 표시되는지 확인

우선순위별 실행 체크리스트

처음 GuardDuty를 도입하거나 기존 설정을 점검할 때 아래 순서로 진행하세요.

즉시 실행 (필수)

모든 사용 중인 AWS 리전에 GuardDuty 활성화
Organizations 위임 관리자를 Security Account로 지정
6가지 보호 플랜 전체 활성화 (S3·EKS·Runtime·Malware·RDS·Lambda)
High/Critical Findings → EventBridge → Lambda/SNS 자동 대응 설정
신규 계정 Auto-Enable 구성 (ALL)

1주일 이내 (중요)

Runtime Monitoring 관리형 에이전트 배포 및 Coverage 탭 확인
크로스 리전 Findings Aggregation 활성화
Security Hub 또는 SIEM 연동 구성
S3 Findings 내보내기 설정 (장기 보관)

1개월 이내 (권장)

Suppression Rules 검토 및 불필요한 규칙 제거
GuardDuty 설정 변경 감지 EventBridge 규칙 추가
샘플 Finding 생성으로 전체 자동화 파이프라인 검증
Usage 탭에서 예상 비용 확인 및 불필요한 플랜 최적화

마무리

GuardDuty는 "켜두면 알아서 되는" 서비스가 아닙니다. 올바른 범위 설정, 자동화된 대응, 그리고 지속적인 룰에 대한 튜닝이 함께해야 실제 위협을 막는 방어선이 됩니다.

위협 탐지는 모든 보안 시스템 운영의 절반에 해당합니다. 나머지 절반은 탐지 후 대응 시간을 줄이는 것입니다. 평균 대응 시간(MTTC)을 시간 단위에서 초 단위로 단축하는 것이 GuardDuty 자동화의 핵심 목표입니다.

참고: TOC Consulting — AWS GuardDuty Security Best Practices