2주차는 시험 비중이 가장 큰 도메인 1(보안 아키텍처)에 몰아 썼다. 1주차에 IAM 뼈대를 잡아둔 상태라 이번 주는 그 위에 얹히는 것들을 다뤘다. 페더레이션(엔터프라이즈 로그인), KMS 기반 암호화, S3 암호화 옵션, 보안 그룹과 NACL, WAF/Shield/GuardDuty 같은 관리형 보안 서비스, 그리고 Secrets Manager와 Parameter Store 비교까지. 개별 서비스 자체는 어렵지 않은데 서로 뭘 언제 쓰는지가 시나리오형 문제에서 계속 헷갈렸다.
참고 자료
이번 주에도 노션 "SAA 관련 자료" 페이지에 걸어둔 링크들을 그대로 활용했다. KMS와 네트워크 보안 부분은 Tutorials Dojo cheat sheet가 특히 도움이 됐다.
- Charlie Kim - AWS Certified Solutions Architect – Associate 자격증 준비 과정 및 시험 후기
- 루이3 - AWS Certified – Associate 덤프 문제 사이트 (문제 풀이용)
- velog G.log - 시리즈 [TIL] AWS Certified 준비 (SAA-C03, DVA-C02)
- velog kyj311.log - 시리즈 Architecting on AWS 정리 (SAA 대비)
- Tutorials Dojo - "KMS cheat sheet", "Security Group NACL cheat sheet" 검색
- AWS 공식 문서 - KMS 개발자 가이드 (Envelope Encryption 부분)
1. 페더레이션과 IAM Identity Center
1주차에 STS/AssumeRole 개념까지 봤으니 이번 주는 그 확장판. 시험에서 "기업 내 AD 사용자가 AWS 콘솔에 접근" 같은 시나리오가 나오면 이 파트다.
SAML 2.0 페더레이션
- 사내 IdP(ADFS, Okta 등)와 AWS를 SAML로 연결
- 사용자가 IdP에 로그인 → IdP가 SAML Assertion 발급 → AWS STS의 AssumeRoleWithSAML로 임시 자격 증명 획득
- AWS 계정 안에 별도 IAM User를 만들 필요가 없어서 관리 부담이 줄어든다
Web Identity Federation
- Google, Facebook, Amazon 같은 OIDC 공급자로 로그인한 사용자에게 AWS 리소스 접근 부여
- AssumeRoleWithWebIdentity 사용
- 실제로는 이걸 직접 다루기보다 Cognito로 감싸는 게 훨씬 흔함
Amazon Cognito
헷갈리기 쉬운 두 컴포넌트가 있다.
- User Pool: 사용자 로그인 자체를 관리 (회원가입, 로그인, MFA, 소셜 로그인). 결과물은 JWT 토큰
- Identity Pool: 로그인한 사용자에게 AWS 임시 자격 증명 발급. 결과물은 STS 자격 증명
앱 사용자가 S3에 직접 업로드하는 시나리오라면:
User Pool로 로그인 → Identity Pool로 임시 자격 증명 받음 → S3에 직접 요청
IAM Identity Center (구 AWS SSO)
- 여러 AWS 계정 + 사내 사용자를 한 곳에서 관리
- Organizations와 연동해 계정별 권한 세트를 통합 관리
- 시나리오에 "여러 계정에 대한 단일 로그인" 나오면 이 서비스
시험 힌트 정리:
- 사내 AD → SAML 페더레이션 or IAM Identity Center
- 모바일 앱 사용자 → Cognito Identity Pool
- 소셜 로그인 → Cognito User Pool
- 여러 AWS 계정 통합 로그인 → IAM Identity Center
2. KMS와 데이터 암호화
이번 주에 가장 시간을 많이 쓴 파트. 시험에 "저장 데이터 암호화(Encryption at Rest)" 관련 문제가 계속 나온다.
2.1 대칭키 vs 비대칭키
- 대칭 CMK: 하나의 키로 암/복호화. 대부분의 AWS 서비스 통합 (S3, EBS, RDS 등). 성능 좋음
- 비대칭 CMK: 공개키/개인키 쌍. 서명 검증이나 외부에 공개키만 배포해야 하는 경우
시험에선 대부분 대칭키를 쓴다고 보면 된다. 비대칭은 "외부에 키를 노출하지 않고 서명"류 문제.
2.2 KMS 키 종류
종류 관리 주체 특징
| AWS Owned Key | AWS | 여러 계정이 공유. 보이지 않고 로그도 없음 |
| AWS Managed Key | AWS | aws/서비스명 형식. 확인은 가능, 무료 |
| Customer Managed Key (CMK) | 고객 | 정책/순환/삭제 직접 제어. 월 $1 + API 호출 요금 |
CMK만 KMS Key Policy를 세밀하게 편집 가능. 시험에서 "키 정책 편집", "감사 로그 필요", "삭제 지연 필요"가 요건이면 무조건 CMK.
2.3 자동 키 순환
- AWS Managed Key: 매년 자동 순환 (변경 불가)
- CMK: 옵션으로 매년 자동 순환. 기본은 꺼져 있음
- 순환 후에도 예전 키 소재는 남아 있어서 이전에 암호화된 데이터도 복호화 가능
2.4 Envelope Encryption (반드시 이해)
KMS 자체는 4KB 이상 데이터를 직접 암호화하지 못한다. 그래서 실제 데이터는 Data Key로 암호화하고, Data Key를 KMS CMK로 암호화하는 방식.
평문 데이터 ──[Data Key로 암호화]──> 암호문
Data Key ──[CMK로 암호화]──> 암호화된 Data Key (암호문 옆에 함께 저장)
주요 API:
- GenerateDataKey: 평문 Data Key + 암호화된 Data Key 함께 반환
- GenerateDataKeyWithoutPlaintext: 나중에 복호화용으로 저장할 때
- Decrypt: 암호화된 Data Key를 KMS에 보내 평문 Data Key 획득
시험 문제 힌트: "4KB보다 큰 데이터를 KMS로 암호화" → Envelope Encryption / GenerateDataKey.
2.5 CloudHSM
- 하드웨어 보안 모듈(HSM) 을 고객 전용으로 제공
- FIPS 140-2 Level 3 준수. 규제 요건이 KMS로 부족할 때
- 키 관리를 AWS도 못 보게 완전히 고객이 통제해야 하는 경우
- KMS와 달리 서비스 통합이 자동으로 안 됨. 애플리케이션 레벨에서 붙여야 함
3. S3 암호화 옵션
시험에 자주 나오는 옵션들. 이름이 비슷해서 반드시 정리해둬야 한다.
옵션 키 소유 키 관리 사용 예
| SSE-S3 | AWS | AWS 완전 관리, AES-256 | 기본, 별 요건 없을 때 |
| SSE-KMS | AWS/고객 | KMS CMK로 관리, 감사 로그 | 감사/규제 요건, 키 정책 필요 |
| DSSE-KMS | AWS/고객 | 이중 계층 암호화 | 국방/정부급 규제 요건 |
| SSE-C | 고객 | 고객이 키 직접 제공, AWS는 보관 안 함 | 키를 AWS 밖에서 관리해야 할 때 |
| Client-Side Encryption | 고객 | 업로드 전 클라이언트에서 암호화 | AWS를 완전히 신뢰 못 할 때 |
2023년부터 S3 신규 객체는 SSE-S3가 기본 활성화된다. 이거 놓치면 안 됨.
시험 힌트:
- "감사 로그로 누가 언제 키 썼는지 추적" → SSE-KMS
- "AWS에 키를 절대 저장하지 않음" → SSE-C or Client-Side
- "규제상 이중 암호화" → DSSE-KMS
S3 Bucket Key: SSE-KMS에서 KMS API 호출을 대폭 줄여주는 옵션. 대용량 요청에서 비용 최대 99% 절감. 시나리오에 "SSE-KMS 비용이 너무 높음" 나오면 답은 이거.
4. Security Group vs NACL
이 두 개 비교는 시험 단골. 표로 정리.
항목 Security Group NACL
| 적용 대상 | ENI (인스턴스 레벨) | 서브넷 레벨 |
| 상태(State) | Stateful (반환 트래픽 자동 허용) | Stateless (양방향 규칙 필요) |
| 규칙 종류 | Allow만 가능 | Allow 및 Deny 가능 |
| 규칙 평가 | 전부 평가 후 하나라도 매치되면 허용 | 번호 순서대로 평가, 매치되면 즉시 결정 |
| 기본 정책 | 모든 인바운드 차단, 모든 아웃바운드 허용 | 기본 NACL은 모두 허용, 커스텀 NACL은 모두 차단 |
실제로 헷갈리는 포인트
Stateful의 의미: SG에서 인바운드 80 포트만 열어도, 그에 대한 응답은 아웃바운드 규칙과 무관하게 자동으로 나간다. NACL은 반대로 아웃바운드 응답 포트(에페메랄 포트 1024–65535)를 별도로 열어줘야 한다.
Deny가 필요할 때: SG에는 Deny 규칙이 없다. 특정 IP만 차단해야 하면 NACL을 써야 한다. 시나리오에 "특정 악성 IP 차단" 나오면 SG가 아니라 NACL이 답.
규칙 번호: NACL 규칙은 낮은 번호부터 평가되므로, 100번에 Allow가 걸리고 200번에 Deny를 놓으면 200번 규칙은 무시된다. 반대로 100번에 Deny, 200번에 Allow면 Deny가 이김.
NAT Gateway
- Private Subnet의 인스턴스가 인터넷을 나가야 할 때 사용
- Public Subnet에 배치. Private에 배치하면 아무 의미 없다는 게 시험 함정
- NAT Gateway는 관리형/고가용성, NAT Instance는 저렴하지만 직접 관리
- 최신 시험은 대부분 NAT Gateway가 답
5. 관리형 보안 서비스
이름이 다 비슷해서 헷갈리는 것들. 한 문장씩 정리했다.
서비스 역할 사용 시점
| AWS WAF | HTTP/HTTPS 계층(L7) 웹 방화벽 | SQL Injection, XSS 차단 |
| AWS Shield Standard | 무료 L3/L4 DDoS 보호 | 자동 적용 |
| AWS Shield Advanced | 유료 고급 DDoS 보호 + WAF 포함 | 대규모 서비스 |
| GuardDuty | 위협 탐지 (지속적 모니터링) | 이상 API 호출, 크립토 마이닝 등 |
| Macie | S3 내 민감 데이터(PII) 자동 발견 | 개인정보 스캔 요건 |
| Inspector | EC2/ECR/Lambda 취약점 스캔 | CVE 자동 검사 |
| Security Hub | 여러 보안 서비스 결과 통합 대시보드 | 중앙 관제 |
| Detective | 보안 이벤트 원인 조사 (그래프 분석) | 사고 후 포렌식 |
시나리오 힌트
- "SQL Injection 방어" → WAF
- "DDoS로 사이트 다운" → Shield Advanced
- "S3에 개인정보가 있는지 스캔" → Macie
- "EC2 AMI에 알려진 취약점 검사" → Inspector
- "이상한 API 호출/암호화폐 마이닝 탐지" → GuardDuty
- "여러 보안 서비스 결과를 한 화면에서" → Security Hub
CloudTrail, Config는 보안 서비스는 아니지만 함께 자주 언급된다:
- CloudTrail: API 호출 감사 로그
- Config: 리소스 구성 변경 이력, 규정 준수 평가
6. Secrets Manager vs Parameter Store
기밀 정보 저장은 이 두 개 중 하나로 좁혀진다.
항목 Secrets Manager SSM Parameter Store
| 자동 순환 | 가능 (RDS/Redshift 등 통합) | 불가 (직접 구현 필요) |
| 비용 | 시크릿당 월 $0.40 + API 호출 | 표준 무료, Advanced $0.05/시크릿 |
| 최대 크기 | 64KB | 표준 4KB, Advanced 8KB |
| KMS 통합 | 기본 지원 | SecureString 타입에서 지원 |
| 크로스 계정 공유 | 리소스 정책으로 가능 | 불가 (직접 로직 필요) |
시험 힌트:
- "DB 자격 증명 자동 순환" → Secrets Manager
- "비용 최소화" or "환경 변수 대체" → Parameter Store
- "설정 값 저장 (기밀 아님)" → Parameter Store
7. 실전 문제 풀이
이번 주도 ExamTopics SAA-C03에서 보안 관련 문제를 골라 풀었다. 유형별로 3개.
문제 1 (S3 암호화 자주 나오는 유형)
한 회사가 S3에 대용량 로그 파일을 SSE-KMS로 암호화하여 저장한다. 최근 KMS API 요청량이 급증하면서 요금이 부담스러워졌다. 데이터 보안은 유지하면서 비용을 줄이는 방법은?
- A. 암호화 방식을 SSE-S3로 변경한다
B. S3 Bucket Key를 활성화한다
C. CloudFront를 통해 S3에 접근하도록 변경한다
D. 데이터를 압축하여 저장한다
정답: B
S3 Bucket Key는 버킷 레벨에서 임시 데이터 키를 캐시해 KMS API 호출을 크게 줄인다. 공식 문서에서는 최대 99%까지 요금 절감을 언급한다. 보안 수준은 SSE-KMS와 동일. A는 감사 로그가 사라지고, C는 무관하며, D는 KMS 호출 수와 무관하다.
문제 2 (SG vs NACL 자주 나오는 유형)
한 회사가 EC2 인스턴스에 대해 특정 IP 대역에서 오는 트래픽을 명시적으로 차단해야 한다. 이 인스턴스는 여러 서브넷에 분산되어 있다. 어떻게 구성해야 하는가?
- A. 보안 그룹에 해당 IP를 Deny 규칙으로 추가한다
B. 서브넷의 NACL에 해당 IP를 Deny 규칙으로 추가한다
C. VPC의 라우팅 테이블에서 해당 IP를 블랙홀로 라우팅한다
D. IAM 정책에 조건 키를 사용해 IP를 차단한다
정답: B
Security Group은 Deny 규칙이 없다. 특정 IP 차단은 무조건 NACL. NACL은 서브넷 레벨이라 여러 서브넷에 각각 적용해야 하지만 요구사항 자체가 서브넷 분산이므로 문제 없음. C는 인바운드 차단에 부적합, D는 AWS API 호출 제한이지 네트워크 계층 차단이 아니다.
문제 3 (관리형 보안 서비스 비교 유형)
한 회사가 AWS 계정에서 발생하는 비정상적인 API 호출과 크립토 마이닝 시도를 탐지하고 싶다. 별도 에이전트 설치 없이 지속적으로 모니터링해야 하며, 여러 계정에 걸쳐 결과를 통합 관리할 수 있어야 한다. 가장 적합한 조합은?
- A. GuardDuty를 활성화하고, 여러 계정 결과를 Security Hub에 집계
B. Inspector를 EC2에 설치하고 CloudWatch로 알람 설정
C. Macie로 S3를 스캔하고 SNS로 알림
D. CloudTrail 로그를 Athena로 직접 쿼리
정답: A
GuardDuty는 CloudTrail/VPC Flow Logs/DNS 로그를 기반으로 에이전트 없이 이상 API 호출과 마이닝을 탐지한다. Security Hub는 여러 계정의 GuardDuty 결과를 통합 대시보드로 제공. Inspector(B)는 취약점 스캐너지 이상 행위 탐지가 아님. Macie(C)는 S3 민감 데이터 스캔용. D는 지속적 모니터링에 부적합하다.
8. 이번 주 회고
지난 주 IAM을 정리해뒀던 게 이번 주에 계속 도움이 됐다. 결국 이번 주에 나온 서비스 대부분이 IAM 정책이나 리소스 정책 위에 얹혀 있는 형태였고, S3 암호화 옵션도 SSE-KMS면 어차피 KMS Key Policy가 붙는다. 보안 도메인이 IAM을 축으로 확장된다는 감각이 이제야 잡힌 것 같다.
가장 힘들었던 건 KMS의 Envelope Encryption과 CMK/AWS Managed Key/AWS Owned Key 구분이었다. 처음엔 다 KMS니까 비슷비슷하게 봤는데, 누가 키 정책을 편집할 수 있느냐는 관점으로 다시 보니 CMK만 답이 되는 이유가 명확해졌다. 시나리오형 문제에서 감사 로그 필요, 키 정책 커스터마이징 필요, 삭제 지연 필요 같은 단어가 나오면 자동으로 CMK로 정답이 좁혀진다.
또 다른 큰 수확은 Security Group과 NACL을 완전히 분리해서 이해한 것. 예전에는 대충 "둘 다 방화벽"이라고 뭉뚱그렸는데, Stateful/Stateless 개념을 노트에 그림으로 그려두고 나니 문제에서 어느 쪽을 물어보는지 즉시 판별 가능해졌다. 특히 Deny 규칙 필요가 나오면 무조건 NACL이라는 사실은 앞으로 계속 써먹을 것 같다.
관리형 보안 서비스들은 이름과 역할을 한 문장으로 매핑해서 노션 "SAA Tip"에 옮겨뒀다.
팀원 블로그
정재현 블로그
https://blog.naver.com/jjaehyun__/224344487255
[2026 하계 모각코] 2주차 모임
2주차 목표: LC Part 3~4 + RC Part 5 문법 기초 1주차에서 시험 전체 구조를 훑어봤다면, 2주차는 ...
blog.naver.com
박소윤 블로그
https://coding567.tistory.com/128
[2026 하계모각코] 2차시 결과
coding567.tistory.com
2주차 모임 사진
