Day 1 - Amazon GuardDuty: 위협 탐지 원리, 결과 유형, 위협 인텔, 멀티계정 위임 관리자

탐지(detection)는 예방(prevention)이 뚫렸음을 전제로 한다. 방화벽·IAM·암호화로 아무리 막아도 자격증명 탈취, 내부자, 제로데이는 통과한다. 그래서 보안 운영의 두 번째 기둥은 "이미 일어난(또는 일어나는 중인) 악성 활동을 증거 기반으로 알아채는 것"이다. Amazon GuardDuty는 이 탐지 계층의 1차 진입점으로, 에이전트 없이(agentless) 계정 전역의 텔레메트리를 상시 분석해 위협을 결과(finding)으로 토해낸다.

GuardDuty의 본질은 "로그를 수집하는 서비스가 아니라, 로그를 읽어 의미를 부여하는 분석 엔진"이다. CloudTrail을 켜야 GuardDuty가 보는 것이 아니라, GuardDuty가 CloudTrail/VPC Flow/DNS 스트림을 직접 구독해서 분석한다. 사용자가 로그를 저장·전달하도록 구성할 필요가 없고, 활성화하는 순간 데이터 소스가 연결된다 — 이 "켜기만 하면 끝"이 시험이 묻는 포인트다.

무엇을 분석하는가: 3대 기초 데이터 소스

GuardDuty가 추가 비용·구성 없이 항상 소비하는 세 가지 기초(foundational) 소스:

CloudTrail 관리 이벤트  → API 호출 행위 (누가 무엇을 했나)
CloudTrail S3 데이터 이벤트(옵션) → S3 객체 수준 접근
VPC Flow Logs           → 네트워크 흐름 (어디로 연결했나)
DNS 쿼리 로그           → 도메인 해석 (무엇을 찾았나)

중요한 미묘함: GuardDuty는 이 로그들을 복제하지 않는다. 계정에 VPC Flow Logs를 켜지 않았어도, GuardDuty는 내부적으로 흐름 데이터를 받아 분석한다(별도 저장 안 함). DNS 분석은 VPC 기본 DNS resolver(Route 53 Resolver)를 쓸 때만 가능하다 — 커스텀 DNS나 외부 resolver를 쓰면 GuardDuty의 DNS 기반 결과(예: DNS exfiltration)은 사각지대가 된다.

이는 행위 기반 탐지(behavioral detection)의 전형이다. 시그니처 매칭(알려진 악성 IP·해시)에만 의존하지 않고, 베이스라인 대비 이상(anomaly)을 통계·ML로 잡는다. GuardDuty는 계정별로 "정상" 프로파일(평소 호출하는 API, 평소 통신하는 지역·포트)을 학습해, 평소와 다른 행위를 위협 점수화한다. 이것이 NIST CSF의 "Detect" 기능 중 "Anomalies and Events(DE.AE)"에 대응한다.

데이터 소스가 다르면 답할 수 있는 질문도 다르다

탐지 서비스를 고르는 시험 문제는 결국 "이 질문에 답할 수 있는 데이터를 누가 갖고 있는가"로 환원된다. 각 서비스가 무엇을 먹는가를 축으로 정리하면 헷갈릴 일이 없다.

⚠️ 함정: 이 표에서 가장 자주 뒤섞이는 쌍이 GuardDuty와 Inspector다. "EC2가 침해된 것 같다"는 GuardDuty, "EC2가 침해될 수 있는가"는 Inspector다. 문장의 시제가 힌트다 — 과거·현재진행이면 위협 탐지, 미래·가정이면 취약점 관리. 또 하나 틀리기 쉬운 것이 "GuardDuty를 쓰려면 VPC Flow Logs를 먼저 켜야 한다"는 오해다. GuardDuty는 흐름 데이터를 서비스 내부 경로로 직접 받으므로, 사용자가 Flow Logs를 활성화하거나 S3에 저장할 필요가 전혀 없다. 반대로 사용자가 Flow Logs를 껐다고 해서 GuardDuty의 네트워크 탐지가 멈추지도 않는다.

