Amazon SCS-C02: 위협 탐지 및 알림 — 학습 가이드

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

다음의 일부입니다: AWS Security Specialty SCS-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

조직 전체에 걸쳐 GuardDuty 중앙 집중화하기

Amazon GuardDuty는 지속적인 위협 탐지 서비스로, CloudTrail 관리 및 데이터 이벤트, VPC Flow Logs, DNS 쿼리 로그, EKS 감사 로그, RDS 로그인 활동, 런타임 원격 측정(telemetry)을 분석합니다. 위협 목적(Backdoor, CryptoCurrency, Recon, UnauthorizedAccess, PenTest, Policy, Stealth, Trojan, Impact)과 리소스 유형(EC2, IAMUser, S3, Kubernetes, RDS, Lambda, Runtime)별로 분류된 결과를 생성합니다.

GuardDuty를 계정별로 운영하는 것은 확장성이 떨어집니다. AWS Organizations 환경에서의 올바른 아키텍처는 Organizations 관리 계정을 사용하여 위임된 관리자(delegated administrator)(일반적으로 전용 보안 또는 감사 계정)를 지정하는 것입니다. 위임된 관리자에서 조직 전체에 GuardDuty를 활성화하고 **자동 활성화(auto-enable)**를 켜서, 새로운 멤버 계정과 새로운 리전이 생성될 때 자동으로 보호되도록 합니다. 자동 활성화가 없으면, 새로 생성된 계정은 운영자가 수동으로 탐지를 활성화할 때까지 사각지대에 놓이게 되며, 이는 공격자들이 온보딩 과정에서 악용하는 바로 그 허점입니다.

실제 문제: 사용 사례 시나리오

시나리오: Meridian Financial은 프로덕션, 개발, 공유 서비스를 위해 28개 계정에 걸쳐 멀티 계정 AWS 환경을 운영하고 있습니다. 관리 계정은 AWS Organizations를 통해 계정들을 관리하며, CloudTrail 및 S3 로깅은 중앙 집중화되어 있지만, 보안 경고 및 조사 데이터는 멤버 계정 전반에 분산되어 있어 인시던트 분류(triage)가 느리고 일관성이 없습니다.

과제: 최근 한 계정에서 발생한 측면 이동(lateral movement) 탐지로 인해 GuardDuty 결과가 중앙 SOC 도구에 신속하게 표시되지 않아, 격리 및 포렌식 조사가 지연되었습니다.

권장 접근 방식:

관리 계정에서 위임된 GuardDuty 관리자를 지정하고 AWS Organizations를 통해 조직 전체에 GuardDuty를 활성화하여 모든 멤버 계정이 중앙 탐지기로 결과를 전달하도록 합니다.
관리 계정에서 중앙 집중식 AWS Security Hub를 집계기(aggregator)로 켜고, 모든 계정과 리전에 Security Hub를 활성화하여 GuardDuty 결과를 다른 보안 표준과 함께 정규화합니다.
관리 계정에서 Amazon EventBridge 규칙을 구성하여 GuardDuty 및 Security Hub 결과를 캡처하고, 페이징을 위한 Amazon SNS, 아카이빙을 위한 Amazon Kinesis Data Firehose to S3, 또는 SIEM으로의 직접 전송과 같은 중앙 집중식 대상으로 라우팅합니다.
자동화된 격리 조치(예: EC2 API를 통해 EC2 인스턴스 격리 및 AWS Systems Manager 인시던트 생성)를 위해 EventBridge에 의해 트리거되는 Lambda 응답기를 배포하고, 조사를 위해 결과에 태그를 지정합니다.
중앙 집중식 조사를 위해 Amazon Detective를 통합하고, S3에 아카이브된 결과를 장기적인 상관관계 분석 및 보고를 위해 분석/SIEM 시스템으로 전달합니다.

근거: Security Hub 및 EventBridge와 함께 위임된 GuardDuty 관리자를 사용하면 탐지를 중앙 집중화하고, 경고를 정규화하며, 조직 전체의 위협 탐지 및 시기적절한 인시던트 대응을 위한 AWS 모범 사례에 따라 자동화되고 감사 가능한 대응을 활성화할 수 있습니다.

# From the Organizations management account
aws organizations enable-aws-service-access \
  --service-principal guardduty.amazonaws.com

aws guardduty enable-organization-admin-account \
  --admin-account-id 111122223333

