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.

침해된 EC2 인스턴스의 격리

침해가 의심되는 EC2 인스턴스에 대한 첫 번째 운영 목표는 증거를 인멸하지 않고 격리하는 것입니다. AWS에서의 격리는 인스턴스의 네트워크 노출, 수명 주기 바인딩, 대응 담당자의 접근성에 영향을 미치는 계층적 활동입니다.

표준적인 격리 절차는 인스턴스의 보안 그룹을 강화하는 것부터 시작합니다. 각 인스턴스는 이상적으로 자체 전용 보안 그룹을 가지므로, 인그레스 및 이그레스 규칙을 포렌식 팀(또는 전용 진단 보안 그룹)만 접근할 수 있도록 허용하는 최소한의 집합으로 교체할 수 있습니다. 인스턴스가 Application Load Balancer 뒤에 있거나 대상 그룹에 속해 있다면 먼저 등록을 취소해야 합니다. Auto Scaling 그룹의 멤버인 경우, --should-decrement-desired-capacity 플래그를 사용하여 분리해야 ASG가 즉시 대체 인스턴스를 시작하거나, 더 나쁘게는 조사 중에 “비정상” 인스턴스를 종료하는 것을 방지할 수 있습니다.

aws autoscaling detach-instances \
  --instance-ids i-0abc123 \
  --auto-scaling-group-name web-asg \
  --should-decrement-desired-capacity

aws elbv2 deregister-targets \
  --target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/web/abc \
  --targets Id=i-0abc123

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --disable-api-termination

선의의 운영자, 자동화 스크립트 또는 ASG 스케일 인 이벤트가 보존하려는 볼륨을 파괴할 수 있으므로 종료 방지를 활성화하는 것이 필수적입니다. 종료 방지는 ASG에서 분리하는 것을 대체하지 않습니다. 그룹 범위에서 인스턴스를 제거하지 않으면 ASG는 스케일 인 중에 보호된 인스턴스를 여전히 종료할 수 있습니다.

즉각적인 이그레스 차단이 필요한 서브넷 수준의 격리(예: 인스턴스가 알려진 악성 IP로 비콘을 보내는 경우)를 위해, 서브넷의 네트워크 ACL에 가장 낮은 번호의 규칙으로 모든 아웃바운드를 명시적으로 거부하는 규칙을 추가할 수 있습니다. 이는 상태 비저장(stateless)이며 새로운 플로우에만 영향을 미치는 보안 그룹 변경과 달리 모든 플로우에 즉시 적용됩니다. 진단용 SG를 통해 포렌식 접근 경로가 확보되면, 대응 담당자 서브넷이 SG 허용 목록을 통해 대상에 도달할 수 있도록 NACL 거부 규칙을 제거할 수 있습니다.

휘발성 및 비휘발성 증거 보존

휘발성 증거(프로세스 목록, 열린 네트워크 소켓, 로드된 커널 모듈, 메모리 내용, tmpfs 내용 등)는 인스턴스가 중지되는 순간 파괴됩니다. 비휘발성 증거는 EBS에 존재하며 중지/시작에도 유지되지만, 볼륨이 분리되거나 스냅샷 없이 인스턴스가 종료되면 손실될 수 있습니다. 작업 순서 규칙: 인스턴스가 실행 중인 동안 먼저 휘발성 아티팩트를 수집한 다음, EBS 스냅샷을 생성합니다.

휘발성 증거 수집은 사람이 대화형 셸에 직접 입력하는 대신 SSM Run Command를 통해 스크립트로 실행해야 합니다. Run Command는 호출, 파라미터, 실행 주체, 출력을 CloudWatch Logs 또는 S3에 기록하며, 이 기록 자체가 증거 보관 연속성 기록의 일부가 됩니다.

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

