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.

SSH 없이 ECS Exec 및 런타임 검사하기

ECS Exec은 SSH, 배스천 호스트 또는 퍼블릭 IP를 노출하지 않고도 실행 중인 컨테이너(Fargate 태스크 포함)에 대한 대화형 셸을 제공합니다. 이는 AWS가 태스크의 사이드카 실행 환경에 주입하는 SSM 에이전트를 통해 작동합니다. SSH 데몬, 키 자료, 보호해야 할 인바운드 네트워크 경로가 없기 때문에 운영 오버헤드가 최소화되고, 모든 세션은 CloudTrail을 통해 감사할 수 있으며 선택적으로 S3 또는 CloudWatch Logs에 기록할 수 있습니다.

ECS Exec이 작동하려면 다음 세 가지 요구 사항을 모두 충족해야 합니다.

태스크 역할 권한: *실행 역할(execution role)이 아닌 태스크 역할(task role)*에 ssmmessages:CreateControlChannel, ssmmessages:CreateDataChannel, ssmmessages:OpenControlChannel, ssmmessages:OpenDataChannel 권한이 필요합니다. 실행 역할은 이미지를 가져오고 로그를 쓰는 역할만 합니다. 런타임 SSM 트래픽은 컨테이너 프로세스가 맡는 ID가 태스크 역할이기 때문에 태스크 역할을 통해 흐릅니다.
서비스 또는 태스크 구성: 서비스를 생성하거나 업데이트할 때 --enable-execute-command를 사용해야 합니다. 이 플래그는 새 태스크에 enableExecuteCommand를 활성화하며, 기존 태스크는 교체해야 합니다.
컨테이너 이미지 지원: 컨테이너 이미지에 셸(/bin/sh 또는 /bin/bash)이 있어야 합니다.

일반적인 검사 흐름은 다음과 같습니다.

aws ecs update-service --cluster prod --service api \
  --enable-execute-command --force-new-deployment

aws ecs execute-command --cluster prod \
  --task 5f8c...c2 --container api \
  --interactive --command "/bin/sh"

엔지니어는 해당 셸에서 S3로 로그를 복사하거나, 힙 덤프를 트리거하거나, 포렌식을 위해 /proc을 읽을 수 있습니다. 대안으로 SSH를 통해 컨테이너에 접근하거나 디버그 에이전트를 활성화하기 위해 태스크를 재시작하는 방법이 있지만, 이는 Fargate에서는 실패하거나 수집하려던 증거를 파괴하게 됩니다.

EC2의 컨테이너에서 IMDS 액세스 차단하기

EC2 인스턴스의 IMDSv2 홉 제한(hop-limit) 설정이 해당 인스턴스의 컨테이너를 보호한다는 것은 흔한 오해입니다. 적어도 브리지(bridge) 또는 호스트(host) 네트워크 모드의 기본 설정에서는 그렇지 않습니다. 컨테이너는 호스트의 네트워크 네임스페이스나 NAT 브리지를 공유하므로 169.254.169.254에 도달하여 일반적으로 태스크 역할보다 훨씬 더 많은 권한을 가진 인스턴스 프로파일 자격 증명을 검색할 수 있습니다. 이는 최소 권한 원칙을 완전히 무너뜨립니다.

Fargate로의 마이그레이션이 불가능할 경우, 해결책은 두 부분으로 구성됩니다.

태스크에 awsvpc 네트워크 모드를 사용합니다. 각 태스크는 자체 ENI와 네트워크 네임스페이스를 갖게 됩니다. IMDS 트래픽은 더 이상 호스트의 링크-로컬 엔드포인트에 투명하게 도달하지 않습니다.
**컨테이너 인스턴스의 /etc/ecs/ecs.config 파일에 ECS_AWSVPC_BLOCK_IMDS=true**를 설정합니다. 이는 ECS 에이전트에게 169.254.169.254로 향하는 awsvpc 태스크의 패킷을 삭제하는 iptables 규칙을 설치하도록 지시합니다.