# From the delegated admin
aws guardduty update-organization-configuration \
  --detector-id abc123 \
  --auto-enable-organization-members ALL \
  --features '[{"Name":"RDS_LOGIN_EVENTS","AutoEnable":"NEW"},
               {"Name":"EKS_AUDIT_LOGS","AutoEnable":"NEW"},
               {"Name":"RUNTIME_MONITORING","AutoEnable":"NEW"}]'

GuardDuty는 리전별 서비스이므로, 운영하는 모든 리전에서 위임된 관리자 관계 및 자동 활성화 설정을 구성해야 합니다. 이는 자주 발생하는 사각지대의 원인입니다. 예를 들어, 한 팀이 us-east-1에서 GuardDuty를 활성화하고 전 세계적으로 적용될 것이라고 가정하는 경우입니다.

서비스별 보호 기능

기본 GuardDuty는 기초적인 데이터 소스를 다루지만, 몇몇 보호 계획은 추가 비용과 추가적인 원격 측정 데이터 수집이 발생하므로 명시적으로 활성화해야 합니다:

RDS Protection: Aurora MySQL/PostgreSQL 및 RDS 엔진에 대한 로그인 활동을 프로파일링하여, 알 수 없는 사용자가 DB 엔드포인트에 인증할 때 CredentialAccess:RDS/AnomalousBehavior.SuccessfulLogin과 같은 결과를 생성합니다. 이는 의심스러운 데이터베이스 로그인을 탐지하는 올바른 방법입니다. RDS Protection이 이미 기본적으로 해당 결과를 생성하므로 DB 감사 로그에 대한 사용자 지정 CloudWatch 지표 필터를 구축하지 마십시오.
EKS Protection: Kubernetes 감사 로그를 수집하여 비정상적인 API 접근, 권한 있는 파드(pod) 생성, 노출된 대시보드 사용 등을 탐지합니다.
Runtime Monitoring: EC2, ECS/Fargate 또는 EKS에 경량의 eBPF 기반 에이전트를 배포하여 프로세스, 파일, 네트워크 이벤트를 표면화합니다. 이는 런타임에 파일리스 멀웨어(fileless malware)나 리버스 셸(reverse shell)을 탐지하는 데 필요합니다.
Malware Protection: 다른 결과에 의해 플래그가 지정된 인스턴스에 연결된 EBS 볼륨을 스냅샷 스캔하거나, S3 객체 업로드 시 온디맨드 스캔을 수행합니다.
Lambda Protection 및 S3 Protection: 각각 함수 호출 패턴과 데이터 플레인 S3 접근을 다룹니다.

기본 서비스만 활성화하고 DB 로그인 이상 행위가 나타나기를 기대하는 것은 흔한 잘못된 구성입니다. 해당 기능이 켜지기 전까지는 관련 결과 유형이 생성되지 않습니다.

Security Hub를 집계 플레인으로 사용

Security Hub는 GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config, Health 및 서드파티 ISV 제품의 결과를 수집하여 AWS Security Finding Format(ASFF)으로 정규화합니다. 또한 자체 규정 준수 표준(AWS Foundational Security Best Practices, CIS, PCI DSS, NIST 800-53)도 실행합니다.

조직 전체에서 중앙 집중화하려면:

Organizations에서 Security Hub를 서비스로 활성화하고 위임된 관리자(일반적으로 GuardDuty와 동일한 보안 계정)를 지정합니다.
새 계정 자동 활성화를 켜서 멤버가 자동으로 등록되도록 합니다.
결과 집계 리전(홈 리전이라고도 함)을 구성하고 다른 모든 리전을 여기에 연결합니다. 리전 간 집계가 없으면 각 리전은 독립적인 Security Hub 인스턴스를 유지하며 분석가는 콘솔을 전환해야 합니다.

따라서 글로벌 조직 전체 배포 패턴에는 두 가지 조정된 설정이 필요합니다: 집계 리전 연결과 조직 전체 자동 활성화 토글입니다. 하나를 활성화하고 다른 하나를 활성화하지 않으면 새 계정이 보호되지 않거나 새 리전이 고립됩니다.

중요한 제한 사항: Security Hub는 집계하고 우선순위를 지정하지만 수정하지는 않습니다. 이를 수정 플랫폼으로 취급하는 것은 범주 오류입니다. 수정은 다운스트림의 EventBridge를 통해 이루어집니다.

EventBridge를 자동화 패브릭으로 사용

GuardDuty와 Security Hub는 모두 기본 이벤트 버스로 결과를 게시합니다. aws.guardduty는 GuardDuty Finding 이벤트를, aws.securityhub는 Security Hub Findings - Imported(Hub에 의해 생성/업데이트됨) 및 Security Hub Findings - Custom Action(운영자에 의해 트리거됨) 이벤트를 내보냅니다.

