정답 · 해설

해설

【핵심 용어】 ▸ GuardDuty Trusted IP List — GuardDuty가 특정 IP에서의 활동을 무시하도록 설정하는 기능 ▸ S3 백업 — GuardDuty가 지원하는 신뢰 IP 목록의 저장 위치 【정답 포인트】 ▸ 구성 파일 형식 → A(평문) 또는 B(JSON) 중 선택하지 않음, 모두 지원되는 형식이므로 관계없음 ▸ 업로드 방식 → D 선택: S3 업로드 + GuardDuty에서 S3 URI를 참조하는 것이 공식 지원 방식 ▸ 직접 업로드(C, E) → GuardDuty는 S3 경로로 신뢰 IP 목록을 참조하므로 직접 업로드 불가 【오답 체크】 (A) 평문 파일은 가능하지만, A만으로는 불완전함. D와 함께 선택되어야 함 (B) JSON 형식도 가능하지만 문제에서는 형식보다 '업로드 방식'이 중요 (C) 직접 업로드는 지원되지 않음. GuardDuty는 S3 경로 참조만 지원 (E) 수동 붙여넣기는 확장성 없고 자동화되지 않음 【시험 포인트】 GuardDuty Trusted IP List 설정 패턴: 파일 생성 + S3 업로드 + S3 경로를 GuardDuty에서 참조. 많은 수의 IP를 관리할 때는 파일 형식(평문/JSON)과 무관하게 S3를 통한 자동화된 관리가 필수입니다.

해설

【핵심 용어】 ▸ IAM Access Analyzer — 리소스 접근 기록 확인, 하지만 자격 증명 남용 감지는 CloudTrail 기반 ▸ IAM 자격 증명 보고서 — 각 사용자의 액세스 키 활동, 마지막 사용 시간 기록 ▸ 키 비활성화 — 보안 키 사용 중단의 직접적인 방법 【정답 포인트】 ▸ B 선택: 노출된 액세스 키를 즉시 비활성화하여 추가 무단 사용 방지 (요구사항 2 충족) ▸ E 선택: IAM 자격 증명 보고서에서 마지막 사용 시간 확인 → 무단 사용 여부 파악 (요구사항 1 충족) ▸ 해설: E는 "이미 발생했는지" 탐지, B는 "앞으로 방지"하는 역할 분담 【오답 체크】 (A) Access Analyzer는 리소스 접근 기록을 보지만, 자격 증명 노출로 인한 "누가 언제 사용했는지"는 IAM 자격 증명 보고서와 CloudTrail 확인이 더 정확 (C) GuardDuty는 threat detection이지, 코드의 노출된 키를 "차단"하는 기능은 없음. 이미 공개 저장소에 있는 키는 차단 불가 (D) 새 키 생성은 "방지" 조치가 아니라 대체 조치. 먼저 기존 키를 비활성화해야 함 【시험 포인트】 IAM 자격 증명 노출 시나리오: 1) 탐지(CloudTrail/자격 증명 보고서) → 2) 즉시 비활성화(키 revoke) → 3) 대체 키 생성. 문제에서 "무단 사용 여부 파악" + "추가 사용 방지" 두 요구사항이 있으므로, 탐지 도구 (E) 와 차단 도구 (B) 를 모두 선택해야 합니다.

해설

【핵심 용어】 ▸ Presigned URL — 임시 토큰이 포함된 URL, 일시적 접근 권한을 부여 ▸ AWS STS (Security Token Service) — 임시 보안 자격 증명 발급 서비스 ▸ Instance Profile — EC2의 IAM 역할, 장기 자격 증명 보유 【정답 포인트】 ▸ 요구사항: "클라이언트는 임시 자격 증명만 사용" → presigned URL 생성에 사용되는 자격 증명도 임시여야 함 ▸ C 선택: STS를 사용하여 역할을 가정 → 임시 자격 증명 획득 → presigned URL 생성 ▸ 로직: Instance Profile(장기) → STS AssumeRole(임시) → Presigned URL 생성 → 클라이언트 전달 ▸ 목적: Presigned URL 자체는 임시이지만, "생성에 사용된 자격 증명"도 임시 자격 증명으로부터 생성되어야 함 【오답 체크】 (A) S3 버킷 정책은 presigned URL 생성 방식과 무관. Presigned URL은 생성 시점의 자격 증명에 기반하며, 리소스 태그 기반 필터링 필요 (B) 클라이언트별 태그 기반 제한은 좋은 실무 방법이지만, "임시 자격 증명" 요구사항을 직접 충족하지 않음 (D) IAM 사용자의 장기 액세스 키를 스크립트에 포함 → 보안상 가장 위험한 방식. "임시 자격 증명" 요구사항 위반 【시험 포인트】 Presigned URL 보안 모범 사례: 생성 시 사용되는 자격 증명은 가능한 한 단기 권한 집합으로 제한. STS로 "적절한 권한"을 가진 임시 역할을 가정한 후 presigned URL을 생성하면, 임시 자격 증명 요구사항과 최소 권한 원칙을 모두 만족합니다.