시나리오: Meridian Financial은 단일 AWS 계정 내 여러 VPC에 걸쳐 고객 대면 웹 애플리케이션을 운영하고 있습니다. 이 환경은 Application Load Balancer 뒤의 Auto Scaling 그룹, EBS 기반 EC2 인스턴스, 중앙 집중식 CloudTrail 및 CloudWatch 로깅, GuardDuty, 그리고 KMS로 암호화된 S3 기반 로그 아카이브를 사용합니다. 보안 운영팀은 원격 관리를 위해 AWS Systems Manager를 사용하며, 백업과 스냅샷은 지정된 복구 계정에 저장합니다.

과제: 운영 환경의 EC2 인스턴스 하나에서 의심스러운 아웃바운드 트래픽과 예기치 않은 프로세스 활동 등 침해 징후가 나타났습니다. 팀은 감사 추적 기록을 파괴하지 않으면서 포렌식 분석을 위해 인스턴스를 격리하고 휘발성 메모리와 비휘발성 디스크 증거를 모두 보존해야 합니다.

권장 접근 방식:

Auto Scaling 및 ELB API를 사용하여 대상 그룹에서 인스턴스를 분리하고 Auto Scaling 프로세스를 일시 중단합니다. 그런 다음 제한적인 보안 그룹(모든 인바운드/아웃바운드 거부)을 적용하고 인스턴스의 네트워크 ACL 규칙을 업데이트하여 네트워크 접근을 격리하는 동시에 AWS Systems Manager Session Manager를 통한 관리는 유지합니다.
AWS Systems Manager Run Command를 사용하여 게스트 내부 메모리 캡처(예: LiME)를 실행합니다. 이 작업은 RAM 덤프를 연결된 암호화된 EBS 볼륨에 쓰거나, 보존을 위해 SSE-KMS로 암호화되고 S3 객체 잠금이 활성화된 S3 버킷에 직접 씁니다.
EC2 CreateSnapshot(또는 CreateImage)을 사용하여 연결된 모든 볼륨의 특정 시점 EBS 스냅샷을 캡처합니다. 그런 다음 증거 보관 연속성을 유지하고 조작을 방지하기 위해 해당 스냅샷을 별도의 AWS 계정이나 다른 리전으로 복사합니다.
인스턴스 ENI에 대해 VPC Traffic Mirroring을 활성화하거나 검색하여 전용 모니터링 EC2로 패킷 캡처를 수집하고, 동시에 VPC Flow Logs, ELB 액세스 로그, CloudTrail, CloudWatch Logs 및 GuardDuty 결과를 보안 S3 아카이브로 내보냅니다.
수집된 모든 아티팩트를 AWS Security Hub 또는 티켓팅 시스템에 태그하고 인벤토리를 작성합니다. S3 객체가 암호화되고 객체 잠금이 설정되었는지 확인하고, CloudTrail을 통해 모든 접근을 로깅하면서 IAM 접근을 소규모 포렌식 팀으로 제한합니다.

근거: 이미지를 생성하기 전에 네트워크 접근을 격리하면 추가적인 오염을 방지할 수 있으며, SSM을 사용하면 새로운 네트워크 벡터가 열리는 것을 피할 수 있습니다. 휘발성 메모리를 먼저 캡처하고 불변의 EBS 스냅샷과 보안 S3 아카이브를 생성하면 AWS 인시던트 대응 모범 사례에 따라 증거 무결성과 증거 보관 연속성을 보존할 수 있습니다.

# ssm-document: capture-volatile.yml
schemaVersion: '2.2'
description: Collect volatile artifacts from a suspect Linux host
mainSteps:
  - action: aws:runShellScript
    name: volatileCapture
    inputs:
      runCommand:
        - TS=$(date +%s)
        - mkdir -p /var/ir/$TS && cd /var/ir/$TS
        - ps auxfww > processes.txt
        - ss -tanp > sockets.txt
        - lsof -n > openfiles.txt
        - cat /proc/mounts > mounts.txt
        - lsmod > modules.txt
        - dd if=/dev/mem of=mem.raw bs=1M 2>/dev/null || true
        - aws s3 cp . s3://ir-evidence-bucket/$INSTANCE_ID/$TS/ --recursive

휘발성 증거 캡처 직후, 연결된 모든 EBS 볼륨의 스냅샷을 생성합니다. 스냅샷에 사건 식별자를 태그하여 해당 사건과 명확하게 연결되도록 합니다.