echo 'ECS_AWSVPC_BLOCK_IMDS=true' >> /etc/ecs/ecs.config
systemctl restart ecs

여기에 최소한의 인스턴스 프로파일(기본적으로 ECS 에이전트에 필요한 AmazonEC2ContainerServiceforEC2Role만 포함)과 애플리케이션 권한을 위한 태스크별 IAM 역할을 결합합니다. 인스턴스의 IMDS 홉 제한을 1로 설정하고 IMDSv2를 필수로 요구하는 것은 유용한 심층 방어(defense-in-depth) 조치이지만, 근본적인 해결책은 아닙니다. 브리지 모드 컨테이너는 요청이 호스트에서 시작되기 때문에 여전히 홉 1에서 IMDS에 도달할 수 있습니다.

GuardDuty 런타임 모니터링, EKS Protection 및 컨트롤 플레인 로그

GuardDuty는 계층화된 컨테이너 탐지 기능을 제공합니다.

EKS Protection은 EKS 감사 로그를 분석하여 의심스러운 Kubernetes API 활동(익명 액세스, 권한 있는 파드 생성, 시스템 파드에 대한 exec 실행 등)을 탐지합니다.
**런타임 모니터링(Runtime Monitoring)**은 컨테이너 내부의 프로세스, 파일, 네트워크 활동을 관찰하는 eBPF 기반 센서(EKS의 경우 관리형 애드온, ECS/Fargate의 경우 SSM 관리형 에이전트)를 배포합니다. 이를 통해 파드나 태스크 내부에서 발생하는 리버스 셸, 암호화폐 채굴 바이너리, 자격 증명 유출과 같은 탐지 결과를 찾아냅니다.

EKS 컨트롤 플레인 감사 로그가 실제로 CloudWatch Logs로 전송되지 않으면 EKS Protection은 아무 소용이 없습니다. 클러스터에서 최소한 audit 및 authenticator 로그 유형을 활성화하십시오.

aws eks update-cluster-config --name prod \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

이것이 없으면 GuardDuty는 EKS Protection 탐지 결과를 검사할 데이터 플레인이 없습니다. 이는 운영자가 GuardDuty 기능은 활성화했지만 클러스터의 로깅 구성은 꺼둔 채로 두었다가 왜 Kubernetes 관련 탐지 결과가 나타나지 않는지 의아해하는, 자주 발생하는 함정입니다.

ECR 고급 스캔을 이용한 이미지 스캔

ECR 고급 스캔(Enhanced Scanning)은 Amazon Inspector를 기반으로 하며, 컨테이너 이미지의 OS 및 언어 패키지(Python, Node, Java, Go, Ruby) CVE에 대한 지속적인 스캔을 제공합니다. 기본 스캔은 푸시 시점에 한 번만 실행되며 OS 패키지만 다룹니다. 반면 고급 스캔은 지속적이며, 대부분의 최신 취약점이 존재하는 애플리케이션 종속성까지 포함합니다.

두 서비스가 모두 활성화되면 탐지 결과가 자동으로 Security Hub로 전송되어 규정 준수를 위한 단일 창(single pane of glass)을 제공하고, CI/CD 빌드를 실패시키는 EventBridge 규칙을 작성할 수 있게 해줍니다. 일반적인 적용 패턴은 다음과 같습니다.

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

시나리오: NovaTech Corp는 고객 대면 마이크로서비스를 혼합된 컴퓨팅 환경에서 운영합니다: EC2 기반의 여러 ECS 클러스터, 데이터 처리를 위한 EKS 클러스터, 이벤트 처리를 위한 서버리스 Lambda. 이미지는 ECR에 저장되고, 운영팀은 호스트 접근을 위해 SSM을 사용하며, GuardDuty/CloudWatch가 활성화되어 있지만 컨테이너와 컨트롤 플레인 구성 요소 전반에 걸쳐 가시성이 고르지 않습니다.