해설

【핵심 용어】 ▸ AWS Shield Advanced — DDoS 공격 탐지 및 완화 전담 서비스 ▸ Amazon Macie — 민감한 데이터 탐지(DDoS 아님) ▸ AWS WAF/Firewall Manager — 애플리케이션 계층 규칙(DDoS 트래픽 탐지 아님) ▸ Amazon Inspector — 취약점 스캔(DDoS 탐지 아님) 【정답 포인트】 ▸ DDoS "활성 이벤트" 탐지는 Shield Advanced의 전담 기능 ▸ Shield Advanced는 DDoS 공격 시 CloudWatch 메트릭 발행 → CloudWatch 알람으로 실시간 모니터링 가능 ▸ DDoS "발생 감지" → Shield Advanced Metrics → CloudWatch Alarm → SNS/Email 알림 【오답 체크】 (A) Macie는 S3의 민감한 데이터(PII, 신용카드 번호 등) 탐지 전문. 네트워크 트래픽 DDoS 탐지 불가 (B) Inspector는 EC2, ECR 취약점 스캔. DDoS 공격 탐지와 무관 (C) Firewall Manager는 여러 계정의 WAF/Shield 중앙 관리. DDoS "활성 이벤트" 메트릭 제공 안 함 (D) ✓ Shield Advanced만이 DDoS 공격 실시간 탐지 및 CloudWatch 메트릭 발행 【시험 포인트】 AWS 보안 서비스 역할 구분: Macie(데이터), Inspector(취약점), Firewall Manager(중앙 관리), Shield Advanced(DDoS). "DDoS 공격 발생 알림"은 Shield Advanced 메트릭만 사용 가능합니다.

해설

【핵심 용어】 ▸ AWS Elastic Disaster Recovery (DRS) — 온프레미스에서 AWS로의 지속적 서버 복제 전담 서비스 ▸ RTO 1시간 미만 → 지속적 블록 레벨 복제 필수 ▸ RPO (Recovery Point Objective) → DRS의 복제 에이전트는 거의 실시간 동기화 【정답 포인트】 ▸ "물리 서버와 가상 서버 지속적 복제" → AWS DRS의 핵심 기능 ▸ "RTO 1시간 미만" → DRS의 Continuous Replication + Automated Recovery으로 가능 ▸ "비용 최적화" → DRS는 증분 블록 복제로 대역폭 효율적 ▸ "자동화" → DRS의 기본 스테이징 영역(Default Staging Area)은 자동 설정 ▸ C 로직: 온프레미스 에이전트 설치 → 지속적 복제 → 장애 시 자동 failover 【오답 체크】 (A) AWS Backup은 "앱-인식 백업"이지, "지속적 블록 레벨 복제"가 아님. 복구 지점 간격이 크면 RPO 충족 어려움 (B) Storage Gateway Volume Gateway는 블록 스토리지 게이트웨이이지, "DR 레플리케이션" 전담 아님. EBS 스냅샷은 증분이지만 지속적 동기 복제 아님 (D) Direct Connect + Lambda + EventBridge는 수동 구성 필요. "자동화"와 "RTO 1시간" 달성 어려움 (C) ✓ DRS만이 온프레미스 물리/가상 서버의 지속적 복제, RTO < 1시간, 자동 failover 모두 지원 【시험 포인트】 DR 솔루션 선택 기준: "지속적 복제" + "RTO < 1시간" + "물리/가상 서버 혼합" → AWS Elastic Disaster Recovery (DRS). Backup/Storage Gateway/Direct Connect는 부분적 요구사항만 충족합니다.

해설