2019년 Capital One 침해는 GuardDuty가 무엇을 보는 서비스인지 이해하는 데 교과서적인 사건이다. 공격자는 잘못 구성된 웹 방화벽 뒤의 EC2 워크로드를 SSRF로 유도해 인스턴스 메타데이터 서비스(IMDS)에서 IAM 역할의 임시 자격증명을 꺼냈고, 그 자격증명으로 S3 버킷의 데이터를 대량으로 읽어 갔다. 이 공격 경로를 GuardDuty 관점에서 쪼개 보면 각 단계가 서로 다른 데이터 소스에 흔적을 남긴다 — 자격증명이 AWS 밖 IP에서 사용된 사실은 CloudTrail 관리 이벤트에, 대량 객체 읽기는 S3 데이터 이벤트에, 외부로 나가는 이례적 트래픽은 VPC Flow에 남는다. GuardDuty가 이 사건 계열에 대응해 내놓는 대표 결과가 UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS(EC2 역할 자격증명이 AWS 외부에서 사용됨)이다. 교훈은 두 가지다. 첫째, 역할 자격증명은 인스턴스를 벗어나는 순간 그냥 문자열이므로 "인스턴스가 안전하니 역할도 안전하다"는 가정은 성립하지 않는다. 둘째, 예방 통제(IMDSv2 강제, SSRF 방어, 최소 권한)와 탐지 통제(GuardDuty)는 어느 하나로 대체되지 않는다 — 예방은 확률을 낮추고, 탐지는 예방이 실패한 뒤의 시간을 줄인다.

보호 플랜(Protection Plans): 기초 위에 얹는 확장 탐지

기초 소스 외에, 추가 데이터 소스를 켜는 보호 플랜들이 있다. 각각 별도 과금되고 별도 결과 유형을 생성한다:

• S3 Protection: CloudTrail S3 데이터 이벤트 분석 → 의심스러운 S3 접근 패턴
• EKS Protection: EKS 감사 로그 분석 → 쿠버네티스 API 수준 위협
• Runtime Monitoring: 경량 에이전트(EKS/ECS/EC2)로 호스트 내부 행위(프로세스, 파일, 네트워크) 가시성 → 컨테이너·인스턴스 런타임 위협
• Malware Protection (EBS): 의심 EC2의 EBS 볼륨 스냅샷을 떠 멀웨어 스캔(에이전트 불필요)
• Malware Protection for S3: 업로드 객체 스캔
• RDS Protection: Aurora 로그인 활동 분석 → DB 자격증명 공격
• Lambda Protection: Lambda 네트워크 활동 분석

⚠️ 함정: "GuardDuty를 켰는데 호스트 내부 침해(악성 프로세스)를 못 본다"는 시나리오의 답은 보통 Runtime Monitoring 활성화다. 기초 GuardDuty는 네트워크/API 관점만 본다. 또 "EC2가 멀웨어에 감염된 것 같다 → 스캔하라"는 Malware Protection(EBS)이다.

보호 플랜을 고를 때의 판단 기준을 한 표로 정리하면 다음과 같다. 시험은 "이 가시성이 없다 → 무엇을 켜야 하나"의 형태로 묻는다.

Malware Protection for EC2가 "에이전트 없이" 동작하는 방식은 시험보다 실무에서 더 중요한 함의를 갖는다. GuardDuty는 의심 인스턴스의 EBS 볼륨 스냅샷을 서비스 계정 쪽으로 복제해 스캔한다. 이것이 의미하는 바는 세 가지다. (1) 워크로드에 성능 영향이 사실상 없다 — 스캔은 인스턴스 밖에서 일어난다. (2) 감염된 호스트가 스캔을 방해하거나 결과를 조작할 수 없다 — 침해된 호스트 위에서 도는 안티바이러스가 갖는 근본적 신뢰 문제를 우회한다. (3) 대신 볼륨이 고객 관리형 KMS 키로 암호화되어 있으면 GuardDuty 서비스 역할이 그 키를 쓸 수 있어야 한다. "Malware Protection을 켰는데 특정 인스턴스만 스캔이 실패한다"의 흔한 원인이 KMS 키 정책이다. 스냅샷 보존 여부도 선택할 수 있는데, 포렌식을 위해 보존하면 그 스냅샷 자체가 민감 자산이 되므로 접근 통제를 따로 걸어야 한다.

