DOP-C02의 보안 도메인은 시험 전반에서 가장 높은 비중을 차지합니다. 단순히 서비스 기능을 암기하는 것이 아니라, "이 아키텍처의 어느 계층에 어떤 보안 통제를 적용해야 하는가"를 설계할 수 있어야 합니다. 이것이 심층 방어(Defense in Depth)의 핵심입니다.
IAM 대규모 관리
CodeBuild 서비스 역할과 최소 권한
CodeBuild 프로젝트가 S3 버킷에서 아티팩트를 가져오고 ECR에 이미지를 푸시하는 경우를 생각해 보겠습니다. CodeBuild Service Role에는 , , , 등 꼭 필요한 권한만 부여해야 합니다.
시험에서 자주 나오는 함정: "CodeBuild에 AdministratorAccess를 주면 편리하다"는 선택지는 명백한 오답입니다. 최소 권한 원칙(Least Privilege)은 DOP-C02의 핵심 보안 사고 방식입니다.
S3 Mountpoint 크로스 계정 IAM
S3 Mountpoint를 사용해 다른 계정의 S3 버킷을 EC2 인스턴스에 마운트할 때는 두 가지 설정이 모두 필요합니다. 첫째, EC2 인스턴스에 연결된 IAM 역할에 크로스 계정 S3 접근 허용 정책. 둘째, S3 버킷 정책에서 다른 계정의 IAM 역할을 명시적으로 허용.
S3 버킷 정책과 IAM 정책 모두 허용(Allow)이어야 접근이 됩니다. 하나라도 명시적 거부(Deny)가 있으면 접근이 차단됩니다.
IAM Identity Center(SSO)와 조직 보안
AWS Organizations 환경에서 수십 개의 멤버 계정을 운영할 때 각 계정마다 IAM 사용자를 생성하는 것은 관리 악몽입니다. IAM Identity Center(구 SSO)는 중앙에서 통합 인증을 제공하고, 단일 진입점에서 여러 계정과 애플리케이션에 접근하게 해 줍니다.
| 구분 | IAM 사용자 | IAM Identity Center | |------|-----------|---------------------| | 관리 위치 | 계정별 분산 | 중앙 집중 | | 인증 방식 | 사용자명/비밀번호 + MFA | IdP 연동(SAML 2.0) | | 권한 할당 | 계정별 정책 | Permission Set | | 감사 | CloudTrail per 계정 | 중앙 CloudTrail |
SCPs(Service Control Policies)는 조직의 루트 또는 OU 수준에서 권한의 최대 범위를 제한합니다. 중요한 점은 SCP 자체가 권한을 부여하는 것이 아니라 허용 가능한 권한의 상한선을 정한다는 것입니다. 따라서 멤버 계정의 IAM 정책에 허용이 있어도 SCP에서 거부되면 접근이 차단됩니다.
Permission Boundary(권한 경계)는 IAM 역할에 부여할 수 있는 최대 권한을 제한합니다. 개발팀이 스스로 IAM 역할을 생성할 수 있도록 위임하면서도, Permission Boundary를 설정해 특정 권한(예: IAM 관리 권한, S3 프로덕션 버킷 접근)은 절대 부여할 수 없도록 가드레일을 설정합니다.
Secrets Manager 자격 증명 자동 교체
RDS 자격 증명을 Secrets Manager에 저장하고 30일 자동 교체를 활성화했는데, 일부 애플리케이션에서 간헐적 DB 연결 오류가 발생하기 시작했습니다. 원인은 무엇일까요?
애플리케이션이 시작 시점에 한 번만 Secrets Manager에서 자격 증명을 조회해 메모리에 캐시하고 이후 갱신하지 않는 구조가 문제입니다. 30일이 되어 새 자격 증명으로 교체되면 메모리의 구 자격 증명은 유효하지 않게 됩니다.
해결책: 연결 실패 시 또는 일정 시간마다 API를 재호출해 최신 자격 증명을 가져오는 로직을 구현합니다. AWS SDK 캐싱 라이브러리를 사용하면 TTL 기반 자동 갱신을 최소한의 코드 변경으로 구현할 수 있습니다.
보안 통제와 데이터 보호
S3 + CloudFront + WAF 아키텍처
정적 프론트엔드 웹 애플리케이션을 호스팅하면서 SQL 인젝션, XSS 공격을 방어하고, EC2 서버 관리 없이 글로벌 사용자에게 저지연으로 제공하려면 어떻게 해야 할까요?
S3 정적 웹사이트 호스팅 + CloudFront + AWS WAF 조합이 정답입니다. S3는 서버리스로 정적 파일을 호스팅하고, CloudFront는 400개 이상의 엣지 로케이션에서 콘텐츠를 캐시해 글로벌 사용자에게 저지연을 제공하며, AWS WAF는 CloudFront와 통합되어 모든 엣지 로케이션에서 SQL 인젝션과 XSS를 차단합니다.
ALB + WAF + ACM 조합은 언제 사용할까요? EC2 인스턴스가 있는 동적 웹 애플리케이션에서 TLS를 EC2 CPU 부하 없이 종료하고, WAF로 L7 공격을 차단하며, ACM으로 인증서 자동 갱신을 원할 때입니다.
CloudFront 사용자 지정 오리진 HTTPS 요구사항
CloudFront에서 온프레미스 서버를 사용자 지정 오리진으로 구성할 때 502 오류가 발생하면 즉시 의심해야 할 것이 있습니다. CloudFront는 사용자 지정 오리진과 HTTPS 연결 시 오리진의 인증서가 공인 CA(Certificate Authority) 발급 인증서인지 검증합니다. 자체 서명 인증서는 이 검증을 통과하지 못합니다.
ACM 인증서는 AWS 서비스 전용으로 온프레미스 서버에 직접 설치할 수 없습니다. 오리진 서버에는 Let's Encrypt, DigiCert 등 공인 CA에서 발급한 인증서를 설치해야 합니다. end-to-end 암호화를 유지하면서 오리진 프로토콜 정책을 HTTPS Only로 설정합니다.
CloudFront end-to-end HTTPS 인증서 구성 요약:
| 구간 | 인증서 위치 | 요구사항 | |------|-----------|---------| | 뷰어 ↔ CloudFront | us-east-1 ACM 인증서 | 반드시 us-east-1 리전 | | CloudFront ↔ ALB | ALB 리전 ACM 인증서 | ALB와 동일 리전 | | CloudFront ↔ 온프레미스 | 서버에 설치된 공인 CA 인증서 | 자체 서명 인증서 불가 |
WAF 규칙 조합 — 국가 차단 + IP 예외 + 웹 공격 방어
특정 국가의 접근을 차단하되 해당 국가에 있는 내부 팀 IP는 허용하고, SQL 인젝션도 방어해야 하는 요구사항을 단일 WAF Web ACL로 구현할 수 있습니다.
WAF 규칙 우선순위(낮은 번호 = 먼저 평가): (낮은 번호) IP Set Allow — 허용할 IP 대역을 먼저 ALLOW (높은 번호) Geo Match Block — 특정 국가 BLOCK AWS Managed Rules — SQL 인젝션, XSS 차단
1번 규칙이 2번보다 먼저 평가되므로, 차단 대상 국가에 있어도 허용 IP라면 통과합니다.
AWS Firewall Manager를 활용하면 Organizations 전체에 WAF 정책을 자동으로 적용하고, 신규로 생성되는 ALB/API Gateway에도 WAF Web ACL을 수분 내에 자동 연결합니다. Config 규칙 자동 수정과의 차이: Config는 비준수를 탐지 후 교정하지만 Firewall Manager는 생성 즉시 연결하므로 보안 공백이 없습니다.
Egress-Only Internet Gateway — IPv6 아웃바운드 전용
프라이빗 서브넷의 EC2 인스턴스가 IPv6 전용 외부 API와 통신해야 하는데, 외부에서의 인바운드 IPv6 연결은 허용하면 안 되는 경우가 있습니다.
이때 Egress-Only Internet Gateway를 사용합니다. IPv4의 NAT Gateway에 대응하는 IPv6 전용 게이트웨이입니다. 인스턴스에서 시작한 아웃바운드 연결의 응답만 허용하고 외부에서의 인바운드는 상태 기반으로 차단합니다.
전제 조건: VPC에 IPv6 CIDR 블록 활성화, 서브넷에 IPv6 주소 할당, 라우팅 테이블에 추가.
보안 모니터링과 감사
EventBridge + CloudTrail AssumeRole 탐지
멀티 계정 환경에서 크로스 계정 역할 인수(AssumeRole)를 모니터링하는 것은 권한 에스컬레이션 탐지의 핵심입니다. EventBridge에서 CloudTrail 이벤트를 감지하고 알림을 트리거하는 아키텍처를 구성합니다. 특히 예상치 못한 계정에서의 역할 인수나 비정상적인 패턴을 탐지하는 데 유용합니다.
Amazon Inspector v2 — SSM Agent 기반 CVE 스캐닝
Amazon Inspector v2는 EC2 인스턴스의 OS 패키지 취약점(CVE)과 네트워크 접근성을 자동 평가합니다. Inspector v2는 SSM Agent를 통해 추가 에이전트 없이 스캔을 수행하는 에이전트리스 방식을 지원합니다. 활성화하면 모든 EC2 인스턴스와 ECR 이미지를 지속적으로 자동 평가합니다.
Inspector vs GuardDuty 구별 표:
| 서비스 | 무엇을 감시 | 이벤트 소스 | 탐지 내용 | |--------|-----------|-----------|---------| | Amazon Inspector | EC2, Lambda, ECR | 취약점 데이터베이스(CVE) | 소프트웨어 취약점, 네트워크 노출 | | Amazon GuardDuty | 계정, VPC, IAM | VPC Flow Logs, CloudTrail, DNS | 악성 행동, 비정상 API 호출 | | Amazon Macie | S3 버킷 | 머신러닝 + 패턴 매칭 | 민감 데이터(PII) 분류, 이상 접근 |
GuardDuty — 위협 탐지 자동 대응
GuardDuty Finding이 생성되면 EventBridge가 즉시 감지합니다. Finding 유형별로 자동 대응을 설계할 수 있습니다.
예시 시나리오: EC2 인스턴스에서 가상화폐 마이닝 패턴 탐지 → EventBridge → Lambda → 해당 인스턴스의 보안 그룹을 격리(모든 인바운드/아웃바운드 차단) 설정.
노출된 IAM 액세스 키 탐지 → EventBridge → Lambda → 호출 → SNS 알림.
AWS Config + SSM Automation — 지속적 규정 준수 자동 교정
Config 규칙 + SSM Automation Runbook의 조합으로 "탐지 즉시 자동 수정"을 구현합니다.
활용 예시: 비승인 AMI로 실행된 인스턴스 자동 종료 ( 관리형 규칙) 퍼블릭 S3 버킷 자동 비공개 전환 SSH 0.0.0.0/0 보안 그룹 규칙 자동 제거
Macie vs Config의 역할 구분을 명확히 해야 합니다. Macie는 S3에 저장된 데이터 내용을 분석해 PII 등 민감 데이터를 분류하고 이상 접근 패턴을 탐지합니다. Config는 리소스의 구성 설정이 정책을 준수하는지 평가합니다. 퍼블릭 S3 버킷 탐지는 Config가, S3 내 민감 데이터 위치 파악은 Macie가 담당합니다.