【핵심 용어】 ▸ Cognito Pre Sign-up Lambda Trigger — 사용자 가입 직전 커스텀 검증 로직 실행 ▸ AWS WAF Geographic Matching — IP 지역 정보 기반 요청 필터링 ▸ Cognito Hosted UI — 관리형 인증 UI, WAF 연결 가능 【정답 포인트】 ▸ "커스텀 검증" + "수락/거부" → Lambda Pre Sign-up Trigger (A) ▸ "지리적 위치 기반 필터링" → AWS WAF Geographic Match Rule (B) ▸ 두 가지 보호층: 1) WAF에서 지역 외 요청 조기 차단 2) Lambda에서 추가 비즈니스 로직 검증 ▸ Lambda는 요청의 userAttributes, validationData를 받아 AutoConfirmUser 플래그로 수락/거부 결정 ▸ WAF는 Source IP 기반 지역 판별 → Block 또는 Allow 【오답 체크】 (C) 앱 클라이언트 ID는 인증 클라이언트 식별용. "지역 기반 검증" 기능 없음 (D) Cognito 자체에는 "지리 제한 설정"이 없음 (4.x 시점). WAF나 Lambda로 구현 필요 (E) 소셜 IdP (Google, Facebook 등)는 "위치 검증"과 무관. 가입자 본인 인증만 담당 【시험 포인트】 Cognito 보안 강화 패턴: Lambda Trigger (비즈니스 로직) + WAF (네트워크 레벨). "지역 외 부정 가입 차단"은 WAF의 지리 매칭 규칙으로 조기 차단하고, Lambda Pre Sign-up으로 추가 커스텀 검증을 수행하는 2단계 방어입니다.

해설

【핵심 용어】 ▸ AWS IAM Identity Center — 조직 전체 중앙 SSO 관리 서비스 ▸ AWS Managed Application — Identity Center와 통합된 SaaS 애플리케이션 ▸ Amazon Cognito — 애플리케이션 수준 인증(조직 전체 중앙 관리용 아님) ▸ Identity Pool — Cognito의 임시 AWS 자격 증명 발급 (AWS 리소스 접근용) 【정답 포인트】 ▸ "조직 전체" + "중앙 관리" → IAM Identity Center (AWS Organizations과 통합) ▸ "Amazon Q Developer" → AWS 관리형 애플리케이션으로 등록 가능 ▸ IAM Identity Center에 Q Developer를 추가 → 모든 멤버 계정 사용자에게 SSO로 접근 권한 부여 ▸ 로직: Organizations 조직 → Identity Center 활성화 → Q Developer (AWS Managed App) 추가 → 사용자/그룹에 권한 할당 【오답 체크】 (B) Cognito + "새로운 ID 풀" → 애플리케이션별 임시 AWS 자격 증명 발급용. "조직 전체 중앙 SSO" 구조 아님 (C) Cognito + AWS Managed Application → 조직 수준이 아닌 개별 애플리케이션 수준 인증. 중앙 관리 불가 (D) IAM Identity Center + "ID 풀" → Identity Center는 권한 집합으로 관리. ID 풀은 Cognito 개념 (A) ✓ IAM Identity Center + AWS Managed Application = 조직 전체 중앙 SSO 관리 【시험 포인트】 AWS Organizations 통합 SSO: IAM Identity Center (formerly AWS SSO) 사용. "조직 전체 중앙 관리" 요구사항은 IAM Identity Center의 설계 목적입니다. Amazon Q Developer는 AWS 관리형 애플리케이션으로서 Identity Center와 즉시 통합됩니다.

해설

【핵심 용어】 ▸ AWS Shield Advanced — DDoS 공격 완화, AWS DDoS Response Team(DRT) 지원 ▸ AWS WAF — 애플리케이션 계층(L7) DDoS 규칙 기반 차단 ▸ VPC Flow Logs — 네트워크 트래픽 로그 수집 (실시간 차단은 아님) ▸ GuardDuty — 위협 탐지 (DDoS 공격 특화 아님) 【정답 포인트】 ▸ B 선택: Shield Advanced 구독 → AWS DRT 지원 → "대응 시간 최소화" - DRT는 공격 분석, 완화 규칙 추천, 실시간 지원 제공 - Shield Advanced의 자동 완화 + 전문가 지원으로 빠른 대응 ▸ E 선택: AWS WAF 규칙 생성 → L7 DDoS 트래픽 필터링 - Rate-based 규칙, IP reputation, 지역 제한 등으로 자동 차단 ▸ 조합: Shield Advanced(L3-L4) + WAF(L7) = 다층 DDoS 방어 【오답 체크】 (A) GuardDuty는 악성 활동(malware, intrusion 탐지). DDoS "공격 감지 및 자동 차단" 기능 없음 (C) VPC Flow Logs는 분석용(사후 조사). Lambda로 "자동 차단"은 지연 발생. "최소화 다운타임" 요구사항 충족 어려움 (D) CloudTrail/Config/Systems Manager는 설정 감사/복구. "네트워크 트래픽" DDoS 차단과 무관 (B) ✓ Shield Advanced + DRT = 가장 빠른 전문가 지원 (E) ✓ WAF 규칙 = L7 DDoS 자동 필터링 【시험 포인트】 DDoS 공격 대응 "다운타임 최소화": 1) Shield Advanced 가입 (DRT 지원 포함) → 전문가 조언 + 자동 완화 2) WAF 규칙 사전 구성 → 공격 패턴 자동 차단. "자동화된 빠른 대응"이 핵심입니다.

해설

【핵심 용어】 ▸ Gateway VPC Endpoint for S3 — S3 접근을 위한 프라이빗 경로, 공개 인터넷 불필요 ▸ VPC Peering — VPC 간 직접 연결 (다른 계정도 가능) ▸ Transit Gateway — 중앙 집중식 VPC 연결 허브 ▸ VPN Connection — 암호화 터널 (오버헤드 증가) 【정답 포인트】 ▸ 요구사항: "공개 인터넷 사용 불가" + "Account A → Account B S3 쓰기" ▸ "이미 권한 있음" → IAM 권한은 OK, "네트워크 경로"만 필요 ▸ Gateway VPC Endpoint는: - Account A 내 VPC에만 생성 - S3로의 트래픽을 AWS 내부 경로로 라우팅 (공개 인터넷 불필요) - 크로스 계정 S3 접근도 지원 (IAM 정책으로 제어) - 추가 비용 없음 - 간단한 라우팅 테이블 업데이트만 필요 【오답 체크】 (A) Transit Gateway는 다중 VPC 연결에 유용하지만, "Account A → S3" 단순 경로는 과도 (B) VPN 어플라이언스는 암호화 오버헤드 + 관리 복잡. Gateway Endpoint가 더 효율적 (C) VPC Peering은 Account A ↔ Account B VPC 연결만 가능. 이미 권한 있으면 S3 접근 가능하지만, "더 효율적인" Gateway Endpoint가 있음 (D) ✓ Gateway Endpoint = 최단 경로, 비용 효율적, 공개 인터넷 우회 【시험 포인트】 VPC Endpoint 선택: "특정 AWS 서비스로의 프라이빗 접근" → Gateway Endpoint (S3, DynamoDB). "프라이빗 서비스 엔드포인트" → Interface Endpoint. Account 간 S3 접근은 "권한" (IAM) + "경로" (Gateway Endpoint)로 충분합니다.

해설

【핵심 용어】 ▸ AWS Config Managed Rule — 리소스 규정 준수 자동 확인 ▸ AWS-EnableCloudTrail — CloudTrail 상태 확인 + 자동 복구 규칙 ▸ EventBridge → Lambda — 이벤트 기반 트리거 (이벤트 순서 의존) ▸ Automated Remediation — Config의 자동 복구 기능 【정답 포인트】 ▸ "여러 리전에서" + "자동 복구" → Config Managed Rule + Auto Remediation ▸ AWS-EnableCloudTrail (Managed Rule) 의 기능: - 모든 리전에서 CloudTrail 활성화 상태 주기적 확인 - CloudTrail이 비활성화되면 자동으로 StartLogging 호출 - Compliance 대시보드에서 추적 ▸ "가장 효율적" → Config의 관리형 규칙은 사전 검증, 유지보수 불필요 【오답 체크】 (B) EventBridge + Lambda는 이벤트 기반 반응형 접근 - CloudTrail "중지" 이벤트를 감지해야 하는데, 이는 CloudTrail 자체가 비활성화되면 이벤트 생성 안 됨 (catch-22) - EventBridge는 실시간이지만 정기적 확인 안 함 (C) CloudWatch 알람은 메트릭 기반. CloudTrail 상태(활성/비활성)는 메트릭 아님 (D) Trusted Advisor는 "주 1회" 수준의 검사. "자동 복구" 기능 없음 (A) ✓ Config Managed Rule = 정기적 확인 + 자동 복구 + 다중 리전 지원 【시험 포인트】 CloudTrail 자동 보호: AWS Config의 "AWS-EnableCloudTrail" Managed Rule이 표준. "자동" + "다중 리전" + "효율적"이라는 조건에서 Config의 Managed Rule은 사전 구성되어 있으므로 즉시 배포 가능합니다.