aws ec2 create-snapshot \
  --volume-id vol-0def456 \
  --description "IR-2024-0917 root volume i-0abc123" \
  --tag-specifications 'ResourceType=snapshot,Tags=[
     {Key=IncidentId,Value=IR-2024-0917},
     {Key=SourceInstance,Value=i-0abc123},
     {Key=Handler,Value=jdoe}]'

인스턴스 자체에도 동일한 사건 티켓, 조사관 이름, 그리고 Quarantine과 같은 상태 레이블을 태그합니다. 일관된 메타데이터 태깅은 증거 보관 연속성을 위한 AWS 네이티브 메커니즘입니다. 이는 쿼리가 가능하고, IAM 조건 키를 통해 불변성을 유지할 수 있으며, 리소스에 대한 모든 CloudTrail 이벤트에 나타납니다.

Session Manager와 Run Command를 이용한 실시간 대응

미묘하지만 시험에 매우 중요한 점이 있습니다. 기존 SSH 세션은 보안 그룹 규칙이 제거되어도 유지됩니다. 보안 그룹은 상태 저장(stateful) 방식이며 연결이 설정될 때 규칙을 평가합니다. 따라서 이미 설정된 TCP 세션은 해당 세션을 허용했던 인그레스 규칙이 삭제된 후에도 계속해서 트래픽이 흐릅니다. 만약 대응 담당자가 자신의 SSH 세션에 의존하면서 SG 규칙을 제거하여 인스턴스를 격리한다면, 그 세션은 작동합니다. 하지만 세션이 끊어지는 순간 접근이 차단되고, 이후로는 bastion이나 키 기반 재진입이 불가능해집니다.

올바른 패턴은 포렌식 팀에게 SSM Session Manager를 통해 접근 권한을 부여하는 것입니다. Session Manager는 인바운드 포트를 열 필요가 없습니다. Session Manager는 SSM Agent가 SSM, EC2 Messages, SSM Messages 엔드포인트로 보내는 아웃바운드 연결을 통해 작동합니다(격리된 인스턴스에 인터넷 경로가 필요 없도록 VPC 인터페이스 엔드포인트를 통하는 것이 이상적입니다). ssm:UpdateInstanceInformation 및 메시지 API를 허용하는 인스턴스 프로파일을 연결하고, 대응팀에게 격리된 인스턴스에 대한 태그로 범위가 지정된 ssm:StartSession 권한을 부여합니다.

Session Manager 세션은 SSM 컨트롤 플레인에 의해 중개되기 때문에, 보안 그룹의 인그레스를 강화하거나 완전히 비워도 세션에 영향을 주지 않습니다. 또한 모든 키 입력은 S3 또는 CloudWatch Logs에 기록될 수 있어, 블랙박스가 아닌 감사 가능한 대화형 세션을 만들 수 있습니다.

암호화된 스냅샷의 교차 계정 복구

성숙한 환경에서는 포렌식 스냅샷을 침해된 워크로드 계정에서 분리된 전용 포렌식 계정으로 라우팅합니다. 계정 간에 스냅샷을 공유하려면 두 가지가 필요합니다. 스냅샷을 대상 계정과 공유해야 하고(modify-snapshot-attribute --create-volume-permission), 스냅샷이 고객 관리형 KMS 키로 암호화된 경우 KMS 키 정책은 포렌식 계정의 보안 주체에게 kms:Decrypt, kms:CreateGrant, kms:DescribeKey 권한을 부여해야 합니다. AWS 관리형 aws/ebs 키로 암호화된 스냅샷은 계정 간에 공유할 수 없습니다. 먼저 복사 작업을 통해 CMK로 다시 암호화해야 합니다. 포렌식 계정에서는 공유된 스냅샷을 복사하고 로컬 포렌식 CMK로 다시 암호화하여, 이후의 볼륨 생성이 소스 계정에 의존하지 않도록 합니다.

플레이북 설계 및 오버헤드 최소화