과제: 프로덕션 컨테이너에서 의심스러운 아웃바운드 연결이 나타났고, 한 엔지니어가 파드(pod)가 EC2 인스턴스 메타데이터 서비스에 접근할 수 있어 자격 증명 유출 위험이 있음을 발견했습니다. 이미지 취약점과 불충분한 컨트롤 플레인 로깅이 근본 원인을 가리고 있을 수 있습니다.

권장 접근 방식:

태스크에 ECS Exec을 활성화하고 호스트 및 컨테이너 런타임 검사를 위해 AWS Systems Manager Session Manager(ECS Exec + SSM) 사용을 요구하여 SSH 필요성을 제거하고 세션 활동이 CloudTrail 및 CloudWatch Logs에 기록되도록 보장합니다.
EC2 인스턴스에 IMDSv2를 강제(Instance Metadata Service HttpTokens=required, hop limit=1)하고, 호스트 수준 네트워크 규칙을 적용하여 컨테이너 네트워크 네임스페이스에서 169.254.169.254로의 접근을 차단함으로써 컨테이너가 인스턴스 메타데이터를 쿼리할 수 없도록 합니다.
컨테이너와 Lambda에 대해 Amazon GuardDuty 런타임 모니터링 및 악성 프로그램 방지(Malware Protection)를 켜고, 탐지 결과를 Security Hub와 EventBridge로 전달하여 자동화된 격리 플레이북을 실행합니다.
컨트롤 플레인 로그(audit, authenticator, controllerManager, scheduler)를 CloudWatch Logs로 보내도록 활성화하고, 서비스 계정용 IAM 역할(IRSA)을 채택하며, 위험한 기능을 제한하기 위해 어드미션 컨트롤(Pod Security 또는 OPA Gatekeeper)을 강제하여 EKS를 강화합니다.
푸시 시 스캔(scan-on-push) 기능이 있는 Amazon ECR 고급 이미지 스캐닝(Inspector/ECR scanning)을 활성화하고, 탐지 결과를 CI에 통합하여 EventBridge + Lambda를 통해 이미지를 차단/격리하는 정책을 시행합니다.
텔레메트리 중앙화: CloudTrail, GuardDuty 탐지 결과, EKS 컨트롤 플레인 로그, ECR 스캔 결과를 중앙화된 S3/Lambda/Security Hub 파이프라인으로 보내고, 지속적인 규정 준수를 위해 AWS Config 규칙에 피드합니다.

근거: 이 절차는 SSH 기반 접근을 제거하고, 메타데이터 자격 증명 탈취를 방지하며, 런타임 탐지 및 자동화된 대응을 제공하고, 이미지 위생을 강제하며, 컨트롤 플레인 가시성을 제공합니다. 이는 최소 권한, 심층 방어, 중앙 집중식 관측 가능성이라는 AWS 모범 사례에 부합합니다.

# CodeBuild buildspec fragment
post_build:
  commands:
    - aws ecr describe-image-scan-findings \
        --repository-name api --image-id imageTag=$TAG \
        --query 'imageScanFindings.findingSeverityCounts' > findings.json
      CRIT=$(jq '.CRITICAL // 0' findings.json)
      if [ "$CRIT" -gt 0 ]; then echo "Critical CVEs present"; exit 1; fi

파이프라인에 통합하는 것이 스캔을 단순한 대시보드 확인 작업에서 실제적인 통제 수단으로 바꾸는 핵심입니다.

Lambda: Authorizer, 보안 암호 및 실행 역할

Lambda 함수 수준 보안에는 자주 혼동되는 세 가지 차원이 있습니다:

리소스 정책(함수 정책): 어떤 보안 주체(API Gateway, EventBridge, 다른 계정)가 함수를 호출할 수 있는지 제어합니다. API Gateway의 Lambda Authorizer는 HTTP 호출자를 위한 ID 게이트 역할을 합니다. 이는 API Gateway가 백엔드 함수를 호출하기 전에 캐시하고 적용하는 IAM 정책을 반환합니다.
실행 역할: 런타임에 함수 코드가 맡게 되는 ID입니다. 신뢰 정책에는 lambda.amazonaws.com이 포함되어야 하며, CloudWatch Logs가 작동하려면 logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents 권한을 부여해야 합니다. 로그가 누락된 경우, 해결책은 거의 항상 실행 역할에 있습니다. Lambda 콘솔은 CloudWatch가 수신한 로그를 렌더링할 뿐이므로 콘솔 문제가 아닙니다. “콘솔 로그에만” 의존하는 것은 진단상의 함정입니다. 실행 역할 권한이 없으면 로그 스트림이 생성되지 않고 콘솔에는 아무것도 표시되지 않습니다.
보안 암호 검색: 자격 증명을 환경 변수에 평문으로 포함시키지 마십시오. Secrets Manager 또는 SSM Parameter Store SecureString에 저장하고 콜드 스타트 시에 가져오십시오:

import boto3, os, json
_ssm = boto3.client("ssm")
_cached = None

def get_db_password():
    global _cached
    if _cached is None:
        r = _ssm.get_parameter(Name=os.environ["DB_PWD_PARAM"], WithDecryption=True)
        _cached = r["Parameter"]["Value"]
    return _cached

실행 역할에는 CMK에 대한 ssm:GetParameter와 kms:Decrypt 권한이 필요합니다. 모듈 범위에서 캐시하여 웜 호출 시 API 호출을 피하도록 합니다. 처리량이 높은 함수에서는 Secrets Manager Lambda 확장을 사용하여 자동 순환을 인식하는 캐싱을 사용하십시오.

ECR 암호화 및 리포지토리 보호

Amazon ECR은 기본적으로 AWS 관리형 키를 사용하여 모든 저장된 이미지를 AES-256으로 암호화하지만, 규제 대상 워크로드는 일반적으로 고객 관리형 KMS 키를 요구합니다. 그래야 키 순환, 키 정책, CloudTrail 감사 가능성을 고객이 제어할 수 있습니다. KMS 암호화는 리포지토리 생성 시에만 구성할 수 있습니다. 기존 ECR 리포지토리는 생성된 후에 AES-256에서 KMS로 전환할 수 없습니다. 따라서 마이그레이션을 하려면 새로운 KMS 암호화 리포지토리를 생성하고, 이미지를 복제하거나 다시 푸시하고, 다운스트림 소비자를 업데이트한 다음, 이전 리포지토리를 삭제해야 합니다. KMS로 암호화된 리포지토리에서 이미지를 가져오는 교차 계정 소비자는 ECR 읽기 권한 외에도 CMK에 대한 kms:Decrypt 권한을 부여받아야 합니다. 그렇지 않으면 리포지토리 정책이 해당 보안 주체를 허용하더라도 KMS 접근 오류로 인해 풀(pull)이 실패합니다.

{
  "encryptionConfiguration": {
    "encryptionType": "KMS",
    "kmsKey": "arn:aws:kms:us-east-1:111122223333:key/abcd-...-ef01"
  },
  "imageScanningConfiguration": { "scanOnPush": true },
  "imageTagMutability": "IMMUTABLE"
}

변경 불가능한 태그(Immutable tags)는 검증된 v1.2.3 태그가 스캔 후 악성 이미지에 의해 조용히 덮어쓰이는 태그 하이재킹 공격을 방지합니다.

이미지 스캐닝: 기본, 향상된, 그리고 Inspector

ECR은 두 가지 스캐닝 모드를 제공합니다. 기본 스캐닝은 오픈소스 Clair CVE 데이터베이스를 사용하며, 푸시 시(또는 수동 호출 시)에만 실행되고 ECR 콘솔에 결과를 반환합니다. 무료이지만, 지속적인 재스캔을 수행하지 않고, OS와 프로그래밍 언어 패키지를 함께 다루지 않으며, Security Hub와의 네이티브 통합 기능이 없습니다. 향상된 스캐닝은 Amazon Inspector를 기반으로 하며, 운영 체제 패키지와 애플리케이션 언어 패키지(Python, Java, Node.js, Go, Ruby, .NET)를 모두 다룹니다. Inspector는 푸시된 이미지를 업데이트된 취약점 인텔리전스에 대해 지속적으로 모니터링하므로, 이미지가 푸시된 지 일주일 후에 공개된 CVE라도 재빌드 없이 결과를 생성합니다.