해설

【핵심 용어】 ▸ IAM Roles Anywhere — 온프레미스 시스템에서 X.509 인증서로 임시 AWS 자격 증명 획득 ▸ Certificate-based Authentication — 공개 키 인증서(X.509) 사용 ▸ AWS Private CA — 조직 내 인증서 발급 (IAM Roles Anywhere와 함께 사용) ▸ Bastion Host — SSH 키 기반 점프 서버 (제거 대상) 【정답 포인트】 ▸ "Bastion host 제거" + "인증서 기반 인증" + "온프레미스 → AWS 리소스" → IAM Roles Anywhere ▸ IAM Roles Anywhere 아키텍처: 1. Private CA에서 온프레미스 시스템을 위한 X.509 인증서 발급 2. 온프레미스 시스템이 Credential Helper Tool로 인증서 제시 3. IAM Roles Anywhere이 인증서 검증 후 임시 자격 증명 발급 (STS AssumeRole) 4. 임시 자격 증명으로 S3, DynamoDB 접근 ▸ "인증서 기반" 요구사항 ✓, "Bastion 제거" ✓, "임시 자격 증명" ✓ 【오답 체크】 (A) Direct Connect + VPC Endpoint는 "네트워크 경로" 개선이지, "인증 방식"을 바꾸지 않음. Bastion 대체 안 됨 (B) ✓ IAM Roles Anywhere = 인증서 기반 인증 + 임시 자격 증명 + Bastion 불필요 (C) Private CA만으로는 AWS 리소스 접근 불가. IAM Roles Anywhere와 함께 사용되어야 함 (부분적) (D) IAM 사용자의 장기 액세스 키 기반. "인증서 기반"이 아니고, Bastion과 같이 온프레미스에서 키 관리 필요 【시험 포인트】 Bastionless 온프레미스 → AWS: IAM Roles Anywhere + Private CA 조합. 온프레미스 시스템의 X.509 인증서로 임시 AWS 자격 증명을 획득하는 "인증서 기반 인증" 패턴은 SCS-C03의 핵심 주제입니다.

해설

【핵심 용어】 ▸ AWS IAM Identity Center — 조직 전체 중앙 SSO, 외부 IdP 연결, 임시 자격 증명 발급 ▸ SAML-based IdP — 온프레미스 또는 클라우드의 ID 공급자 (Okta, Azure AD 등) ▸ Permission Set — Identity Center의 권한 모음 (IAM 정책과 유사) ▸ Session Duration Limit — 자동으로 임시 자격 증명 만료 시간 설정 【정답 포인트】 ▸ "조직 전체" + "SAML 기반 IdP" + "60분 임시 자격 증명" → IAM Identity Center ▸ IAM Identity Center 설정: 1. External IdP (SAML) 설정 2. Permission Set 생성 (사용자 권한 정의) 3. Session Duration Limit = 60분 4. 사용자가 SSO 포털 또는 AWS CLI로 로그인 → 자동으로 임시 자격 증명 발급 ▸ "IAM 사용자 제거" → 장기 액세스 키 제거, SSO 중심으로 전환 【오답 체크】 (A) AWS STS 직접 사용은 "조직 전체 중앙 관리"가 아님. "사용자가 수동으로 get-session-token" 실행 필요 (B) ✓ IAM Identity Center = SAML + 임시 자격 증명 + 세션 기간 제한 + 조직 전체 SSO (C) Secrets Manager + Cognito는 애플리케이션 수준 인증. "조직 전체 SSO" 구조 아님 (D) IAM Roles Anywhere는 "인증서 기반 온프레미스 접근". "SAML IdP" + "조직 전체 SSO" 요구사항과 맞지 않음 【시험 포인트】 AWS Organizations 전체 SSO + SAML: IAM Identity Center (formerly AWS SSO) 사용. Identity Center는 외부 SAML IdP 연결, 권한 집합(Permission Set) 기반 권한 관리, 세션 기간 제한 (자동 임시 자격 증명 만료)을 지원하는 조직 수준 SSO 솔루션입니다.

해설

【핵심 용어】 ▸ CloudTrail 관리 이벤트(management events) — 리소스 구성 변경(예: PutBucketPolicy, DeleteBucketPolicy) 기록 ▸ CloudTrail 데이터 이벤트(data events) — 객체 수준 작업(예: s3:PutObjectAcl, GetObject) 기록, 기본 비활성 ▸ EventBridge — CloudTrail 로그 기반 특정 API 호출 패턴 매칭 【정답 포인트】 ▸ PutBucketPolicy/DeleteBucketPolicy는 관리 이벤트라 기본 CloudTrail 구성으로 캡처되어 EventBridge 이벤트 발생 ▸ s3:PutObjectAcl은 객체 수준 = 데이터 이벤트라 기본 구성에서 기록되지 않아 이벤트 미발생 → 데이터 이벤트 로깅을 켜야 함 【오답 체크】 (A) 이벤트 패턴을 All Events로 바꿔도 CloudTrail이 해당 호출을 기록하지 않으면 소용없음. (B) Bucket Level Operations 선택도 데이터 이벤트가 로깅되지 않으면 무효. (C) CloudTrail Insights는 비정상 API 활동량 탐지용으로 특정 호출 캡처와 무관. 【시험 포인트】 객체 수준 API(PutObjectAcl, GetObject 등)를 잡으려면 CloudTrail 데이터 이벤트를 별도로 활성화.

해설

【핵심 용어】 ▸ AWS WAF Logging — 애플리케이션 계층(L7) 요청 분석 로그 ▸ S3 → Athena — 비용 효율적, 즉시 쿼리 가능한 분석 ▸ Partition Projection — Athena의 자동 파티션 추론 기능 ▸ CloudTrail — API 호출 기록 (WAF 로그용 아님) 【정답 포인트】 ▸ WAF 로그는 "CloudTrail이 아닌 S3"로 직접 전송 ▸ S3 로그 + Athena = 표준 WAF 분석 스택: 1. WAF → S3 로그 저장 2. Athena 테이블 생성 + Partition Projection 3. SQL로 WAF 로그 쿼리: User-Agent, Source IP, Request Count, Block/Allow 통계 등 ▸ 비용: Athena 요금만 (Firehose 추가 비용 없음) ▸ 속도: 바로 쿼리 가능 【오답 체크】 (A) CloudTrail은 AWS API 호출 기록. WAF 로그는 CloudTrail에 저장되지 않음. "WAF가 CloudTrail로 전송"은 오류 (B) OpenSearch는 실시간 스트리밍에 유리하지만, S3 기반 배치 분석에는 오버헤드. Partition Projection은 Athena 기능 (OpenSearch 아님) (C) ✓ WAF → S3 → Athena + Partition Projection = 표준 (D) CloudTrail 오류 + Firehose 추가 비용 【시험 포인트】 WAF 로그 분석: 저장소(S3) + 쿼리 엔진(Athena). "애플리케이션 계층 공격 분석"은 WAF 로그의 Request/Response 필드, User-Agent, Source IP, 차단된 규칙 등을 SQL로 분석합니다.

해설

