문제 7 오답 (선택: A)
한 애플리케이션이 VPC 내부에서 S3로 데이터를 전송해야 하지만, 트래픽이 인터넷을 거치지 않아야 합니다. 어떤 솔루션이 적합합니까?
A. NAT 게이트웨이
NAT 게이트웨이는 결국 인터넷 게이트웨이를 통해 외부로 나가는 경로이므로 요구사항(인터넷 비경유)에 맞지 않습니다.
B. 인터넷 게이트웨이
이름 그대로 인터넷을 경유하는 구성요소라 요구사항과 정반대입니다.
C. Gateway 타입 VPC 엔드포인트
D. VPN 연결
VPN은 온프레미스와 VPC를 연결하는 용도로, S3 접근 경로 자체를 인터넷 없이 제공하는 솔루션은 아닙니다.
문제 12 오답 (선택: A)
회사는 PCI-DSS 컴플라이언스를 위해 AWS 리소스 구성이 지속적으로 규정을 준수하는지 모니터링해야 합니다. 적합한 서비스는?
A. AWS Trusted Advisor만 사용
Trusted Advisor는 일반적인 모범 사례 점검 도구로, PCI-DSS 같은 특정 컴플라이언스 표준에 대한 지속적·세부적 평가에는 한계가 있습니다.
B. AWS Config + Conformance Pack
C. Amazon Inspector만 사용
Inspector는 소프트웨어 취약점 스캔에 특화된 도구로, 리소스 구성의 컴플라이언스 준수 여부를 평가하는 도구가 아닙니다.
D. AWS Budgets
Budgets는 비용 관리 도구로 보안 컴플라이언스와는 무관합니다.
PCI-DSS(Payment Card Industry Data Security Standard)는 신용카드/체크카드 결제 정보를 다루는 모든 사업자가 지켜야 하는 보안 표준입니다. Visa, Mastercard, American Express, Discover, JCB 같은 주요 카드사들이 공동으로 만든 민간 표준(법률은 아닙니다)이며, PCI Security Standards Council이라는 기구에서 관리하고 있습니다.
AWS 환경에서 SCS-C03 시험과 관련해서 보면, AWS 자체는 PCI DSS Level 1 서비스 제공자로 인증을 받았지만, 이는 “공동 책임 모델(Shared Responsibility Model)“에 따라 AWS는 인프라(데이터센터, 물리 보안, 하이퍼바이저 등)에 대한 컴플라이언스만 책임지고, 그 위에서 동작하는 애플리케이션, 데이터 암호화 설정, IAM 권한, 로깅 구성 등은 사용자(고객)가 직접 PCI-DSS 요구사항에 맞게 구성해야 합니다. 그래서 앞서 다룬 문제에서 나온 AWS Config + Conformance Pack 같은 도구로 사용자 환경이 지속적으로 PCI-DSS 기준을 준수하고 있는지 자동으로 점검하게 됩니다.
문제 22 오답 (선택: D)
한 회사가 Direct Connect를 통해 온프레미스와 AWS를 연결하면서 전송 데이터의 기밀성을 추가로 보장하고자 합니다. 적합한 방법은?
A. Direct Connect는 기본적으로 암호화되므로 추가 조치 불필요
일반 Direct Connect 연결 자체는 기본적으로 암호화되지 않습니다(전제가 틀림).
B. Direct Connect 위에 VPN(IPsec)을 구성하여 암호화 계층 추가, 또는 MACsec 지원 사용
C. NACL만 강화
NACL은 트래픽 필터링 기능이지 암호화 기능이 아닙니다.
D. VPC 피어링 사용
VPC 피어링은 VPC 간 연결을 위한 것으로 온프레미스-AWS 간 전송 암호화와는 무관합니다.
도메인 1. 위협 탐지 및 사고 대응 (Threat Detection and Incident Response) — 14%
핵심 서비스: GuardDuty, Security Hub, Detective, Macie, Inspector
- GuardDuty: 위협 탐지 서비스. CloudTrail, VPC Flow Logs, DNS 로그, S3 데이터 이벤트, EKS 감사 로그를 분석. 멀티 계정은 위임 관리자(Delegated Administrator) 구조로 중앙화.
- Security Hub: 여러 보안 서비스의 탐지 결과를 통합. CIS, PCI-DSS, AWS FSBP 등 컴플라이언스 표준 동시 평가 가능.
- Detective: 보안 조사를 위한 그래프 기반 분석 도구. GuardDuty 탐지 결과의 근본 원인 분석에 사용.
- 사고 대응 절차: 격리(보안 그룹 변경) → 스냅샷/메모리 덤프로 증거 보존 → 별도 포렌식 환경에서 분석 → 절대 종료/재부팅/로그 삭제 금지.
- 자동 대응: EventBridge 규칙 + Lambda로 GuardDuty/Security Hub 탐지 결과에 따라 자동 격리·알림 구성 (SOAR 패턴).
도메인 2. 보안 로깅 및 모니터링 (Security Logging and Monitoring) — 18%
핵심 서비스: CloudTrail, CloudWatch, VPC Flow Logs, Config
- CloudTrail: 모든 API 호출 기록. 로그 파일 무결성 검증(Log File Validation)으로 변조 여부 확인. Organization Trail로 전 계정 통합 가능.
- CloudWatch Logs: 구독 필터(Subscription Filter)로 실시간 스트리밍, Logs Insights로 쿼리.
- VPC Flow Logs: 네트워크 트래픽 메타데이터 기록(페이로드는 기록 안 함).
- AWS Config: 리소스 구성 변경 이력 추적, Conformance Pack으로 컴플라이언스 규정 묶음 평가.
- 로그 보존: S3 라이프사이클 정책 + Object Lock(컴플라이언스 모드)으로 장기 보존 및 삭제 방지.
도메인 3. 인프라 보안 (Infrastructure Security) — 20%
핵심 서비스: VPC, Security Group, NACL, WAF, Shield, Network Firewall, Firewall Manager
- 보안 그룹 vs NACL: 보안 그룹은 Stateful(인스턴스 단위), NACL은 Stateless(서브넷 단위, 인바운드/아웃바운드 별도 규칙).
- VPC 엔드포인트: Gateway 타입(S3, DynamoDB, 무료) vs Interface 타입(PrivateLink 기반, 대부분의 서비스, ENI 사용, 유료).
- WAF: L7(HTTP/HTTPS) 트래픽 필터링. SQL Injection, XSS 등 방어. Rate-based rule로 DDoS 일부 완화.
- Shield Standard vs Advanced: Standard는 무료 기본 보호, Advanced는 비용 보호 + DRT(DDoS Response Team) 지원 + WAF 비용 포함.
- Network Firewall: Stateful/Stateless 규칙 그룹, 도메인 기반 필터링 지원(보안 그룹/NACL은 불가).
- Firewall Manager: Organization 전체에 WAF/Shield/보안그룹/Network Firewall 정책을 중앙 배포·관리.
도메인 4. ID 및 액세스 관리 (Identity and Access Management) — 16%
핵심 서비스: IAM, Organizations(SCP), IAM Identity Center, STS
- 정책 평가 우선순위: 명시적 거부(Explicit Deny) > 명시적 허용 > 기본 거부. SCP·권한 경계·IAM 정책이 모두 허용해야 최종 허용(교집합 구조).
- SCP: Organization 단위 가드레일. 루트 사용자를 포함한 계정 내 모든 IAM 주체에 적용. 권한을 부여하지 않고 상한선만 설정.
- 권한 경계(Permission Boundary): 특정 IAM 사용자/역할에 적용되는 최대 권한 범위. SCP와 달리 개별 엔터티 단위.
- 교차 계정 접근: IAM 역할 + AssumeRole(STS)이 표준 패턴. Access Key 공유나 퍼블릭 권한 부여는 지양.
- MFA 강제:
aws:MultiFactorAuthPresent조건 키로 IAM 정책에서 제어. - IAM Access Analyzer: 조직 외부에 의도치 않게 공유된 리소스(S3, IAM 역할, KMS 키 등)를 식별.
도메인 5. 데이터 보호 (Data Protection) — 18%
핵심 서비스: KMS, Secrets Manager, ACM, Macie
- KMS: 키 정책(Key Policy)이 기본 접근 제어 메커니즘이며 IAM 정책과 함께 평가됨. CMK(고객 관리형) vs AWS 관리형 키 vs 고객 제공 키(BYOK)의 관리 부담 차이.
- 저장 시 암호화(at-rest): S3 SSE-S3/SSE-KMS, EBS 기본 암호화(계정 단위 설정 가능), RDS는 생성 후 직접 암호화 전환 불가 → 스냅샷 복사 방식 사용.
- 전송 중 암호화(in-transit): TLS/HTTPS, RDS SSL 강제, VPN/Direct Connect + MACsec. SSE류는 저장 시 암호화이지 전송 중 암호화가 아님을 구분.
- Secrets Manager vs Parameter Store: Secrets Manager는 자동 회전(rotation) 지원, DB 자격 증명에 특화. Parameter Store SecureString은 더 단순한 키-값 저장.
- Macie: S3에 저장된 PII 등 민감 데이터 자동 탐지.
도메인 6. 관리 및 보안 거버넌스 (Management and Security Governance) — 14%
핵심 서비스: Organizations, Control Tower, Config, Trusted Advisor
- 멀티 계정 전략: Organizations + SCP로 가드레일, Control Tower로 계정 프로비저닝 자동화.
- 컴플라이언스 자동화: Config + Conformance Pack으로 PCI-DSS, HIPAA 등 표준 지속 평가(Trusted Advisor는 일반적 권고 수준).
- 공동 책임 모델(Shared Responsibility Model): AWS는 “클라우드 자체의 보안”(인프라, 하드웨어), 고객은 “클라우드 내부의 보안”(데이터, IAM, 애플리케이션 설정) 책임.
- 침투 테스트 정책: 대부분의 서비스는 사전 승인 없이 허용되나 DNS 존워킹 등 일부 활동은 금지·제한되어 있어 AWS 정책 문서 확인 필요.
문제 2 오답 (선택: B)
다음 IAM 정책을 사용자에게 단독으로 연결했을 때의 의미로 옳은 것은?
{ “Effect”: “Allow”, “NotAction”: “iam:”, “Resource”: "" }
A. iam: 으로 시작하는 작업을 제외한 나머지 모든 작업을 허용한다
B. iam: 으로 시작하는 작업만 허용한다
NotAction은 명시한 작업을 ‘제외’하고 나머지를 대상으로 하므로 정반대의 설명입니다.
문제 8 오답 (선택: B)
다음 VPC 엔드포인트 정책이 연결된 Gateway 엔드포인트를 통한 트래픽에 미치는 효과는?
{ “Statement”: [{ “Effect”: “Allow”, “Principal”: "", “Action”: “s3:”, “Resource”: [ “arn:aws:s3:::allowed-bucket”, “arn:aws:s3:::allowed-bucket/*” ] }] }
A. 이 엔드포인트를 통한 트래픽은 allowed-bucket 외 다른 S3 버킷에는 접근할 수 없다
B. 모든 S3 버킷에 대한 접근이 허용된다
Resource가 allowed-bucket으로 한정되어 있어 그 외 버킷 접근은 허용되지 않습니다.
문제 11 오답 (선택: D)
Auto Scaling으로 동적으로 늘었다 줄었다 하는 웹서버 그룹이 RDS 데이터베이스에 접근해야 합니다. DB 보안 그룹의 인바운드 규칙을 가장 안전하고 유지보수하기 쉽게 구성하는 방법은?
A. 웹서버 인스턴스의 고정 IP 주소를 일일이 등록한다
Auto Scaling 환경에서는 인스턴스가 계속 교체되어 IP가 바뀌므로 수동 IP 등록 방식은 유지보수가 매우 어렵습니다.
B. 웹서버 보안 그룹 ID를 소스로 지정하는 보안 그룹 참조 규칙을 사용한다
C. 0.0.0.0/0을 허용한 뒤 NACL로 보완한다
불필요하게 노출 범위를 넓히는 방식이며 최소 권한 원칙에 어긋납니다.
D. VPC 전체 CIDR를 허용한다
VPC 내 다른 불필요한 리소스까지 DB에 접근 가능해져 과도하게 넓은 권한입니다.
문제 15 오답 (선택: A)
교차 계정 역할을 AssumeRole로 호출할 때, 역할 자체에 정의된 권한보다 더 좁은 권한만 임시로 부여하고 싶습니다(호출자 측에서 추가 제한). 사용해야 할 기능은?
A. 역할의 신뢰 정책(Trust Policy)을 수정한다
신뢰 정책은 ‘누가’ Assume할 수 있는지를 정의할 뿐, 매 호출마다 권한을 더 좁히는 기능은 아닙니다.
B. AssumeRole 호출 시 세션 정책(Session Policy)을 함께 전달한다
문제 16 오답 (선택: A)
랜섬웨어 공격으로 인한 객체 삭제·덮어쓰기 위협에 대비해, 지정된 보존 기간 동안 어떤 주체(루트 사용자 포함)도 객체를 삭제하거나 덮어쓸 수 없도록 강제하려 합니다. 가장 적합한 구성은?
A. 버전 관리(Versioning)만 활성화한다
버전 관리만으로는 이전 버전이나 객체 자체의 영구 삭제(DeleteObject 권한 보유 시)를 원천 차단하지 못합니다.
B. S3 Object Lock(컴플라이언스 모드)과 버전 관리를 함께 활성화한다
문제 18 오답 (선택: C)
AWS IAM Identity Center(구 AWS SSO)에서 여러 AWS 계정에 걸쳐 사용자/그룹에게 일관된 권한 집합을 할당하는 핵심 단위는?
A. 개별 계정의 IAM 사용자
멀티 계정 환경에서 계정마다 개별 IAM 사용자를 만드는 것은 Identity Center가 해결하려는 운영 부담 문제 자체입니다.
B. 권한 집합(Permission Set)
C. SCP
SCP는 계정/OU 단위의 권한 상한선이지, 사용자·그룹에게 직접 할당하는 권한 집합 단위가 아닙니다.
문제 19 오답 (선택: C)
KMS의 Encrypt/Decrypt API 호출 시, 비밀로 취급되지는 않지만 추가적인 무결성 검증과 감사 추적성을 제공하기 위해 함께 전달하는 키-값 쌍은 무엇입니까?
A. Grant Token
Grant Token은 비동기적으로 생성된 Grant의 즉시 사용을 보장하기 위한 토큰으로, 무결성 검증용 키-값 쌍과는 다른 개념입니다.
B. 암호화 컨텍스트(Encryption Context)
C. 키 별칭(Key Alias)
별칭은 키를 가리키는 사람이 읽기 쉬운 이름일 뿐, 암복호화 시 추가 검증에 사용되는 데이터가 아닙니다.
문제 20 오답 (선택: B)
다음 WAF Rate-based 규칙의 동작을 가장 정확히 설명한 것은?
{ “Name”: “RateLimitRule”, “Priority”: 1, “Action”: {“Block”: {}}, “Statement”: { “RateBasedStatement”: { “Limit”: 2000, “AggregateKeyType”: “IP” } } }
A. 동일 출발지 IP에서 5분 동안의 요청 수가 2000건을 초과하면 이후 요청을 차단한다
B. IP와 무관하게 전체 트래픽의 합계가 2000건을 넘으면 모든 사용자를 차단한다
AggregateKeyType이 IP로 지정되어 있으므로 집계 기준은 출발지 IP별이며 전체 합산이 아닙니다.
오답노트 (자주 헷갈리는 포인트 중심)
1. SCP 리전 제한 (Deny + RequestedRegion) 정답 A. StringNotEquals + aws:RequestedRegion 조합은 지정 리전 외 모든 호출을 거부하는 전형적 패턴입니다.
- 오답 B를 고르기 쉬운 이유: Action이
*인데도 “EC2 관련 SCP니까 EC2만”이라고 넘겨짚는 경우가 많습니다. SCP에서 Action 필드를 끝까지 읽는 습관이 중요합니다. - 오답 C를 고르기 쉬운 이유: SCP와 IAM 정책의 JSON 문법이 동일하다는 걸 깜빡하고 “이건 IAM 정책 형식이라 SCP가 아니다”라고 착각하는 경우입니다.
2. NotAction 의미 해석 정답 A. NotAction은 나열된 작업을 “제외한 나머지”가 대상입니다.
- 오답 B가 가장 흔한 함정입니다.
NotAction을 보면 직관적으로 “그 작업만 허용”이라고 거꾸로 읽기 쉬운데, 실제로는 정반대로 동작합니다.Action과NotAction을 항상 짝지어 구분해서 외워두는 게 좋습니다.
3. KMS 키 정책에 루트 계정 누락 정답 A. 루트 계정 허용 구문이 없으면 IAM으로 권한을 더 위임할 수 없고, 지정된 역할이 삭제되면 키 자체가 고립됩니다.
- 오답 B를 고르는 이유: “특정 역할만 쓸 수 있으니 더 안전한 것 아닌가”라는 직관 때문인데, 보안성과 운영 복원력은 다른 문제입니다. 키 정책에서는 항상 루트 계정 허용 여부를 먼저 확인하는 습관이 필요합니다.
4. SecureTransport 조건 버킷 정책 정답 A. aws:SecureTransport: false일 때 거부 → HTTPS 강제.
- 오답 B를 고르는 이유: Condition을 안 읽고 “Deny + Principal *“만 보고 전체 차단이라고 단정하는 경우입니다. Condition 블록은 반드시 끝까지 봐야 합니다.
5. ExternalId 없는 교차 계정 신뢰 정책 정답 A. ExternalId 부재 시 confused deputy 공격에 취약.
- 오답 B를 고르는 이유: “Principal이 root니까 가장 안전”이라는 잘못된 직관. 오히려 root는 통제 범위가 가장 넓어서 위험도가 커지는 경우가 많습니다.
6. SCP 화이트리스트 전략 정답 A. FullAWSAccess 분리 후 Allow 정책으로 교체.
- 오답 C를 고르는 이유: “Deny만 추가하면 되지 않나”라는 생각이지만, FullAWSAccess가 살아있으면 기본 허용 상태가 유지되어 진짜 화이트리스트가 되지 않습니다.
7. ABAC vs RBAC 구분 정답 A. 태그 변수(${aws:PrincipalTag/...})를 활용하면 ABAC.
- 오답 B와 헷갈리는 이유: “역할(Role)에 정책이 붙어 있으니 RBAC 아닌가”라는 표면적 접근 때문입니다. 핵심은 권한 결정 방식이 고정 역할 이름 기반인지, 동적 속성(태그) 비교 기반인지입니다.
8. VPC 엔드포인트 정책 범위 정답 A. 엔드포인트 정책은 해당 엔드포인트를 지나는 트래픽에만 적용.
- 오답 C를 고르는 이유: “정책이 있으니 인터넷 경로까지 다 막겠지”라는 과대 해석입니다. 엔드포인트 정책의 적용 범위(그 엔드포인트를 통과하는 트래픽)를 정확히 구분해야 합니다.
9. KMS Grant의 용도 정답 B. 임시·세분화된 권한 위임에는 Grant + RetireGrant/RevokeGrant.
- 오답 A를 고르는 경우: “그냥 키 정책 고치면 되지”라는 직관이지만, 매번 영구 정책을 수정하는 건 비효율적이고 위험합니다. Grant는 이런 임시 위임을 위해 설계된 전용 기능입니다.
10. 데이터 이벤트 로깅 비용 정답 A. 객체 단위 데이터 이벤트는 비용이 크게 늘 수 있어 선별 적용 권장.
- 오답 B를 고르는 이유: “CloudTrail은 기본 무료”라는 인상이 강해서 데이터 이벤트도 무료라고 착각하기 쉽습니다. 관리 이벤트와 데이터 이벤트의 과금 체계 차이를 기억해야 합니다.
11. 보안 그룹 참조 vs IP 목록 정답 B. Auto Scaling 환경에서는 보안 그룹 참조 규칙이 정석.
- 오답 A를 고르는 이유: 전통적인 네트워크 사고방식(고정 IP 화이트리스트)에 익숙해서입니다. 클라우드의 동적 환경에서는 IP보다 보안 그룹 참조가 우선 고려 대상입니다.
12. GuardDuty 오탐 처리 정답 B. Trusted IP List 또는 Suppression Rule.
- 오답 D를 고르는 이유: “Flow Logs를 끄면 스캐너 트래픽이 안 보이겠지”라는 발상이지만, 이는 핵심 탐지 데이터 소스 자체를 잃는 과도한 조치입니다.
13. NotIpAddress 조건 해석 정답 A. 지정 CIDR 외부에서의 호출이 거부 대상.
- 오답 B와 헷갈리는 이유는 2번 문제와 동일한 패턴(Not 계열 조건의 방향성 혼동)입니다.
Not이 붙은 조건 키는 항상 “반대”로 한번 더 검증하는 습관이 필요합니다.
14. 멀티 리전 키 정답 B. Multi-Region Key + Replica Key.
- 오답 A를 고르는 이유: “그냥 복사하면 되지”라는 단순한 접근이지만, 표준 키는 리전 간 동일 키 자재 공유를 지원하지 않습니다.
15. 세션 정책(Session Policy) 정답 B. AssumeRole 시 세션 정책으로 권한을 추가로 좁힐 수 있음.
- 오답 A를 고르는 이유: “신뢰 정책을 고치면 권한도 좁아지겠지”라는 혼동인데, 신뢰 정책은 ‘누가 Assume 가능한가’를 정할 뿐 세션 단위 권한 축소 기능이 아닙니다.
16. Object Lock 컴플라이언스 모드 정답 B. 버전 관리 + Object Lock(컴플라이언스 모드)이 함께 있어야 진짜 삭제 방지.
- 오답 A를 고르는 이유: 버전 관리만으로 충분하다고 생각하기 쉽지만, 삭제 권한이 있는 사용자는 여전히 객체를 영구 삭제할 수 있습니다.
17. Config 자동 교정 정답 A. Config 규칙 + SSM Automation 문서로 Auto Remediation.
- 오답 C를 고르는 이유: CloudTrail Insights를 “이상 탐지하면 자동으로 막아주는 도구”로 오해하는 경우가 많은데, Insights는 탐지만 하고 교정 기능은 없습니다.
18. Permission Set의 역할 정답 B. IAM Identity Center의 멀티 계정 권한 할당 단위.
- 오답 A를 고르는 이유: 기존 IAM 사용자 중심 사고에 머물러 있는 경우입니다. Identity Center의 핵심은 계정별 IAM 사용자를 만들지 않고 중앙에서 권한을 관리하는 것입니다.
19. Encryption Context 정답 B. 비밀이 아닌 무결성/감사용 키-값 쌍.
- 오답 A(Grant Token)와 헷갈리는 이유: 둘 다 KMS API 호출 시 함께 쓰이는 부가 개념이라 혼동되기 쉽습니다. Grant Token은 권한 즉시성 보장용, Encryption Context는 무결성/감사용으로 구분해서 외워야 합니다.
20. WAF Rate-based Rule 정답 A. IP별 집계, 임계값 초과 시 차단.
- 오답 B를 고르는 이유:
AggregateKeyType을 읽지 않고 “Rate 제한이니 전체 합산”이라고 단정하는 경우입니다. AggregateKeyType 필드를 꼭 확인해야 합니다.
21. 교차 계정 S3 접근 조건 정답 A. 양쪽(IAM 정책 + 버킷 정책) 모두 허용 필요.
- 오답 B를 고르는 이유: “리소스 소유자가 허용하면 끝”이라는 단순화인데, 다른 계정 주체는 자기 계정의 IAM 정책에서도 허용되어야 한다는 이중 요건을 놓치기 쉽습니다.
22. CloudHSM vs KMS 정답 B. 전용 단일 테넌트 하드웨어 요구사항 = CloudHSM.
- 오답 A를 고르는 이유: KMS도 FIPS 인증을 받았다는 점만 보고 단일 테넌트 요구사항까지 충족한다고 착각하기 쉽습니다. “전용/단일 테넌트”라는 키워드가 나오면 CloudHSM을 먼저 떠올려야 합니다.
23. 정책 변수 ${aws:username} 정답 A. 각 사용자 본인 리소스로 범위 한정.
- 오답 D를 고르는 이유: 정책 변수 문법이 낯설어 “이거 문법 오류 아닌가”라고 의심하는 경우입니다.
${aws:username}은 공식적으로 지원되는 변수입니다.
24. GuardDuty Malware Protection 정답 B. EBS 스냅샷 기반 악성코드 스캔 전용 기능.
- 오답 A(S3 Protection)를 고르는 이유: GuardDuty의 여러 보호 기능 이름이 비슷해서 헷갈리기 쉽습니다. S3는 S3, EC2/EBS는 Malware Protection으로 매칭해서 암기하는 게 좋습니다.
25. Resource Control Policy(RCP) 정답 B. 리소스 기반 정책에 대한 조직 차원 가드레일.
- 오답 A(Tag Policy)와 헷갈리는 이유: Organizations의 여러 정책 유형(Tag, Backup, AI Opt-out, RCP)이 비교적 최근에 늘어나서 이름과 역할 매칭이 헷갈리기 쉽습니다. RCP는 “리소스 정책에 대한 SCP”라고 기억하면 쉽습니다.
26. Macie Custom Data Identifier 정답 B. 정규식 기반 사용자 정의 식별자.
- 오답 A를 고르는 이유: Macie가 관리형 식별자만 지원한다고 오해하는 경우입니다. 회사 고유 패턴은 커스텀 식별자로 직접 정의할 수 있습니다.
27. MFA 조건 신뢰 정책 정답 A. 세션 단위 MFA 인증 상태를 요구.
- 오답 B를 고르는 이유: “역할 생성 시 MFA 등록”이라는, 가입 시점 검증으로 잘못 이해하는 경우입니다. 이 조건 키는 매 호출 시점의 세션 상태를 평가합니다.
28. Origin Access Control(OAC) 정답 B. OAC + 버킷 정책으로 CloudFront 경유 강제.
- 오답 C를 고르는 이유: “WAF만 추가하면 되지 않나”라는 생각이지만, WAF는 CloudFront를 통과하는 트래픽만 검사하므로 오리진 직접 접근 자체를 막는 것과는 별개입니다.
29. Amazon Detective 용도 정답 B. 멀티 계정 행위 그래프 분석.
- 오답 A(Athena)를 고르는 이유: 둘 다 “로그 분석”이라는 점에서 비슷해 보이지만, Athena는 SQL 쿼리 도구이고 Detective는 그래프 기반 시각적 조사에 특화되어 있다는 차이를 기억해야 합니다.
30. SourceVpce 조건 SCP의 부작용 정답 A. 데이터 유출 방지 의도 + 다른 정상 경로 차단 부작용 고려 필요.
- 오답 B를 고르는 이유: “조건을 걸었으니 완벽하다”고 단정하기 쉬운데, 실무에서는 항상 의도한 경로 외의 정상적인 예외 케이스(콘솔, Lambda 등)를 함께 검토해야 합니다.
핵심 정리 (이번 세트에서 다룬 개념)
IAM/SCP 정책 평가
ActionvsNotAction,Condition의Not계열 키(NotIpAddress,StringNotEquals)는 항상 “반대 방향”으로 한 번 더 검증- SCP는 권한을 “부여”하지 않고 “상한선”만 설정 — 화이트리스트 전략은 FullAWSAccess 분리가 핵심
- ABAC는 정책에 동적 태그 변수(
${aws:PrincipalTag/...})가 쓰였는지로 RBAC와 구분 - 정책 변수(
${aws:username})는 셀프 서비스 패턴의 핵심 도구
KMS / 암호화
- 키 정책에 루트 계정 허용이 없으면 운영상 키가 고립될 위험
- KMS Grant: 임시·세분화된 권한 위임, RetireGrant/RevokeGrant로 회수
- Encryption Context: 비밀 아님, 무결성·감사용 / Grant Token: 권한 즉시성 보장용으로 구분
- Multi-Region Key(+Replica Key): 동일 키 자재를 여러 리전에서 사용
- CloudHSM: 전용 단일 테넌트 하드웨어가 필요한 규제 요구사항
네트워크/엣지 보안
- 보안 그룹 참조 규칙: 동적 Auto Scaling 환경의 표준 패턴
- VPC 엔드포인트 정책: 해당 엔드포인트를 통과하는 트래픽에만 적용(인터넷 경로와 별개)
- WAF Rate-based Rule:
AggregateKeyType(IP 등) 기준으로 임계값 초과 시 차단 - CloudFront + OAC + 버킷 정책: 오리진 직접 접근을 막아 WAF 우회 방지
탐지/조사
- GuardDuty Malware Protection: EBS 스냅샷 기반 악성코드 스캔(S3 Protection과 구분)
- Trusted IP List / Suppression Rule: 오탐 처리, GuardDuty/Flow Logs 비활성화는 지양
- Amazon Detective: 멀티 계정 행위를 그래프로 시각화해 근본 원인 조사(Athena와 구분)
- Macie Custom Data Identifier: 정규식 기반 회사 고유 패턴 탐지
거버넌스
- Resource Control Policy(RCP): 리소스 기반 정책에 대한 조직 차원 가드레일(Tag/Backup/AI Opt-out Policy와 구분)
- IAM Identity Center의 Permission Set: 멀티 계정 권한 할당의 핵심 단위
- 교차 계정 S3 접근: 호출자 측 IAM 정책 + 리소스 측 버킷 정책, 양쪽 모두 허용 필요