격리 조치를 SSM Automation 문서나 Step Functions 워크플로우로 코드화하여 EventBridge를 통해 GuardDuty 또는 Security Hub 결과에 의해 트리거되도록 합니다. 단일 자동화는 다음을 수행해야 합니다: (1) Run Command를 통해 휘발성 데이터 수집, (2) 인시던트 태그를 붙여 볼륨 스냅샷 생성, (3) 종료 방지 활성화, (4) ASG에서 분리하고 ELB 대상에서 등록 취소, (5) SG를 격리용 SG로 교체, (6) 인스턴스에 티켓 ID 태그 지정. 인스턴스를 계속 실행 상태로 두면 실시간 증거가 보존되고 Session Manager를 통한 대화형 조사가 가능해집니다. 전원을 끄는 것은 자동 격리의 일부가 아니라 나중에 신중하게 결정해야 할 단계입니다. 종료 시 휘발성 증거가 사라지고 악성코드에 내장된 정리 로직이 트리거될 수 있기 때문입니다.

내재화해야 할 함정들: 기존 SSH 세션을 신뢰하면서 SG 규칙을 제거하면 대응 담당자가 상황을 파악할 수 없게 되고 격리에 대한 잘못된 확신을 갖게 됩니다. 스냅샷을 생성하기 전에 현재 위치에서 복구를 수행하면 침입 방법에 대한 답을 제공하는 아티팩트가 파괴됩니다. 그리고 인스턴스를 ASG나 대상 그룹에 그대로 두면 자동 종료되거나, 더 나쁘게는 인시던트의 범위를 숨기는 자동 교체가 발생할 수 있습니다.

즉각적인 격리

워크로드가 침해된 것으로 의심될 때, 가장 먼저 결정해야 할 것은 현재 위치에서 격리할지 아니면 서비스에서 제거할지입니다. 서비스에서 제거(중지 또는 종료)하면 RAM 콘텐츠, 실행 중인 프로세스, 열린 소켓, 메모리에만 상주하는 악성코드와 같은 휘발성 증거가 파괴됩니다. 현재 위치에서 격리하는 것이 거의 항상 올바른 첫 조치이며, 공격자가 통제가 적용되기 전에 추가 데이터를 유출하거나 측면으로 이동할 수 없도록 충분히 빠르게 수행되어야 합니다.

두 가지 AWS 네이티브 컨트롤은 서로 다른 계층에서 작동하며, 그 차이점이 중요합니다. 보안 그룹은 상태 저장(stateful) 방식이며 탄력적 네트워크 인터페이스(ENI)에 연결됩니다. 네트워크 ACL(NACL)은 상태 비저장(stateless) 방식이며 서브넷에 연결됩니다. 인스턴스의 보안 그룹을 잠긴 “격리” SG로 교체하는 것은 외과적인 접근 방식입니다. 이는 동일한 서브넷의 다른 워크로드에 영향을 주지 않고 하나의 ENI를 격리하며 인스턴스의 런타임 상태를 보존합니다. 하지만 보안 그룹 변경은 ENI에 도달하는 새로운 흐름에만 영향을 미치며, 침해된 인스턴스가 이미 장기 실행 아웃바운드 연결을 유지하고 있다면 기존 상태가 지속될 수 있습니다. NACL 거부 규칙은 서브넷 경계에서 즉시 적용되며, 외과적 정밀성보다 속도가 더 중요할 때 트래픽을 훨씬 더 빨리 차단할 수 있습니다. 예를 들어 동일한 서브넷의 여러 인스턴스가 연루되었을 때나 공격자의 활성 세션을 즉시 차단해야 할 때 그렇습니다. NACL은 정책상 인스턴스를 직접 수정할 수 없을 때도 유용합니다.

표준적인 격리 SG는 모든 인바운드 트래픽을 차단하고, com.amazonaws.<region>.ssm, com.amazonaws.<region>.ssmmessages, com.amazonaws.<region>.ec2messages에 대한 VPC 인터페이스 엔드포인트로의 아웃바운드 트래픽만 허용합니다. 이는 C2 채널, 데이터 유출, 측면 이동을 차단하면서 Systems Manager Session Manager 접근을 유지합니다.

QuarantineSG:
  Type: AWS::EC2::SecurityGroup
  Properties:
    GroupDescription: Forensic quarantine - SSM only
    VpcId: !Ref VpcId
    SecurityGroupEgress:
      - IpProtocol: tcp
        FromPort: 443
        ToPort: 443
        DestinationPrefixListId: !Ref SsmEndpointPrefixList
    SecurityGroupIngress: []

증거 보존 순서

포렌식 가치는 가장 휘발성이 높은 것부터 가장 낮은 순서로 감소하므로, 작업 순서는 고정되어 있으며 협상의 여지가 없습니다:

먼저 종료 방지(termination protection)를 활성화합니다. DisableApiTermination=true로 설정하면 Auto Scaling 이벤트, 운영자 실수 또는 예약된 작업으로 인해 조사 중인 인스턴스가 파괴되는 것을 방지할 수 있습니다. 또한 Auto Scaling 그룹에서 인스턴스를 분리하여 ASG 상태 확인(health check)으로 인해 인스턴스가 교체되지 않도록 합니다.
Auto Scaling으로부터 분리 또는 보호합니다. EnterStandby를 사용하거나 인스턴스를 분리하여 ASG가 비정상(unhealthy)으로 간주하여 종료하지 않도록 합니다.
연결된 모든 EBS 볼륨을 스냅샷합니다. CreateSnapshot(또는 다중 볼륨 원자적 캡처를 위한 CreateSnapshots)은 불변의 암호화된 포렌식 아티팩트를 생성합니다. 스냅샷에 인시던트 ID, 소스 인스턴스 ID, 타임스탬프, 분석가 정보를 태그로 지정합니다. 계정이 침해되더라도 살아남을 수 있도록 보안 팀이 소유한 전용 포렌식 계정으로 스냅샷을 복사합니다.
메모리를 캡처합니다. SSM RunCommand 문서를 사용하여 메모리 수집 도구(Linux의 경우 LiME, AVML; Windows의 경우 WinPMEM)를 호출하고, 이미지를 규정 준수 모드(compliance mode)의 Object Lock이 설정된 S3 포렌식 버킷으로 스트리밍합니다. 메모리는 인스턴스가 아직 실행 중일 때 캡처해야 합니다. 중지된 인스턴스는 수집할 RAM이 없습니다.
메타데이터를 수집합니다. 인스턴스 ID, AMI, IAM 인스턴스 프로파일, VPC/서브넷, ENI ID, 태그, 실행 중인 프로세스 목록, netstat 출력, IMDS 콘텐츠를 기록합니다. 다운스트림 자동화 및 운영자가 상태를 인식할 수 있도록 인스턴스에 Status=Quarantined 및 IncidentId=<id> 태그를 지정합니다.
조사에 오프라인 디스크 분석이 필요한 경우에만 인스턴스를 중지합니다. 중지하면 메모리가 지워지므로 이 단계는 항상 마지막에 수행합니다.

aws ec2 modify-instance-attribute --instance-id i-0abc --disable-api-termination
aws autoscaling enter-standby --instance-ids i-0abc \
    --auto-scaling-group-name app-asg --should-decrement-desired-capacity
aws ec2 create-snapshots --instance-specification InstanceId=i-0abc \
    --description "IR-2024-071 forensic" --copy-tags-from-source volume
aws ssm send-command --instance-ids i-0abc \
    --document-name "AWS-RunShellScript" \
    --parameters 'commands=["avml /tmp/mem.lime && aws s3 cp /tmp/mem.lime s3://forensics-bucket/"]'

자동화된 IR 워크플로우

GuardDuty 탐지 결과는 몇 시간이 아닌 몇 초 내에 격리 조치를 트리거해야 합니다. 표준적인 파이프라인은 EventBridge → Lambda → SSM Automation이며, 알림에는 SNS를 사용합니다.

EventBridge 규칙은 source: aws.guardduty와 GuardDuty Finding 상세 유형(detail-type)에 매칭되며, UnauthorizedAccess:EC2/*, Backdoor:EC2/*, Trojan:EC2/*, CryptoCurrency:EC2/*와 같은 EC2 관련 탐지 유형으로 필터링하는 패턴을 사용합니다.

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "type": [{"prefix": "UnauthorizedAccess:EC2/"},
             {"prefix": "Backdoor:EC2/"},
             {"prefix": "Trojan:EC2/"}]
  }
}

Lambda 대상은 detail.resource.instanceDetails.instanceId에서 인스턴스 ID를 추출한 다음, SSM Automation 문서를 호출하거나 SDK를 직접 호출하여 다음을 수행합니다: 종료 방지 활성화, ModifyNetworkInterfaceAttribute를 통해 ENI 보안 그룹을 격리용 SG로 교체, 연결된 모든 볼륨 스냅샷, 인스턴스 태깅, SOC 채널에 SNS 메시지 게시. 원시 SDK 호출 대신 SSM Automation을 사용하면 Automation 실행 기록에 단계별 감사 추적(audit trail)이 남습니다.

데이터 유출 및 C2 분석을 위한 로깅

원격 측정(telemetry) 없는 격리는 추측에 불과합니다. VPC 또는 서브넷 수준에서 트래픽 유형을 ALL(ACCEPT 및 REJECT 모두)로 설정하여 VPC Flow Logs를 활성화해야 합니다. REJECT 기록은 스캐닝, 차단된 데이터 유출 시도, 알려진 악성 IP에 도달하려는 C2 비콘을 드러내며, ACCEPT 기록은 어떤 플로우가 성공했는지 보여줍니다. 실시간 쿼리를 위해 플로우 로그를 CloudWatch Logs로 라우팅하고, 장기 보존을 위해 Object Lock이 설정된 S3로 라우팅합니다. 포렌식 S3 버킷 및 KMS에 대한 데이터 이벤트가 포함된 CloudTrail은 증거 처리에 대한 감사 체인을 제공합니다. 플로우 로그만으로는 놓칠 수 있는 DGA 및 DNS 터널링을 포착하기 위해 DNS 쿼리 로깅(Route 53 Resolver)과 결합합니다.

Session Manager를 통한 통제된 포렌식 접근

Session Manager는 SSH 키, 배스천 호스트 또는 22/3389 포트 개방의 필요성을 없애주며, 바로 이 때문에 격리용 SG가 모든 전통적인 접근을 차단할 수 있습니다. SSE-KMS가 적용된 S3 버킷과 CloudWatch Logs에 세션 로깅을 활성화하고, 세션 기본 설정에서 EnforceEncryption=true를 강제하여 TLS 및 로그 암호화 없이는 세션이 실행되지 않도록 합니다. ssm:StartSession에 대한 IAM 정책은 tag:Status=Quarantined 태그가 있는 인스턴스로 범위를 제한하고, 인시던트 대응 역할에만 부여해야 합니다.

흔히 저지르는 실수와 그 이유

인스턴스를 먼저 중지하거나 종료하는 것. 인스턴스를 중지하면 메모리가 해제되고, 활성 연결이 끊어지며, 휘발성 아티팩트를 수집할 수 없게 됩니다. 종료하면 DeleteOnTermination=false로 설정하지 않는 한 루트 볼륨도 함께 해제되며, 설령 그렇다 해도 런타임 상태는 손실됩니다. 전원 상태를 변경하기 전에는 항상 제자리에서 격리해야 합니다.
NACL이 더 빠름에도 불구하고 보안 그룹에만 의존하는 것. 보안 그룹 변경은 정교하지만 연결된 ENI에만 영향을 미치고 새로운 플로우만 제어합니다. 서브넷의 여러 인스턴스가 연루되었거나 공격자의 기존 아웃바운드 세션을 즉시 차단해야 할 때, 서브넷 수준의 NACL 거부 규칙이 더 빠르게 차단합니다. NACL은 상태 비저장(stateless)이며 이전 상태와 관계없이 모든 패킷을 차단하기 때문입니다.
스냅샷을 생성하기 전에 복구 조치를 하는 것. EBS 스냅샷을 생성하기 전에 인스턴스를 리이미징, 패치 또는 교체하면 디스크에 저장된 증거(악성코드 바이너리, 지속성 메커니즘, 로그, 타임스탬프)가 파괴됩니다. 스냅샷은 저렴하고 변경 불가능(immutable)합니다. 모든 복구 조치 전에 스냅샷을 생성하고, 전용 포렌식 계정으로 복사하여 침해된 프로덕션 계정에서 삭제할 수 없도록 하십시오.

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

시나리오: Meridian Financial은 다중 계정 AWS 환경을 운영하며, 전용 프로덕션 계정에서 워크로드를 실행합니다. 여기에는 고객 데이터를 호스팅하는 EC2 및 EKS 서비스, 아카이브용 S3 버킷, CloudTrail, GuardDuty, Security Hub 및 Config가 활성화된 보안 계정의 중앙 집중식 로깅, 배포를 위한 CI/CD 파이프라인이 포함됩니다. 운영팀은 패치 및 유지 관리를 위해 Systems Manager를, 퍼블릭 엔드포인트를 위해 Route 53/ALB를 사용합니다.

과제: GuardDuty 탐지 결과와 예상치 못한 아웃바운드 트래픽 급증으로 인해 EC2 인스턴스가 침해되어 데이터 유출 및 의심스러운 IAM API 호출에 관여하고 있을 가능성이 높습니다. 이에 따라 포렌식 증거를 보존하고 감사 가능한 조사관 액세스를 유지하면서 즉각적인 격리가 필요합니다.

권장 접근 방식:

GuardDuty 탐지 결과에 대해 EventBridge를 통해 즉각적인 격리를 트리거합니다. 이를 통해 Lambda/SSM Automation을 사용하는 Step Functions 워크플로우를 호출하여 격리용 보안 그룹을 연결하고, 퍼블릭 IP를 제거하거나 ENI를 분리하며, IAM을 통해 관련된 IAM 자격 증명을 취소/교체합니다.
SSM Automation 문서를 실행하여 휘발성 및 영구적 증거를 보존합니다. 인스턴스의 EBS 스냅샷과 AMI를 생성하고, 스냅샷을 전용 포렌식 AWS 계정으로 복사하며, 내보낸 아티팩트를 S3 Object Lock(규정 준수 모드) 및 KMS 암호화가 적용된 S3 버킷에 저장합니다.
데이터 유출 및 C2 분석을 위한 로깅을 수집합니다. 이를 위해 CloudTrail 관리 및 데이터 이벤트(S3, Lambda)가 활성화되었는지 확인하고, VPC Flow Logs, ALB/NGINX 액세스 로그 및 Route 53 쿼리 로그를 중앙 보안 계정으로 전달하며, 타임라인 상관관계 분석을 위해 해당 탐지 결과를 Amazon Detective로 에스컬레이션합니다.
EventBridge -> Step Functions -> Lambda를 사용하여 오케스트레이션 및 알림을 자동화합니다. 이를 통해 격리, 증거 복사, 사고 담당자에게 SNS 알림 전송, 기존 ITSM 시스템에 티켓 생성을 조율합니다.
실시간 조사를 위해 AWS Systems Manager Session Manager 세션을 요구하여 통제된 포렌식 액세스를 제공합니다. 세션 로깅은 CloudWatch Logs 및 포렌식 S3 버킷에 기록되며, MFA 및 임시 자격 증명을 사용하는 지정된 포렌식 IAM 역할에만 액세스가 허용됩니다.

근거: 이 접근 방식은 위협을 신속하게 격리하고, 분석을 위해 변경 불가능한 아티팩트와 중앙 집중식 로그를 보존하며, 반복 가능한 대응 단계를 자동화하여 격리 시간을 단축하고, AWS 모범 사례에 따라 Session Manager를 통해 감사 가능하고 최소 권한 원칙을 따르는 포렌식 액세스를 강제합니다.

← 컨테이너 및 서버리스 보안 · 모든 도메인

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

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

시험 합격하기 →

Amazon 찾아보기 →