【핵심 용어】 ▸ Amazon GuardDuty Delegated Administrator — 중앙 계정에서 모든 멤버 계정 관리 ▸ AWS Organizations Integration — GuardDuty는 조직 전체 멤버 자동 검색 ▸ GuardDuty Findings → EventBridge → SNS → Email — 5분 이내 실시간 알림 ▸ AWS Control Tower Audit Account — 보안 findings 중앙화 대상 【정답 포인트】 ▸ "50개 계정 중앙화" + "실시간 5분 이내 알림" → GuardDuty Delegated Administrator ▸ GuardDuty 아키텍처: 1. 감사 계정 = GuardDuty Delegated Administrator 2. 조직의 모든 멤버 계정 자동 관리 (수동 초대 불필요) 3. 모든 findings는 감사 계정에 중앙화 4. EventBridge가 GuardDuty findings 실시간 감지 5. SNS로 이메일 알림 (5분 이내) ▸ "가장 효율적": Delegated Administrator는 초기 설정 후 자동 관리 【오답 체크】 (A) ✓ GuardDuty Delegated Administrator = 중앙화 + 자동 관리 + 실시간 findings (B) 각 계정에 수동으로 GuardDuty 설정 → 확장성 낮음. CloudWatch 알람은 "findings"가 아닌 "메트릭" 기반 (C) AWS Config는 "리소스 규정 준수" 감시 (위협 탐지 아님). Lambda로 S3 폴링은 지연 발생 (5분 내 어려움) (D) Amazon Inspector는 "취약점 스캔" (EC2만 해당). "모든 계정의 위협 탐지" 요구사항과 맞지 않음 【시험 포인트】 다중 계정 위협 탐지 중앙화: GuardDuty Delegated Administrator + EventBridge + SNS. GuardDuty의 "조직 통합" 기능으로 모든 멤버 계정을 자동으로 관리하고, findings는 실시간으로 감사 계정으로 중앙화됩니다.

해설

【핵심 용어】 ▸ Shield Advanced Automatic Application Layer DDoS Mitigation — L7 DDoS "자동" 완화 ▸ WAF Rate-based Rules — 요청 속도 기반 자동 차단 ▸ CloudFront Shield Advanced Integration — CloudFront에서 L3-L4 + L7 보호 【정답 포인트】 ▸ "실시간 자동" + "Layer 7 DDoS" → Shield Advanced + Automatic DDoS Mitigation ▸ Shield Advanced (CloudFront)의 자동 완화 기능: 1. L3-L4 공격: 자동 스크러빙 센터 필터링 2. L7 공격: "Automatic Application Layer DDoS Mitigation" 옵션으로 자동 차단 3. WAF Rate-based 규칙과 함께 사용 시 효과 극대화 ▸ "수동 작업 불필요" → Lambda 커스텀 규칙 관리 불필요 ▸ D의 조합: Rate-based Rules(정밀) + Shield Advanced(자동) = 다층 방어 【오답 체크】 (A) Shield Advanced만으로는 "자동 완화" 기능 미흡. CloudWatch 알람은 "탐지" (완화 아님) (B) Proactive Engagement는 DRT의 "전문가 지원". "자동 완화" 아님 (C) Network Firewall + Lambda → 수동 규칙 업데이트 필요. "자동" 요구사항 미충족 (D) ✓ Rate-based Rules + Shield Advanced + Automatic Mitigation = 완전 자동 【시험 포인트】 CloudFront L7 DDoS 완전 자동 방어: Shield Advanced의 "Automatic Application Layer DDoS Mitigation" 옵션 활성화. 이 옵션은 AWS ML 모델로 비정상 패턴 자동 감지 후 임시 규칙 생성 및 적용하여 수동 개입 없이 공격 완화합니다.

해설

【핵심 용어】 ▸ Service Control Policy (SCP) — 조직 전체 또는 계정 단위 "거부" 권한 정책 (IAM 정책보다 상위) ▸ "Prevention" (방지) vs "Detection" (탐지) → "생성 방지"는 SCP 영역 ▸ Security Group Rule 생성 → ec2:AuthorizeSecurityGroupIngress API 【정답 포인트】 ▸ "보안 그룹 규칙 생성을 방지" → "사후 탐지"가 아닌 "사전 방지"가 필요 ▸ SCP의 거부 문(Deny statement)로 구현: ```json { "Effect": "Deny", "Action": "ec2:AuthorizeSecurityGroupIngress", "Resource": "arn:aws:ec2:eu-central-1:*:security-group/*", "Condition": { "StringLike": {"ec2:IpProtocol": "tcp"}, "NumericLike": {"ec2:FromPort": "22"}, "IpAddress": {"ec2:CidrIp": "0.0.0.0/0"} } } ``` ▸ SCP는 조직의 모든 멤버 계정에 적용 (실수 방지) 【오답 체크】 (A) CloudTrail + CloudWatch + SNS = "탐지 + 알림". "방지"하지 못함. 규칙 생성 후 알림 받음 (B) EventBridge + Lambda = "탐지 후 삭제". "생성 방지"가 아님. 이미 생성된 규칙을 제거하는 사후 조치 (D) Network Firewall = "네트워크 트래픽" 필터링 ("보안 그룹 규칙 생성" 방지와 무관) (C) ✓ SCP = "보안 그룹 규칙 생성 자체를 거부" → 가장 확실한 방지 【시험 포인트】 AWS Organizations 규정 준수 강화: "생성 방지"는 "탐지 후 수정"보다 강력. SCP는 조직 수준에서 위험한 액션 전체를 거부하므로, 개별 계정의 IAM 정책이나 수동 규칙으로 우회 불가능합니다. 이 문제는 "방지(Prevention)"가 명시되어 있으므로 SCP 선택이 확실합니다.