{"source": ["aws.securityhub"]}와 같이 너무 광범위한 규칙은 모든 공급자의 모든 결과 업데이트에 대해 대상을 호출하여 SNS 주제를 플러딩하고 정보성 노이즈로 온콜 엔지니어에게 빠르게 페이징을 발생시킵니다. 올바른 접근 방식은 severity.Label, ProductArn, Types 또는 특정 Title 값을 기준으로 필터링하는 것입니다.

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{ "numeric": [">=", 7] }],
    "type": [{ "prefix": "CredentialAccess:RDS/" }]
  }
}

시끄러운 서드파티 ISV 제품은 무시하면서 심각도가 높은 GuardDuty 결과에만 반응하는 Security Hub 중심 패턴의 경우:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["HIGH", "CRITICAL"] },
      "ProductArn": [
        { "wildcard": "arn:aws:securityhub:*::product/aws/guardduty" }
      ],
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

일반적인 대상에는 이메일/SMS/Slack 알림을 위한 SNS 주제, 보안 그룹을 교체하여 인스턴스를 격리하는 Lambda 함수, SSM Automation runbook 또는 다단계 응답을 오케스트레이션하는 Step Functions 상태 머신이 포함됩니다. Aurora 로그인 이상 사용 사례의 경우, 최소 노력 경로는 GuardDuty RDS Protection → RDS 결과 유형으로 필터링된 EventBridge 규칙 → 이메일 구독이 있는 SNS 주제입니다. 사용자 지정 폴링, Lambda, 서드파티 SIEM이 필요하지 않습니다.

Security Hub 사용자 지정 작업

사용자 지정 작업은 운영자가 주도하는 트리거입니다. Security Hub 콘솔에서 분석가는 하나 이상의 결과를 선택하고 사용자 지정 작업(예: “Quarantine EC2”)을 선택합니다. Security Hub는 선택된 결과 ARN을 포함하는 Security Hub Findings - Custom Action 이벤트를 내보냅니다. EventBridge 규칙은 사용자 지정 작업의 ARN과 일치하여 응답을 수행하는 Lambda를 호출합니다. 이를 통해 맞춤형 UI를 구축하지 않고도 사람이 개입할 수 있는 버튼을 얻을 수 있습니다.

aws securityhub create-action-target \
  --name "Quarantine EC2" \
  --description "Attach isolation SG and snapshot volumes" \
  --id QuarantineEC2

결과 ARN(arn:aws:securityhub:us-east-1:111122223333:action/custom/QuarantineEC2)은 EventBridge 규칙의 resources 필드에서 일치 값이 됩니다.

억제 및 신호 관리

노이즈 관리는 일회성 필터가 아니라 훈련입니다. Security Hub 자동화 규칙 또는 GuardDuty 억제 규칙을 사용하여 알려진 양성 결과(예: 침투 테스트 도구의 예상 Recon:EC2/Portscan 결과)를 자동으로 아카이브합니다. ProductArn으로 EventBridge 규칙을 필터링하여 시끄러운 서드파티 통합을 완전히 비활성화하지 않고 조용하게 만듭니다. Severity.Label을 Workflow.Status = NEW와 결합하여 재오픈되거나 이미 알림이 전송된 결과가 다시 페이징되지 않도록 합니다. 목표는 사람에게 도달하는 모든 경고가 실행 가능하고 신뢰도 높은 이벤트를 나타내도록 하는 것입니다. 그 외의 모든 것은 대응 준비 태세를 약화시킵니다.

조사 피벗

심각도가 높은 결과(예: Backdoor:EC2/C&CActivity.B!DNS)가 발생했을 때 가장 빠른 조사 경로는 CloudTrail 및 Flow Logs에 대해 Athena 쿼리를 직접 작성하는 것이 아닙니다. Amazon Detective는 GuardDuty와 함께 활성화하면 CloudTrail, VPC Flow Logs 및 GuardDuty 결과로부터 엔터티 그래프를 미리 구축합니다. 결과에서 Detective의 IAM 역할 또는 EC2 인스턴스 프로필로 직접 피벗하면 사용자 지정 쿼리 작업 없이도 관련 기간 동안의 API 활동, 네트워크 피어, 성공 대 실패 연결 수를 확인할 수 있습니다.

← 아이덴티티 및 액세스 관리 · 모든 도메인 · 로깅 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →