시험 대비 · 도메인 1

보안 아키텍처 설계 (30%)

Design Secure Architectures는 가중치가 가장 큰 도메인인데 과제 진술은 셋뿐입니다. 범위가 좁고 깊다는 뜻이고, 같은 판단 지점이 시나리오를 바꿔 가며 반복된다는 뜻입니다. 여기서 실점하면 다른 도메인으로 만회하기가 가장 어렵습니다. 반대로 투입 대비 회수가 가장 큰 구간이기도 합니다.

이 페이지는 무엇을 판단해야 하는지를 정리합니다. 판단에 필요한 지식은 2장 IAM, 3장 VPC 네트워킹 기초, 16장 보안·암호화·거버넌스가 담당합니다.

학습 목표

이 도메인의 성격

SAA-C03 도메인별 출제 비중 가운데 보안 아키텍처 설계가 30%로 가장 큰 조각입니다. 과제 진술이 3개뿐이므로 진술 하나가 감당하는 비중이 다른 도메인보다 큽니다. 학습 시간을 여기에 먼저 배정하는 근거입니다
도메인 1의 과제 진술 세 개와 중심 질문
과제 진술 중심 질문 주 담당 챕터
1.1 AWS 리소스에 대한 보안 액세스 설계 누가 무엇을 호출할 수 있는가. 자격 증명의 종류와 수명, 권한의 결합 방식 2장 IAM과 자격 증명
1.2 보안 워크로드와 애플리케이션 설계 패킷이 어디를 지나는가. 서브넷 배치, 접근 제어 계층, 경로 통제 3장 VPC 네트워킹 기초 · 4장 VPC 연결과 하이브리드
1.3 적절한 데이터 보안 제어 결정 키를 누가 쥐는가. 저장·전송 암호화, 비밀 관리, 증적과 불변성 16장 보안·암호화·거버넌스 · 8장 S3

세 진술은 계층이 다릅니다. 1.1은 자격 증명 계층, 1.2는 네트워크 계층, 1.3은 데이터 계층입니다. 시나리오 하나에 세 계층이 함께 나오는 경우도 많으므로, 문항을 읽을 때 어느 계층에서 답을 요구하는지 먼저 정하면 선택지가 빠르게 갈립니다.

과제 진술 1.1 · AWS 리소스에 대한 보안 액세스 설계

이 진술의 문항은 대부분 "이 주체가 이 리소스를 호출할 수 있게 하려면" 또는 "이 접근이 왜 거부되는가" 형태입니다. 서비스 이름을 아는 것보다 정책이 어떻게 결합되는지가 훨씬 자주 결정적입니다.

액세스 키가 아니라 IAM 역할 SAA 빈출

이 도메인에서 가장 자주 재활용되는 판단입니다. EC2 인스턴스·컨테이너·Lambda 함수가 AWS API를 호출해야 한다면 답은 IAM 역할입니다. 역할이 전달하는 자격 증명은 임시이고 자동으로 교체되므로, 유출된 키를 찾아 회수하는 문제 자체가 생기지 않습니다.

선택지에 "IAM 사용자를 만들어 액세스 키를 발급하고 인스턴스에 저장한다"가 보이면 거의 항상 오답입니다. 실행 주체별로 역할의 이름이 다를 뿐 결론은 같습니다.

실행 주체별로 자격 증명을 전달하는 방식
실행 주체 정답 방식 오답 방식
Amazon EC2 인스턴스 인스턴스 프로파일로 IAM 역할 연결 액세스 키를 자격 증명 파일이나 환경 변수에 저장
Amazon ECS 태스크 태스크 역할(실행 역할과 구분) 컨테이너 이미지에 키를 굽는 방식
AWS Lambda 함수 실행 역할 환경 변수에 키를 넣는 방식
다른 AWS 계정의 주체 역할을 만들고 신뢰 정책으로 상대 계정을 허용한 뒤 sts:AssumeRole 상대 계정용 IAM 사용자를 만들어 키를 전달
사내 디렉터리 사용자 AWS IAM Identity Center로 페더레이션 사람마다 IAM 사용자를 만들어 관리

정책 평가 순서와 결합 규칙

접근 허용 여부는 세 줄로 정리됩니다. 기본은 암묵적 거부이고, 어느 정책에서든 명시적 Deny가 하나라도 있으면 즉시 거부이며, 명시적 Allow가 있고 거부가 없으면 허용됩니다. 우선순위는 명시적 Deny 우선, 그다음 명시적 Allow, 마지막이 암묵적 거부입니다.

더 자주 틀리는 것은 순서가 아니라 결합 규칙입니다. 같은 계정 안에서 자격 증명 기반 정책과 리소스 기반 정책은 합집합으로 동작하지만, 권한 경계·SCP·세션 정책은 교집합으로 동작합니다.

정책 유형별 결합 규칙
조합 결과 시험에서의 의미
자격 증명 기반 + 리소스 기반 (동일 계정) 합집합 둘 중 하나만 허용해도 통과합니다
자격 증명 기반 + 권한 경계 교집합 양쪽이 모두 허용해야 통과합니다
자격 증명 기반 + SCP 교집합 SCP가 허용하지 않으면 IAM 정책이 아무리 넓어도 거부됩니다
자격 증명 기반 + 세션 정책 교집합 역할을 맡을 때 전달한 세션 정책이 상한이 됩니다
권한 경계 + SCP + 자격 증명 기반 셋 다 허용해야 통과 교차 계정 문항에서 원인을 찾을 때 순서대로 확인합니다

교차 계정 접근은 이 규칙의 대표 응용입니다. 다른 계정의 리소스에 접근하려면 호출자 쪽 자격 증명 기반 정책과 리소스 쪽 리소스 기반 정책이 둘 다 허용해야 합니다. 한쪽만 고친 선택지는 오답입니다.

SCP와 권한 경계

서비스 제어 정책(Service Control Policy, SCP)은 조직 전체에 상한을 겁니다. 두 가지 성질만 기억하면 관련 문항이 대부분 풀립니다 — SCP는 권한을 부여하지 않고, 멤버 계정의 루트 사용자에게도 적용됩니다. 루트를 통제할 수 있는 사실상 유일한 수단이라는 점이 자주 출제됩니다.

권한 경계는 개별 IAM 주체에 거는 상한입니다. 적용 범위가 조직이 아니라 주체라는 점이 SCP와의 결정적 차이이며, "개발자에게 IAM 역할을 만들 권한을 주되 자기보다 큰 권한은 못 만들게 한다"는 요구가 나오면 권한 경계가 답입니다.

과제 진술 1.2 · 보안 워크로드와 애플리케이션 설계

이 진술은 네트워크 경계를 묻습니다. 무엇을 퍼블릭 서브넷에 두고 무엇을 프라이빗 서브넷에 두는가, 어떤 계층에서 트래픽을 막는가, 그리고 트래픽이 인터넷을 지나는가가 중심입니다.

보안 그룹과 네트워크 ACL SAA 빈출

보안 그룹과 네트워크 ACL 비교
항목 보안 그룹 네트워크 ACL
적용 계층 인스턴스(네트워크 인터페이스) 수준 서브넷 수준 — 서브넷의 모든 인스턴스에 적용
규칙 종류 허용 규칙만 허용과 거부 모두
평가 방식 모든 규칙을 평가 가장 낮은 번호부터 순서대로 평가
상태 상태 저장(stateful) — 반환 트래픽이 자동 허용 상태 비저장(stateless) — 반환 트래픽을 규칙으로 명시 허용
전형적 용도 계층 간 접근 허용(웹에서 앱, 앱에서 데이터베이스) 서브넷 단위의 광범위한 차단, 특정 대역 거부

인터넷을 거치지 않는 경로

"트래픽이 퍼블릭 인터넷을 지나면 안 된다"는 제약이 붙으면 암호화 여부가 아니라 경로가 판단 기준이 됩니다. NAT 게이트웨이를 통해 서비스의 퍼블릭 엔드포인트로 나가는 구성은 이 제약을 만족하지 못합니다.

비공개 경로를 만드는 선택지
요구 선택 판단 기준
VPC에서 Amazon S3 · Amazon DynamoDB에 접근 게이트웨이 VPC 엔드포인트 이 두 서비스 전용입니다. 라우팅 테이블에 경로가 추가되는 방식이라 네트워크 인터페이스를 만들지 않습니다
그 밖의 AWS 서비스에 비공개 접근 인터페이스 VPC 엔드포인트(AWS PrivateLink) 서브넷에 네트워크 인터페이스가 생기고 보안 그룹을 연결할 수 있습니다
다른 VPC의 서비스에 비공개 접근 AWS PrivateLink 또는 VPC 피어링 특정 서비스만 노출하려면 PrivateLink, 네트워크를 잇는 것이 목적이면 피어링
온프레미스와 전용 연결 AWS Direct Connect 인터넷 회선 위의 VPN은 암호화는 되지만 경로가 공용망입니다
다수 VPC와 온프레미스를 한 번에 AWS Transit Gateway 피어링을 여러 개 만들어 연결 수가 급증하는 구성의 대안입니다

게이트웨이 엔드포인트를 쓰면 NAT 게이트웨이를 지나는 트래픽이 줄기 때문에 보안 요구와 비용 요구가 같은 답을 가리키는 경우가 많습니다. 비용 도메인에서도 같은 판단이 나옵니다.

웹 계층 보호

AWS WAF는 HTTP 요청의 내용을 보고 규칙으로 차단합니다. SQL 삽입이나 특정 경로·헤더 패턴을 막는 요구가 나오면 WAF입니다. AWS Shield는 디도스(DDoS) 공격에 대응하며, 표준 보호는 기본 제공되고 상위 보호는 별도 구독입니다.

붙이는 위치도 함께 묻습니다. WAF는 Amazon CloudFront 배포, Application Load Balancer, Amazon API Gateway 같은 요청을 받는 지점에 연결합니다. 네트워크 계층의 광범위한 트래픽 검사가 필요하면 AWS Network Firewall이 답입니다.

과제 진술 1.3 · 적절한 데이터 보안 제어 결정

이 진술의 판단 축은 키를 누가 쥐는가와 증적이 남는가입니다. "암호화한다"는 선택지가 여러 개 있을 때, 문제문이 요구한 키 관리 수준으로 갈립니다.

Amazon S3 저장 데이터 암호화 선택

S3 서버 측 암호화 방식과 선택 기준
방식 키 관리 주체 이 방식을 고르는 신호
SSE-S3 Amazon S3가 관리 암호화 요구는 있지만 키 관리 요구는 없는 경우. 신규 객체에 자동 적용되는 기본값입니다
SSE-KMS AWS KMS 키(고객 관리형 키 선택 가능) 키 사용 감사가 필요하거나 키 정책으로 접근을 따로 통제해야 하는 경우. KMS 호출이 CloudTrail에 남습니다
DSSE-KMS AWS KMS 키 — 이중 계층 규정이 이중 암호화를 요구하는 경우
SSE-C 고객이 요청마다 키를 제공 키를 AWS에 맡길 수 없는 경우. AWS는 키를 저장하지 않으므로 키를 잃으면 데이터를 복구할 수 없습니다

KMS와 봉투 암호화

AWS KMS는 데이터를 직접 암호화하지 않고 데이터 키를 만들어 줍니다. 서비스는 그 데이터 키로 데이터를 암호화하고, 데이터 키 자체는 KMS 키로 암호화해 함께 저장합니다. 이 구조를 봉투 암호화(envelope encryption)라고 합니다. 큰 데이터를 KMS로 왕복시키지 않으면서도 키 통제를 KMS에 남기는 것이 목적입니다.

KMS 키 종류와 선택 기준
키 종류 특징 고르는 신호
AWS 관리형 키 서비스가 계정 안에 자동으로 만들어 쓰는 키. 키 정책을 직접 편집하지 않습니다 암호화만 필요하고 키 통제 요구가 없는 경우
고객 관리형 키 키 정책·별칭·자동 교체·비활성화·삭제 일정을 직접 통제합니다 키 정책으로 접근을 제한하거나 교차 계정 공유가 필요한 경우, 키 교체를 직접 관리해야 하는 경우
AWS CloudHSM 전용 하드웨어 보안 모듈에서 키를 관리합니다 규정이 전용 HSM에서의 키 보관을 요구하는 경우

키 접근은 키 정책과 IAM 정책이 함께 작동합니다. IAM 정책만 넓게 열어 두고 키 정책이 그 주체를 허용하지 않으면 복호화가 거부됩니다. "권한은 줬는데 복호화가 안 된다"는 시나리오의 원인이 대개 여기입니다.

Secrets Manager와 Parameter Store

AWS Secrets Manager와 AWS Systems Manager Parameter Store 비교
항목 AWS Secrets Manager Parameter Store
주 용도 데이터베이스 자격 증명 같은 비밀 설정값과 파라미터. SecureString으로 비밀도 저장 가능
자동 교체 내장 — 교체를 자동화할 수 있습니다 내장 기능 없음
고르는 신호 "자격 증명을 주기적으로 교체해야 한다" "설정값을 계층 구조로 관리한다", 교체 요구가 없다

선택 기준은 사실상 하나입니다. 자동 교체 요구가 문제문에 있으면 Secrets Manager이고, 없으면 Parameter Store가 후보에 남습니다.

증적과 불변성

규정 준수 문항은 기록이 남는가와 지워지지 않는가를 묻습니다. AWS CloudTrail은 누가 어떤 API를 호출했는지를 남기고, AWS Config는 리소스 구성이 규칙에 맞는지를 지속적으로 평가합니다. 둘은 대체 관계가 아니라 질문이 다릅니다.

보관 자체가 요구일 때는 S3 버전 관리와 S3 Object Lock을 씁니다. Object Lock은 지정한 기간 동안 객체 삭제와 덮어쓰기를 막습니다. 민감 데이터가 어디에 있는지 찾아야 한다면 Amazon Macie가 답입니다.

판단 지점 점검표 18개

아래는 이 도메인에서 반드시 판단할 수 있어야 하는 지점입니다. 서비스를 아는 것과 판단하는 것은 다릅니다. 각 행을 읽고 기준을 한 문장으로 말할 수 없다면 담당 챕터로 돌아갑니다.

도메인 1 보안 아키텍처 설계의 판단 지점과 담당 챕터
번호 판단 지점 기준 담당 챕터
1 EC2에서 AWS API를 호출한다 — 액세스 키인가 IAM 역할인가 거의 항상 역할. 임시 자격 증명이 자동 교체됩니다 2장
2 IAM 정책 평가 순위 명시적 거부 우선, 그다음 명시적 허용, 기본은 암묵적 거부 2장
3 자격 증명 기반 정책과 리소스 기반 정책 동일 계정에서는 합집합. 교차 계정에서는 양쪽 모두 필요 2장
4 역할 위임과 신뢰 정책 누가 이 역할을 맡을 수 있는지는 신뢰 정책이 정합니다 2장
5 SCP의 성질 권한을 부여하지 않고 상한만 정하며 멤버 계정 루트에도 적용됩니다 2장
6 권한 경계와 SCP의 차이 적용 범위가 개별 주체인가 조직·계정인가 2장
7 외부 사용자에게 접근을 준다 — Identity Center인가 Cognito인가 Directory Service인가 직원의 AWS 접근은 Identity Center, 앱 사용자 인증은 Cognito, Active Directory 연동은 Directory Service 2장 · 16장
8 보안 그룹과 네트워크 ACL 상태 저장 여부와 거부 규칙 지원 여부. 보안 그룹에는 거부가 없습니다 3장
9 프라이빗 서브넷의 아웃바운드 NAT 게이트웨이. 이중화하려면 가용 영역마다 하나씩 3장
10 인터넷을 거치지 않는 서비스 접근 S3와 DynamoDB는 게이트웨이 엔드포인트, 나머지는 인터페이스 엔드포인트 4장
11 저장 데이터 암호화 방식 선택 키 관리 주체와 감사 요구가 기준 8장 · 16장
12 KMS 봉투 암호화와 고객 관리형 키 키 정책 통제나 교차 계정 공유가 필요하면 고객 관리형 키 16장
13 Secrets Manager와 Parameter Store 자동 교체 요구가 있으면 Secrets Manager 16장
14 전송 중 암호화 — 인증서를 어디에 붙이는가 요청을 받는 지점(CloudFront · ALB · API Gateway)에서 종료합니다 14장 · 16장
15 위협 탐지 서비스 선택 위협은 GuardDuty, 취약점은 Inspector, 민감 데이터는 Macie, 집계는 Security Hub 16장
16 웹 계층 보호 — WAF와 Shield 요청 내용 기반 규칙은 WAF, 디도스 대응은 Shield 14장 · 16장
17 S3 신규 버킷의 현행 기본값 퍼블릭 액세스 차단 켜짐, ACL 비활성, SSE-S3 자동. 버전 관리는 여전히 꺼짐 8장
18 감사 추적 — CloudTrail과 Config 누가 무엇을 호출했나는 CloudTrail, 구성이 규칙에 맞나는 Config 17장

이 도메인의 함정

도메인 미니 퀴즈

이 도메인의 판단 지점을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.

이어서 볼 곳

공식 문서 출처