결과(Finding)의 해부

결과는 GuardDuty 탐지의 산출물이다. 결과 타입은 일관된 명명 규칙을 따른다:

ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact

예) UnauthorizedAccess:EC2/SSHBruteForce
    Backdoor:EC2/C&CActivity.B!DNS
    CryptoCurrency:EC2/BitcoinTool.B!DNS
    Recon:IAMUser/UserPermissions
    Exfiltration:S3/AnomalousBehavior
    Trojan:EC2/DNSDataExfiltration
    PenTest:IAMUser/KaliLinux
    Policy:S3/BucketBlockPublicAccessDisabled

• ThreatPurpose(위협 목적): Backdoor, Behavior, CryptoCurrency, Exfiltration, Impact, PenTest, Persistence, Policy, PrivilegeEscalation, Recon, Stealth, Trojan, UnauthorizedAccess 등 — 공격 단계/의도를 나타낸다.
• ResourceTypeAffected: EC2, IAMUser, S3, EKSCluster, RDS, Lambda 등.
• DetectionMechanism: .B!DNS처럼 어떻게 탐지했는지(DNS 기반, etc).

각 결과는 severity(심각도) 점수 0.1~8.0+를 가진다: Low(1.0–3.9), Medium(4.0–6.9), High(7.0–8.9). 시험에서는 점수 자체보다 어떤 결과가 어떤 위협을 의미하는지가 중요하다.

ThreatPurpose 분류는 사실상 MITRE ATT&CK 전술(Tactics) 매핑이다 — Recon(정찰), PrivilegeEscalation(권한 상승), Persistence(지속성), Exfiltration(유출), Impact(영향) 등은 ATT&CK의 킬체인 단계와 대응한다. 결과를 ATT&CK 관점에서 읽으면 "공격이 어느 단계까지 왔는가"를 판단해 대응 우선순위를 정할 수 있다.

실물 결과를 한 줄씩 읽는다 (1) — 자격증명 유출

이 주차의 진짜 역량은 결과 목록을 외우는 것이 아니라 결과 하나를 받아 무슨 일이 일어났는지 재구성하는 것이다. GuardDuty 결과 JSON의 뼈대를 실물로 확인한다.

{
  "SchemaVersion": "2.0",
  "AccountId": "111122223333",
  "Region": "ap-northeast-2",
  "Id": "ac1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d",
  "Type": "UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS",
  "Severity": 8,
  "Title": "Credentials created exclusively for an EC2 instance have been used from an external IP address.",
  "Resource": {
    "ResourceType": "AccessKey",
    "AccessKeyDetails": {
      "AccessKeyId": "ASIAEXAMPLEKEYID",
      "PrincipalId": "AROAEXAMPLE:i-0abc123def4567890",
      "UserType": "AssumedRole",
      "UserName": "app-server-role"
    }
  },
  "Service": {
    "ServiceName": "guardduty",
    "DetectorId": "12abc34d567e8fa901bc2d34e56789f0",
    "ResourceRole": "TARGET",
    "Action": {
      "ActionType": "AWS_API_CALL",
      "AwsApiCallAction": {
        "Api": "ListBuckets",
        "ServiceName": "s3.amazonaws.com",
        "CallerType": "Remote IP",
        "RemoteIpDetails": {
          "IpAddressV4": "198.51.100.24",
          "Country": { "CountryName": "Netherlands" },
          "Organization": { "Asn": "64500", "AsnOrg": "EXAMPLE-HOSTING" }
        }
      }
    },
    "Count": 14,
    "EventFirstSeen": "2026-03-14T02:11:07Z",
    "EventLastSeen": "2026-03-14T02:29:52Z"
  }
}

한 줄씩 무엇을 뜻하는지 풀면 이렇다.

이 한 건에서 도출되는 대응 순서는 명확하다. (1) 해당 역할 세션 무효화 — 액세스 키를 지우는 게 아니라 역할에 시점 기반 거부 정책(aws:TokenIssueTime 조건)을 붙이거나 역할 신뢰/권한을 즉시 축소한다. (2) 원본 인스턴스 격리(격리 SG로 이동, 종료 금지 — 메모리 증거가 사라진다). (3) IMDSv2 강제 여부 확인 — 이 유형의 유출은 대개 SSRF+IMDSv1에서 온다. (4) CloudTrail에서 그 세션이 실제로 무엇을 읽었는지 범위 산정. (5) Detective로 같은 IP·같은 역할이 건드린 다른 엔티티 추적(day2).

Resource.ResourceType이 AccessKey인 결과에 대해 "인스턴스를 종료(terminate)한다"를 정답으로 고르면 안 된다. 임시 자격증명은 이미 인스턴스 밖에 있고 만료 전까지 유효하므로, 인스턴스를 없애도 자격증명은 계속 살아 있다. 게다가 종료는 포렌식 증거(메모리·디스크 상태)를 파괴한다. 정답의 형태는 항상 "세션 무효화 + 인스턴스 격리(종료 아님) + 스냅샷"이다.

실물 결과를 한 줄씩 읽는다 (2) — DNS 기반 채굴 탐지

{
  "Type": "CryptoCurrency:EC2/BitcoinTool.B!DNS",
  "Severity": 8,
  "Resource": {
    "ResourceType": "Instance",
    "InstanceDetails": {
      "InstanceId": "i-0abc123def4567890",
      "InstanceType": "c6i.8xlarge",
      "NetworkInterfaces": [
        { "PublicIp": "203.0.113.77", "VpcId": "vpc-0a1b2c3d", "SubnetId": "subnet-0e5f6a7b" }
      ],
      "Tags": [{ "Key": "Env", "Value": "prod" }]
    }
  },
  "Service": {
    "ResourceRole": "ACTOR",
    "Action": {
      "ActionType": "DNS_REQUEST",
      "DnsRequestAction": { "Domain": "pool.example-mining.net", "Protocol": "UDP", "Blocked": false }
    },
    "Count": 431
  }
}

읽는 법이 앞의 결과와 어떻게 다른지가 핵심이다.

• !DNS 접미사와 ActionType: "DNS_REQUEST" — 탐지 근거가 도메인 질의다. 실제 채굴 트래픽을 본 게 아니라, 채굴 풀로 알려진 도메인을 물어봤다는 사실을 잡은 것이다. 그래서 VPC 기본 Route 53 Resolver를 쓰지 않으면 이 결과는 아예 생기지 않는다.
• ResourceRole: "ACTOR" — 이번엔 인스턴스가 행위 주체다. 앞 결과(TARGET)과 정반대이며, 이 필드 하나로 "당한 쪽인가 하는 쪽인가"가 갈린다.
• Blocked: false — Route 53 Resolver DNS Firewall 같은 통제로 차단되지 않고 질의가 성공했다는 뜻. 차단됐다면 위험도 판단이 달라진다.
• InstanceType: "c6i.8xlarge" + Env: prod — 큰 컴퓨트 인스턴스가 채굴에 쓰이고 있다. 비용 관점 피해도 즉시 발생 중이다.
• Count: 431 — 일회성 오탐이 아니라 지속적 활동이다.

2018년 공개된 테슬라 AWS 계정의 암호화폐 채굴 사건은 이 결과 유형이 현실에서 어떤 모습인지 보여준다. 인증이 걸려 있지 않은 쿠버네티스 관리 콘솔이 인터넷에 노출돼 있었고, 공격자가 그 안에서 자격증명을 얻어 클라우드 자원에 채굴 소프트웨어를 올렸다. 주목할 점은 공격자가 탐지를 피하려고 채굴 풀을 공개 풀 대신 자체 서버로 두고, 비표준 포트를 쓰고, CPU 사용률을 낮게 유지했다는 것이다. 즉 "CPU 100%를 보고 알아채겠지"라는 운영 감각은 이미 통하지 않는다. 이것이 GuardDuty처럼 DNS·네트워크 평판과 행위 이상을 동시에 보는 탐지가 필요한 이유이고, 동시에 커스텀 DNS resolver를 쓰는 환경에서 DNS 기반 결과가 사각지대가 되는 것이 왜 실질적 위험인지도 설명한다.

결과 유형 → 의미 → 1차 대응 매핑

시험에서 반복 등장하는 결과를 "무엇을 시사하는가"와 "무엇을 먼저 하는가"로 묶어 외우는 것이 가장 효율적이다.

🎯 시나리오: "GuardDuty가 Recon:IAMUser/UserPermissions에 이어 PrivilegeEscalation:IAMUser/AdministrativePermissions, 그리고 Persistence:IAMUser/*를 순서대로 냈다"는 상황이 나오면, 이는 개별 알림 세 건이 아니라 하나의 침해가 킬체인을 따라 진행 중이라는 뜻이다 — 정찰 → 권한 상승 → 지속성 확보. 이때 "각 결과를 개별 티켓으로 처리한다"는 답은 오답이고, 정답은 동일 주체·IP 기준으로 묶어 단일 인시던트로 격상하고(Detective finding group, Security Hub 상관), 자격증명 무효화와 새로 생성된 지속성 아티팩트 제거를 함께 수행하는 것이다. ThreatPurpose를 ATT&CK 단계로 읽는 훈련이 여기서 값을 한다.

위협 인텔리전스: 알려진 악성 + 사용자 정의

GuardDuty는 AWS·서드파티(CrowdStrike, Proofpoint 등)가 큐레이션하는 위협 인텔 피드를 내장한다. 알려진 악성 IP·도메인과의 통신은 즉시 결과가 된다.

추가로 사용자가 직접 두 가지 리스트를 등록할 수 있다:

• Trusted IP list(신뢰 IP): 이 IP들에서의 활동은 결과를 생성하지 않음(화이트리스트). 자사 사무실·VPN IP 등.
• Threat IP list(위협 IP): 이 IP들과의 통신은 결과 생성(커스텀 블랙리스트). 자체 위협 인텔 통합.

GuardDuty 위협 평가
  ├─ AWS 큐레이션 인텔 (자동)
  ├─ Trusted IP list  → 매칭 시 결과 억제
  └─ Threat IP list   → 매칭 시 결과 생성

Trusted IP / Threat IP 리스트는 위임 관리자(또는 개별 계정) 수준에서 관리되며, 멤버 계정은 자체 리스트를 추가할 수 없다(조직 모드에서는 관리자가 중앙 관리). 또 GuardDuty는 예방 도구가 아니다 — Trusted IP에 넣어도 그 IP의 접근을 허용하는 게 아니라 결과를 안 만드는 것뿐이다. 접근 통제는 SG/NACL/WAF의 몫이다.

멀티계정: 위임 관리자(Delegated Administrator)

엔터프라이즈는 수십~수백 계정을 쓴다. GuardDuty를 계정마다 따로 켜고 따로 보는 것은 비현실적이다. AWS Organizations + 위임 관리자 패턴이 정답이다:

관리 계정(management) ──지정──▶ 위임 관리자 계정(보통 Security Tooling 계정)
                                      │
                                      ├─ 조직 전체 GuardDuty 활성화
                                      ├─ "Auto-enable for new accounts" 설정
                                      └─ 모든 멤버 결과를 중앙 집계·관리

• 관리 계정이 한 계정(권장: 별도 Security Tooling 계정)을 GuardDuty 위임 관리자로 지정.
• 위임 관리자는 조직 내 모든 계정에서 GuardDuty를 활성화하고, 자동 등록(auto-enable)으로 신규 계정도 자동 포함.
• 멤버 계정의 결과는 위임 관리자 콘솔에 집계되어 단일 창에서 본다.

이는 AWS의 멀티계정 보안 베이스라인 모범사례다. 보안 도구(GuardDuty, Security Hub, Detective, Macie 등)는 워크로드 계정과 분리된 전용 Security Tooling 계정에 위임해, 워크로드 계정 관리자가 탐지를 끄거나 결과를 숨길 수 없게 한다(권한 분리). 위임 관리자 패턴은 관리 계정(루트 권한 집중)에 보안 운영 부담을 지우지 않으면서도 조직 전체 가시성을 준다.

멤버 계정은 자기 계정에서 GuardDuty를 비활성화할 수 없다(위임 관리자가 조직 모드로 강제 시). "신규 계정이 탐지 사각지대"라는 문제의 답은 auto-enable 활성화다. 또 위임 관리자 지정은 관리 계정만 할 수 있다.

실물 CLI: 켜기부터 조직 배포까지

콘솔 클릭은 시험에 나오지 않지만, CLI는 각 개념이 어떤 단위로 존재하는지를 드러내기 때문에 이해에 도움이 된다. 특히 GuardDuty의 모든 것이 리전별 detector 하나에 매달려 있다는 점이 CLI에서 명확해진다.

# 1) detector 생성 = 이 리전에서 GuardDuty 켜기.
#    detector는 리전마다 하나뿐이며, 이후 모든 명령이 detector-id를 요구한다.
aws guardduty create-detector \
  --enable \
  --finding-publishing-frequency FIFTEEN_MINUTES \
  --data-sources '{"S3Logs":{"Enable":true}}'
 
# 2) 지금 열려 있는 High 심각도 결과만 추리기 (severity 7 이상, 아직 아카이브 안 된 것)
DETECTOR=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)
 
aws guardduty list-findings \
  --detector-id "$DETECTOR" \
  --finding-criteria '{
    "Criterion": {
      "severity": { "GreaterThanOrEqual": 7 },
      "service.archived": { "Eq": ["false"] }
    }
  }' \
  --sort-criteria '{"AttributeName":"severity","OrderBy":"DESC"}'
 
# 3) 결과 본문 조회 — 위에서 본 JSON이 여기서 나온다
aws guardduty get-findings \
  --detector-id "$DETECTOR" \
  --finding-ids "ac1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d" \
  --query 'Findings[].{Type:Type,Sev:Severity,Actor:Service.ResourceRole,
                        Api:Service.Action.AwsApiCallAction.Api,
                        Ip:Service.Action.AwsApiCallAction.RemoteIpDetails.IpAddressV4,
                        Count:Service.Count}'

신뢰/위협 IP 목록은 S3에 올린 텍스트 파일을 가리키는 방식이다 — 목록 자체가 버전 관리 가능한 아티팩트가 된다.

aws guardduty create-ip-set \
  --detector-id "$DETECTOR" \
  --name corp-egress-ips --format TXT \
  --location s3://sec-intel-111122223333/trusted/corp-egress.txt \
  --activate
 
aws guardduty create-threat-intel-set \
  --detector-id "$DETECTOR" \
  --name internal-blocklist --format TXT \
  --location s3://sec-intel-111122223333/threat/blocklist.txt \
  --activate

조직 배포는 두 단계다. 관리 계정에서 위임하고, 위임 관리자 계정에서 자동 활성화 정책을 건다.

# (관리 계정에서 실행) 보안 계정을 GuardDuty 위임 관리자로 지정
aws guardduty enable-organization-admin-account --admin-account-id 999988887777
 
# (위임 관리자 계정에서 실행) 조직 전 계정 + 신규 계정 자동 포함
aws guardduty update-organization-configuration \
  --detector-id "$DETECTOR" \
  --auto-enable-organization-members ALL \
  --features '[{"Name":"RUNTIME_MONITORING","AutoEnable":"ALL"},
               {"Name":"EBS_MALWARE_PROTECTION","AutoEnable":"ALL"}]'

여기서 --auto-enable-organization-members ALL이 "기존 + 신규 전부", NEW가 "신규만", NONE이 "자동 활성화 안 함"이다. 시험에서 "신규 계정이 사각지대"라는 증상은 이 값이 NEW가 아니라 NONE이거나 아예 설정되지 않은 상태에 해당한다. 그리고 보호 플랜(feature)마다 auto-enable을 따로 지정해야 한다 — 기초 GuardDuty만 자동으로 켜지고 Runtime Monitoring은 켜지지 않는 반쪽 배포가 흔한 실수다.

[ 멀티계정 GuardDuty 배선 ]

 Organizations 관리 계정
   │  enable-organization-admin-account (이 명령만 관리 계정 전용)
   ▼
 Security Tooling 계정 = GuardDuty 위임 관리자
   │  update-organization-configuration --auto-enable-organization-members ALL
   │  + feature별 AutoEnable (Runtime / Malware / EKS / RDS / Lambda)
   │
   ├── 멤버 계정 A (워크로드)  ─── 결과 ──┐
   ├── 멤버 계정 B (워크로드)  ─── 결과 ──┤
   └── 신규 계정 N (자동 등록) ─── 결과 ──┤
                                          ▼
                        위임 관리자 콘솔 = 전 계정 단일 결과 뷰
                                          │
                                          └─▶ Security Hub / EventBridge

 ※ 멤버 계정은 자기 detector를 끄지 못한다 = 워크로드 팀이 탐지를 무력화할 수 없다.
 ※ 리전마다 detector가 따로 있다 = 위임·auto-enable도 리전마다 적용해야 한다.

위 다이어그램의 마지막 줄이 실무·시험 양쪽에서 놓치기 쉬운 사각지대다. GuardDuty는 리전 서비스이므로 서울 리전에 아무리 잘 배포해도 쓰지 않는 리전에서 벌어지는 활동은 보이지 않는다. 공격자가 평소 사용하지 않는 리전에서 인스턴스를 띄워 채굴하는 것은 고전적인 수법이며, 그래서 "쓰지 않는 리전에도 GuardDuty를 켠다"는 것이 베이스라인 권고다(비활동 리전은 분석할 데이터가 거의 없어 비용도 미미하다). 리전 자체를 막고 싶다면 그건 SCP(aws:RequestedRegion 조건)의 몫이며, 탐지와 예방을 각각 걸어야 한다.

운영: 노이즈를 줄이지 않으면 탐지는 실패한다

결과가 하루 수백 건 쌓이면 아무도 보지 않게 되고, 그 순간 GuardDuty는 켜져 있으나 없는 것과 같아진다. 노이즈 관리 수단은 세 가지이며 성격이 다르다는 점이 중요하다.

# 승인된 내부 취약점 스캐너가 만드는 포트스캔 탐지 결과만 자동 아카이브
aws guardduty create-filter \
  --detector-id "$DETECTOR" \
  --name suppress-approved-scanner \
  --action ARCHIVE \
  --finding-criteria '{
    "Criterion": {
      "type": { "Eq": ["Recon:EC2/Portscan"] },
      "resource.instanceDetails.tags.value": { "Eq": ["security-scanner"] }
    }
  }'

Trusted IP list와 억제 규칙 중 무엇을 쓸지는 "나중에 그 사실을 알고 싶은가"로 결정한다. Trusted IP는 증거 자체를 남기지 않는다 — 나중에 그 IP가 침해되어 조사할 때 "이 IP에서 무슨 일이 있었나"를 GuardDuty 결과로는 되짚을 수 없다. 억제 규칙은 결과를 만들되 아카이브만 하므로, 필터를 풀면 과거 결과가 그대로 보인다. 그래서 실무 권고는 가능한 한 억제 규칙을 쓰고 Trusted IP는 최소화하는 것이다. 이는 로깅 일반의 원칙과 같다 — 보지 않기로 결정하는 것과 기록하지 않기로 결정하는 것은 전혀 다른 무게를 가진다. 전자는 되돌릴 수 있고 후자는 되돌릴 수 없다.

결과 발행 주기(finding-publishing-frequency)는 기존 결과의 후속 발생에만 적용된다. 기본값은 6시간이고 15분·1시간으로 줄일 수 있는데, 완전히 새로운 결과는 주기와 무관하게 즉시 EventBridge로 발행된다. "자동 대응이 6시간 늦게 돈다"는 증상은 새 결과가 아니라 반복 결과를 트리거로 삼았을 때 나온다. 자동 격리 같은 즉시성이 필요한 대응을 설계할 때 이 차이를 모르면 파이프라인이 조용히 느려진다.

결과가 나온 뒤: 자동화 연계

결과는 보는 것으로 끝나면 안 된다. GuardDuty는 결과를 Amazon EventBridge로 발행한다(거의 실시간). 이를 트리거로:

GuardDuty Finding ──▶ EventBridge Rule ──▶ Lambda(격리/스냅샷/태깅)
                                        ├─▶ SNS(알림)
                                        ├─▶ Step Functions(대응 워크플로)
                                        └─▶ Security Hub(집계, 자동 통합)

예: UnauthorizedAccess:EC2/SSHBruteForce 결과 → EventBridge → Lambda가 해당 EC2를 격리 SG로 이동 + 포렌식 스냅샷 + 티켓 생성. 신규 결과는 EventBridge에 즉시, 기존 결과의 후속 발생은 기본 6시간(설정 가능 15분~) 간격으로 집계 발행된다.

