
AWS
299+ 무료 연습 문제 (AI 검증 답안 포함)
AI 기반
모든 AWS Certified Security - Specialty (SCS-C02) 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
결제 마이크로서비스용 AWS CloudFormation 템플릿을 검토하던 중, 보안 엔지니어는 PaymentApiToken이라는 이름의 파라미터가 기본값으로 프로덕션 API 토큰을 plaintext로 노출하고 있음을 발견했다. 해당 토큰은 템플릿 전반에서 12번 참조되고 있으며(Lambda environment variables, API Gateway headers, ECS task definition), 엔지니어는 템플릿에서 plaintext를 제거하고, 스택 작업 중 12개 모든 위치에서 값을 참조할 수 있는 기능을 유지하며, secret이 at rest에서 암호화되고 stack events 또는 logs에 절대 나타나지 않도록 보장해야 한다. 또한 60일마다 자동 rotation을 지원해야 한다. 다음 중 이러한 요구사항을 가장 안전한 방식으로 충족하는 솔루션은 무엇인가?
Systems Manager Parameter Store SecureString은 저장 시 KMS 기반 암호화를 제공하며, ssm-secure dynamic reference 구문을 사용해 CloudFormation에서 참조할 수 있습니다. 그러나 Parameter Store는 관리형 secret rotation을 위한 주된 AWS 서비스가 아니며, 60일마다 자동 rotation을 구현하려면 기본 제공 workflow가 아니라 custom automation이 필요합니다. 문제에서 명시적으로 자동 rotation을 요구하고 가장 안전한 솔루션을 묻고 있으므로, Secrets Manager가 더 적합합니다. Parameter Store는 암호화된 configuration 값을 저장하는 데는 적절하지만, 전체 secret lifecycle management 측면에서는 덜 완전합니다.
AWS Secrets Manager는 API token과 같은 secret을 저장하고 관리하도록 특별히 설계된 AWS 서비스입니다. 이 서비스는 AWS KMS를 사용해 저장 시 secret을 암호화하고, 기본 제공 자동 rotation을 지원하므로 token을 60일마다 rotation해야 한다는 요구 사항을 직접 충족합니다. Secrets Manager에 대한 CloudFormation dynamic reference를 사용하면 template에 plaintext로 하드코딩하지 않고도 동일한 secret 값을 여러 속성에서 재사용할 수 있습니다. 이 선택지는 관리형 secret 저장, access control, auditing, rotation을 하나의 서비스에서 결합하므로 보기 중 가장 안전하고 운영적으로도 가장 적절한 옵션입니다.
Amazon DynamoDB는 template 속성에서 secret을 가져오기 위한 CloudFormation dynamic reference source로 지원되지 않습니다. DynamoDB는 저장 시 데이터를 암호화할 수 있지만, 관리형 secret 저장소가 아니라 범용 NoSQL database이므로 기본 제공 secret rotation, secret version staging, 또는 secret 전용 access pattern을 제공하지 않습니다. 운영 환경의 API token에 DynamoDB를 사용하는 것은 불필요한 application 및 운영 복잡성을 추가합니다. 또한 infrastructure와 application에서 사용하는 secret을 저장하고 rotation하는 AWS 모범 사례와도 맞지 않습니다.
Amazon S3는 template에서 secret을 해석하기 위한 CloudFormation dynamic reference source로 지원되지 않습니다. 객체가 SSE-S3로 암호화되어 있더라도, S3는 secret management 서비스가 아니라 object storage이므로 자격 증명과 token에 대한 기본 제공 secret rotation이나 version-stage semantics를 제공하지 않습니다. 또한 SSE-S3는 S3 관리형 key를 사용하며, Secrets Manager와 같은 secret 중심 제어 및 workflow를 제공하지 않습니다. 따라서 운영 환경의 API token을 관리하기에는 S3가 더 약하고 덜 안전한 설계 선택입니다.
핵심 개념: 이 문제는 infrastructure-as-code(CloudFormation)에서 dynamic references, at rest 암호화, 자동 rotation을 사용해 secret을 안전하게 관리하는지를 평가한다. 핵심 서비스는 AWS Secrets Manager(Secret + rotation에 특화)와 CloudFormation dynamic references(템플릿 및 stack outputs/events에서 plaintext를 피하기 위함)이다. 정답이 맞는 이유: Option B가 가장 안전한 이유는 AWS Secrets Manager가 AWS KMS로 암호화된 민감 값을 저장하도록 설계되어 있고, 템플릿에 plaintext를 포함하지 않고도 deploy/runtime 시점에 값을 조회할 수 있으며, rotation Lambda를 사용해 일정(60일) 기반의 native 자동 rotation을 지원하기 때문이다. Secrets Manager에 대한 CloudFormation dynamic references({{resolve:secretsmanager:...}})를 사용하면 템플릿 본문에 secret 값을 넣지 않고도 12개 모든 위치에서 secret을 참조할 수 있다. 올바르게 사용하면 CloudFormation이 배포 시점에 값을 resolve하고 템플릿에 plaintext를 영구 저장하지 않으므로, secret 값이 CloudFormation stack events/console output에 표시되지 않는다. 주요 AWS 기능: - KMS를 통한 Secrets Manager의 at rest 암호화(AWS-managed 또는 customer-managed keys). - 구성 가능한 간격(60일)과 rotation Lambda 통합을 통한 automatic rotation. - Secrets Manager에 대한 CloudFormation dynamic references를 사용해 parameters 및 resource properties에서 참조(예: Lambda environment variables, ECS task definition environment variables, 지원되는 경우 API Gateway integration/request parameters). - secret을 읽을 수 있는 주체를 제한하는 세분화된 IAM policies(least privilege) 및 secret access에 대한 CloudTrail auditing. 흔한 오해: SSM Parameter Store SecureString(Option A)은 암호화되어 있고 dynamic references를 지원하지만, Secrets Manager와 같은 1급(First-class) 내장 rotation 워크플로를 제공하지 않는다(rotation은 보통 custom automation이 필요). 또한 일부 팀은 “SecureString”이 자동으로 rotation과 전체 secret lifecycle management를 의미한다고 잘못 가정한다. 시험 팁: 요구사항에 “automatic rotation”과 “most secure”가 포함되면, 문제가 비용을 명시적으로 제한하거나 사용을 금지하지 않는 한 AWS Secrets Manager를 우선 선택하라. CloudFormation에서는 템플릿에서 plaintext를 피하고 코드 저장소에서의 우발적 노출을 줄이기 위해 “dynamic references”를 찾는 것이 핵심이다. secret 저장소는 항상 KMS 암호화와 least-privilege IAM과 함께 사용하라.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.


이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
글로벌 edtech 회사가 AWS Organizations에서 15개의 AWS 계정을 운영하고 있으며, 공개 또는 교차 계정 액세스를 탐지하기 위해 조직 수준에서 AWS Identity and Access Management (IAM) Access Analyzer를 활성화했습니다. 보안 팀은 새로 생성된 IAM 또는 리소스 정책이 ACTIVE Access Analyzer finding을 트리거하는 경우, IAM role trust policy를 업데이트하여 외부 principal에 대한 명시적 Deny를 추가함으로써 외부 액세스를 자동으로 교정(remediate)하고, 5분 이내에 security-ops@example.com으로 이메일 알림을 전송하는 자동화된 워크플로를 요구합니다. 이 요구 사항을 충족하기 위해 보안 엔지니어가 구현해야 하는 단계 조합은 무엇입니까? (세 개를 선택하세요.)
의도된 아키텍처에서 orchestration 구성 요소로서 올바릅니다. AWS Step Functions는 Access Analyzer finding을 검사하고, resource type에 따라 분기하며, AWS SDK integrations 또는 Lambda를 통해 필요한 remediation actions를 호출하는 데 매우 적합합니다. 또한 retries, error handling, auditability를 제공하므로 자동화된 보안 대응에 유용합니다. 옵션의 문구에서는 trust policy에 명시적 Deny를 추가한다고 되어 있지만, 올바른 remediation 패턴은 외부 access를 제거하거나 제한하도록 trust policy를 업데이트한 다음 SNS에 notification을 게시하는 것입니다.
오답입니다. AWS Batch는 큐잉된, 컴퓨팅 집약적이며 더 오래 실행되는 작업을 위해 설계되었고, 근실시간 보안 remediation에는 불필요한 인프라와 지연을 유발합니다. finding을 Batch를 통해 Lambda로 전달하는 것은 EventBridge에서 Step Functions/Lambda로 직접 통합하는 방식에 비해 안티패턴입니다. 또한 교차 계정 작업을 복잡하게 만들고 5분 알림 SLA를 더 비결정적으로 만듭니다.
정답입니다. Amazon EventBridge는 IAM Access Analyzer finding events를 수신하고 status가 ACTIVE인 findings를 필터링하기에 적절한 서비스입니다. Step Functions state machine을 직접 호출할 수 있으므로 polling이나 custom event ingestion 없이 near-real-time remediation이 가능합니다. 이는 조직 전체의 security findings에 대한 표준 AWS event-driven automation 패턴입니다.
오답입니다. CloudWatch metric filter는 CloudWatch Logs의 로그 이벤트에서 동작하며, IAM Access Analyzer finding을 1급 이벤트로 처리하지 않습니다. 설령 finding이 어딘가에 로깅되더라도, metric filter로 AWS Batch를 트리거하는 방식은 간접적이고 취약합니다. EventBridge가 서비스 이벤트를 위한 의도된 통합 지점이며, 자동 대응을 위한 더 나은 필터링, 라우팅, 신뢰성을 제공합니다.
오답입니다. SQS는 메시지 큐이며, 자체적으로 이메일 수신자에게 “알림을 전달”하지 못합니다. 큐를 폴링한 뒤 SNS/SES로 이메일을 보내는 consumer(Lambda/EC2)가 필요해 복잡성과 지연 가능성이 증가합니다. SQS는 버퍼링에 유용할 수 있지만, 여기서는 필요하지 않으며 이메일 요구 사항을 직접 충족하지도 못합니다.
정답입니다. Amazon SNS는 운영 팀에 email notifications를 보내기 위한 AWS의 기본 서비스입니다. SNS topic을 생성하고 security-ops@example.com을 구독시키면 workflow는 remediation 직후 보안 팀에 즉시 알릴 수 있습니다. SNS는 Step Functions와 깔끔하게 통합되며, 요구되는 5분 미만 notification 목표를 지원합니다.
핵심 개념: 이 문제는 IAM Access Analyzer findings에 대해 event-driven 방식의 조직 전체 자동 대응을 구축하는 것에 관한 것입니다. 요구되는 패턴은 near real time으로 ACTIVE findings를 탐지하고, 영향을 받은 policy를 수정하기 위한 orchestration workflow를 호출한 다음, email notification을 보내는 것입니다. 가장 적합한 AWS 서비스는 Access Analyzer events를 라우팅하는 Amazon EventBridge, workflow orchestration을 위한 AWS Step Functions, 그리고 email 전송을 위한 Amazon SNS입니다. 정답인 이유: EventBridge는 finding이 ACTIVE 상태가 될 때 IAM Access Analyzer finding events를 매칭하고 Step Functions workflow를 트리거할 수 있습니다. Step Functions는 finding 세부 정보를 검사하고 AWS APIs 또는 Lambda functions를 호출하여 영향을 받은 policy를 수정할 수 있습니다. 예를 들어, 외부 access를 제거하거나 제한하도록 IAM role trust policy를 업데이트할 수 있습니다. 그런 다음 SNS는 필요한 시간 창 내에 security-ops@example.com으로 필요한 email notification을 전송합니다. 주요 AWS 기능: 1) IAM Access Analyzer는 EventBridge와 통합되므로 polling 없이 findings가 automation을 트리거할 수 있습니다. 2) EventBridge는 ACTIVE와 같은 finding status에 대한 event pattern matching을 지원하며 Step Functions를 직접 호출할 수 있습니다. 3) Step Functions는 여러 account에 걸친 policy remediation workflows를 위해 branching, retries, 그리고 service integrations를 제공합니다. 4) SNS는 email subscriptions를 지원하며 운영 알림을 위한 표준 AWS-native 서비스입니다. 흔한 오해: CloudWatch metric filters는 log 기반 pattern matching용이지, Access Analyzer findings를 직접 소비하기 위한 것이 아닙니다. AWS Batch는 batch compute workloads를 위한 서비스이며 security findings에 대한 적절한 near-real-time trigger 또는 orchestration 메커니즘이 아닙니다. SQS는 consumer 분리에 유용하지만 자체적으로 email notifications를 보내지는 않습니다. 시험 팁: AWS 보안 automation 문제에서는 service-generated findings의 trigger로 EventBridge, remediation logic으로 Step Functions 또는 Lambda, 그리고 email notifications용으로 SNS를 찾으세요. IAM policy semantics에도 주의하세요. trust policies는 일반적으로 Allow statements를 통해 assumption을 허용하며, 보통 Deny statements를 추가하기보다는 해당 Allow를 제거하거나 더 엄격하게 제한하는 방식으로 수정합니다.
한 미디어 분석 회사가 Application Load Balancer 뒤에서 Amazon EC2 인스턴스에서 지연 시간에 민감한 ingestion API를 실행하고 있습니다. 인스턴스는 최소 6개와 원하는 용량 9개로 구성된 Auto Scaling group에 있으며, 동일한 VPC 내의 세 개의 private subnet에 분산되어 있고 해당 VPC에는 다른 워크로드도 호스팅되고 있습니다. 보안 팀은 동일한 AWS Region에서 Amazon GuardDuty detector를 활성화하고, findings를 AWS Security Hub와 통합했습니다. 팀은 비정상적인 egress 트래픽 급증(예: GuardDuty finding type Behavior:EC2/TrafficVolumeUnusual, severity >= 5)을 감지하고, 애플리케이션 및 subnet 내의 관련 없는 리소스에 대한 영향을 최소화하면서 AWS 모범 사례를 따르는 초기 격리 조치를 즉시 수행하는 자동화된 대응을 구현해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?
instance profile을 제거하거나 취소하는 것은 비정상적인 egress traffic volume에 대한 GuardDuty finding에 대해 가장 효과적인 첫 번째 격리 단계가 아닙니다. 의심스러운 트래픽은 malware, 손상된 애플리케이션 프로세스 또는 instance profile credentials에 전혀 의존하지 않는 data exfiltration으로 인해 발생할 수 있습니다. 또한 실행 중인 EC2 인스턴스에서 IAM role을 변경하거나 제거하는 것은 직접적인 network isolation 메커니즘이 아니며 outbound connections를 즉시 중단시키지 못할 수 있습니다. 이러한 유형의 finding에 대한 AWS 모범 사례는 먼저 credentials에 집중하기보다 인스턴스의 network access를 격리하는 것입니다.
이것이 모범 사례 격리 패턴인 이유는 GuardDuty findings를 트리거로 사용하고, EventBridge를 거의 실시간 라우팅에 사용하며, Lambda를 자동화된 remediation에 사용하기 때문입니다. 인스턴스를 Auto Scaling Standby로 전환하거나 다른 방식으로 서비스에서 제외하면, 즉시 종료하는 대신 forensic analysis를 위해 인스턴스를 보존하면서 production traffic을 받지 않도록 할 수 있습니다. quarantine security group을 적용하면 영향을 받은 인스턴스만 인스턴스 수준에서 격리할 수 있으며, 이는 subnet 전체 제어를 변경하는 것보다 훨씬 더 정밀합니다. 이 접근 방식은 blast radius를 최소화하고, Auto Scaling group이 애플리케이션 용량을 유지할 수 있게 하며, EC2 compromise containment에 대한 AWS incident response guidance와도 일치합니다.
세 개의 private subnet 모두에 대해 network ACLs를 변경하면 불필요하게 큰 blast radius가 발생합니다. NACLs는 의심스러운 인스턴스만이 아니라 해당 subnet의 모든 리소스에 적용되기 때문입니다. 이는 동일한 VPC와 subnet에서 호스팅되는 관련 없는 워크로드를 중단시킬 수 있으며, 애플리케이션과 다른 리소스에 대한 영향을 최소화해야 한다는 요구 사항과 직접적으로 충돌합니다. 또한 NACLs는 stateless이므로, 정밀한 deny rules를 구현하고 유지 관리하는 것은 quarantine security group을 사용하는 것보다 오류가 발생하기 쉽습니다. GuardDuty EC2 findings의 경우 AWS는 일반적으로 광범위한 subnet 수준 network 변경보다 대상이 명확한 인스턴스 격리를 선호합니다.
GuardDuty findings를 email notification용 SNS topic으로 보내는 것은 alerting은 제공하지만 자동화된 containment는 수행하지 않습니다. 문제는 즉각적인 초기 대응 조치를 명시적으로 요구하므로, 보안 팀의 수동 triage는 너무 느리며 자동화 요구 사항을 충족하지 못합니다. 이 옵션은 또한 의심스러운 egress traffic을 줄이거나 잠재적으로 손상된 인스턴스를 격리하는 데 아무런 역할도 하지 않습니다. SNS는 자동화된 워크플로를 보완할 수는 있지만, 그 자체만으로는 incident containment에 충분하지 않습니다.
핵심 개념: 이 문제는 GuardDuty findings에 대한 자동화된 incident response를 테스트하며, 빠르고 표적화되어 있고 blast radius를 최소화하는 격리 조치에 초점을 둡니다. 핵심 서비스는 Amazon GuardDuty(탐지), Amazon EventBridge(findings 라우팅), AWS Lambda(자동화), Auto Scaling(인스턴스 라이프사이클 제어), security groups(인스턴스 수준 네트워크 격리)입니다. 정답이 맞는 이유: 옵션 B는 공유 네트워크 제어를 변경하는 대신 의심되는 EC2 인스턴스만 격리함으로써 AWS 권장 초기 격리를 구현합니다. EventBridge rule은 GuardDuty findings(예: findingType = Behavior:EC2/TrafficVolumeUnusual 및 severity >= 5)를 매칭하고 Lambda function을 호출할 수 있습니다. function은 finding에서 instance ID를 식별한 다음 (1) load balancer에서 detach하거나 Auto Scaling Standby로 전환하여 트래픽을 처리하지 않도록 하고, (2) 승인된 조사 엔드포인트(예: forensics VPC endpoint, SSM endpoints, 또는 bastion/IR tooling)로의 트래픽을 제외하고 inbound/outbound를 차단하는 quarantine security group을 연결할 수 있습니다. 이는 잠재적인 데이터 유출 또는 C2 트래픽을 즉시 억제하면서 Auto Scaling group을 정상 상태로 유지(필요 시 대체 인스턴스 시작 가능)하고 동일한 subnet에 있는 다른 워크로드에 대한 영향을 피합니다. 주요 AWS 기능 / 모범 사례: - GuardDuty와의 EventBridge 통합은 거의 실시간의 rule 기반 자동화를 제공합니다. - Auto Scaling Standby(또는 target group에서 detach)는 인스턴스를 종료하지 않고 서비스에서 제외하여 증거를 보존합니다. - security groups는 stateful이며 인스턴스 범위로 적용되므로, subnet 전체 NACL 변경보다 blast radius가 작은 격리에 적합합니다. - Quarantine 패턴은 AWS incident response 가이드에 부합합니다: 격리, 보존, 조사, 이후 remediation. 흔한 오해: subnet(NACL) 수준에서 트래픽을 차단하거나 먼저 “credentials를 비활성화”하고 싶을 수 있습니다. 그러나 비정상 egress 볼륨은 instance profile credentials에 의존하지 않는 malware 또는 손상된 프로세스에 의해 발생할 수 있으며, subnet 수준 제어는 관련 없는 애플리케이션을 중단시킬 수 있습니다. 시험 팁: GuardDuty 자동화 대응 문제에서는 EventBridge + Lambda/SSM 자동화를 우선 고려하십시오. 광범위한 네트워크 변경(NACL/VPC route 변경)보다, 되돌리기 쉽고 포렌식 증거를 보존하며 범위를 제한하는 격리(인스턴스 수준 SG 변경, ASG 라이프사이클 조치)를 선택하십시오. 단, 문제가 명시적으로 subnet/VPC 전반 차단을 요구하는 경우는 예외입니다.
한 fintech 회사는 us-east-1 및 eu-west-1 전반에 걸쳐 12개의 AWS account를 운영하고 있으며, IMDSv1이 활성화된 VPC vpc-0f12abcd의 레거시 bastion host(EC2 instance i-0abcfed12345)에서 instance profile credential이 유출되었을 가능성을 의심하고 있습니다. 조직은 AWS CloudTrail에 대해 AWS Organizations organization trail을 활성화해 두었고, VPC Flow Logs는 Amazon CloudWatch Logs로 전달되며, Amazon GuardDuty는 delegated administrator account로 활성화되어 있고, AWS Audit Manager는 PCI evidence collection에 사용됩니다. 보안 팀은 2025-07-04 02:10–03:05 UTC 시간 구간 내에, 도난당한 temporary credential이 외부 AWS account에서 조직 환경의 어떤 resource에 접근하는 데 사용되었는지 여부를 판단해야 합니다. 이 정보를 가장 직접적으로 제공하는 솔루션은 무엇입니까?
정답입니다. GuardDuty의 InstanceCredentialExfiltration finding은 EC2 instance role credential 탈취 및 이후의 의심스러운 사용(종종 예상 네트워크 환경 외부에서의 사용)을 탐지하기 위해 특별히 설계되었습니다. GuardDuty가 organization-wide로 활성화되어 있고 delegated administrator가 있으므로, 보안 팀은 시간 구간과 region으로 finding을 빠르게 필터링하여 수동의 multi-account log correlation 없이도 의심되는 도난 credential이 사용되었는지 확인할 수 있습니다.
오답입니다. AWS Audit Manager는 PCI DSS 같은 framework에 대한 evidence(예: configuration snapshot, control mapping)를 수집하는 compliance automation 서비스입니다. near-real-time threat detection engine으로 동작하지 않으며 InstanceCredentialExfiltration 같은 GuardDuty 스타일의 보안 finding을 생성하거나 인덱싱하지 않습니다. Audit Manager report에 의존하는 것은 간접적이며, 요구된 시간 구간 내의 특정 질문에 답하기 어렵습니다.
오답입니다. CloudTrail에서 GetSessionToken을 검색하는 것은 도난당한 instance profile credential 사용을 탐지하는 신뢰할 수 있는 방법이 아닙니다. Instance profile credential은 이미 temporary STS credential이며 AWS API를 호출하는 데 직접 사용될 수 있어, 공격자가 GetSessionToken을 호출하지 않을 수 있습니다. 또한 CloudTrail은 caller identity(access key, principal)와 source IP를 기록하지만, 단순한 GetSessionToken 쿼리만으로 “외부 AWS account”를 확실히 귀속시키는 것은 보장되지 않습니다.
오답입니다. 여기서 CloudWatch Logs에는 VPC Flow Logs가 포함되어 있는데, 이는 네트워크 flow record(5-tuple metadata)이며 GetSessionToken 같은 AWS API call을 포함하지 않습니다. CloudTrail log가 CloudWatch Logs로 명시적으로 전달된 것이 아니라면(문제에 언급되지 않음) CloudWatch Logs는 STS API event 검색을 위한 올바른 데이터 소스가 아닙니다. 설령 CloudTrail이 CloudWatch에 있더라도, option C와 동일하게 GetSessionToken은 적절한 지표가 아닙니다.
핵심 개념: 이 문제는 EC2 instance profile credential 탈취에 대한 위협 탐지 및 조사, 특히 도난당한 temporary credential이 조직 외부에서 사용되었는지 판단하는 방법을 테스트합니다. 가장 관련성이 높은 서비스는 Amazon GuardDuty로, CloudTrail management event, VPC Flow Logs, DNS log를 분석하여 credential exfiltration 및 비정상 사용을 탐지합니다. 정답이 맞는 이유: GuardDuty에는 이 시나리오를 위한 목적 기반 finding type인 InstanceCredentialExfiltration이 있습니다. 이는 (IMDSv1 SSRF 또는 host compromise로 인해 노출되는 경우가 많은) EC2 instance의 IAM role credential이 탈취되었고, 이후 instance의 예상 네트워크 컨텍스트 밖에서 사용되는 등 도난을 시사하는 방식으로 사용되는지를 탐지하도록 설계되었습니다. GuardDuty가 delegated administrator로 organization-wide 활성화되어 있으므로, 지정된 시간 구간에 대해 해당 admin account에서 finding을 검토하는 것이 “도난당한 credential이 외부 AWS account에서 resource 접근에 사용되었는가?”라는 질문에 가장 직접적으로 답하는 방법입니다. GuardDuty finding에는 timestamp와 컨텍스트 상세 정보(예: CloudTrail을 통해 관측된 API call, source IP/ASN, exfiltration/비정상 사용 지표)가 포함되어, 커스텀 log correlation을 구축하지 않고도 빠르게 확인할 수 있습니다. 주요 AWS 기능 및 best practice: - GuardDuty는 CloudTrail management event를 네트워크 telemetry와 상관 분석하여 credential compromise 패턴을 탐지합니다. - delegated admin을 사용하는 organization-wide GuardDuty는 여러 account/region 전반의 finding을 중앙에서 확인할 수 있게 합니다. - IMDSv2 enforcement는 예방 통제이며, IMDSv1은 SSRF를 통한 credential theft 위험을 증가시킵니다. - CloudTrail organization trail은 forensics의 기반이지만, GuardDuty는 해당 log 위에서 더 높은 수준의 탐지 로직을 제공합니다. 흔한 오해: 자주 있는 함정은 CloudTrail에서 GetSessionToken 같은 STS call을 직접 검색해야 한다고 가정하는 것입니다. Instance profile credential은 이미 STS-issued role credential(내부적으로 AssumeRole을 통해 발급)이며, 공격자는 도난당한 AccessKeyId/SecretKey/SessionToken을 그대로 사용해 다른 AWS API를 호출하는 경우가 많아 GetSessionToken을 호출하지 않을 수 있습니다. 또 다른 오해는 Audit Manager가 보안 event를 제공할 것이라고 기대하는 것인데, Audit Manager는 incident detection이 아니라 compliance evidence를 위한 서비스입니다. Exam tip: 문제가 credential exfiltration/abuse를 판단하는 “가장 직접적인” 방법을 묻는 경우, raw log 검색보다 GuardDuty의 전용 finding type을 우선 선택하십시오. CloudTrail은 탐지 이후의 심층 forensics에 사용하되, 여러 account/region 전반에서 빠르게 확인하려면 중앙화된 GuardDuty finding이 일반적으로 최선의 첫 번째 확인 지점입니다.
온라인 리테일 마켓플레이스는 회사의 audit account에서 AWS Security Hub와 통합되는 서드파티 SaaS container vulnerability scanner를 사용합니다. 보안 팀은 이 서드파티 제품에서 severity label이 HIGH 또는 CRITICAL인 새로운 finding이 us-east-1의 Security Hub로 import될 때, 60초 이내에 remediation workflow가 자동으로 트리거되어야 하며, 어떤 서버도 관리하지 않으면서 분당 최대 500개의 finding이 몰리는 burst도 처리할 수 있도록 확장 가능해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?
정답입니다. Security Hub는 import된 finding을 동일한 Region에서 EventBridge 이벤트로 게시합니다. EventBridge rule은 “Security Hub Findings - Imported” 이벤트를 매칭하고 서드파티 제품 및 severity label HIGH/CRITICAL로 필터링할 수 있습니다. EventBridge는 수 초 내에 Lambda를 호출하며 두 서비스 모두 자동 확장되므로, 서버를 관리하지 않고도 60초 SLA와 burst 요구 사항을 충족합니다. 신뢰성을 위해 retry/DLQ 또는 destination을 추가할 수 있습니다.
오답입니다. Security Hub custom action은 주로 수동, 분석가 주도 워크플로(예: console에서 finding을 선택하고 custom action을 실행) 또는 명시적 API 호출을 위한 것입니다. 새로운 finding이 import될 때 자동으로 실행되지 않습니다. Systems Manager Automation이 remediation을 수행할 수는 있지만, 여기서의 트리거 메커니즘은 import 시 60초 이내 자동 실행 요구 사항을 충족하지 못합니다.
오답입니다. option B와 마찬가지로, Lambda를 target으로 하는 Security Hub custom action은 일반적으로 Security Hub console에서 사용자가 시작하거나(또는 명시적 custom action API 사용) 실행되며, import되는 모든 finding에 대해 자동으로 실행되지 않습니다. 따라서 Lambda 자체는 serverless이고 확장 가능하더라도, HIGH/CRITICAL finding이 import될 때 자동으로 remediation을 트리거해야 한다는 요구 사항을 충족하지 못합니다.
오답입니다. AWS Config rule은 AWS 리소스 구성과 원하는 상태에 대한 compliance를 평가하도록 설계되었으며, Security Hub로 import된 서드파티 vulnerability finding에 반응하도록 설계된 것이 아닙니다. Config 평가는 주기적이거나 구성 변경 기반일 수 있지만, Security Hub import finding을 event source로 네이티브하게 소비하지 않습니다. 이 접근은 60초 요구 사항을 놓칠 위험이 있으며 개념적으로도 맞지 않습니다.
핵심 개념: 이 문제는 AWS Security Hub finding, Amazon EventBridge(이전 CloudWatch Events), 그리고 AWS Lambda를 사용하여 서버 없이(event-driven) 거의 실시간으로 대규모 remediation을 자동화하는 것을 테스트합니다. 정답이 맞는 이유: 서드파티 finding이 Security Hub로 import되면, Security Hub는 동일한 Region(여기서는 us-east-1)에서 “Security Hub Findings - Imported”와 같은 EventBridge 이벤트를 발행합니다. EventBridge rule은 product/source와 finding severity label(HIGH/CRITICAL)을 기준으로 필터링한 뒤, remediation을 실행하는 Lambda function을 호출할 수 있습니다. EventBridge는 수 초 내에 이벤트를 전달하므로 60초 요구 사항을 충족하며, EventBridge와 Lambda는 모두 완전관리형 서비스로 자동 확장됩니다. 분당 500개 finding burst(~초당 8.3개)는 일반적인 EventBridge 및 Lambda 확장 패턴에서 충분히 처리 가능하며, 적절한 Lambda concurrency 설정을 통해 대응할 수 있습니다. 주요 AWS 기능: - EventBridge rule pattern matching: 불필요한 invocation을 피하기 위해 Security Hub event type, product name/ARN, severity label로 필터링합니다. - Serverless scaling: EventBridge는 ingestion과 routing을 확장하고, Lambda는 concurrency로 확장합니다. downstream 시스템을 보호하기 위해 reserved concurrency를 설정할 수 있으며, 복원력을 위해 DLQ(SQS) 또는 on-failure destination을 사용할 수 있습니다. - Cross-account/central account: finding이 audit account로 들어오므로, EventBridge rule과 Lambda를 해당 계정의 us-east-1에 배포하여 event source Region과 정렬할 수 있습니다. 흔한 오해: Security Hub의 custom action(option B/C)은 자동 트리거로 혼동되는 경우가 많습니다. custom action은 Security Hub console에서 분석가가 시작하는 워크플로(또는 명시적 API 호출)를 위한 것이지, import 시 자동 실행을 위한 것이 아닙니다. AWS Config rule(option D)은 리소스 구성 compliance를 평가하는 것이며, 서드파티 vulnerability scanner finding이 Security Hub로 import되는 이벤트에 60초 이내로 반응하는 메커니즘으로는 적합하지 않습니다. 시험 팁: - “Security Hub finding에 대해 자동으로 트리거”라면 “Security Hub 이벤트에 대한 EventBridge rule”을 떠올리십시오. - “서버 없음”과 “burst 처리”라면, 수동/console 기반 action보다 EventBridge + Lambda(필요 시 SQS buffering)를 선호하십시오. - 자동화는 이벤트가 생성되는 Region(us-east-1)과 항상 정렬하십시오.
세 개의 Region(us-east-1, us-west-2, eu-west-1)에 걸쳐 AWS Organizations 조직 내 75개의 AWS 계정을 보유한 글로벌 핀테크 기업이, 조직 내 모든 계정에서 발생하는 보안 및 네트워크 이벤트, 해당 계정들에 배포된 모든 AWS Marketplace 파트너 도구의 이벤트, 그리고 온프레미스 데이터 센터 시스템( syslog를 전송하는 1,200대의 Linux 서버와 30대의 방화벽)에서 발생하는 이벤트를 집계하고 정규화할 수 있는 중앙집중식 솔루션이 필요합니다. 또한 데이터를 400일 동안 보관하고, 분석가가 임의의 SQL 쿼리를 실행할 수 있어야 합니다. 어떤 솔루션이 이러한 요구 사항을 가장 효과적으로 충족합니까?
S3 + Glue + Athena는 로그를 중앙화하고 쿼리할 수 있으며, 자체 구축 로그 lake 패턴으로는 유효합니다. 그러나 많은 AWS Marketplace 파트너 도구나 온프레미스 syslog/방화벽 소스 전반에서 이벤트를 본질적으로 정규화하지는 못하며, 각 소스별로 사용자 지정 수집, 파싱, 스키마 매핑을 구축하고 유지관리해야 합니다. 또한 기본 제공 OCSF 정규화를 제공하지 않으므로, 이 규모의 대형 핀테크 환경에서는 효과성이 떨어집니다.
CloudWatch Logs subscription filter를 OpenSearch로 전달하는 방식은 준실시간 검색과 대시보드를 지원하지만, 75개 계정과 온프레미스 로그까지 포함해 400일 보관을 수행하기에는 일반적으로 비용이 높고 운영 부담이 큽니다. OpenSearch는 저비용 장기 보관보다는 인덱싱된 검색에 최적화되어 있습니다. 또한 여러 파트너 도구 및 사용자 지정 소스에서 오는 이질적인 보안/네트워크 이벤트를 일관된 SQL 분석을 위한 공통 스키마로 자동 정규화하지도 않습니다.
Security Lake는 중앙집중식 다중 계정/다중 Region 보안 data lake를 위해 목적에 맞게 설계되었습니다. AWS Organizations에서 delegated administrator를 사용하면 모든 계정/Region 전반의 수집을 활성화하고, S3에 데이터를 저장하며, OCSF로 정규화할 수 있습니다. AWS 소스, AWS Marketplace 파트너 통합, 그리고 사용자 지정 소스(온프레미스 syslog/방화벽 이벤트 포함)를 지원하며, S3 lifecycle policy를 통해 장기 보관 요구 사항을 충족하면서 Athena로 임의의 SQL 쿼리 분석을 수행하도록 설계되었습니다.
SCP는 API 작업을 deny 또는 allow할 수는 있지만, 모든 서비스와 계정 전반에서 특정 S3 bucket으로 로그를 전달하도록 “강제”할 수는 없으며, 구성은 여전히 서비스별로 구현되어야 합니다. 또한 OpenSearch는 S3 로그 파일에 대한 직접적인 SQL 쿼리 엔진이 아니며(이 경우 Athena가 적합), 이 옵션은 AWS Marketplace 도구 및 온프레미스 소스 전반의 정규화 요구 사항도 다루지 않습니다. 기술적으로 부정확하고 요구 사항을 충족하기에 불완전합니다.
핵심 개념: 이 문제는 관리형 data lake 접근 방식을 사용하여 탐지 및 헌팅을 위해 중앙집중식으로 다중 계정/다중 Region 보안 데이터를 집계하고 정규화하는 능력을 평가합니다. 핵심 서비스는 Amazon Security Lake(조직 전체 수집 및 OCSF로 정규화), Amazon S3 기반 보관, 그리고 임의의 SQL 쿼리를 위한 Amazon Athena입니다. 정답인 이유: 옵션 C는 모든 요구 사항과 직접적으로 일치합니다. (1) delegated administrator를 사용하는 AWS Organizations를 통해 75개 계정과 3개 Region 전반의 보안 및 네트워크 이벤트를 집계합니다. (2) 서로 다른 보안 텔레메트리를 표준화하도록 명시적으로 설계된 Open Cybersecurity Schema Framework(OCSF)로 데이터를 정규화합니다. (3) Security Lake의 custom source 메커니즘을 통해 AWS 소스, AWS Marketplace 파트너 통합, 그리고 사용자 지정 소스(온프레미스 syslog/방화벽 로그 포함)로부터의 수집을 지원합니다. (4) 400일 보관 요구 사항을 충족하도록 구성 가능한 lifecycle/retention을 갖춘 S3 백엔드 data lake에 데이터를 저장합니다. (5) 정규화된 OCSF 테이블에 대해 Athena를 사용하여 분석가가 임의의 SQL 쿼리를 실행할 수 있습니다. 주요 AWS 기능 / 모범 사례: Security Lake는 조직 수준의 활성화, cross-account 데이터 액세스 패턴, 그리고 일관된 스키마(OCSF)를 제공하여 도구별 파싱 부담을 줄입니다. 각 로그 유형마다 ETL 파이프라인을 수동으로 구축하고 유지관리할 필요 없이 데이터를 중앙화합니다. 보관은 S3 lifecycle policy(예: 비용 최적화를 위해 S3 Glacier Instant Retrieval/Flexible Retrieval로 전환하면서 400일 보관 충족)로 처리합니다. Athena는 Security Lake 데이터의 네이티브 쿼리 엔진이며, 서버리스 및 쿼리당 과금 분석과 잘 부합합니다. 흔한 오해: A는 S3 + Glue + Athena가 흔한 로그 data lake 패턴이어서 매력적으로 보이지만, 상당한 사용자 지정 ETL과 스키마 관리 없이는 AWS Marketplace 파트너 도구 및 온프레미스 소스 전반에 걸친 “정규화” 요구 사항을 충족하지 못합니다. 이는 자체 구축 SIEM data lake에 가깝습니다. B는 전형적인 OpenSearch 스트리밍 접근 방식이지만, 대규모/비용 측면에서 400일 보관에 적합하지 않고 다양한 소스를 본질적으로 정규화하지도 않습니다. D는 SCP가 설명된 방식으로 “모든 서비스가 로그를 전달하도록 강제”할 수 없고, OpenSearch로 “S3의 파일을 쿼리”하는 것은 주요 패턴이 아니며(이 경우 Athena가 적합), 여전히 정규화가 부족하므로 부적절합니다. 시험 팁: “AWS Organizations + 계정/Region 전반 집계 + 보안 이벤트 정규화 + Athena SQL”을 보면 Amazon Security Lake와 OCSF를 떠올리십시오. 400일 이상의 장기 보관에는 hot indexing 스토어보다 lifecycle policy가 있는 S3 기반 lake를 선호하십시오. 또한 SCP는 작업을 제한하는 것이지 서비스를 구성하거나 로그 전달을 보장하는 것이 아님을 기억하십시오.
한 회사가 Application Load Balancer 뒤에서 AWS Fargate를 사용하는 Amazon ECS에서 컨테이너화된 REST API를 실행하고 있으며, Fargate task의 NGINX access log는 90일 보존 정책이 설정된 Amazon CloudWatch Logs log group으로 전송되고 있다. 어젯밤 보안 팀이 IPv4 address 203.0.113.77을 의심스러운 것으로 표시했으며, 보안 엔지니어는 최소한의 노력으로 지난 7일간의 log를 분석하여 해당 IP에서 발생한 총 요청 수와 접근한 특정 request path(예: /v1/* 및 /admin/*)를 확인해야 한다. 엔지니어는 무엇을 해야 하는가?
오답. Amazon Macie는 주로 Amazon S3에서 민감 데이터(PII, credential 등)를 발견하고 분류하도록 설계되었다(관리형 data identifier 사용). NGINX access log를 위한 log query engine이 아니며 “IP와 path별 요청 수 집계” 같은 ad hoc aggregation을 기본적으로 제공하지 않는다. 또한 log를 S3로 export하는 것은 7일 조사에 불필요한 단계와 지연을 추가한다.
“최소 노력” 관점에서 오답. CloudWatch Logs subscription filter를 OpenSearch로 보내는 방식은 near-real-time indexing 및 dashboard 구축에 유용하지만, OpenSearch domain을 provisioning/운영하고 ingestion을 구성해야 한다. 또한 추가적인 export/replay 단계 없이 기존 log의 지난 7일을 자동으로 backfill하지 않는다. 빠른 incident query에는 과도하다.
정답. CloudWatch Logs Insights는 기존 log group을 즉시 query할 수 있으며, 지난 7일로 범위를 지정하고 IP 203.0.113.77로 filter한 뒤, 필요 시 NGINX field를 parse하고 stats/count aggregation을 사용하여 총 요청 수와 접근한 request path(및 path/prefix별 count)를 반환할 수 있다. 이는 incident-response log 분석을 위한 가장 빠르고 설정이 최소인 접근 방식이다.
오답. S3로 export하고 Glue crawler를 실행한 뒤 Glue로 결과를 보는 것은 필요 이상으로 운영 작업이 많다. Glue crawler는 schema를 catalog하는 도구이며, 추가 ETL/filtering logic 없이 “IP를 포함하는 entry만 catalog”하는 것을 본질적으로 수행하지 않는다. 7일 범위에서의 단순 count 및 grouping에는 CloudWatch Logs Insights가 의도된 도구이다.
핵심 개념: 이 문제는 Amazon CloudWatch Logs Insights를 사용한 incident-response log 분석을 평가한다. log는 이미 충분한 보존 기간(90일)으로 CloudWatch Logs에 중앙화되어 있다. 요구 사항은 지난 7일을 빠르게 query하여 (1) 특정 IP에서의 요청 수를 집계하고 (2) 접근한 request path를 나열하는 것이다. 정답이 맞는 이유: CloudWatch Logs Insights는 별도의 analytics pipeline을 구축하지 않고도 CloudWatch Logs를 ad hoc 및 대화형으로 query하도록 설계되었다. 최소한의 노력으로 엔지니어는 지난 7일로 범위를 지정한 query를 실행하고, client IP 203.0.113.77로 filter하며, (필요 시) NGINX access log field를 parse한 뒤, 결과를 집계하여 총 요청 수와 request path별(또는 /v1/ 및 /admin/ 같은 path prefix별) count를 반환할 수 있다. 이는 몇 분 내에 두 가지 출력 요구 사항을 모두 충족하며, data export, 신규 infrastructure, 지속적인 ingestion 비용이 필요 없다. 주요 AWS 기능: CloudWatch Logs Insights는 time-range 선택, filtering, parsing(패턴/regex를 사용하는 parse command), aggregation(stats count() by field)을 지원한다. log group 내 여러 log stream에 걸쳐 query할 수 있으며, 보안 조사(예: 의심스러운 IP activity 식별)에 흔히 사용된다. 중앙화된 logging을 활용해 신속한 탐지/조사를 가능하게 하므로 AWS Well-Architected Security 및 Operational Excellence 원칙과도 부합한다. 흔한 오해: OpenSearch로 streaming(옵션 B)은 강력한 dashboard를 제공할 수 있지만, 일회성 7일 조사에 대해 “최소 노력”이 아니다. domain을 provisioning하고 subscription filter를 구성하며 ingestion을 기다려야 하고(또한 별도 재처리/export 없이는 지난 7일을 소급 포함하지 않는다). S3로 export한 뒤 Glue를 사용하는 것(옵션 D)도 운영 부담이 크고 반복 분석이 느리다. Macie(옵션 A)는 S3에서 민감 데이터 탐지를 위한 서비스이며, application log에서 IP/path 패턴을 query하는 용도가 아니다. 시험 팁: log가 이미 CloudWatch Logs에 있고 최근 기간에 대한 빠른 조사/집계가 목적이라면 기본 선택은 CloudWatch Logs Insights이다. 장기 분석, 복잡한 dashboard, 대규모 cross-source correlation, CloudWatch를 넘어서는 보존이 필요할 때 OpenSearch/S3+Athena/Glue를 선택하되, 즉각적이고 최소 노력의 incident triage에는 적합하지 않다.
한 온라인 교육 회사는 별도의 보안 계정에 위임된 관리자(delegated administrator)를 두고 AWS Organizations를 사용하는 멀티 계정 구조에서 120개의 AWS 계정 전반에 걸쳐 AWS Security Hub를 중앙집중화했습니다. 보안 운영 팀은 배포된 리소스(예: public S3 buckets 또는 과도하게 허용적인 security groups)가 회사 보안 기준선에서 벗어나는(drfit) 경우마다 거의 실시간에 가까운 자동화된 대응 및 수정(remediation)을 요구하며, 모든 작업은 audit account에 중앙에서 로깅되어야 합니다. 조직은 이미 production OU에 연결된 service control policies (SCPs)의 최대 개수와 최대 SCP policy size에 도달했으며, 팀은 기존 SCP를 어떤 것도 변경해서는 안 됩니다. 솔루션은 확장성과 비용 효율성을 최대화해야 합니다. 이러한 요구 사항을 충족하기 위해 보안 관리자가 수행해야 할 작업 조합은 무엇입니까? (세 가지 선택)
정답입니다. AWS Config는 S3 bucket 및 security group과 같은 리소스의 configuration drift와 compliance violation을 탐지하기 위한 AWS의 기본 서비스입니다. custom rule은 조직별 baseline을 평가할 수 있으며, Lambda function은 member account로 role을 assume하여 비준수 리소스를 remediation할 수 있습니다. 이 접근 방식은 많은 계정에 걸쳐 확장 가능하며, SCP를 변경하지 않으면서도 detective control과 corrective control을 통해 security baseline을 적용해야 한다는 요구 사항에 부합합니다.
오답입니다. AWS Systems Manager Change Manager는 approval, scheduling, governance workflow를 갖춘 통제된 운영 변경을 위해 설계되었습니다. 이는 120개 계정 전반에서 configuration drift를 지속적으로 탐지하거나 security baseline violation을 거의 실시간에 가까운 수준으로 자동 remediation하기 위한 기본 서비스가 아닙니다. remediation에 SSM runbook을 사용할 수는 있지만, detection 및 eventing 요구 사항은 AWS Config, Security Hub, EventBridge가 더 잘 충족합니다.
오답입니다. Security Hub custom action은 주로 analyst가 Security Hub console에서 수동으로 downstream workflow를 트리거할 수 있게 하는 데 사용됩니다. 자동 remediation에는 필요하지 않은데, EventBridge가 analyst의 상호작용 없이도 Security Hub finding에 직접 반응할 수 있기 때문입니다. custom action을 포함하면 자동 응답이라는 명시된 요구 사항에 대해 확장성이나 비용 효율성을 개선하지 못하는 추가적인 수동 지향 구성 요소만 더하게 됩니다.
정답입니다. Amazon EventBridge는 AWS Security Hub finding과 일치하도록 매칭하고 Lambda function을 호출하여 거의 실시간에 가까운 자동 remediation을 수행할 수 있습니다. 이는 특히 Security Hub가 이미 delegated administrator를 통해 집계되고 있는 경우, multi-account 환경에서 중앙 집중식 security operation을 위한 표준 event-driven architecture입니다. 이 방식은 확장 가능하고 비용 효율적이며, remediation workflow가 audit 목적을 위해 모든 action을 로깅할 수 있으므로 중앙 집중식 운영 가시성을 지원합니다.
오답입니다. Lambda를 사용해 API request를 검사하고 custom finding을 생성하는 것은 기본 AWS compliance 및 security 서비스를 맞춤형 솔루션으로 대체하는 것입니다. API request inspection은 일반적으로 CloudTrail event를 기반으로 하며, drift detection에서 중요한 현재 configuration state를 신뢰성 있게 나타내지 못합니다. 이 옵션은 public bucket이나 과도하게 허용적인 security group을 탐지하는 데 AWS Config + Security Hub를 사용하는 것보다 확장성이 낮고 운영적으로 더 복잡하며 열등합니다.
정답입니다. 일부 AWS Config rule은 configuration change에 의해 직접 트리거되지 않고 periodic 방식이므로, 스케줄된 EventBridge rule을 사용해 선택된 Config rule의 evaluation을 호출하여 지속적인 compliance coverage를 보장할 수 있습니다. 이는 그렇지 않으면 모든 resource change마다 즉시 평가되지 않는 rule 유형을 보완함으로써 거의 실시간 탐지를 보강합니다. custom inspection framework를 구축하는 것보다 더 확장 가능하고 비용 효율적이며, 대규모 조직 전반에서 광범위한 baseline enforcement를 유지하는 데 도움이 됩니다.
핵심 개념: 요구 사항은 120개의 AWS 계정 전반에서 security baseline drift를 탐지하고 SCP를 수정하지 않으면서 거의 실시간에 가까운 자동 remediation을 트리거하는 것입니다. AWS에서 가장 확장 가능한 패턴은 AWS Config를 사용해 resource compliance를 평가하고, 결과를 AWS Security Hub에 중앙 집중화한 다음, Amazon EventBridge를 사용해 AWS Lambda와 같은 remediation logic을 호출하는 것입니다. 일부 AWS Config rule은 configuration change trigger 방식이 아니라 periodic 방식이므로, 광범위한 baseline coverage가 필요한 경우 선택된 rule에 대한 evaluation을 스케줄링하는 것이 완전한 솔루션의 일부가 될 수 있습니다. 정답인 이유: AWS Config는 S3 bucket 및 security group과 같은 리소스에 대한 configuration compliance 및 drift detection을 위한 기본 서비스입니다. Security Hub는 delegated administrator account를 통해 조직 전체의 finding을 집계하며, EventBridge는 이러한 finding에 거의 실시간으로 반응하여 Lambda 기반 remediation을 호출할 수 있습니다. 스케줄된 EventBridge rule은 지속적으로 실행되지 않는 특정 Config rule의 evaluation을 트리거하는 데 사용할 수 있어, 운영 효율성을 유지하면서도 포괄적인 coverage를 보장합니다. 주요 기능: AWS Config는 compliance evaluation을 위해 managed rule과 custom rule을 지원하며, 여기에는 조직 전체 배포 패턴도 포함됩니다. Security Hub는 member account의 finding을 delegated administrator account로 통합합니다. EventBridge는 Security Hub finding에 대한 event pattern matching을 지원하며 자동 remediation을 위해 Lambda를 호출할 수 있습니다. remediation action의 중앙 로깅은 Lambda가 log를 출력하도록 하고 audit account에서 조직 전체 audit logging을 사용함으로써 달성할 수 있습니다. 흔한 오해: Security Hub custom action은 종종 자동 remediation trigger와 혼동되지만, 이는 자율적인 event-driven response가 아니라 console에서 analyst가 시작하는 action을 위한 것입니다. Systems Manager Change Manager는 governance 및 approval을 위한 것이지 지속적인 drift detection을 위한 것이 아닙니다. Lambda로 custom API inspection pipeline을 구축하는 것은 configuration-state compliance를 위해 Config와 Security Hub를 사용하는 것보다 더 복잡하고 신뢰성이 낮습니다. 시험 팁: security baseline으로부터의 drift에 대한 문제에서는 custom event inspection보다 AWS Config를 우선 고려하세요. 거의 실시간에 가까운 자동 대응이 필요하다면, Security Hub 또는 Config finding에 의해 트리거되는 EventBridge + Lambda 또는 SSM Automation을 찾으세요. SCP를 변경할 수 없다면, 정답은 일반적으로 preventive guardrail보다 detective control과 자동 remediation 쪽으로 이동합니다.
한 핀테크 회사는 분당 18,000개의 로그 이벤트를 Amazon CloudWatch Logs의 /prod/recon이라는 이름의 로그 그룹에 기록하며 보존 기간은 30일이고, 로그에는 고객 이메일 주소가 포함되어 있다. 12명의 개발자는 애플리케이션을 수정하거나 중복된 정제(sanitized) 로그 그룹을 생성하지 않고도 모든 로그 스트림 전반에서 문제 해결을 위해 CloudWatch Logs 콘솔과 API를 사용해야 한다. 또한 보안 엔지니어는 다른 모든 필드는 계속 표시되도록 하면서 개발자가 어떤 이메일 주소도 볼 수 없도록 보장해야 한다. 어떤 솔루션이 이 요구 사항을 충족하는가?
Amazon Macie는 주로 Amazon S3에서 민감 데이터를 발견하고 분류하며(그리고 findings/alerts를 지원), 개발자가 로그 이벤트의 나머지 부분은 보되 이메일 주소는 보지 못하도록 CloudWatch Logs에서 인플레이스(in-place)로 마스킹/리댁션을 제공하지 않는다. Macie는 이메일이 존재함을 식별할 수는 있지만 CloudWatch Logs 콘솔/API에서 “개발자는 이메일을 볼 수 없음”을 강제하지는 못한다.
customer managed KMS key로 로그 그룹을 암호화하고 개발자 액세스를 거부하면 개발자는 로그를 복호화하고 읽을 수 없게 된다. 요구 사항은 선택적 보호로, 개발자는 문제 해결을 위해 다른 모든 필드는 보되 이메일 주소만 보지 못해야 한다. KMS key policy와 grants는 로그 이벤트 내 필드 수준 redaction을 지원하지 않으며, 암호화된 데이터 전체에 대한 액세스를 제어한다.
Lambda로 보내는 subscription filter는 이메일을 파싱해 마스킹할 수 있지만, 다른 목적지(대개 다른 로그 그룹, S3, 또는 OpenSearch)로 전달해야 한다. 이는 사실상 중복된 sanitized 사본을 만드는 것이며, 문제에서 명시적으로 금지한다. 또한 높은 수집률(분당 18,000 이벤트)에서 운영 오버헤드와 비용을 증가시키고, 네이티브 CloudWatch Logs 기능 대비 장애 지점/지연을 추가한다.
CloudWatch Logs data protection policy는 managed data identifier(예: EmailAddress)를 사용해 민감 데이터를 탐지하고 마스킹과 같은 조치를 적용하도록 설계되어 있다. /prod/recon에 policy를 적용하면 개발자는 모든 스트림에서 CloudWatch Logs 콘솔과 API를 계속 사용하면서도 이메일 주소는 redacted되고 다른 필드는 계속 표시된다. 이는 애플리케이션 변경 없음, 중복 sanitized 로그 그룹 없음, 강제된 PII 보호라는 모든 제약을 충족한다.
핵심 개념: 이 문제는 Amazon CloudWatch Logs data protection(민감 데이터 보호)과 애플리케이션을 변경하거나 로그 목적지를 중복 생성하지 않고도 로그 조회/쿼리 시 PII 노출을 방지하는 방법을 테스트한다. 또한 최소 권한(least-privilege)과 운영상 문제 해결 요구 사항도 다룬다. 정답이 맞는 이유: CloudWatch Logs data protection policy는 민감 데이터 패턴을 자동으로 탐지(AWS managed data identifier인 EmailAddress 등 사용)하고 마스킹과 같은 조치를 적용할 수 있다. /prod/recon 로그 그룹에서 이를 활성화하면 개발자는 CloudWatch Logs 콘솔과 API를 계속 사용하여 모든 로그 스트림에서 문제 해결을 수행할 수 있지만, 이메일 주소는 가려지고 각 로그 이벤트의 나머지 부분은 그대로 표시된다. 이는 애플리케이션 변경 없음, 중복 “sanitized” 로그 그룹 없음, 개발자가 이메일 주소를 볼 수 없어야 함이라는 요구 사항을 직접 충족한다. 주요 AWS 기능: 1) CloudWatch Logs data protection policy: 로그 그룹 수준에서 연결(attached)된다. 2) Managed data identifiers: AWS는 일반적인 PII를 탐지하기 위한 내장 식별자(예: EmailAddress)를 제공한다. 3) Masking/redaction: 비민감 필드를 그대로 유지하여 로그 활용성을 보존한다. 4) 운영 단순성: 기존 로그 그룹에서 인플레이스(in-place)로 동작하며 문제 해결에 사용되는 콘솔/API 액세스 패턴을 지원한다. 흔한 오해: A) Macie는 Amazon S3(및 일부 다른 데이터 스토어)에서의 발견/분류를 위한 서비스이며, CloudWatch Logs 조회 시 실시간 마스킹을 제공하지 않는다. 민감 데이터 존재를 찾을 수는 있지만 Logs 콘솔에서의 redaction을 강제하지는 못한다. B) KMS 암호화는 로그 그룹 전체에 대한 복호화 접근을 제어하며, 다른 필드는 허용하면서 이메일 주소만 선택적으로 숨길 수는 없다. KMS decrypt를 거부하면 개발자가 어떤 로그도 읽을 수 없게 되어 문제 해결 요구 사항을 위반한다. C) subscription filter + Lambda는 마스킹 후 전달할 수 있지만, 새로운 sanitized 목적지를 만들게 되어(사실상 로그를 복제) 비용/복잡성이 증가하며 분당 18,000 이벤트에서 부담이 크다. 또한 중복 sanitized 로그 그룹을 만들지 말라는 제약을 충족하지 못한다. 시험 팁: “애플리케이션 변경 없이 CloudWatch Logs에서 PII를 마스킹” 및 “개발자는 계속 문제 해결을 해야 함”을 보면, managed data identifiers와 masking을 사용하는 CloudWatch Logs data protection policy를 선택하라. KMS는 복호화가 올-오어-낫싱(all-or-nothing)이며, Macie는 발견/분류이지 콘솔 내 redaction 강제가 아니다.
한 미디어 분석 스타트업은 AWS Batch(EC2 compute environment)에서 비디오 트랜스코딩 작업을 실행하며, Amazon Elastic Container Registry(Amazon ECR)에서 private container image를 가져옵니다. 현재 두 Region에 걸친 12개의 ECR repository가 기본 AES-256 encryption을 사용하고 있지만, 컴플라이언스 요구 사항에 따라 모든 repository를 customer managed AWS KMS key(alias/media-sec)로 마이그레이션하고 image push 시 CVE detection을 활성화해야 합니다. 보안 엔지니어는 어떤 repository도 unencrypted 상태로 남지 않게 하면서, 다음 image push 이후 vulnerability report를 제공하는 접근 방식을 구현해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?
오답입니다. AES-256으로 생성된 기존 ECR repository에서 단순히 “KMS encryption을 활성화”할 수는 없습니다. ECR repository encryption 설정은 생성 시 정의되며 일반적으로 CMK로 전환하도록 변경할 수 없습니다. 또한 EC2 instance에 Amazon Inspector Agent를 설치하는 것은 host vulnerability를 평가하는 것이지, ECR로 image push 시 트리거되는 container image CVE를 평가하는 것이 아니므로 “다음 image push 이후 report” 요구 사항을 충족하지 못합니다.
정답입니다. 각 Region에서 encryption을 customer managed KMS key(alias/media-sec)로 설정하여 repository를 다시 생성하면 모든 repository가 요구되는 CMK로 암호화됩니다. ECR image scanning on push를 활성화하면 다음번 image가 push될 때 ECR이 vulnerability scan을 수행하고 검토 가능한 findings를 scan report로 생성하므로, 컴플라이언스 및 탐지 요구 사항을 충족합니다.
오답입니다. CMK로 repository를 재생성하고 scanning을 활성화하는 것은 ECR 요구 사항과는 부합하지만, AWS Systems Manager(SSM) Agent를 설치하고 inventory report를 생성하는 것은 container image CVE findings를 제공하지 않습니다. SSM Inventory는 instance/software inventory 및 compliance metadata를 위한 것이지, image push 이벤트에 연동된 ECR image vulnerability scanning 결과가 아닙니다.
오답입니다. A와 마찬가지로 기존 ECR repository를 AES-256에서 CMK encryption으로 in-place로 변경할 수는 없습니다. 또한 AWS Trusted Advisor는 image push 이후 container image CVE scanning이나 vulnerability report를 제공하지 않습니다. Trusted Advisor는 비용 최적화, 성능, 내결함성, service limits, 일부 보안 점검에 초점을 두며, ECR image CVE findings를 제공하지 않습니다.
핵심 개념: 이 문제는 Amazon ECR repository 구성에서 (1) customer managed AWS KMS key(CMK)를 사용한 at rest encryption과 (2) 다음 image push 이후 findings를 생성하는 vulnerability scanning을 테스트합니다. 또한 기존 ECR repository에서 in-place로 변경할 수 있는 것과 없는 것을 간접적으로 테스트합니다. 정답이 맞는 이유: 새 컴플라이언스 규칙 하에서 “어떤 repository도 unencrypted 상태로 남지 않게” 하려면 각 repository가 지정된 CMK(alias/media-sec)를 사용하도록 구성되어야 합니다. ECR에서는 encryption 구성은 repository 생성 시점에 설정되며, 기존 repository를 AES-256(AWS owned key)에서 customer managed KMS key로 in-place로 소급 전환할 수 없습니다. 따라서 컴플라이언스를 만족하는 접근 방식은 각 Region에서 KMS encryption을 alias/media-sec로 설정하여 새 repository를 생성(또는 가능하다면 삭제 후 동일한 이름으로 재생성)하는 것입니다. 또한 “scan on push”를 활성화하면 다음번 image push 이후 ECR이 자동으로 vulnerability scan을 트리거하고 해당 push된 image에 대한 findings report를 생성합니다. 주요 AWS 기능 및 모범 사례: - ECR at rest encryption: AES-256(AWS owned) vs AWS KMS(customer managed key). CMK는 key policy 제어, rotation 옵션, AWS CloudTrail을 통한 감사 가능성을 제공합니다. - ECR image scanning: “scan on push”(basic scanning) 또는 account 설정에 따라 Amazon Inspector를 통한 enhanced scanning. 어느 쪽이든 scan on push를 활성화하면 다음 push 이후 report를 받는 요구 사항을 충족합니다. - Multi-Region: KMS key는 Regional입니다. 두 Region 모두에 alias/media-sec가 존재(또는 생성)해야 하며, ECR이 이를 사용할 수 있는 권한이 있어야 합니다. 흔한 오해: 자주 있는 함정은 일부 다른 서비스처럼 기존 ECR repository에서 “KMS encryption을 활성화”할 수 있다고 가정하는 것입니다. 또 다른 함정은 host 기반 CVE scanning(Inspector Agent/SSM inventory)과 ECR의 container image scanning을 혼동하는 것입니다. 요구 사항은 EC2 instance가 아니라 image push에 연동된 image에 대한 vulnerability report입니다. 시험 팁: “after the next image push”가 보이면 ECR “scan on push”(또는 Inspector enhanced scanning)를 떠올리십시오. “AES-256 default에서 CMK로 encryption 마이그레이션”이 보이면 해당 서비스가 in-place encryption 변경을 지원하는지 확인하십시오. ECR repository의 경우 repository 재생성과 image repush/retag를 마이그레이션의 일부로 계획해야 합니다.
미디어 분석 스타트업이 두 개의 Availability Zone에 걸친 세 개의 프라이빗 서브넷에서 100개의 Amazon EC2 인스턴스(60개 Amazon Linux 2 및 40개 Windows Server 2019)를 실행하고 있다. 인터넷 게이트웨이가 없고 인바운드 security group 규칙도 없다. 엔지니어는 TCP 22/3389를 열거나 SSH key pair를 배포하지 않고, AWS Cloud 내부에서만 원격 관리를 수행해야 한다. 또한 이 솔루션은 두 OS 유형 모두에서 대규모로 동작해야 하며, 세션 로그를 S3 bucket으로 중앙 집중식으로 로깅할 수 있어야 한다. 어떤 솔루션이 이러한 요구 사항을 충족하는가?
정답. Systems Manager Session Manager는 인바운드 포트(22/3389)를 열지 않고도 Linux 및 Windows 인스턴스 모두에 대화형 액세스를 제공하며, SSH key를 배포할 필요도 없다. 액세스는 IAM으로 제어되고, 세션 로그는 S3 bucket으로 중앙 집중화할 수 있다(선택적으로 KMS로 암호화). IGW가 없는 프라이빗 서브넷에서는 SSM 관련 서비스에 대한 VPC interface endpoint를 사용해 연결성을 확보한다.
오답. Session Manager가 올바른 원격 액세스 메커니즘이긴 하지만, SSH-RSA key pair를 생성하고 배포하는 것은 불필요하며 SSH key pair 배포를 피하라는 요구 사항을 위반한다. Session Manager는 SSH key가 전혀 필요 없다. 이 옵션은 이점 없이 운영 오버헤드와 위험(키 관리/로테이션)을 추가한다.
오답. EC2 Instance Connect는 주로 Linux 인스턴스에 대한 SSH 액세스를 위한 것이며, 여전히 22번 포트에 대한 네트워크 연결(연결 소스에서의 인바운드 허용)과 적절한 security group/NACL 규칙이 필요하다. TCP 22를 열지 말라는 요구 사항을 충족하지 못하며, S3로의 중앙 집중식 세션 로깅을 포함해 Windows Server 관리를 대규모로 수행하는 표준 통합 접근 방식도 아니다.
오답. 이 옵션은 두 가지 측면에서 맞지 않는다: SSH key를 생성/배포해야 하며(명시적으로 금지됨), EC2 Instance Connect에 의존하는데 이는 여전히 22번 포트의 SSH를 사용하고 Windows 관리에 대한 포괄적 솔루션이 아니다. 또한 Session Manager의 S3 로깅과 같은 중앙 집중식 세션 로깅/감사 모델을 본질적으로 제공하지 않는다.
핵심 개념: 이 문제는 인바운드 포트 개방 없이 프라이빗 서브넷의 EC2 인스턴스를 안전하고 확장 가능하게 원격 관리하기 위해, IAM 기반 액세스 제어와 중앙 집중식 감사 로깅을 제공하는 AWS Systems Manager (SSM) Session Manager를 사용하는지를 평가한다. 정답이 맞는 이유: 옵션 A는 모든 제약을 충족한다: 인바운드 security group 규칙 없음, Internet gateway 없음, TCP 22/3389 개방 없음, SSH key 배포 없음, Amazon Linux 2와 Windows Server 모두에서 동작, 100개 인스턴스로 확장 가능, 그리고 Amazon S3로 세션 로깅 지원. Session Manager는 SSM Agent가 아웃바운드 HTTPS(일반적으로 SSM endpoint로)로 통신하는 방식으로 대화형 shell/PowerShell 액세스를 제공한다. 인스턴스가 IGW 없는 프라이빗 서브넷에 있으므로, 연결성은 Systems Manager (ssm), EC2 Messages (ec2messages), SSM Messages (ssmmessages)를 위한 VPC interface endpoint(AWS PrivateLink)로 달성된다(또한 CloudWatch Logs를 함께 사용한다면 선택적으로 추가). 액세스는 IAM policy로 제어되며(MFA, permission boundary, 최소 권한 적용 가능), 세션 활동은 중앙 집중식 감사를 위해 S3 bucket(및/또는 CloudWatch Logs)으로 로깅할 수 있다. 주요 AWS 기능: - Session Manager: 인바운드 포트 없이 브라우저/CLI 기반 세션 제공; Linux 및 Windows 지원. - IAM 기반 권한 부여: 세밀한 제어(어떤 인스턴스, 어떤 사용자, 세션 지속 시간, 태그 기반 액세스). - 중앙 집중식 로깅: S3 로그 저장(선택적으로 SSE-KMS로 암호화), 그리고 API 감사용 CloudTrail. - 프라이빗 연결: VPC interface endpoint로 트래픽을 AWS 네트워크 내부에 유지하여 Well-Architected Security pillar(노출 최소화, 강력한 ID, 감사 가능성)와 정렬. 흔한 오해: 흔한 함정은 Linux 관리에 SSH key가 필요하거나 Windows에 RDP가 필요하다고 가정하는 것이다. Session Manager는 둘 다 제거한다. 또 다른 오해는 “internet gateway 없음”이 SSM을 막는다는 것인데, 실제로 SSM은 VPC endpoint로 프라이빗하게 동작한다. EC2 Instance Connect도 종종 “키 없이”로 혼동되지만, 여전히 SSH와 22번 포트에 대한 네트워크 도달성이 필요하며 Windows에 대한 통합 솔루션도 아니다. 시험 팁: “인바운드 규칙 없음”, “프라이빗 서브넷”, “SSH/RDP 없음”, “중앙 집중식 세션 로깅”, “Linux와 Windows에서 대규모로 동작” 같은 요구 사항이 보이면, 시험에서의 정답은 거의 항상 IAM 및 S3/CloudWatch 로깅을 갖춘 Systems Manager Session Manager이며, 프라이빗 액세스를 위한 VPC interface endpoint가 함께 제시된다.
구독형 오디오 플랫폼이 Amazon CloudFront를 통해 CMAF 세그먼트를 장시간 라이브 스트림으로 배포하고 있습니다. 각 방송은 6~10시간 동안 진행되며 약 10,800개의 2초 세그먼트를 생성하고, 이 세그먼트들은 /members/audio/ 경로 아래에 저장됩니다. 오리진은 private이며 CloudFront를 통해서만 접근 가능하고(오리진 URL은 노출되지 않음), 웹 애플리케이션은 유료 사용자를 내부 identity store로 인증합니다. 또한 CloudFront key pair가 이미 발급되어 있습니다. 세그먼트 콘텐츠에 대한 접근을 제한하는 가장 단순하고 효과적인 방법은 무엇입니까?
기능적으로는 per-object signed URL도 동작하지만 CMAF에 대해 가장 단순한 방법은 아닙니다. 6~10시간 스트림에서 약 10,800개의 세그먼트는 애플리케이션이 지속적으로 signed URL을 생성·전달해야 하고(새 세그먼트가 나타날 때마다 재서명 필요 가능), 이는 애플리케이션 복잡도를 높이고 재생 지연을 유발할 수 있으며 플레이어 로직을 복잡하게 만듭니다. Signed URL은 소수의 파일 또는 일회성 다운로드에 더 적합합니다.
Signed cookie는 /members/audio/*처럼 공통 경로 아래의 대규모 객체 집합을 보호하는 데 가장 적합합니다. 사용자가 인증된 후 앱이 기존 key pair를 사용해 CloudFront signed cookie를 설정하면, CloudFront는 cookie가 만료될 때까지 매칭되는 모든 세그먼트 및 playlist 객체에 대한 접근을 인가합니다. 이는 운영 오버헤드를 최소화하며 세그먼트/스트리밍 콘텐츠에 대한 CloudFront 권장 접근 방식과 일치합니다.
Lambda@Edge로 JWT를 검증하면 커스텀 인가 로직을 강제할 수 있지만, Lambda@Edge 배포/복제, 요청당 실행 비용/지연, 운영 복잡성 등 구성 요소가 추가됩니다. 여기서는 CloudFront가 이미 native private content 제어(signed cookie/URL)를 제공하고 오리진도 이미 CloudFront 뒤에서 private이므로 불필요합니다. signed cookie/policy로 표현할 수 있는 시간/경로/IP 기반 정책을 넘어서는 로직이 필요할 때만 Lambda@Edge를 사용하세요.
CloudFront distribution URL을 암호화하는 것은 실질적인 접근 제어가 아닙니다. 앱이 URL을 숨기거나 런타임에 복호화하더라도 클라이언트는 결국 복사·재사용 가능한 요청을 전송하게 됩니다. 이는 보안의 은폐에 불과하며, KMS는 이런 방식으로 CloudFront 요청 인가와 통합되지 않습니다. 올바른 제어는 CloudFront signed URL/cookie와 private 오리진을 통해 수행합니다.
핵심 개념: 이 문제는 인증된 사용자를 위한 CloudFront private content 제어를 테스트하며, 특히 경로 아래에 많은 객체(CMAF 세그먼트)를 보호할 때 CloudFront signed URL과 signed cookie 중 무엇을 선택해야 하는지를 묻습니다. 정답이 맞는 이유: 각 라이브 스트림은 /members/audio/ 아래에 약 10,800개의 2초 CMAF 세그먼트 객체를 생성합니다. 세그먼트마다 signed URL을 생성하고(그리고 세그먼트가 생성될 때마다 갱신) 운영하는 것은 부담이 크고, 플레이어 워크플로에 지연과 복잡성을 추가합니다. CloudFront signed cookie는 정확히 이런 사용 사례를 위해 설계되었습니다. 즉, 뷰어를 한 번 인가한 뒤, 경로 패턴에 매칭되는 여러 제한 객체(예: 모든 세그먼트와 playlist)에 대해 매 요청 URL을 서명하지 않고도 접근을 허용합니다. 애플리케이션은 유료 사용자를 identity store로 인증한 다음, 이미 발급된 CloudFront key pair를 사용해 CloudFront signed cookie(Policy, Signature, Key-Pair-Id)를 설정합니다. 이후 브라우저/플레이어는 세그먼트 파일을 일반적으로 요청하며, CloudFront는 cookie policy를 강제하여 비인가 요청을 차단합니다. 주요 AWS 기능 / 구성: - https://d123.cloudfront.net/members/audio/* 같은 리소스에 대한 접근을 제한하고 세션 길이에 맞춘 만료 시간을 갖는 커스텀 policy로 CloudFront signed cookie를 사용합니다. - 오리진을 private로 유지(예: Origin Access Control이 적용된 S3 또는 CloudFront로만 제한된 custom origin)하여 우회 접근이 불가능하게 합니다. - 필요하다면 policy에 IP 제한을 포함할 수 있습니다(모바일 사용자에게는 종종 피함). - CloudFront가 이를 검증할 수 있도록 cache behavior가 필요한 cookie를 전달하도록(또는 서명 방식에 따라 trusted key groups / trusted signers를 사용하도록) 설정합니다. 흔한 오해: Signed URL과 signed cookie 모두 CloudFront 콘텐츠를 제한하므로 signed URL이 정답처럼 보일 수 있습니다. 하지만 signed URL은 보호해야 할 객체 수가 적거나 단일 공유 링크를 배포해야 할 때 가장 적합합니다. 수천 개의 객체가 있는 세그먼트 스트리밍에서는 signed cookie가 더 단순하고 효과적입니다. 시험 팁: “HLS/DASH/CMAF 세그먼트처럼 경로 아래에 많은 객체” + “인증된 사용자” + “CloudFront key pair 이미 발급”을 보면 “signed cookie”를 떠올리세요. Lambda@Edge/JWT는 signed cookie/policy로 표현할 수 있는 범위를 넘어서는 요청별 동적 인가 결정이 필요할 때에만 고려하세요.
핀테크 스타트업의 보안 엔지니어가 확인한 결과, AWS IAM role로 SAML federation을 수행하는 데 사용되는 기업 IdP(Okta)와 고객 대상 애플리케이션을 위한 Amazon Cognito user pool 모두 최소 password length를 전혀 강제하지 않고 있습니다. AWS로 federation하는 직원 4,000명과 Cognito에 있는 고객 계정 200,000개가 있는 상황에서, 새로운 컴플라이언스 통제가 7일 이내에 모든 사용자 password에 대해 최소 12자 요구사항을 의무화했습니다. 두 identity store 전반에 걸쳐 요구되는 최소 password length를 구현하기 위해 엔지니어가 수행해야 할 조치 조합은 무엇입니까? (두 개 선택)
오답(제시된 대상 집단에 대해). IAM account password policy는 해당 AWS account의 IAM user에만 적용됩니다(IAM user의 console password). Okta에서 인증하는 SAML-federated 직원에게는 영향을 주지 않으며, Amazon Cognito user pool user에도 적용되지 않습니다. 회사에 console password를 가진 IAM user가 추가로 있는 경우에만 유용할 수 있으나, 시나리오에서는 이를 나타내지 않습니다.
정답. Cognito user pool은 고객 대상 애플리케이션의 identity store이므로, Cognito가 해당 200,000개 고객 계정에 대한 password 요구사항을 강제할 책임이 있습니다. User pool password policy를 최소 12자로 업데이트하면 Cognito가 관리하는 user에 대한 컴플라이언스 요구사항을 직접 충족하며, 애플리케이션 authorization 로직을 변경하지 않고도 빠르게 구현할 수 있습니다.
정답. Okta에서 AWS IAM role로 SAML federation을 사용하는 직원 4,000명의 경우 Okta가 인증을 수행하고 SAML assertion을 발급합니다. AWS는 직원의 password를 검증하지 않으며 그 length를 강제할 수 없습니다. 따라서 최소 password length는 Okta의 password policy에서 강제되어야 하며(이상적으로는 MFA와 함께), 기업 identity store에 대한 컴플라이언스 통제를 충족합니다.
오답. AWS Organizations의 Service Control Policy는 member account에서 principal이 수행할 수 있는 AWS API action을 제한하지만, IAM user, Cognito user 또는 외부 IdP에 대해 password length를 강제하는 메커니즘을 제공하지 않습니다. SCP는 Okta에 영향을 줄 수 없고, Cognito password policy 설정을 강제할 수도 없습니다. 기껏해야 특정 구성을 변경하지 못하게 막을 수는 있어도 password complexity를 강제하지는 못합니다.
오답. IAM policy(및 condition key)는 AWS API action과 resource에 대한 authorization을 제어할 뿐, IAM user password의 length 규칙을 검증하거나 강제하지 않으며 Cognito user pool password에도 적용할 수 없습니다. Cognito password policy는 IAM policy condition이 아니라 user pool에서 구성합니다. 마찬가지로 federated user의 password는 AWS가 아니라 IdP에서 관리합니다.
핵심 개념: 이 문제는 federated identity와 네이티브 AWS identity store에서 password policy가 실제로 어디에서 강제되는지를 테스트합니다. Okta(SAML IdP)가 직원 인증을 제어하고, Amazon Cognito user pool이 고객 인증을 제어합니다. AWS IAM password policy는 IAM user에만 적용되며(federated user에는 적용되지 않음), SCP/IAM policy는 외부 IdP 또는 Cognito password에 대해 password length 규칙을 강제할 수 없습니다. 정답이 맞는 이유: 7일 이내에 두 identity store 모두에서 최소 12자 요구사항을 충족하려면, password를 소유(관리)하는 각 시스템에서 policy를 구성해야 합니다. SAML을 통해 federation하는 직원의 경우 AWS는 Okta password를 보거나 검증하지 않으며 SAML assertion만 소비합니다. 따라서 최소 password length는 Okta의 password policy에서 강제되어야 합니다(Option C). Cognito에 대해 직접 인증하는 고객의 경우 Cognito가 password 권한(authority)이므로, user pool password policy를 업데이트하여 최소 12자를 요구해야 합니다(Option B). 주요 AWS 기능 / 구성: Amazon Cognito user pool에서는 password policy(최소 length, 복잡도 요구사항)를 구성할 수 있으며 user pool user에 적용됩니다. 기업 SAML federation의 경우 SAML trust policy가 있는 AWS IAM role은 인증을 IdP에 의존하며, AWS는 IdP의 password 규칙이 아니라 role permission을 통해 authorization을 강제합니다. 이는 최소 권한(least privilege)과 인증(IdP)과 인가(AWS)의 분리 원칙에 부합합니다. 흔한 오해: 자주 있는 함정은 AWS account IAM password policy가 “모든 AWS access”를 지배한다고 가정하는 것입니다. 이는 IAM username/password로 sign-in하는 IAM user에만 영향을 줍니다. Federated user는 외부에서 인증합니다. 또 다른 오해는 SCP 또는 IAM policy로 password length를 강제할 수 있다는 생각인데, 이들은 API action을 제한할 수는 있어도 Cognito 또는 외부 IdP의 password 내용을 검증할 수는 없습니다. 시험 팁: 항상 credential의 “source of truth”를 식별하십시오. 인증이 federated(SAML/OIDC)라면 IdP에서 password/MFA를 강제합니다. 사용자가 Cognito에 인증한다면 user pool에서 password policy를 강제합니다. IAM password policy는 IAM user에만 해당하며, SCP는 AWS API permission을 위한 guardrail이지 credential complexity control이 아닙니다.
보안 엔지니어가 Amazon EC2 인스턴스에서 애플리케이션을 트러블슈팅하고 있습니다. 이 애플리케이션은 계정 111122223333에서 WebForensicsRole이라는 이름의 인스턴스 프로파일 role을 사용하여, 세션 지속 시간 3600초로 계정 444455556666의 CorpForensicsAccessRole이라는 cross-account role에 대해 sts:AssumeRole을 호출하지만, 호출이 "An error occurred (AccessDenied) when calling the AssumeRole operation" 오류 메시지와 함께 실패합니다. 이 오류를 해결하기 위해 엔지니어가 수행해야 하는 단계 조합은 무엇입니까? (두 개 선택)
정답입니다. 호출 role(WebForensicsRole)은 계정 444455556666의 특정 대상 role ARN에 대해 sts:AssumeRole을 허용하는 identity-based policy가 있어야 합니다. 이 allow가 없으면, 대상 role의 trust policy와 무관하게 STS가 요청을 거부합니다. 이는 cross-account role assumption에 필요한 두 가지 필수 권한 구성 요소 중 하나입니다.
오답입니다. AmazonSSMManagedInstanceCore는 Systems Manager 기능(SSM Agent, Session Manager, Run Command)을 활성화하며 sts:AssumeRole 권한 부여와는 관련이 없습니다. 이를 연결하면 인스턴스를 관리하거나 트러블슈팅하는 데 도움이 될 수는 있지만, CorpForensicsAccessRole을 assume할 권한을 부여하지 않으며 AssumeRole AccessDenied 오류를 해결하지 못합니다.
정답입니다. 대상 role(CorpForensicsAccessRole)은 trust policy에 principal arn:aws:iam::111122223333:role/WebForensicsRole이 sts:AssumeRole을 호출하도록 허용하는 내용을 포함해야 합니다. 이 신뢰 관계는 cross-account 액세스에 필수입니다. WebForensicsRole에 sts:AssumeRole 권한이 있더라도, 대상 role이 이를 신뢰하지 않으면 호출은 실패합니다.
오답입니다. WebForensicsRole의 trust policy는 ec2.amazonaws.com이 이를 assume하도록 허용해야(인스턴스 프로파일이 자격 증명을 전달할 수 있도록) 하지만, 시나리오에서는 애플리케이션이 이미 인스턴스 프로파일 role을 사용하여 AssumeRole을 시도하고 있습니다. 실패한 작업은 CorpForensicsAccessRole로의 cross-account AssumeRole이며, 이는 WebForensicsRole의 trust policy 수정이 아니라 A와 C에 의해 좌우됩니다.
오답입니다. 호출을 특정 regional STS endpoint(예: us-east-1)로 보내는 것은 일반적으로 AccessDenied 오류의 원인이 아닙니다. endpoint 선택 문제는 보통 네트워크/endpoint 오류, 서명 문제 또는 서비스 가용성 문제로 나타납니다. AssumeRole에 대한 권한 부여 실패는 거의 항상 호출자 권한 누락, trust policy 누락/오류, 또는 명시적 deny/조건 문제 때문입니다.
핵심 개념: 이 문제는 AWS STS AssumeRole을 사용한 cross-account 액세스를 테스트합니다. AssumeRole이 성공하려면 서로 독립적인 두 가지 권한 검사가 통과되어야 합니다: (1) 호출자의 identity-based policy가 대상 role ARN에 대해 sts:AssumeRole을 허용해야 하고, (2) 대상 role의 trust policy(해당 role에 대한 resource-based policy)가 호출자 principal을 신뢰해야 합니다. 정답이 맞는 이유: A가 필요한 이유는 WebForensicsRole(EC2 인스턴스 프로파일을 통해 호출하는 role)이 arn:aws:iam::444455556666:role/CorpForensicsAccessRole에 대해 sts:AssumeRole을 호출하도록 명시적으로 허용되어야 하기 때문입니다. 이 identity-based allow가 없으면, 대상 role이 호출자를 신뢰하더라도 STS는 AccessDenied를 반환합니다. C가 필요한 이유는 CorpForensicsAccessRole이 trust policy(해당 role의 AssumeRolePolicyDocument)에서 principal arn:aws:iam::111122223333:role/WebForensicsRole을 신뢰해야 하기 때문입니다. trust policy가 해당 principal(또는 external ID 같은 허용 조건)을 허용하지 않으면, 호출자에 allow 문이 있더라도 STS는 AccessDenied를 반환합니다. 주요 AWS 기능 / 구성: - WebForensicsRole의 identity-based policy: Action sts:AssumeRole을 Allow하고 Resource를 대상 role ARN으로 설정. - CorpForensicsAccessRole의 trust policy: Principal을 소스 role ARN(또는 조건이 있는 소스 계정)으로 설정하고 Action sts:AssumeRole. - 선택 사항이지만 흔함: sts:ExternalId, aws:PrincipalArn 또는 MFA 요구 사항 같은 조건; 또한 세션 지속 시간은 대상 role의 MaxSessionDuration 범위 내여야 합니다. 흔한 오해: - EC2 서비스 trust(인스턴스 프로파일 role에 필요)와 cross-account trust(대상 role에 필요)를 혼동하는 경우. EC2 trust는 인스턴스가 자격 증명을 얻는 방식에 영향을 주지만, 다른 role을 assume할 수 있는지 여부에는 직접적인 영향을 주지 않습니다. - STS endpoint region 선택이 AccessDenied를 유발한다고 생각하는 경우. endpoint 문제는 보통 연결 또는 endpoint 관련 오류를 유발하며, 권한 부여 실패를 의미하지는 않습니다. 시험 팁: Cross-account AssumeRole에서는 항상 “양측 권한(two-sided permissions)”을 확인하세요: 호출자 policy와 대상 trust policy. AssumeRole에서 AccessDenied가 보이면, 먼저 두 문서를 확인한 다음 명시적 deny(SCP, permission boundary, session policy) 및 조건 불일치(ExternalId, MFA, source IP/VPC endpoint 조건)를 점검하세요.
한 fintech 회사의 security engineer는 임시 vendor IAM user가 특정 account에서 테이블을 보고 편집하기 위해 Amazon DynamoDB console에만 액세스할 수 있도록 보장해야 하며, 어떤 상황에서도 다른 AWS services를 사용하지 못하도록 방지해야 합니다. 해당 vendor IAM user는 나중에 광범위한 permissions(예: AdministratorAccess)을 부여하는 하나 이상의 IAM groups에 추가될 수 있지만, 사용자의 effective permissions는 DynamoDB로만 제한된 상태를 유지해야 합니다. 이 요구 사항을 충족하기 위해 security engineer가 취해야 할 접근 방식은 무엇입니까?
DynamoDB access를 허용하는 inline policy는 현재 필요한 permissions를 부여할 수는 있지만, 나중에 group membership이나 다른 attached policies를 통해 추가 permissions를 얻는 것을 막지 못합니다. 사용자가 이후 AdministratorAccess가 있는 group에 추가되면 다른 services에도 액세스할 수 있습니다. Inline policies는 guardrail이 아니라 identity-based permissions의 한 소스일 뿐입니다.
DynamoDB actions만 허용하는 permissions boundary는 사용자가 할 수 있는 일을, 향후 어떤 group memberships나 attached policies가 추가되더라도, 하드한 최대치로 제한합니다. 나중에 AdministratorAccess가 연결되더라도 DynamoDB 밖의 actions는 boundary에서 허용되지 않으므로 계속 deny됩니다. 이는 어떤 상황에서도 다른 AWS services 사용을 방지해야 한다는 요구 사항을 직접 충족합니다.
사용자를 DynamoDB-only group에 넣는 것은 access를 부여하는 일반적인 방법이지만, 향후 변경에 대해 지속적으로 보장되지 않습니다. 사용자가 이후 더 광범위한 permissions(예: AdministratorAccess)을 가진 다른 group에 추가되면 사용자의 effective permissions가 확장됩니다. Group 기반 permission 관리는 additive이며, 본질적으로 최대 permission boundary를 강제하지 않습니다.
Explicit denies가 있는 role은 role이 할 수 있는 일을 제한할 수는 있지만, vendor가 항상 그 role을 assume하고 해당 role credentials만 사용한다는 전제에 의존합니다. 또한 underlying IAM user가 나중에 직접 또는 groups를 통해 다른 permissions를 부여받는 것을 본질적으로 막지 못합니다. 요구 사항은 향후 어떤 attachment가 있더라도 IAM user의 effective permissions를 제한하는 것이며, 이는 permissions boundary로 더 잘 충족됩니다.
핵심 개념: 이 문제는 IAM effective permissions와, 향후 group membership과 무관하게 최대 permission set을 강제하는 방법을 평가합니다. 핵심 개념은 IAM permissions boundary로, 이는 IAM principal(user 또는 role)이 받을 수 있는 permissions의 상한을 정의합니다. 정답인 이유: DynamoDB actions만 허용하는 permissions boundary policy는 vendor IAM user가 이후 AdministratorAccess 같은 광범위한 permissions를 가진 groups에 추가되더라도 다른 AWS services를 절대 사용할 수 없도록 보장합니다. IAM evaluation에서는 어떤 action이 identity-based policy에 의해 allowed되어야 하고 동시에 permissions boundary 범위 내에 있어야 합니다. 따라서 DynamoDB가 아닌 action은 boundary 내에서 허용되지 않으므로(implicit deny), group membership을 통한 privilege escalation을 방지합니다. 주요 AWS 기능: Permissions boundaries는 user 또는 role에 연결되는 managed policies로, 최대 permissions에 대한 guardrail을 설정합니다. 이는 delegated administration에 흔히 사용되며 임시 또는 vendor access를 제한하는 데도 사용됩니다. “console에서 테이블을 보고 편집” 요구를 충족하려면 boundary가 관련 DynamoDB actions(예: dynamodb:DescribeTable, dynamodb:UpdateTable, dynamodb:PutItem 등)을 허용해야 하며, 일반적으로 console 사용성을 위해 필요한 read-only actions도 허용해야 합니다(종종 AWS-managed DynamoDB policies 또는 custom least-privilege set을 통해). Resource scoping을 통해 account 내 특정 tables/ARNs로 추가 제한할 수도 있습니다. 흔한 오해: Inline policies 또는 group policies(옵션 A/C)는 permissions를 부여하지만 향후 permissions를 상한으로 제한하지는 못합니다. 나중에 AdministratorAccess를 추가하면 의도와 달리 권한이 확장됩니다. Role에서 explicit deny를 사용하는 전략(옵션 D)은 이론적으로 가능하지만, vendor가 일관되게 role을 assume하는 것에 의존하며, IAM user 자체가 직접 또는 groups를 통해 다른 permissions를 부여받는 것을 막지 못합니다. 시험 팁: 요구 사항에 “나중에 admin groups에 추가되더라도 제한이 유지되어야 함”이 포함되면 permissions boundary(또는 organization 수준의 SCP)를 떠올리십시오. Boundaries는 principal의 최대 permissions를 제한하며, 자체적으로 access를 부여하지는 않습니다—boundary 범위 내에서 DynamoDB permissions를 부여하는 identity-based policies가 별도로 필요합니다.
한 의료 분석 회사가 4개의 OU(prod, dev, staging, shared)에 걸쳐 20개의 AWS account로 구성된 새로운 AWS Organizations 구조를 구축하고 있으며, 외부 SAML 2.0 IdP(Okta)에서 3,200명의 workforce user를 통합해야 합니다. 이를 통해 management account에서 회사가 모든 account 및 두 개의 내부 SAML application에 대한 액세스를 중앙에서 관리할 수 있어야 합니다. 회사는 IdP에서 MFA가 강제되어야 하고, user 및 group의 자동 프로비저닝, 그리고 account 전반에 걸친 최소 권한의 role 기반 액세스가 필요합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?
AWS Directory Service for Microsoft AD는 SAML/ADFS 스타일 구성과 통합할 수 있지만, AWS Organizations를 통해 여러 AWS account에 대한 액세스를 중앙에서 관리하기 위한 적절한 control plane이 아닙니다. 또한 directory user에 IAM policy를 직접 연결할 수 없습니다. AWS에서 권한 부여는 IAM role/policy를 통해 수행됩니다. 이 옵션은 중앙 집중식 multi-account RBAC 및 SAML app assignment 요구 사항을 깔끔하게 충족하지 못합니다.
IAM Identity Center는 AWS Organizations 계정과 지원되는 business applications 전반에서 중앙 집중식 workforce access를 위해 특별히 설계되었습니다. Okta를 외부 identity source로 사용하고 인증 및 MFA에는 SAML을, 자동 사용자 및 그룹 provisioning에는 SCIM을 사용하는 것은 federation, MFA, lifecycle management 요구 사항을 직접적으로 충족합니다. Permission sets를 사용하면 회사는 least-privilege access를 한 번 정의한 뒤 이를 여러 계정과 OUs 전반의 그룹에 할당할 수 있으므로, 3,200명의 사용자 규모에도 잘 확장됩니다. 또한 IAM Identity Center는 SAML-enabled applications에 대한 access 할당도 지원하므로, 두 개의 내부 SAML 앱도 동일한 중앙 집중식 access 플랫폼에서 관리할 수 있습니다.
20개 account 각각에서 SAML federation을 별도로 구성하면 관리 오버헤드가 크게 증가하고 거버넌스가 일관되지 않게 됩니다. 또한 OU 전반에서 management account로부터 중앙에서 관리해야 한다는 요구 사항을 약화시킵니다. 추가로 federated user는 IAM user가 아니며, “federated user”에 policy를 직접 연결하는 것이 아니라 role을 assume하여 액세스를 부여합니다. 이 접근 방식은 확장성이 떨어지고 오류가 발생하기 쉽습니다.
Amazon Cognito는 주로 고객 대상 application 인증/권한 부여(web/mobile) 및 app user를 위한 social/SAML IdP federation을 위해 설계되었습니다. AWS Organizations 환경에서 workforce가 AWS account에 액세스하도록 하는 표준 솔루션이 아니며, IAM Identity Center와 같은 중앙 집중식 multi-account permission-set 모델을 제공하지 않습니다. 3,200명의 직원에 대한 AWS account 액세스를 Cognito로 관리하는 것은 비정형적이며 복잡합니다.
핵심 개념: 이 문제는 중앙 집중식 workforce access를 위해 AWS Organizations와 통합된 AWS IAM Identity Center를 테스트하며, 여기에는 외부 SAML 2.0 IdP federation, SCIM provisioning, 그리고 permission sets를 통한 least-privilege authorization이 포함됩니다. 정답인 이유: IAM Identity Center는 AWS Organizations 계정과 지원되는 애플리케이션 전반에서 workforce access를 중앙에서 관리하도록 설계된 AWS 서비스입니다. Okta를 외부 identity source로 구성하고, 인증에는 SAML 2.0을 사용하며 자동 사용자 및 그룹 provisioning에는 SCIM을 사용하면, 회사는 IdP에서 MFA를 강제하고 lifecycle management를 자동화하며 그룹 기반으로 access를 할당할 수 있습니다. 그런 다음 permission sets를 사용하여 대상 계정에 least-privilege IAM roles를 provisioning할 수 있고, application assignments를 사용하여 두 개의 내부 SAML 애플리케이션에 대한 access도 관리할 수 있습니다. 주요 AWS 기능: - AWS Organizations integration이 포함된 IAM Identity Center: 조직 전반의 member accounts 및 애플리케이션에 대한 access를 중앙에서 관리합니다. - Permission sets: 대상 계정에 IAM roles를 생성하는 재사용 가능한 access 정의이며, AWS managed policies, customer managed policies, inline policies를 지원합니다. - Group-based assignments: provisioning된 Okta groups를 permission sets 및 accounts/OUs에 매핑하여 확장 가능한 RBAC를 구현합니다. - SAML을 사용하는 외부 IdP: 인증과 MFA는 Okta가 처리하고, AWS는 SAML assertions를 신뢰합니다. - SCIM provisioning: IAM Identity Center로 사용자와 그룹을 자동 provisioning 및 deprovisioning합니다. - Application assignments: IAM Identity Center user portal을 통해 지원되는 SAML 애플리케이션에 대한 access를 중앙에서 관리합니다. 흔한 오해: 계정별 SAML federation(option C)은 가능해 보일 수 있지만, 불필요한 운영 오버헤드를 만들고 조직 전반에 대한 중앙 집중식 governance를 제공하지 못합니다. Directory Service(option A)는 Microsoft AD 사용 사례를 위한 것이며, directory users에 IAM policies를 직접 연결할 수 없습니다. Cognito(option D)는 주로 AWS 계정에 대한 enterprise workforce access보다는 애플리케이션 end users를 대상으로 합니다. 시험 팁: 문제에 AWS Organizations, 많은 workforce users, 외부 SAML IdP, SCIM provisioning, 중앙 집중식 계정 access, least-privilege RBAC가 포함되어 있다면 IAM Identity Center가 best-practice 정답입니다. 또한 IAM Identity Center는 management account에서만이 아니라 delegated administrator account에서도 관리할 수 있다는 점을 기억하세요.
미디어 아카이빙 회사는 법적 보존(legal hold) 요구 사항을 충족하기 위해 4.5 PB의 원본 감시 영상을 9년 동안 보관해야 한다. 컴플라이언스 팀은 보안 아키텍트에게 보관 기간 동안 root account를 포함한 어떤 사용자도 영상을 수정하거나 삭제할 수 없도록 WORM 제어를 구현하되, 스토리지 비용과 운영 오버헤드를 최소화하라고 지시했다. 어떤 솔루션이 이 요구 사항을 가장 비용 효율적으로 충족하는가?
정답. compliance mode의 S3 Object Lock는 진정한 WORM 보존을 제공한다. 보존 기간이 끝날 때까지 root account를 포함한 어떤 사용자도 객체를 덮어쓰거나 삭제할 수 없다. 이는 엄격한 legal hold 요구 사항을 충족한다. 또한 운영이 단순(표준 S3 API)하며, lifecycle transition을 S3 Glacier Deep Archive 같은 저비용 아카이브 티어로 결합해 9년 보존을 최소 스토리지 비용으로 달성할 수 있다.
오답. governance mode의 S3 Object Lock는 절대적인 WORM이 아니다. s3:BypassGovernanceRetention 권한(또는 이에 준하는 privileged access)을 가진 사용자는 보존을 무시하고 객체를 삭제/수정할 수 있다. 이는 “root account를 포함한 어떤 사용자도” 보관 기간 동안 삭제 또는 수정할 수 없어야 한다는 요구 사항을 충족하지 못한다. governance mode는 변경 불가능한 컴플라이언스 보존이 아니라 내부 통제를 위한 것이다.
이 시나리오에서 최선의 답이 아니다. S3 Glacier Vault Lock는 Glacier vault에 컴플라이언스 제어를 강제할 수 있지만, 레거시 Glacier vault 모델과 별도의 API를 사용하므로 S3에 비해 운영 오버헤드가 증가한다. 문제는 4.5 PB를 오버헤드를 최소화하면서 비용 효율적으로 보관하라고 하며, 일반적으로 S3에서 Object Lock + lifecycle로 Glacier Deep Archive를 사용하는 방식이 하나의 서비스 내에서 더 단순한 관리와 동등하거나 더 나은 비용 최적화를 제공한다.
오답. S3 Lifecycle로 S3 Glacier storage class로 전환된 객체에 S3 Glacier Vault Lock를 적용할 수 없다. Vault Lock는 S3 Glacier vault(레거시)에 적용되며 S3 bucket이나 S3 Glacier/Deep Archive storage class에는 적용되지 않는다. S3 객체의 경우 올바른 변경 불가능성 메커니즘은 Glacier Vault Lock가 아니라 S3 Object Lock(compliance mode)이다.
핵심 개념: 이 문제는 AWS에서 장기 아카이브를 위한 변경 불가능(WORM) 보존을 테스트한다. 주요 서비스/기능은 Amazon S3 Object Lock(WORM)과 S3 storage class(특히 S3 Glacier Deep Archive)로, 엄격한 legal hold 요구 사항을 충족하면서 비용을 최소화하는 것이다. 정답이 맞는 이유: compliance mode의 S3 Object Lock는 보존 기간이 만료될 때까지 객체를 삭제하거나 덮어쓰지 못하도록 WORM을 강제하며, 이 보호는 높은 권한의 ID( root account 포함)에도 적용된다. 이는 “보관 기간 동안 root account를 포함한 어떤 사용자도 영상을 수정하거나 삭제할 수 없다”는 요구 사항과 정확히 일치한다. 또한 S3를 사용하면 별도의 아카이브 API를 관리하는 것보다 운영 오버헤드를 줄일 수 있고, Object Lock를 lifecycle transition(예: S3 Glacier Deep Archive)과 결합해 변경 불가능성 제어를 유지하면서 저비용 아카이브 티어로 전환할 수 있다. 주요 AWS 기능: - S3 Object Lock (Compliance mode): 어떤 IAM principal도 우회할 수 없는 보존을 강제한다. 보존 기간과 legal hold를 지원한다. - Bucket은 생성 시 Object Lock가 활성화되어 있어야 하며, 일반적으로 versioning을 사용해 객체 버전을 보존한다. - Lifecycle policy는 잠긴(locked) 객체를 S3 Glacier/Glacier Deep Archive로 전환하여 비용을 최적화하면서 보존 제어를 유지할 수 있다. - Bucket policy는 가드레일(예: PUT 시 Object Lock 헤더 요구, 암호화되지 않은 업로드 거부, 접근 경로 제한)을 강제할 수 있지만, WORM 보장은 Object Lock compliance mode에서 나온다. 흔한 오해: - governance mode(옵션 B)는 “보존”처럼 들리지만, 특별 권한을 가진 privileged user가 이를 우회할 수 있어 “root 포함” 요구 사항을 위반한다. - Glacier Vault Lock(옵션 C)은 WORM 유사 제어이지만, 레거시 S3 Glacier vault( S3 bucket과 분리)에 적용되며 운영 복잡도를 증가시킨다. 또한 문제는 오버헤드 최소화와 대규모 데이터의 비용 효율적 관리를 강조하므로 S3 + lifecycle이 더 적합하다. - S3 lifecycle로 Glacier로 전환한 뒤 Vault Lock를 적용하는 것(옵션 D)은 개념적으로 잘못되었다. Vault Lock는 S3 Glacier vault용이지, S3 bucket 내의 S3 Glacier storage class에 적용되는 것이 아니다. 시험 팁: “WORM”, “legal hold”, “root도 삭제 불가”를 보면 S3 Object Lock의 compliance mode를 떠올려라. 또한 비용을 강조하면 lifecycle transition을 S3 Glacier Deep Archive와 함께 연상하라. 주의: “governance”는 우회 가능성을 의미하고, “compliance”는 우회 불가를 의미한다.
IoT analytics 플랫폼이 수명이 짧은 컨테이너 플릿을 실행하고 있으며, 각 디바이스 등록 시 AWS KMS CreateGrant를 호출하여 디바이스 ID가 customer managed key를 사용할 수 있도록 허용한 다음 100ms 이내에 1KB 페이로드를 지속적으로 초당 1,200건의 요청 속도로 암호화하려고 시도하지만, 성능 테스트 중 grant가 생성된 직후 첫 번째 Encrypt 호출이 간헐적으로 AccessDeniedException으로 즉시 실패합니다. 이러한 오류를 제거하기 위해 보안 전문가는 무엇을 권장해야 합니까?
오답입니다. 2분마다 retry하는 방식은 디바이스 등록 후 100 ms 이내에 암호화해야 한다는 애플리케이션 요구 사항을 충족하지 못합니다. eventual consistency 문제가 그 시점에는 해결될 수 있더라도, 이 접근 방식은 즉시 grant를 사용하도록 설계된 KMS 기능을 사용하는 대신 증상만 다루는 것입니다. 또한 높은 처리량의 워크로드에 심각한 지연과 운영 비효율을 초래합니다.
오답입니다. 이 선택지는 클라이언트가 제공한 token을 CreateGrant에 전달하는 것으로 설명하지만, 이 워크플로에서 KMS grant token은 사용자가 임의로 제공하는 값이 아닙니다. 관련 token은 CreateGrant 응답이 반환하는 grant token이며, 이후 KMS 작업의 GrantTokens를 통해 전달됩니다. 따라서 이 선택지는 KMS grant token이 어떻게 획득되고 사용되는지를 잘못 설명하고 있습니다.
오답입니다. grant name은 단지 grant의 식별자일 뿐이며 authorization을 우회하거나 consistency를 건너뛰게 해주지 않습니다. Encrypt 요청에 grant name을 제공해도 새로 생성된 grant를 더 빨리 유효하게 만들 수 없습니다. KMS는 GrantTokens 파라미터에서 grant name이 아니라 grant token을 기대하기 때문입니다. 이 선택지는 grant를 라벨링하는 데 사용되는 메타데이터와 해당 grant를 즉시 사용할 수 있게 하는 token을 혼동하고 있습니다.
정답입니다. AWS KMS CreateGrant는 새 grant가 서비스 전체에 완전히 전파되기 전에 즉시 사용할 수 있게 해주는 grant token을 반환합니다. 반환된 token을 클라이언트에 전달하고, 클라이언트가 이를 Encrypt 요청의 GrantTokens 파라미터에 포함하도록 하면, 플랫폼은 eventual consistency로 인해 발생하는 간헐적인 AccessDeniedException을 방지할 수 있습니다. 이것이 grant를 생성한 뒤 수 밀리초 내에 key를 사용해야 하는 저지연 워크플로를 위해 특별히 마련된 KMS 메커니즘입니다.
핵심 개념: 이 문제는 AWS KMS grant의 eventual consistency에 관한 것입니다. CreateGrant 호출이 성공한 후에도 새 grant는 KMS authorization 경로 전반에서 즉시 보이지 않을 수 있으므로, 바로 이어지는 Encrypt 호출이 간헐적으로 AccessDeniedException으로 실패할 수 있습니다. AWS KMS는 CreateGrant에서 grant token을 반환함으로써 이를 해결하며, 호출자는 이후 KMS 작업의 GrantTokens 파라미터에 이 값을 전달하여 grant를 즉시 사용할 수 있습니다. 정답인 이유: 엔지니어링 팀은 CreateGrant가 반환한 grant token을 저장하고, Encrypt를 수행하는 구성 요소에 이를 제공해야 합니다. Encrypt 요청에 해당 token을 포함하면 KMS는 새로 생성된 grant가 아직 완전히 전파되지 않았더라도 이를 인정합니다. 이렇게 하면 허용할 수 없는 지연을 추가하지 않고 race condition을 직접 제거할 수 있습니다. 주요 특징: CreateGrant는 GrantToken 값을 반환합니다. Encrypt는 GrantTokens 요청 파라미터를 지원합니다. grant token은 새로 생성된 grant의 전파 지연을 메우기 위해 특별히 설계되었습니다. 이는 grant를 생성한 직후 즉시 사용해야 하는 수명이 짧고 지연 시간에 민감한 워크플로를 위한 의도된 메커니즘입니다. 흔한 오해: grant name은 grant token이 아니며 authorization 시점에 아무런 영향을 주지 않습니다. 일반적인 KMS 사용에서 클라이언트가 CreateGrant용 임의의 token을 만들어내는 것은 아닙니다. 관련 token은 KMS가 반환하는 값입니다. 긴 retry 대기 시간은 불필요하며 워크로드의 100 ms 요구 사항에도 위배됩니다. 시험 팁: CreateGrant 다음에 즉시 Encrypt 또는 Decrypt가 이어지고 간헐적인 AccessDeniedException이 보인다면, KMS eventual consistency와 grant token을 떠올리세요. 표준적인 해결 방법은 CreateGrant가 반환한 grant token을 다음 KMS API 호출의 GrantTokens에 전달하는 것입니다.
한 기술 회사는 개발자가 암호화 키를 직접 다루지 않으면서, 3개 AWS Regions와 8개 AWS accounts에 걸쳐 2,500대 Amazon EC2 instances로 구성된 Auto Scaling fleet의 Amazon EBS volumes를 투명하게 암호화할 수 있는 메커니즘이 필요합니다. 해당 솔루션은 지속적인 관리 없이 자동으로 확장되어야 하며, 조직은 암호화 키를 즉시 삭제하여 접근을 철회할 수 있어야 하고, 철회 RTO가 1분 미만이어야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?
오답입니다. AWS KMS는 ScheduleKeyDeletion에 대해 PendingWindowInDays를 0으로 설정하는 것을 허용하지 않으며, 대기 기간(최소 7 days, 최대 30 days)이 강제됩니다. 또한 KMS key를 비활성화하는 것은 즉각적인 cryptographic erasure와 동일하지 않습니다. 따라서 fleet 전반에서 1분 미만의 철회 RTO를 충족할 수 없습니다.
정답입니다. KMS imported key material을 사용하면 EBS가 KMS-integrated envelope encryption을 통해 대규모로 volumes를 투명하게 암호화할 수 있어 개발자가 키에서 완전히 분리됩니다. 즉각적인 철회가 필요할 경우 DeleteImportedKeyMaterial이 KMS에서 cryptographic material을 즉시 제거하여 사실상 복호화를 불가능하게 만들며, 지속적인 관리 없이 1분 미만의 철회 RTO를 충족합니다.
오답입니다. CloudHSM은 고객이 제어하는 HSMs를 제공하지만, EBS encryption은 AWS KMS와 통합되며 PKCS#11을 통해 CloudHSM keys를 EBS volume encryption에 직접 사용하지 않습니다. CloudHSM을 사용하면 운영 오버헤드(clusters, HA, backups, lifecycle)가 크게 증가하고, KMS만큼 “투명한 EBS encryption” 통합 요구 사항을 깔끔하게 충족하지 못합니다.
오답입니다. Systems Manager Parameter Store는 EBS encryption을 위한 암호학적 key management system으로 설계되지 않았습니다. Parameter Store에 키를 저장하면 applications 또는 개발자가 key material을 조회하고 처리해야 하므로, 개발자가 암호화 키를 절대 다루지 않아야 한다는 요구 사항을 위반합니다. 또한 KMS처럼 EBS encryption과 통합되지 않습니다.
핵심 개념: 이 문제는 Amazon EBS에 대해 AWS KMS를 사용하여 AWS-native 방식으로 대규모 암호화를 수행하는 것, 특히 개발자가 키를 다루지 않으면서 신속한 암호학적 철회(cryptographic revocation)를 달성하는 방법을 평가합니다. 핵심 구분점은 KMS key를 비활성화/삭제 예약하는 것과 key material을 즉시 제거하는 것의 차이입니다. 정답이 맞는 이유: AWS imported key material(BYOK)과 함께 AWS KMS를 사용하면, 조직은 KMS를 통해 투명한 EBS 암호화( Auto Scaling fleets 포함)를 수행하면서도, imported key material을 삭제하여 접근을 빠르게 철회할 수 있습니다. DeleteImportedKeyMaterial을 호출하면 KMS는 해당 KMS key로 이전에 보호되었던 어떤 data keys도 복호화할 수 있는 데 필요한 cryptographic material을 즉시 상실합니다. 이는 거의 즉각적인 cryptographic erasure를 제공하여 1분 미만 RTO를 충족하며, EBS가 envelope encryption을 위해 KMS와 통합되므로 개발자가 키를 처리할 필요가 없습니다. 주요 AWS 기능: - EBS encryption은 KMS와 통합됨: instances와 개발자는 plaintext keys를 절대 보지 않으며, EBS는 KMS key로 보호되는 data keys를 사용합니다. - Multi-account/multi-Region 확장: KMS keys를 Region별로 사용( EBS encryption은 Region-scoped)하고 IAM/key policies를 통해 공유합니다. 자동화를 통해 8개 accounts와 3개 Regions 전반에서 배포를 표준화할 수 있습니다. - Imported key material lifecycle: ImportKeyMaterial + DeleteImportedKeyMaterial을 통해 즉시 철회가 가능하며, 필요 시 나중에 재-import할 수도 있습니다. 흔한 오해: - “ScheduleKeyDeletion을 0 days로 설정”은 불가능합니다. KMS는 최소 대기 기간(7–30 days)을 강제합니다. 또한 key를 비활성화하는 것만으로는 cryptographic erasure와 같은 방식의 즉각적인 철회를 보장하지 않습니다. - CloudHSM이 가장 강력한 제어처럼 보일 수 있지만, EBS는 EBS encryption을 위해 CloudHSM keys를 직접 사용하지 않습니다. EBS에 통합된 서비스는 KMS입니다. - Parameter Store는 EBS를 위한 key management/encryption authority가 아니며, applications/개발자가 키를 처리해야 하므로 요구 사항을 위반합니다. 시험 팁: EBS, RDS, S3 SSE-KMS 같은 AWS-managed services의 경우 기본 답은 보통 KMS입니다. 문제가 즉각적인 철회/crypto-shredding을 요구한다면, key deletion scheduling이 아니라 “imported key material”과 “DeleteImportedKeyMaterial”을 찾으십시오. 또한 EBS encryption은 Region-specific이므로 Region별 키를 계획하고 accounts 전반에서 policy/permissions를 자동화해야 합니다.
한 엔터프라이즈는 단일 AWS Organizations 조직에서 28개의 AWS 계정을 운영하며, 모든 Region에서 모든 Amazon EC2 인스턴스(Amazon Linux 2 및 Windows Server 2019)가 시작 후 15분 이내에 CorpShield EDR agent version 3.8을 실행해야 한다. 중앙 tools account가 사업부에서 사용하는 golden AMI를 게시하며, AWS Systems Manager는 소프트웨어 인벤토리 및 패칭을 위해 조직 전체에서 이미 활성화되어 있다. 보안 엔지니어는 기존 인스턴스를 교체하거나 수동 타기팅에 의존하지 않고, agent가 없는 모든 EC2 managed instance를 지속적으로 탐지하고 agent가 없을 때 자동으로 설치하는 솔루션을 구현해야 한다. 이러한 요구 사항을 충족하는 솔루션은 무엇인가?
golden AMI에 agent를 사전 설치하는 것은 향후 인스턴스에 대한 강력한 예방 조치이며, 승인된 AMI로만 시작을 제한하면 표준화를 개선할 수 있습니다. 그러나 이것은 기존 인스턴스에 agent가 없는지 또는 나중에 agent가 제거되거나 비정상 상태가 되는지를 지속적으로 탐지하지는 못합니다. 요구 사항은 교체 없이 기존 인스턴스를 포함하여 agent가 없는 인스턴스에 자동 설치를 명시적으로 요구합니다. AMI 또는 인스턴스에 태그를 지정하는 것 자체로는 compliance 평가나 수정이 제공되지 않습니다.
Systems Manager Patch Manager는 patch baseline과 maintenance schedule을 기반으로 한 patch compliance 및 배포를 위해 설계되었으며, 일부 애플리케이션 patch 시나리오도 포함합니다. 그러나 이것은 근본적으로 예약 기반 프로세스이며, 모든 Region에서 인스턴스 시작 후 15분 이내에 EDR agent가 설치되도록 보장하는 데 필요한 near-real-time의 event-driven 탐지 및 수정 루프를 제공하지 않습니다. 또한 compliance event를 기반으로 새롭게 noncompliant 상태가 된 인스턴스만 자연스럽게 대상으로 삼지도 않으므로, Config + EventBridge + SSM 수정 패턴보다 적합성이 떨어집니다. agent package를 baseline에 포함할 수 있다고 하더라도, 이 옵션은 명시된 지속적인 자동 수정 요구 사항을 여전히 충족하지 못합니다.
이 옵션은 필요한 EDR agent가 없는 인스턴스를 지속적으로 식별하고 자동으로 수정하는 closed-loop compliance 프로세스를 생성합니다. AWS Config는 Systems Manager Inventory가 수집한 설치된 소프트웨어 정보를 기반으로 인스턴스 compliance를 평가하기 위해 조직 전체에서 중앙 집중식으로 사용할 수 있으며, EventBridge는 인스턴스가 NON_COMPLIANT 상태가 될 때 반응할 수 있습니다. 그런 다음 Lambda function은 특정 영향을 받은 인스턴스에 대해 Systems Manager Run Command를 호출할 수 있으며, 이는 수동으로 대상을 지정하는 작업을 피하고 기존 인스턴스를 교체할 필요도 없습니다. 이는 명시된 운영 모델 내에서 지속적인 탐지, 자동 수정, 조직 전체 범위, 그리고 시작 후 적용을 명확하게 해결하는 유일한 옵션입니다.
Systems Manager Distributor는 EDR installer와 같은 third-party software를 표준화된 방식으로 패키징하고 배포하는 데 유용합니다. 그러나 이 옵션은 모든 인스턴스를 선택하고 Run Command로 package를 설치하는 것만 설명하며, 이는 지속적인 compliance 모니터링이라기보다 일회성 또는 수동 시작 배포 방식입니다. 새 인스턴스가 agent 없이 시작되거나 나중에 agent가 누락되는 시점을 탐지하는 메커니즘은 포함되어 있지 않습니다. 자동화된 compliance trigger와 대상 지정된 수정 워크플로가 없으면, 명시된 요구 사항을 충족하지 못합니다.
핵심 개념: 이 문제는 AWS Organizations 전반에서 AWS Config + 이벤트 기반 자동화 + AWS Systems Manager를 사용하여 대규모로 지속적인 컴플라이언스 탐지와 자동 remediation을 수행하는지를 평가한다. 핵심은 인스턴스를 재구축하지 않고도 필수 소프트웨어가 누락된 managed instance를 탐지하고 remediation하는 것이다. 정답이 맞는 이유: 옵션 C는 조직 전체에 걸친 지속적인 제어 루프를 제공한다. AWS Config는 필수 애플리케이션이 있는지 인스턴스를 평가하고 NON_COMPLIANT 리소스를 표시한다. EventBridge rule은 컴플라이언스 상태 변경에 반응하여 Lambda function을 호출할 수 있고, Lambda는 해당 비준수 인스턴스에 대해 Systems Manager Run Command를 트리거하여 CorpShield EDR agent를 설치한다. 이는 (1) 드리프트를 지속적으로 탐지하고, (2) 자동으로 remediation하며, (3) 기존 인스턴스를 교체하지 않고, (4) 컴플라이언스 이벤트에서 instance ID를 가져오므로 수동 타기팅을 피한다는 요구 사항을 충족한다. Systems Manager가 이미 조직 전체에서 활성화되어 있으므로 Run Command는 시작 직후 빠르게 실행될 수 있으며, 15분 요구 사항은 거의 실시간 이벤트 처리로 달성 가능하다. 주요 AWS 기능: - AWS Organizations 및 aggregator를 통한 AWS Config의 multi-account/multi-Region 활성화로 중앙 가시성 제공. - Systems Manager Inventory 데이터를 활용하여 SSM managed instance에 설치된 애플리케이션을 평가하는 managed rule ec2-managedinstance-applications-required(또는 동등한 애플리케이션 인벤토리 컴플라이언스 rule). - AWS Config 컴플라이언스 변경 알림과의 EventBridge 통합. - 자동 remediation 패턴: EventBridge -> Lambda -> SSM Run Command(또는 Automation), 최소 권한 IAM 및 cross-account 실행(예: delegated admin, assumed role). 흔한 오해: - “golden AMI + SCP”(옵션 A)는 향후 시작을 강제하지만, 기존 인스턴스에 대한 지속적 탐지/리미디에이션을 제공하지 않으며, 다른 소스에서 시작되었거나 이미 실행 중인 인스턴스에 대해 15분 이내 설치를 보장하지 않는다. - Patch Manager(옵션 B)는 OS/패치 컴플라이언스 및 예약된 maintenance window에 적합하며, 서드파티 agent의 즉시 이벤트 기반 설치에는 이상적이지 않다. - Distributor + Run Command(옵션 D)는 패키지 배포에는 도움이 되지만 “모든 인스턴스”를 선택하는 것은 수동 타기팅이며, 드리프트에 대한 지속적 탐지/자동 remediation을 본질적으로 제공하지 않는다. 시험 팁: 요구 사항에 “지속적으로 탐지” 및 “자동으로 remediation”이 포함되면 AWS Config + EventBridge + SSM Automation/Run Command를 찾는다. 조직 전체 규모에서는 예약된 window나 일회성 fleet 작업보다 AWS Organizations 통합 및 이벤트 기반 remediation을 선호한다.
Practitioner