향상된 스캐닝은 레지스트리 수준(리전별)에서 활성화되며, 리포지토리별 포함 필터를 사용하여 prod-* 또는 team-a/*와 같은 와일드카드 패턴을 사용합니다. 이는 “대부분의 리포지토리는 스캔하되 샌드박스/실험용 리포지토리는 제외"와 같은 일반적인 요구사항에 대한 올바른 제어 방법입니다. 즉, 개별 리포지토리에 대한 부정적 제외 대신 스캔할 대상을 나열하는 긍정적 필터를 정의합니다.

aws ecr put-registry-scanning-configuration \
  --scan-type ENHANCED \
  --rules '[{
    "scanFrequency": "CONTINUOUS_SCAN",
    "repositoryFilters":[{"filter":"prod-*","filterType":"WILDCARD"}]
  },{
    "scanFrequency": "SCAN_ON_PUSH",
    "repositoryFilters":[{"filter":"dev-*","filterType":"WILDCARD"}]
  }]'

Inspector 통합 및 Security Hub 집계

스캐닝이 필요한 각 계정과 리전에서 Amazon Inspector를 활성화해야 합니다. AWS Organizations 설정에서는 보안 도구 계정을 Inspector의 위임된 관리자로 지정하여 스캐닝 활성화, 새 멤버 계정에 대한 자동 등록 설정, 집계된 결과 조회를 할 수 있습니다. 위임을 잊거나 자동 등록 설정을 잊는 것은 미묘한 장애 모드입니다. 조직에 새로 가입한 계정이 스캔되지 않는 컨테이너를 조용히 ECR로 보내게 되어, 오류 표시 없이 적용 범위 보장을 위반하게 됩니다.

두 서비스가 모두 활성화되고 Security Hub의 Inspector 통합이 켜져 있으면 Inspector 결과는 자동으로 AWS Security Hub로 전달됩니다. 그러면 Security Hub는 결과를 AWS Security Finding Format(ASFF)으로 정규화하고, GuardDuty, Macie, Config 결과와 연관시키며, 위임된 Security Hub 관리자 및 교차 리전 집계와 결합될 때 단일 창(single pane of glass)을 제공합니다. Security Hub 결과에 대한 EventBridge 규칙을 사용하여 심각한 CVE를 Lambda로 라우팅하여 티켓을 자동 생성하거나, 문제가 있는 이미지에 quarantine=true 레이블을 태그하거나, 파이프라인 게이트를 통해 배포를 차단할 수 있습니다.

중앙 집중식 스캐닝 및 교차 계정 CI/CD

다중 계정 컨테이너 워크로드를 위한 권장 패턴은 강화된 중앙 레지스트리 계정을 핵심에 둡니다.

중앙 계정: 향상된 스캐닝, 변경 불가능한 태그, 이미지 서명(AWS Signer와 통합된 Notation/Sigstore 사용) 기능이 있는 KMS 암호화 ECR 리포지토리를 호스팅합니다.
빌드 계정: CodeBuild/CodePipeline 작업을 실행하여 빌드하고, 중앙 ECR에 푸시하며, Inspector 결과를 기다린 후 심각도 임계값에 따라 게이트를 통제합니다.
워크로드 계정(개발/스테이지/프로덕션): 교차 계정 권한을 통해 중앙 레지스트리에서 이미지를 풀(pull)합니다.

교차 계정 읽기 액세스에는 두 가지 계층이 필요합니다. 즉, 사용하는 계정에서 ecr:GetDownloadUrlForLayer, ecr:BatchGetImage, ecr:GetAuthorizationToken을 부여하는 IAM 정책과, 중앙 계정의 ECR 리포지토리에서 특정 소비자 계정 또는 역할을 허용하는 리포지토리 정책이 필요합니다.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowProdPull",
    "Effect": "Allow",
    "Principal": {"AWS":"arn:aws:iam::444455556666:role/EcsTaskExecutionRole"},
    "Action": ["ecr:BatchGetImage","ecr:GetDownloadUrlForLayer"]
  }]
}

ECR 리포지토리 정책은 리소스 기반이므로, 자격 증명 정책과 리소스 정책의 교집합이 액세스를 결정합니다. 둘 중 하나라도 누락되면 AccessDeniedException이 발생합니다. KMS가 관련된 경우, KMS 키 정책은 교차 계정 보안 주체에게 kms:Decrypt 권한도 부여해야 합니다.

EKS 컨트롤 플레인 로깅 및 관측성

EKS의 경우 관리형 컨트롤 플레인에 직접 액세스할 수 없으므로, 컨트롤 플레인 로깅을 명시적으로 활성화해야만 보안 관련 Kubernetes 이벤트를 볼 수 있습니다. 다섯 가지 로그 유형을 사용할 수 있습니다: api, audit, authenticator, controllerManager, scheduler. audit 로그는 가장 가치 있는 보안 아티팩트입니다. IAM authenticator를 통해 확인된 호출자 자격 증명과 함께 클러스터에 대한 모든 API 호출을 기록합니다. 그리고 authenticator 로그는 IAM-to-Kubernetes RBAC 매핑 결정을 기록합니다. 모든 유형은 /aws/eks/<cluster>/cluster 로그 그룹의 CloudWatch Logs로 스트리밍되며, 여기에서 Kinesis Data Firehose로 구독하거나 S3로 전달하거나 SIEM으로 전송할 수 있습니다.

aws eks update-cluster-config --name prod-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator",
  "controllerManager","scheduler"],"enabled":true}]}'

GuardDuty EKS Protection(노드의 런타임 위협 탐지)으로 컨트롤 플레인 로그를 보완하고, 노드 인스턴스 프로필 대신 IRSA(IAM Roles for Service Accounts)를 사용하여 감사 로그가 AWS API 활동을 특정 파드에 귀속시키도록 하십시오.

흔히 빠지는 함정

푸시 시 스캔에만 의존: 기본 ‘푸시 시 스캔’은 푸시 시점에 알려진 취약점은 잡아내지만, 레지스트리에 이미 있는 이미지에 대해 나중에 공개되는 CVE는 처리하지 못합니다. PCI DSS 및 FedRAMP와 같은 감사 프레임워크는 지속적인 취약점 평가를 요구하며, 이를 위해서는 CONTINUOUS_SCAN 빈도의 향상된 스캔과 Security Hub 집계가 필수적입니다. 푸시당 한 번의 스냅샷으로는 이 통제 요구사항을 충족하지 못합니다.

미사용 시 암호화가 필요할 때 ECR에서 KMS를 건너뛰는 경우: 기본 AES-256 암호화는 실제 암호화이지만, 고객 관리형 키, 키 교체 기록, 주체별 kms:Decrypt 감사 추적을 요구하는 컴플라이언스 체계는 AWS 소유 키로는 충족될 수 없습니다. 암호화 유형은 리포지토리별로 변경이 불가능하므로, 이 문제는 생성 시점에 해결해야 합니다. “나중에 켜겠다"는 것은 리포지토리를 재생성하지 않고는 불가능합니다.

Inspector 위임된 관리자 또는 자동 등록을 잊는 경우: Inspector에 대한 위임된 관리자가 없으면 각 계정 소유자가 독립적으로 스캔을 활성화하고 결과를 전달해야 하는데, 이는 운영상 실현 불가능하며 보안 적용 범위에 공백을 만듭니다. 새 멤버 계정에 대한 자동 활성화가 없으면, Control Tower나 Organizations를 통해 생성된 모든 새 계정은 Inspector가 비활성화된 상태로 시작됩니다. 따라서 중앙 계정의 Security Hub에는 아무런 결과가 표시되지 않더라도 해당 계정의 ECR 이미지는 스캔되지 않습니다. 이는 명백한 오류가 아닌 조용한 거짓 음성(silent false-negative)에 해당합니다.

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

시나리오: Meridian Financial은 프로덕션 EKS 클러스터, ECS 서비스, 그리고 prod, dev 및 전용 보안 계정에 분산된 여러 ECR 레지스트리를 갖춘 다중 계정 AWS 환경을 운영합니다. 엔지니어링 팀은 CI/CD 파이프라인을 통해 ECR에 컨테이너 이미지를 푸시하고 EKS/ECS에 배포하며, 보안 팀은 모니터링 및 규정 준수를 위해 중앙 집중식 계정을 유지 관리합니다.

당면 과제: 최근 배포에서 심각도 높은 취약점이 포함된 컨테이너가 프로덕션 전에 탐지되지 않은 채 전달되었습니다. 조사 결과, EKS 컨트롤 플레인 로그가 제한적이고 스캔 결과가 여러 계정에 단편적으로 흩어져 있어 해결(remediation)이 지연된 것으로 밝혀졌습니다.

권장 접근 방식:

ECR 리포지토리 수준 보호 활성화: 이미지 태그 불변성 강제, 특정 IAM 역할에 의한 푸시/풀을 제한하는 리포지토리 정책 적용, 전용 AWS KMS 고객 관리형 키(CMK)로 리포지토리 미사용 시 암호화.
푸시 시 이미지 스캔(기본)을 켜고, Amazon Inspector 향상된 이미지 스캔을 활성화하여 ECR에 대한 취약점 결과를 생성합니다. 여러 계정의 심각도를 중앙에서 집계하기 위해 Inspector를 AWS Security Hub와 통합합니다.
중앙 집중식 교차 계정 스캔 구현: ECR 복제를 구성하거나 보안 계정의 CodeBuild/CodePipeline 역할에 교차 계정 풀(pull) 권한을 부여하여, 보안 계정이 Inspector 및 추가적인 SCA/DAST 도구로 모든 이미지를 스캔하도록 합니다. 결과물은 보안 계정의 CMK로 암호화된 중앙 S3 버킷에 저장합니다.
CI/CD 게이팅 적용: Inspector/Security Hub 결과를 쿼리하고 심각도 높음/치명적 결과가 있는 이미지에 대해 자동으로 배포를 차단하거나 승인을 요구하는 파이프라인 스캔 단계(CodeBuild/CodePipeline 또는 STS assume-role을 사용하는 GitHub Actions)를 추가합니다.
EKS 관측성(observability) 향상: EKS 컨트롤 플레인 로그(API, Audit, Authenticator, ControllerManager, Scheduler)를 중앙 집중식 로깅 계정의 CloudWatch Logs로 전송하도록 활성화하고, EKS API 이벤트에 대해 CloudTrail을 활성화하며, 런타임 모니터링을 위해 Container Insights와 GuardDuty를 사용합니다.

근거: 이 접근 방식은 심층 방어(defense-in-depth)를 적용합니다. 즉, 레지스트리를 암호화하고 보호하며, Inspector를 사용한 향상된 스캔을 자동화하고, 일관된 정책 시행을 위해 Security Hub에서 결과를 중앙 집중화하며, CI/CD에서 배포를 게이팅하고, 신속한 탐지 및 포렌식을 위해 EKS 컨트롤 플레인 로그를 활성화합니다. 이는 AWS의 최소 권한 및 중앙 집중식 모니터링 모범 사례와 일치합니다.

← 취약점 · 모든 도메인 · 사고 대응 및 포렌식 →

이 문제 연습하기 → · 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 찾아보기 →