GuardDuty 탐지 결과의 가치는 상관(correlation)과 대응(response)으로 완성된다. 단일 탐지 결과는 노이즈일 수 있으나, Detective로 조사하고(Day 2), Security Hub로 다른 탐지 결과와 상관하고(Day 4), EventBridge로 자동 대응을 걸 때 운영 가치를 낸다. GuardDuty를 "알람 생성기"로만 보면 절반만 쓰는 것이다 — 탐지→조사→대응의 파이프라인 입구로 설계해야 한다.

자주 틀리는 구분

• GuardDuty vs CloudTrail: CloudTrail은 로그를 기록, GuardDuty는 로그를 분석해 위협 판단. CloudTrail이 원천, GuardDuty가 해석자.
• GuardDuty vs Inspector: GuardDuty는 런타임 위협(지금 일어나는 악성 활동), Inspector는 취약점(악용 가능한 약점). 탐지 시점이 다르다(Day 3).
• GuardDuty vs Macie: Macie는 S3의 민감 데이터(PII) 분류, GuardDuty는 위협 행위. 목적이 다르다.
• GuardDuty vs WAF/SG: GuardDuty는 탐지(detect)만, 차단(prevent)은 안 한다. 차단은 다른 통제와 자동화로.
• GuardDuty vs Security Lake/CloudTrail Lake: 후자는 로그를 모아 보관·질의하는 데이터 계층, GuardDuty는 판단하는 분석 계층. GuardDuty는 원본 로그를 사용자에게 돌려주지 않는다.

정리

GuardDuty를 한 문장으로 요약하면 "켜면 켜지는 관리형 위협 탐지"지만, 실제 역량은 그 뒤에 있다. 켜는 것은 시작이고, 시험이 묻는 것은 대개 다음 네 가지 판단이다.

1. 가시성의 경계 — 기초 소스(CloudTrail·Flow·DNS)만으로는 호스트 내부도, 디스크의 멀웨어도, 쿠버네티스 API도 보이지 않는다. "무엇이 안 보이는가"에서 어떤 보호 플랜을 켤지가 결정된다. 그리고 커스텀 DNS resolver·비사용 리전처럼 구성 때문에 생기는 사각지대는 서비스를 켠다고 사라지지 않는다.
2. 결과 읽기 — ThreatPurpose:Resource/Family.Mechanism!Artifact라는 이름과 Severity·ResourceRole·Action·Count 몇 필드만으로 "당한 쪽인가 하는 쪽인가", "무엇을 근거로 탐지했나", "일회성인가 진행 중인가"가 읽힌다. 이 읽기가 곧 1차 대응 결정이다.
3. 역할의 한계 — GuardDuty는 탐지만 한다. 차단은 SG/NACL/WAF/DNS Firewall, 조사는 Detective, 집계는 Security Hub, 조치는 EventBridge 뒤의 자동화가 맡는다. Trusted IP는 접근 허용이 아니라 결과 억제라는 구분도 같은 맥락이다.
4. 조직 규모의 배포 — 위임 관리자(Security Tooling 계정) + auto-enable + 보호 플랜별 자동 활성화 + 전 리전. 이 네 가지가 갖춰져야 "조직 전체가 탐지되고 있다"고 말할 수 있다.

Capital One의 자격증명 유출도, 테슬라 계정의 채굴도, 그것을 알아채는 데 걸린 시간이 피해 규모를 결정했다. 탐지의 가치는 공격을 막는 데 있지 않고 공격이 진행되는 시간을 줄이는 데 있다 — 이 관점이 week9 전체를 관통한다.

한 줄 요약 체크리스트

• GuardDuty를 조직 위임 관리자(Security Tooling 계정)에서 켜고 auto-enable 했는가
• DNS 기반 탐지를 위해 VPC 기본 Route 53 Resolver를 쓰는가
• 호스트 내부 위협이 필요하면 Runtime Monitoring을, 멀웨어는 Malware Protection을 켰는가
• 결과를 EventBridge로 받아 알림·자동 대응에 연결했는가
• Trusted/Threat IP 리스트를 위협 인텔에 맞게 관리하는가