정답 · 해설

해설

【핵심 용어】 ▸ 루트 사용자 대상 SCP — Organizations에서 SCP는 멤버 계정의 루트 사용자에게도 적용되어 서비스 접근을 차단 ▸ 심층 방어 — 루트 자격 증명이 탈취돼도 SCP가 상위에서 작업을 거부 ▸ SCP 특성 — 관리 계정을 제외한 멤버 계정에 권한 상한(guardrail) 부과 【정답 포인트】 ▸ "루트 자격 증명이 침해돼도 계정 보호" → 멤버 계정 루트 사용자에게도 적용되는 SCP로 서비스 접근을 원천 차단 → 자격 증명 유효 여부와 무관하게 방어 【오답 체크】 (B) 루트 비밀번호 제거는 실효성이 낮고 복구/오용 관리가 어려우며 근본 방어가 아님. (C) 루트 액세스 키 삭제는 모범 사례지만 콘솔 로그인 등 다른 루트 오용을 막지 못함. (D) CloudWatch Events 탐지 규칙은 사후 탐지일 뿐 예방적 차단이 아님. 【시험 포인트】 멤버 계정 루트 오용 방어(자격 증명 탈취 대비) → SCP로 루트 사용자 서비스 접근 차단(예방적 가드레일).

해설

【핵심 용어】 ▸ 권한 경계(permissions boundary) — IAM 역할이 가질 수 있는 최대 권한 상한, 권한 상승 방지 ▸ SCP — 조직 루트/OU에 적용해 "권한 경계가 붙은 역할만 새 역할 생성 가능" 등 조건 강제 ▸ 셀프 서비스 역할 생성 — 애플리케이션 팀이 정해진 경계 내에서 스스로 역할 생성 【정답 포인트】 ▸ "팀 셀프 서비스 + 범위 제한 + 권한 상승 방지 + 최소 운영" → SCP + 권한 경계 조합 ▸ 루트 OU에 SCP를 걸어 권한 경계가 부착된 역할만 새 IAM 역할을 만들 수 있게 강제 → 팀이 스스로 생성하되 상승 불가 【오답 체크】 (A) IAM 그룹/사용자 프로비저닝은 셀프 서비스 역할 위임·권한 상승 방지를 자동으로 강제하지 못하고 운영 부담이 큼. (B) 팀 리드 위임 + 분기별 수동 검토는 확장성·상승 방지 자동화가 부족. (C) 계정별 OU + 서비스 제한 SCP는 서비스 범위만 제한할 뿐 역할 생성 셀프 서비스·권한 상승 방지를 직접 해결하지 못함. 【시험 포인트】 셀프 서비스 역할 생성 + 권한 상승 방지 → SCP + 권한 경계(경계 부착 역할만 새 역할 생성 허용).

해설

【핵심 용어】 ▸ 대칭 고객 관리형 KMS 키 — 자동 키 로테이션 지원, 데이터 암호화의 표준 ▸ 자동 키 로테이션(automatic key rotation) — 대칭 CMK에서 지원(비대칭 CMK는 자동 로테이션 미지원) ▸ 키 비활성화·삭제 예약 — CMK는 disable 및 삭제 예약(대기 기간) 가능 【정답 포인트】 ▸ "자동 로테이션 + 비활성화 + 삭제 예약" → 대칭 고객 관리형 KMS 키에서 모두 지원, 자동 키 로테이션 활성화 【오답 체크】 (A) 비대칭 CMK는 자동 키 로테이션을 지원하지 않음 → 요건 미충족. (B) 대칭 키는 맞으나 "봉투 암호화 비활성화"라는 옵션은 존재하지 않고 자동 로테이션 요건과 무관. (D) 비대칭 + 존재하지 않는 옵션 조합으로 이중 부적합. 【시험 포인트】 자동 키 로테이션이 필요하면 → 대칭 고객 관리형 KMS 키. 비대칭 CMK는 자동 로테이션 불가.

해설

【핵심 용어】 ▸ S3 Block Public Access(계정 수준) — 계정 전체 버킷·객체의 공개 접근을 일괄 차단, 오구성·의도치 않은 노출 예방 ▸ 계정 수준 vs 버킷/객체 수준 — 계정 수준 설정이 가장 광범위하고 운영 오버헤드 최소 ▸ 데이터 노출 방지 — 공개 ACL/정책 무력화 【정답 포인트】 ▸ "의도치 않은 노출·오구성 최소화 + 최소 운영" → 계정 수준 S3 Block Public Access 한 번 설정으로 모든 버킷/객체를 포괄 보호 【오답 체크】 (B) 객체 단위 Block Public Access는 계정 수준보다 관리 범위가 좁고 오버헤드 증가. (C) 객체 ACL 비활성화만으로는 공개 접근 전반을 막는 포괄적 예방책이 아님. (D) PrivateLink는 접근 경로 제어이지 공개 노출 예방의 최소 오버헤드 해법이 아님(문항이 D 보기와 병합되어 불완전). 【시험 포인트】 S3 우발적 공개 노출 예방 + 최소 오버헤드 → 계정 수준 S3 Block Public Access.

해설

【핵심 용어】 ▸ CloudWatch Logs 교차 계정 구독(subscription) — 여러 계정의 로그를 실시간으로 한 계정에 스트리밍 ▸ Kinesis Data Firehose — 구독 대상으로 로그를 중앙 계정에 근실시간 집계 ▸ 근실시간 분석 — 로그를 중앙 집중해 이상 징후를 신속 분석 【정답 포인트】 ▸ "근실시간 + 모든 계정 로그를 중앙 집중" → CloudWatch 교차 계정 로그 데이터 공유(구독)를 각 계정에 설정하고 보안 담당 계정의 Kinesis Data Firehose로 전송 【오답 체크】 (A) 하루 4회 수동 복사·붙여넣기는 근실시간이 아니며 운영 불가능한 방식. (B) Logs Insights는 쿼리 도구로, 쿼리 결과를 구독으로 보내는 표준 집계 파이프라인이 아님. (C) Config 애그리게이터는 구성 데이터 집계용이지 애플리케이션 로그 근실시간 집계 대상이 아님. 【시험 포인트】 다계정 로그 근실시간 중앙 집계 → CloudWatch Logs 교차 계정 구독 → Kinesis Data Firehose.

해설

【핵심 용어】 ▸ S3 CRR + SSE-KMS — 암호화 객체 복제에는 복제 IAM 역할에 소스 키 복호화·대상 키 암호화 권한 필요 ▸ s3:GetObjectVersionForReplication — 복제 역할이 소스 객체(버전)를 읽는 데 필요 ▸ 소스 키 kms:Decrypt / 대상 키 kms:Encrypt — 소스에서 복호화, 대상 리전 키로 재암호화 【정답 포인트】 ▸ (C) 복제 역할에 소스 버킷 객체의 s3:GetObjectVersionForReplication 부여 ▸ (D) 소스(us-east-1) 키에 대한 kms:Decrypt 부여 → 암호화 객체 복호화 ▸ (F) 대상(us-west-2) 키에 대한 kms:Encrypt 부여 → 대상 객체 재암호화 → 세 권한이 갖춰져야 암호화 객체 복제 성공 【오답 체크】 (A) 대상 객체를 us-east-1 키로 암호화하도록 바꾸는 것은 리전 종속성상 부적합. (B) 소스 키의 kms:Encrypt는 복제 흐름(소스는 복호화, 대상은 암호화)과 맞지 않음. (E) 소스 키 정책을 엔지니어 IAM 계정에 Decrypt 부여하는 것은 복제 역할 권한 문제와 무관. 【시험 포인트】 SSE-KMS 객체가 CRR 안 됨 → 복제 역할에 GetObjectVersionForReplication + 소스 키 Decrypt + 대상 키 Encrypt.

해설

【핵심 용어】 ▸ GuardDuty 위임 관리자(delegated administrator) 계정 — 조직 findings가 집계되는 계정, 여기서 EventBridge 규칙 구성 ▸ EventBridge + SNS — GuardDuty finding(고심각도) 이벤트를 필터링해 이메일 알림 전송 ▸ 심각도 레벨 — high severity finding만 대상으로 규칙 매칭 【정답 포인트】 ▸ 조직 findings는 GuardDuty 위임 관리자 계정으로 모임 → 그 계정에서 고심각도 finding에 반응하는 EventBridge 규칙을 만들고 SNS 주제로 알림, SecOps 이메일 구독 → 실시간 이메일 알림 【오답 체크】 (A) 관리 계정은 GuardDuty findings 집계 지점이 아님(위임 관리자 계정이 집계 지점) → 규칙 위치가 잘못됨. (B) Config를 경유하는 방식은 불필요하게 복잡하고 실시간성이 떨어짐. (D) CloudTrail의 ListFindings API 호출에 반응하는 방식은 finding 발생 자체가 아니라 조회 행위에 반응하는 잘못된 트리거. 【시험 포인트】 조직 GuardDuty 고심각도 실시간 알림 → 위임 관리자 계정의 EventBridge 규칙 + SNS 이메일 구독.

해설

【핵심 용어】 ▸ SCP(서비스 제어 정책) — OU에 적용하면 하위 기존·신규 계정에 자동으로 상속·지속되는 권한 가드레일 ▸ 리전 제한 SCP — aws:RequestedRegion 조건으로 eu-west-1 외 리전 작업을 거부 ▸ OU 적용 범위 — development OU에 걸면 그 아래 모든 현재·미래 계정에 적용 【정답 포인트】 ▸ "development OU의 모든(기존·신규) 계정을 eu-west-1로 제한 + 지속" → development OU에 리전 제한 SCP 적용 → 하위 계정에 자동 상속되어 신규 계정에도 지속 ▸ 글로벌 서비스는 예외 처리하면서 eu-west-1 외 리전 작업을 거부하는 SCP 구성이 정답 【오답 체크】 (B) 개별 development "계정"에 적용하면 OU 하위 다른/신규 계정에 자동 확장되지 않음 → 지속·확장 요건 미충족. (C)(D) OU에 적용하지만 조건/거부 구조가 리전 제한 요구를 정확히 강제하지 못하는 함정 변형(잘못된 조건 키·리소스 범위 등). 【시험 포인트】 OU 단위 리전 제한을 기존·신규 계정에 지속 적용 → OU에 aws:RequestedRegion 조건의 리전 제한 SCP.