해설

【핵심 용어】 ▸ AWS WAF rate-based rule — 단일 IP의 요청률이 임계치 초과 시 차단/제한, 대량 악성 트래픽 완화 ▸ WAF geo match rule — 국가 단위 차단(합법 사용자까지 차단 위험) ▸ Security Group — IP/포트 기반, 지리 매칭 미지원 【정답 포인트】 ▸ "잠재적 악성 요청을 빠르게 제한" + "정상 사용자 접근은 막지 않음" → rate-based rule이 비정상 고빈도 소스만 제한 ▸ 수백 개 IP가 대량 요청을 보내므로 요청률 기반 제한이 정상 사용자 영향 최소화 【오답 체크】 (B) 국가 전체 geo 차단은 해당 국가의 정상 사용자까지 모두 차단해 요구 위반. (C) 보안 그룹은 지리 기반 매칭 규칙을 지원하지 않음. (D) 수백 개 IP를 SG 거부 규칙으로 수동 관리하는 것은 비현실적이고 IP가 바뀌면 무력. 【시험 포인트】 분산된 대량 요청을 정상 사용자 영향 없이 빠르게 완화 → WAF rate-based rule. 국가 차단은 정상 사용자까지 배제.

해설

【핵심 용어】 ▸ AWS Secrets Manager — 시크릿(API 키 등) 중앙 저장·암호화·자동 교체, KMS로 암호화, IAM으로 접근 제어 ▸ AWS KMS — Secrets Manager 시크릿 암호화 키 ▸ CodeCommit — Git 리포지토리, 시크릿을 소스코드와 분리 저장하는 용도 아님 【정답 포인트】 ▸ "API 키를 암호화 + 소스코드와 분리 + 중앙 보안 계정 저장" → 보안 계정의 Secrets Manager에 KMS 암호화로 저장 ▸ Lambda의 IAM 역할에 접근 권한을 부여해 런타임에 키를 조회하여 API 호출 【오답 체크】 (A) CodeCommit 리포지토리로 옮겨도 결국 소스와 함께 저장돼 "분리" 요구 미충족. (B) S3 SSE-S3 + presigned URL 방식은 키 관리가 불안정하고 복잡하며 중앙 시크릿 관리 표준이 아님. (D) Lambda 환경 변수는 DevOps 계정에 저장되어 "중앙 보안 계정 분리" 요구를 만족하지 못함. 【시험 포인트】 API 키/DB 자격증명 등 시크릿의 중앙 암호화 저장·접근 제어 → Secrets Manager + KMS + IAM 역할.

해설

【핵심 용어】 ▸ AWS CloudTrail — 모든 API 호출 기록, 실패한 호출·오류 원인 추적의 1차 진단 도구 ▸ SCP (Service Control Policy) — OU/계정의 권한 상한선 ▸ CloudFormation 실행 역할 — 스택이 리소스를 생성/변경할 때 사용하는 IAM 역할 【정답 포인트】 ▸ "insufficient IAM permissions 오류의 FIRST 진단 단계" → Production 계정의 CloudTrail 로그에서 실패한 CloudFormation API 호출을 확인해 원인 특정 ▸ 무작정 설정을 바꾸기 전에 어떤 호출이 왜 거부됐는지 근거 확보가 우선 【오답 체크】 (B) 모든 SCP 제거는 위험하고 보안을 훼손하는 성급한 조치, FIRST 단계 아님. (C) 실행 역할 권한 확인은 유효한 조치지만 원인 진단(CloudTrail) 이후 단계. (D) SCP를 Testing과 동일하게 맞추는 것은 진단 없이 변경하는 성급한 조치. 【시험 포인트】 권한 오류 트러블슈팅의 첫 단계는 항상 CloudTrail로 어떤 API가 왜 거부됐는지 확인.