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.

Amazon Inspector: EC2, Lambda, ECR에 걸친 향상된 스캔

Amazon Inspector는 에이전트를 지원하는 지속적인 취약점 관리 서비스로, EC2 인스턴스, ECR에 저장된 컨테이너 이미지, Lambda 함수(애플리케이션 코드 및 종속성 계층 모두)에서 CVE를 탐지합니다. 계정 수준에서 Inspector를 활성화하면 대상 리소스가 자동으로 등록되며(리소스별 옵트인 워크플로는 없음), 결과는 표준화된 ASFF 형식으로 AWS Security Hub에 자동으로 푸시됩니다. 이는 중앙 보안 상태 대시보드가 필요할 때 올바른 통합 패턴입니다.

EC2의 경우, Inspector는 하이브리드 스캔 모델을 사용합니다. SSM Agent(AWS에서 제공하는 연결 사용)는 에이전트리스 방식의 네트워크 연결성 및 패키지 평가에 사용되는 소프트웨어 인벤토리를 수집하며, 심층 호스트 평가를 위해서는 에이전트가 실행 중이고 인스턴스가 SSM을 통해 연결 가능해야 합니다. 이것이 ‘에이전트리스 전용’ 접근 방식이 함정인 이유입니다. SSM Agent 경로(또는 필요한 경우 Inspector의 에이전트 기반 심층 검사) 없이는 네트워크 노출 및 매니페스트 기반 CVE와 같은 피상적인 결과만 얻게 되며, 런타임 라이브러리 인벤토리, 관리되지 않는 패키지, 구성을 놓치게 됩니다. 대부분의 프로덕션 환경에는 하이브리드 모드가 필요합니다.

Lambda의 경우, Inspector는 두 가지 스캔 유형을 수행합니다: 표준 스캔(계층 및 함수 종속성의 패키지 취약점)과 코드 스캔(인젝션 결함, 하드코딩된 보안 암호, 안전하지 않은 API에 대한 함수 코드의 정적 분석). 중요한 자격 요건 규칙: Lambda 함수가 스캔되려면 지난 90일 이내에 한 번 이상 호출되어야 합니다. 유휴 또는 아카이브된 함수는 조용히 Inspector의 스캔 범위에서 제외됩니다. ‘Inspector가 활성화되었으므로 모든 함수가 보호된다’고 가정하는 팀은 감사자가 거의 실행되지 않는 함수에 대한 증거를 요청할 때 곤란을 겪게 됩니다. 해결 방법은 EventBridge를 사용하여 정기적으로 함수를 호출하거나, 제외된다는 사실을 수용하고 문서화하는 것입니다.

ECR의 경우, (Inspector 기반의) 향상된 스캔이 Clair 기반의 기존 기본 스캔을 대체합니다. 향상된 스캔은 푸시 시 스캔과 레지스트리에 이미 있는 이미지에 대한 지속적인 스캔을 모두 지원하므로, 이전에 푸시된 이미지에 대해 새로 공개된 CVE가 발생하면 재푸시 없이도 새로운 결과가 생성됩니다. 비용을 제어하려면 레지스트리 수준에서 향상된 스캔을 활성화하고 리포지토리별 필터(예: prod/*는 지속적 스캔, sandbox/*는 푸시 시 스캔만)를 구성하십시오.

위임된 관리 및 억제 규칙

다중 계정 AWS Organizations 설정에서는 관리 계정에서 Inspector를 위한 위임된 관리자 계정을 지정하십시오. 위임된 관리자는 멤버 계정 전반의 집계된 결과를 보고 조직 전체의 스캔 구성을 제어합니다. 이렇게 하면 결과 조회를 위해 교차 계정 IAM 역할을 부여하는 것을 피하고, 계정별로 Inspector를 단편적으로 활성화하는 안티패턴을 방지할 수 있습니다.

억제 규칙을 사용하면 보안팀이 결과를 삭제하지 않고도 노이즈를 필터링할 수 있습니다. 규칙은 리소스 태그, 심각도, CVE ID 또는 ECR 리포지토리와 같은 속성을 기준으로 일치 여부를 판단합니다. 개발/테스트 Lambda 결과를 프로덕션 대시보드에서 제외하려면 Environment=dev 태그를 키로 사용하는 억제 규칙을 적용하십시오. 결과는 감사 목적으로 기본 데이터 스토어에 계속 존재하지만, 기본 보기와 (구성된 경우) Security Hub에서는 제외됩니다. 개발 계정에 대해 Inspector를 비활성화하여 이 목적을 달성하려고 하지 마십시오. 그렇게 하면 취약한 아티팩트가 개발에서 프로덕션으로 승격되는 것을 탐지할 수 없게 됩니다.

이미지 승격을 위한 CI/CD 게이팅

향상된 ECR 스캔은 (단순히 태그가 아닌) 이미지 다이제스트에 연결된 결과를 생성하며, 파이프라인은 이를 쿼리해야 합니다. 정석적인 패턴은 다음과 같습니다: 이미지 빌드 → ECR로 푸시(푸시 시 스캔 트리거) → 스캔 완료를 폴링하거나 기다림 → 심각도 높음(High) 또는 치명적(Critical) 결과가 있으면 빌드 실패 → 그렇지 않으면 ECS/EKS 태스크/배포 업데이트.

buildspec.yml의 최소한의 CodeBuild 단계:

post_build:
  commands:
      DIGEST=$(aws ecr describe-images --repository-name $REPO \
        --image-ids imageTag=$TAG --query 'imageDetails[0].imageDigest' -o text)
      aws inspector2 list-findings \
        --filter-criteria "{\"ecrImageHash\":[{\"comparison\":\"EQUALS\",\"value\":\"$DIGEST\"}],\"severity\":[{\"comparison\":\"EQUALS\",\"value\":\"HIGH\"},{\"comparison\":\"EQUALS\",\"value\":\"CRITICAL\"}]}" \
        --query 'findings[].findingArn' --output text > findings.txt
    - if [ -s findings.txt ]; then echo "Blocking - CVEs found"; exit 1; fi

이 단계에서 게이팅을 실패하는 것, 즉 ‘Inspector가 우리에게 알려줄 것’이라고 믿는 것은 전형적인 실수입니다. 알림은 취약한 이미지가 이미 실행된 후에 비동기적으로 도착합니다. 게이트는 승격과 동기적으로 이루어져야 합니다. 마찬가지로, 다이제스트가 아닌 태그에만 의존하여 게이팅하는 것은 안전하지 않습니다. 태그는 변경 가능하기 때문에 동일한 태그로 두 번 푸시하면 스캔 결과가 혼동될 수 있습니다.

Patch Manager, 기준 및 패치 그룹

SSM Patch Manager는 세 가지 기본 요소를 기반으로 작동합니다:

패치 기준: 자동 승인 규칙, 승인된 패치, 거부된 패치, 심각도/분류별 규정 준수 수준을 정의합니다.
패치 그룹: 키가 정확히 Patch Group인 태그로, 이 태그의 값은 인스턴스를 특정 기준에 등록합니다.
유지 관리 기간: AWS-RunPatchBaseline이 스캔 또는 설치 작업을 실행하는 일정입니다.

개발 환경에서는 모든 보안 패치를 즉시 자동 승인하고, 프로덕션 환경에서는 7일간의 테스트 기간 후 치명적(Critical)/중요(Important) 패치만 자동 승인하면서 커널 패키지는 거부해야 하는 환경의 경우, 두 개의 기준을 생성합니다. 개발 기준은 모든 보안 분류를 포함하는 ApproveAfterDays: 0 승인 규칙을 사용합니다. 프로덕션 기준은 ApproveAfterDays: 7, ComplianceLevel: CRITICAL을 사용하고, Classification=Security 및 Severity in [Critical, Important] 필터를 적용하며, BlockAllPatchesFromRejectedList를 사용하여 거부된 패치 목록에 kernel*을 추가합니다. 인스턴스에는 Patch Group=Dev 또는 Patch Group=Prod 태그가 지정되고, 각 패치 그룹은 해당하는 기준에 등록됩니다. 규정 준수 상태는 패치 규정 준수 보고서를 통해 집계되며, 중앙 감사를 위해 S3로 내보낼 수 있습니다.

‘로직이 있는’ 단일 기준으로는 개발 환경과 프로덕션 환경의 차이를 표현할 수 없습니다. 기준은 등록된 그룹별로 정적입니다. 서로 다른 유지 관리 기간을 사용하여 이 동작을 흉내 내려고 하지 마십시오. 유지 관리 기간은 패치가 언제 실행될지를 제어할 뿐, 어떤 패치가 승인될지를 제어하지는 않습니다.

실시간 알림 파이프라인

Slack 또는 Microsoft Teams로 새로운 결과에 대한 알림을 보낼 때 운영상 가장 효율적인 구성은 다음과 같습니다.

Inspector가 aws.inspector2 이벤트 소스를 통해 EventBridge로 결과를 전송합니다.
EventBridge 규칙이 심각도(예: HIGH, CRITICAL)에 따라 필터링하고 SNS 토픽을 대상으로 지정합니다.
SNS 토픽에 Slack 채널 또는 Teams 워크스페이스에 매핑된 AWS Chatbot 구독이 있습니다.

Chatbot은 SNS를 직접 구독합니다. Chatbot이 기본적으로 Inspector 결과를 렌더링하므로 메시지 형식을 재지정하기 위해 중간에 Lambda를 두지 마십시오. EventBridge 패턴 예시는 다음과 같습니다.

{
  "source": ["aws.inspector2"],
  "detail-type": ["Inspector2 Finding"],
  "detail": { "severity": ["HIGH", "CRITICAL"] }
}

여기서 피해야 할 두 가지 함정이 있습니다. Security Hub를 통한 라우팅은 지연 시간을 추가하고 사용자 지정 인사이트가 잘못 구성된 경우 심각도 세분성을 잃을 수 있습니다. 또한 SES나 사용자 지정 웹훅 Lambda를 사용하면 Chatbot이 이미 기본적으로 제공하는 기능 추가 없이 운영 오버헤드만 증가시킵니다.

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

시나리오: Meridian Financial은 고객 대면 웹 서비스, 배치 분석, 서버리스 이벤트 프로세서를 지원하는 다중 계정 AWS Organization을 운영하고 있습니다. CI/CD 파이프라인은 컨테이너 이미지를 Amazon ECR로 푸시하고, 레거시 워크로드를 위해 EC2 플릿을 호스팅하며, 새로운 서비스에는 Lambda를 사용합니다. 보안 계정의 중앙 보안팀이 여러 계정에 걸쳐 취약점 가시성 및 패치를 관리해야 합니다.

과제: 최근 CI/CD에서 스캔이 강제되지 않아 심각도가 높은 라이브러리를 포함한 이미지가 프로덕션으로 승격되었고, EC2 인스턴스 패치가 환경 전반에 걸쳐 일관되지 않아 노출 기간이 발생하고 팀을 압도하는 노이즈가 많은 결과가 생성됩니다.

권장 접근 방식:

AWS Organizations에서 위임된 관리자(delegated administration)를 구성하여 보안 계정에서 EC2, Lambda, ECR에 대해 Amazon Inspector 고급 스캔(Enhanced Scanning)을 활성화합니다. 이를 통해 스캔, 결과, 억제 규칙을 중앙에서 관리할 수 있습니다.
푸시 시 ECR 이미지 스캔을 구성하고 CodePipeline/CodeBuild에 스캔 게이트를 통합합니다. Inspector/ECR 스캔 결과가 심각도 임계값을 충족할 때까지 이미지 승격을 차단하고 빌드 단계를 통해 결과를 표시합니다.
정의된 패치 기준선(patch baselines) 및 환경별 패치 그룹(patch groups)을 사용하여 AWS Systems Manager Patch Manager를 구현하고, 비프로덕션 우선 배포를 위해 유지 관리 기간(Maintenance Windows)을 예약하며, SSM Automation 문서를 사용하여 중요한 CVE 수정에 대한 승인을 자동화합니다.
Amazon EventBridge를 사용하여 실시간 알림 파이프라인을 생성하여 Inspector 결과 및 SSM 규정 준수 이벤트를 캡처하고, 이를 Amazon SNS와 경량 AWS Lambda로 라우팅하여 데이터를 보강하고 중복을 제거하며 우선순위가 지정된 알림을 Slack에 게시하고 추적 티켓을 생성합니다.
봉쇄 및 해결 조치를 자동화합니다. EventBridge로 트리거되는 SSM Automation 또는 Lambda 런북을 사용하여 영향을 받는 EC2/Lambda 버전을 격리하거나 이미지 재빌드를 트리거하고, 위임된 관리자 계정을 통해 추적된 오탐(false positive)에 대해서만 Inspector 억제를 적용하여 노이즈를 줄입니다.

근거: 중앙 집중식 Inspector 관리, CI/CD 게이팅, Patch Manager 기준선, EventBridge 기반 파이프라인은 자동화된 예방, 일관된 패치, 우선순위가 지정되고 감사 가능한 대응을 강제함으로써 알림 피로도를 줄이는 AWS 모범 사례를 따릅니다.

Amazon Inspector를 사용한 취약점 탐지

Amazon Inspector는 AWS의 주요 관리형 취약점 평가 서비스이며, 호스트 보안과 관련된 세 가지 영역, 즉 EC2 인스턴스, Amazon ECR의 컨테이너 이미지, Lambda 함수에서 작동합니다. 계정 또는 Organizations 수준(Inspector 콘솔에서 위임된 관리자를 통해)에서 활성화되면, 예약된 특정 시점 스캔이 아니라 지속적인, 에이전트리스 또는 SSM 기반 스캔을 수행합니다. 이러한 지속적인 상태 유지는 CVE 피드가 매일 변경되기 때문에 중요합니다. 지난주의 스냅샷은 이미 오래된 정보일 수 있습니다.

EC2의 경우, Inspector는 SSM Agent에 의존하여 설치된 패키지와 커널 버전을 열거한 다음, 이를 공급업체 권고 및 National Vulnerability Database와 상호 연관시킵니다. 결과에는 CVE 식별자, CVSS 점수, 영향을 받는 패키지, 수정된 버전, 네트워크 연결성 컨텍스트(네트워크 연결성 규칙은 ENI, 보안 그룹, NACL, 라우팅 테이블을 통해 인터넷에 노출된 포트를 식별)가 포함됩니다. 스캔은 SSM에 의존하기 때문에, 인스턴스 프로파일에 AmazonSSMManagedInstanceCore 관리형 정책이 없는 EC2 인스턴스는 Inspector 결과에 나타나지 않습니다. 이는 기억해 둘 만한 조용한 실패(silent failure)입니다.

ECR의 경우, Inspector는 두 가지 스캔 모드를 지원합니다.

기본 스캔: 무료이며, 오픈 소스 Clair 엔진을 사용하고, 푸시 시 또는 온디맨드 방식으로만 실행됩니다.
고급 스캔: Inspector 기반이며, 푸시 이벤트가 한참 지난 후에도 새로운 CVE가 게시될 때마다 OS 패키지와 Python, Node, Java 같은 애플리케이션 언어 패키지 모두를 포함하여 이미지를 지속적으로 재스캔합니다.

흔한 함정은 ECR의 푸시 시 스캔(scan-on-push)을 충분한 호스트 보안으로 간주하는 것입니다. 그렇지 않습니다. 푸시 시 스캔은 빌드 시점에 이미지를 검증하지만, 실행 중인 컨테이너는 이미지와 모든 변경 사항(drift)을 상속받으며, 기반이 되는 EC2 또는 Fargate 호스트는 독립적으로 패치해야 하는 자체 커널과 OS 패키지를 가지고 있습니다. 고급 스캔과 EC2 호스트 스캔을 결합하면 이러한 격차를 해소할 수 있습니다. 모든 Inspector 결과는 AWS Security Hub로 라우팅되어야 합니다. Security Hub는 이를 ASFF 형식으로 정규화하고 EventBridge를 통해 교차 계정 집계, 중복 제거, 다운스트림 자동화를 가능하게 합니다.

Patch Manager와 플릿 전체 수정

AWS Systems Manager Patch Manager는 Inspector가 발견한 사항을 실제로 수정하여 Inspector를 보완합니다. Inspector가 “어떤 CVE가 나에게 영향을 미치는가?“에 답하는 반면, Patch Manager는 “어떤 패치가 누락되었으며, 어떻게 안전하게 설치할 수 있는가?“에 답합니다.

Patch Manager는 **패치 기준선(patch baselines)**을 통해 작동합니다. 이는 분류(보안, 중요, 버그 수정), 심각도, 자동 승인 지연(예: 공급업체 안정성을 위해 릴리스 후 7일이 지나 보안 패치 승인)을 기반으로 승인된 패치를 정의하는 선언적 규칙입니다. AWS는 OS별 기본 기준선(AWS-AmazonLinux2DefaultPatchBaseline, AWS-WindowsPredefinedPatchBaseline 등)을 제공하지만, 프로덕션 플릿은 일반적으로 인스턴스의 Patch Group 태그를 통해 **패치 그룹(patch groups)**에 연결된 사용자 지정 기준선을 사용합니다.

일반적인 스캔 및 패치 워크플로는 두 가지 작업을 사용합니다.

Scan: 아무것도 설치하지 않고 규정 준수 여부를 보고합니다. 결과는 Patch Manager 규정 준수 대시보드와 Config에 표시됩니다.
Install: 승인된 패치를 적용하고, 많은 OS의 경우 재부팅합니다.

이러한 작업은 일반적으로 AWS-RunPatchBaseline 문서 대상을 사용하는 **유지 관리 기간(maintenance windows)**을 통해 예약됩니다. 긴급한 제로데이 시나리오의 경우, Patch Manager는 유지 관리 기간 일정을 우회하는 온디맨드 작업인 **지금 패치(Patch Now)**를 제공합니다. 권장되는 패턴은 취약점을 해결하는 특정 KB 또는 패키지만 승인하는 좁은 범위의 패치 기준선을 만들고, 영향을 받는 패치 그룹을 대상으로 지정한 후, 지금 패치를 실행하고, 실행 출력을 중앙 S3 버킷 및 CloudWatch Logs 그룹으로 스트리밍하는 것입니다. 이 중앙 집중식 로그는 감사관이나 사고 대응을 위한 수정 증거인 감사 증거(audit artifact)가 됩니다.

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

시나리오: Meridian Financial은 수백 개의 EC2 인스턴스(Windows 및 Amazon Linux)와 고객 대면 서비스를 지원하는 소규모 EKS 클러스터가 있는 다중 계정 AWS 환경을 운영하고 있습니다. 이들은 AWS Organizations, 운영 도구로 AWS Systems Manager를 사용하고 공유 이미지 계정에서 AMI를 유지 관리하지만, 계정 전반에 걸쳐 일관된 자동화된 취약점 스캔이나 조정된 패치 롤아웃이 없습니다.

과제: OpenSSL에 영향을 미치는 공개 CVE가 발표되고 Amazon Inspector가 여러 인스턴스에 걸쳐 높은 심각도의 결과를 보고했지만, 패치가 일관성 없이 적용되었고 한 프로덕션 서비스는 수정 지연으로 인해 일시적인 공격 시도를 경험했습니다.

권장 접근 방식:

모든 계정과 리전에서 Amazon Inspector를 활성화하여 이미지 및 실행 중인 인스턴스 취약점 스캔을 모두 수행하고, 높은 심각도의 결과를 AWS Security Hub 및 EventBridge 사용자 지정 이벤트 버스로 전달합니다.
AWS Systems Manager Inventory를 사용하여 영향을 받는 인스턴스를 식별하고 중요도별로 태그를 지정합니다. 필요한 OpenSSL 수정 사항을 포함하고 Windows/Linux 규칙을 대상으로 하는 Patch Manager 기준선을 생성합니다.
Inspector 결과가 정의된 심각도에 도달하면 SSM Automation 문서를 트리거하는 EventBridge 규칙을 생성하고, 인스턴스 ID 목록을 Patch Manager 또는 Run Command를 호출하여 패치를 적용하고 필요한 경우 재부팅하는 Automation 실행서(runbook)에 전달합니다.
상태 저장(stateful) 또는 고위험 서비스의 경우, EC2 Image Builder를 사용하여 패치된 AMI를 생성하고, 통제된 블루/그린 또는 롤링 배포로 Auto Scaling 그룹 또는 EKS 노드 그룹을 업데이트하며, Route 53/ALB 상태 확인으로 서비스 상태를 검증하여 롤링 업데이트를 오케스트레이션합니다.
수정 후, Amazon Inspector를 다시 실행하여 결과가 해결되었는지 확인하고, SSM Compliance 보고를 업데이트하며, SNS를 통해 보안팀에 요약을 보냅니다. 반복 가능한 플릿 전체 대응을 위해 Systems Manager Automation 라이브러리에 Automation 실행서를 보관합니다.

근거: 이 접근 방식은 지속적인 탐지를 위해 Amazon Inspector를, 통제되고 자동화된 수정을 위해 Systems Manager Patch Manager 및 Automation을, 그리고 불변 인프라(immutable infrastructure)를 위해 이미지 기반 재구축을 사용함으로써 탐지, 자동 대응 및 최소한의 영향 반경(blast radius)에 대한 AWS 모범 사례와 일치합니다.

# Example: focused baseline for an urgent CVE
Name: emergency-openssl-cve
OperatingSystem: AMAZON_LINUX_2
ApprovalRules:
  PatchRules:
    - PatchFilterGroup:
        PatchFilters:
          - Key: PRODUCT
            Values: [AmazonLinux2]
          - Key: CVE_ID
            Values: [CVE-2024-XXXXX]
      ApproveAfterDays: 0
      ComplianceLevel: CRITICAL

중앙 집중식 규정 준수는 Systems Manager Explorer에서 위임된 관리자 계정을 구성하고 **리소스 데이터 동기화(resource data sync)**를 활성화하여 모든 계정의 패치 규정 준수 상태를 단일 S3 버킷으로 집계함으로써 활성화됩니다. 이 데이터는 Athena로 쿼리하거나 QuickSight에서 시각화할 수 있습니다.

감사 가능한 관리를 위한 Session Manager

전통적인 SSH 기반 액세스에는 세 가지 구조적 약점이 있습니다. 운영자의 노트북에 장기 수명의 키 자료가 있고, (배스천을 통해서만이라도) 22번 포트에 연결할 수 있어야 하며, 추가 도구 없이는 셸 활동이 중앙에서 기록되지 않습니다. Session Manager는 이 세 가지를 모두 제거합니다.

Session Manager는 SSM Agent의 아웃바운드 HTTPS 연결을 통해 SSM 엔드포인트로 대화형 셸을 터널링합니다. 인바운드 포트, SSH 키 페어, 배스천 호스트가 없습니다. 액세스는 IAM 정책(ssm:StartSession을 인스턴스 태그 또는 ARN으로 범위 지정)에 의해 승인되며, 모든 세션은 선택적으로 KMS 암호화를 사용하여 CloudWatch Logs 또는 S3에 기록될 수 있습니다. Linux에서 세션은 기본적으로 ssm-user로 실행되며, sudo 동작은 IAM이 아닌 인스턴스의 sudoers 구성에 의해 제어됩니다.

새로운 플릿에 대한 올바른 강화 패턴은 다음과 같습니다. EC2 키 페어 없이 인스턴스를 시작하고, AmazonSSMManagedInstanceCore가 포함된 인스턴스 프로파일을 연결하고, 인스턴스를 ssm, ssmmessages, ec2messages용 VPC 엔드포인트가 있는 프라이빗 서브넷에 배치하고, Session Manager 기본 설정 수준에서 세션 로깅을 강제하는 것입니다. Session Manager와 함께 SSH 키를 계속 배포하는 것은 함정입니다. 이는 Session Manager를 도입하여 제거하려 했던 바로 그 공격 표면을 그대로 유지하며, 기록되지 않는 액세스 채널을 남겨둡니다. AMI 생성 프로세스에서 authorized_keys 프로비저닝을 제거하십시오.

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

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