[AWS DEA] 개념정리 - Domain4 데이터 보안 및 거버넌스

AWS DEA-C01 › Domain 4 · 전체 압축 정리

Domain 4 — 데이터 보안 및 거버넌스
핵심만 압축 정리

인증 · 권한부여 · 암호화 · 감사로그 · PII 보호 · Task 1~5 한 페이지

4.1

인증 메커니즘 적용

Task 1 · IAM 자격증명·정책·역할·VPC 보안·Secrets Manager

18%

🔐 인증(Authentication) vs 권한부여(Authorization) 인증 = 사용자를 식별하고 본인이 맞는지 확인 (누구인가?)
권한부여 = 인증된 자격증명이 어디까지 접근할 수 있는지 결정 (무엇을 할 수 있는가?)

IAM 자격증명 유형 비교

유형	특징	자격증명	사용 사례
IAM User	한 사람·애플리케이션에 고유 연결	장기(영구) 자격증명	개별 개발자, 서비스 계정
IAM Group	동일 권한 필요한 사용자 묶음. 로그인 X	—	팀 단위 권한 일괄 관리
IAM Role	누구나 수임 가능. 특정인에 종속 X	임시 자격증명 (STS)	교차 계정 액세스, 서비스 간 연동
Federated ID	외부 IDP(SAML, OIDC) 자격증명 사용	IAM Identity Center	SSO, 기업 디렉터리 연동

IAM 정책 3종류 비교

정책 유형	누가 만드나	연결 대상	특징
AWS 관리형	AWS	사용자·그룹·역할	수정 불가. AWS가 직접 관리·업데이트
고객 관리형	고객	여러 자격증명 재사용	계정 내 여러 User/Group/Role에 연결 가능
인라인	고객	단일 자격증명 전용	1:1 관계. 자격증명 삭제 시 함께 삭제

📌 IAM Role 2가지 정책 — 시험 포인트 역할에는 항상 2개의 정책이 필요:
① 신뢰 정책(Trust Policy) = 이 역할을 수임할 수 있는 사람/서비스 정의
② 자격증명 기반 정책(Identity-based Policy) = 역할 수임 후 어떤 작업을 할 수 있는지 정의
⚠️ 정책에서 명시적으로 허용하지 않은 작업은 기본적으로 거부(Deny)

정책 연결 위치 — 자격증명 기반 vs 리소스 기반

📋 자격증명 기반 정책

IAM User·Group·Role에 연결. "이 자격증명이 무엇을 할 수 있나?"

🪣 리소스 기반 정책

S3 버킷·KMS 키 등 리소스에 직접 연결. "이 리소스에 누가 접근할 수 있나?"

VPC 네트워크 보안 요소

구성 요소	역할	핵심
Security Group	인스턴스 레벨 방화벽	인바운드/아웃바운드 규칙. Stateful(응답 자동 허용)
NACL	서브넷 레벨 방화벽	번호 순서 규칙. Stateless(요청·응답 각각 허용 필요)
Private Subnet	외부 직접 접근 차단	DB·내부 서비스 배치. NAT Gateway로 외부 연결
VPC Endpoint	인터넷 없이 AWS 서비스 접근	Gateway(S3·DynamoDB) / Interface(나머지)
VPC Flow Logs	네트워크 트래픽 기록	보안·규정 준수 감사. CloudWatch 또는 S3로 전송
AWS Network Firewall	VPC 수준 방화벽	트래픽 검사·필터링. 심층 패킷 검사 지원
Bastion Host	Private 리소스 접근 중계	Public Subnet에 배치. SSH 터널로 내부 접근

Secrets Manager — 비밀 수명주기

① 생성Secrets Manager

→

② 저장KMS 암호화

→

③ 사용앱에서 API 호출

→

④ 자동 교체Lambda 기반 Rotation

→

⑤ 삭제

💡 Secrets Manager vs Parameter Store — 구분 포인트 Secrets Manager = 자동 교체(Rotation) 지원. DB·API키·OAuth 토큰. 더 높은 보안. 비용 있음.
Parameter Store = 자동 교체 X. 단순 설정값·구성 데이터. 무료 티어 있음. Secrets Manager 비밀을 Parameter로 참조 가능(비밀 ID 앞에 / 필요).

📝 시험 시나리오 — QuickSight S3 권한 오류

새 S3 버킷에 Athena 테이블 생성 후 QuickSight에서 가져오기 실패. 권한 부족 오류. 사용자에게 권한은 있음. 원인과 해결책은?

교차 서비스 액세스(Cross-Service Access) 문제. 사용자 권한만으로는 불충분. QuickSight 자체에도 S3 버킷 접근 권한을 별도로 부여해야 함. QuickSight 콘솔 → 보안 설정 → 새 S3 버킷에 대한 권한 추가.

---

4.2

권한 부여 메커니즘 적용

Task 2 · RBAC·ABAC·Lake Formation·Redshift 권한 관리

RBAC vs ABAC — 핵심 비교

👤 RBAC (역할 기반 액세스 제어)

역할에 따라 리소스 액세스 결정.
예: 개발자 역할 → 파이프라인 개발 권한
✅ 관리 단순. 역할=권한 명확
❌ 복잡한 비즈니스 로직엔 역할 폭발 문제
Lake Formation, Redshift RBAC 지원

🏷️ ABAC (속성 기반 액세스 제어)

태그(속성)를 기반으로 권한 동적 결정.
예: access-project=Heart 태그 매칭 시 접근
✅ 세분화·동적 권한. 정책 수 감소
❌ 초기 구현 복잡. 속성 전략 설계 필요
Lake Formation LF-Tags, IAM 태그 조건 지원

💡 하이브리드 RBAC+ABAC 두 모델을 결합하여 세분화 계층 추가. 사용자의 역할(RBAC) + 추가 속성(ABAC)을 결합하여 액세스 결정. 복잡한 데이터 레이크 환경에서 권장.

Lake Formation 권한 관리 — 세분화 수준

수준	Lake Formation 지원	적용 대상
데이터베이스 수준	✅	데이터베이스 전체 접근 제어
테이블 수준	✅	특정 테이블 접근 제어
열(Column) 수준	✅	민감한 열만 마스킹·숨기기
행(Row) 수준	✅ (행 필터)	특정 조건 행만 노출
셀(Cell) 수준	✅	DDM으로 셀 단위 마스킹
LF-Tags 기반 (ABAC)	✅	수천 개 리소스를 몇 개 태그로 관리

Amazon Redshift 권한 관리

방법	명령어/기능	설명
사용자 생성	CREATE USER / ALTER USER	데이터베이스 슈퍼 사용자만 생성·삭제 가능
RBAC 역할 기반	CREATE ROLE / GRANT ROLE	역할에 권한 부여 후 사용자에 역할 할당. 최소권한 원칙
열 수준 권한	GRANT SELECT(col) ON TABLE	특정 열에 대한 SELECT·UPDATE 권한만 부여
동적 데이터 마스킹	DDM 마스킹 정책	쿼리 시점에 민감 데이터 변환. 실제 데이터 변경 X
데이터 공유	Lake Formation 통합	Redshift 데이터 공유 객체에 DB·테이블·열·행 수준 권한

📝 시험 시나리오 — API Gateway IAM 권한 모델

API Gateway에서 API 개발자와 API 직접 호출자의 권한 모델이 다른 이유는?

API 개발자 = API 생성·배포·관리. apigateway:* 권한 정책 → User/Role/Group에 연결
API 직접 호출자 = API 실행. 메서드의 authorizationType = AWS_IAM 설정 후 실행 권한 정책 연결
Lambda 백엔드 연동 시 = API Gateway 역할에 lambda:InvokeFunction 권한 추가 필요 (신뢰 정책 + 권한 정책)

---

4.3

데이터 암호화 및 마스킹

Task 3 · KMS·CloudHSM·TLS·암호화 vs 토큰화·익명화·마스킹

암호화 키 관리 서비스 비교

서비스	관리 주체	핵심 특징	선택 기준
AWS KMS	AWS (소프트웨어 HSM)	대부분 AWS 서비스와 통합. CMK/AWS 관리형 키. CloudTrail로 키 사용 로깅. 봉투 암호화(Envelope Encryption)	일반적인 AWS 서비스 암호화
CloudHSM	고객 (하드웨어 HSM 직접 관리)	전용 하드웨어 보안 모듈. AWS는 하드웨어·패치만 관리. 고객이 암호화 계정·자격증명 직접 관리	HSM 직접 제어 필요 시
ACM	AWS	SSL/TLS X.509 인증서 생성·갱신·배포 자동화. NLB·ALB·CloudFront·API Gateway에 연결	TLS 인증서 관리

전송 중(In-Transit) vs 저장 시(At-Rest) 암호화

🌐 전송 중 암호화

• TLS(Transport Layer Security) = 모든 AWS 서비스 HTTPS 엔드포인트 지원
• AWS 데이터센터 간 네트워크 트래픽 = 물리 계층에서 투명하게 암호화
• VPC 내·피어링 VPC 간 = 네트워크 계층 투명 암호화
• TLS 종단 옵션: NLB, ALB, CloudFront, API Gateway

🔒 저장 시 암호화

• S3: SSE-S3, SSE-KMS, SSE-C, 클라이언트 측
• EBS: KMS 키로 볼륨 암호화
• RDS/Aurora: KMS 통합 암호화
• Redshift: KMS 또는 CloudHSM
• EMR: EBS 암호화 + 로컬 디스크 별도 설정
• SQS: SSE로 메시지 암호화
• Glue, SageMaker, Lambda: KMS 통합

⚠️ EMR 암호화 주의 — 시험 출제 포인트 Amazon EBS 볼륨이 암호화되어도 로컬 디스크는 자동으로 암호화되지 않음. 보안 구성(Security Configuration)에서 로컬 디스크 암호화를 별도로 추가해야 함. 루트 디바이스 볼륨 암호화는 사용자 지정 AMI + KMS 키로 EBS 루트 볼륨 암호화하여 CloudFormation CustomAmiID로 지정.

암호화 vs 토큰화 vs 마스킹 vs 익명화 — 4개념 구분

기술	방식	복호화 가능?	원본 관계	사용 사례
암호화	알고리즘+키로 일반텍스트 → 암호텍스트	✅ 키 있으면 가능	수학적 관계	저장·전송 데이터 전반
토큰화	민감 데이터 → 임의 토큰. 볼트DB에 매핑 저장	✅ 볼트 통해서만	토큰은 의미 없는 임의값	신용카드·PII 처리
데이터 마스킹	변경된 값으로 기밀 데이터 일부 모호화	✅ (원본 보존)	일부 변환 (예: 010-****-5678)	열람 제한, 테스트 환경
데이터 익명화	데이터셋에서 개인식별 정보 완전 제거	❌ 복원 불가	관계 단절	분석용 공개 데이터
키 솔팅	해시 함수 입력에 임의 솔트 추가	❌ 단방향	솔트+암호 연결 해시	패스워드 해싱

🪙 토큰화 설계 패턴 — 서버리스 Amazon Cognito(인증) → API Gateway → Lambda(토큰화 계층 호출) → KMS(데이터 키 생성) → DynamoDB(암호 텍스트 저장) + 토큰 → 애플리케이션 DB 저장.
보안 강화: Lambda는 VPC 내 배치. DynamoDB = 게이트웨이 엔드포인트, KMS = 인터페이스 엔드포인트 사용 (인터넷 우회).

Redshift 동적 데이터 마스킹(DDM)

🎭 DDM — 데이터 변환 없이 쿼리 시 마스킹 실제 데이터는 그대로 저장. 쿼리 시점에만 마스킹 표현식 적용. 특정 사용자/RBAC 역할에만 마스킹 정책 적용 가능. 조건부 열로 셀 수준 DDM 가능. 동일 열에 여러 마스킹 정책 적용 후 다른 역할에 할당 가능.

---

4.4

감사를 위해 로그 준비

Task 4 · CloudTrail Lake·CloudWatch Logs·EMR 로깅·규정 준수

📋 감사 로그의 목적 HIPAA·PCI 등 규정에서 특정 기간 동안 데이터 보관·검색 가능성 요구. CloudWatch Logs 보존 정책으로 기간 지정(기본 무기한). 데이터 저장 + 검색 + 기간 후 삭제 3가지 기능 모두 필요.

CloudTrail Lake — 중앙 집중식 이벤트 분석

항목	설명
이벤트 데이터 스토어	CloudTrail 이벤트, Config 항목, Audit Manager 증거, AWS 외부 이벤트를 분리 저장
SQL 쿼리	여러 이벤트 데이터 스토어에 걸쳐 SQL JOIN 쿼리 실행 가능
태그 기반 접근 제어	추적(Trail)은 태그 기반 인증 미지원. 이벤트 데이터 스토어는 태그 기반 접근 제어 지원
CloudWatch 지표 연동	이벤트 데이터 스토어 수집량·보존 기간 지표 제공
외부 이벤트 통합	AWS 외부 사용자 활동 데이터도 로깅·저장 가능

로그 분석 도구 — 목적별 선택

도구	용도	특징
CloudWatch Logs Insights	CloudWatch 로그 SQL 쿼리 분석	Route 53·Lambda·CloudTrail·VPC 로그 필드 자동 감지. 잠재적 원인 식별
Athena + CloudWatch 커넥터	CloudWatch 로그를 SQL로 쿼리	로그 그룹=스키마, 로그 스트림=테이블 매핑. all_log_streams 뷰로 전체 조회
CloudWatch Logs → OpenSearch	실시간 로그 스트리밍·검색	구독 기능으로 거의 실시간 OpenSearch 전송. 대시보드·검색 활용
CloudTrail Lake SQL	AWS API 호출 이력 중앙 분석	여러 계정·리전 이벤트를 단일 SQL로 분석

EMR 로깅 구성

📁 Amazon EMR 로그 구조 기본: 프라이머리 노드의 /mnt/var/log/ 디렉터리에 로그 파일 기록.
S3 로그 보관: 클러스터 생성 시 S3 버킷 지정 → 로그 자동 복사.
CloudTrail 통합: EMR API 호출(콘솔·SDK 모두) 자동 기록 → S3 버킷에 지속 전달.
추적 없어도 CloudTrail 콘솔 이벤트 기록에서 최신 이벤트 조회 가능.

---

4.5

데이터 프라이버시 및 거버넌스

Task 5 · PII 보호·데이터 주권·백업·Macie·안전한 데이터 레이크

전체 수명주기 PII 보호 전략

보호 방법	설명	AWS 서비스
전송 중 보호	TLS로 통신 채널 암호화	ACM, NLB/ALB, CloudFront, API Gateway
저장 시 보호	볼륨·객체·DB 테이블 암호화	KMS, CloudHSM, S3 SSE, EBS
필드 수준 암호화	페이로드 중 민감 필드만 선택적 암호화. 나머지는 일반 텍스트 유지	CloudFront + Lambda@Edge
PII 자동 탐지	S3에서 주민번호·신용카드·이메일 등 자동 감지	Amazon Macie
민감 데이터 식별(ETL)	Glue ETL에서 Comprehend 호출로 민감 정보 식별·마스킹	AWS Glue + Amazon Comprehend
세분화된 접근 제어	분석가·과학자에게 열·행 수준 제어된 접근	Lake Formation + Athena/Redshift Spectrum

안전한 데이터 레이크 파이프라인 — Macie 활용 흐름

원시 S3 버킷데이터 수집

→

스캔 S3 버킷Macie 민감 데이터 스캔

→

민감 데이터 발견?수동 검토 버킷 이동

→

SNS 알림관리자 승인/거부

→

스캔된 데이터 버킷다음 수집 단계 시작

🔄 파이프라인 오케스트레이션 EventBridge(6시간 반복 트리거) → Step Functions(워크플로 오케스트레이션) → Lambda(민감 데이터 스캔 논리) → Macie(스캔 실행) → API Gateway(검토자 결정 수신 REST API 2개 리소스)

S3 데이터 보호 기능 — 스토리지 관리자 역할

🔄 버전 관리

객체 여러 버전 보존. 실수 삭제·덮어쓰기 방지

📋 동일 리전 복제 (SRR)

같은 리전 내 다른 버킷으로 자동 복제

🌏 교차 리전 복제 (CRR)

다른 리전 버킷으로 복제. DR 대비

🔒 S3 Object Lock

WORM(Write Once Read Many). 규정 준수 보관

🏷️ 태그 기반 백업

DataProtectionLevel: Critical 태그로 백업 대상 S3 버킷 선별

💾 AWS Backup

백업 계획 정의. PITR(특정 시점 복원). 다른 계정·리전 볼트에 복사 가능

데이터 주권 — 허용되지 않는 리전으로의 백업 방지

🌍 데이터 주권(Data Sovereignty) 핵심 특정 AWS 리전 외부로 데이터 이동 금지 요구. AWS Organizations + SCP(서비스 제어 정책)으로 특정 리전 외 리소스 생성·복제 차단. AWS Backup Audit Manager로 백업 정책 준수 감사·보고. CloudFormation StackSets로 여러 계정·리전에 CloudTrail·Config 일관 배포.

📝 시험 시나리오 — Redshift 기밀 열 보호

Redshift에 기밀 데이터가 포함된 새 테이블을 여러 팀이 쿼리. 권한 있는 사용자만 기밀 열을 읽도록 하려면?

방법 1: Lake Formation + Redshift Spectrum → 열 수준 접근 제어
방법 2: Amazon Redshift 열 수준 GRANT/REVOKE 명령으로 직접 제어
방법 3: Redshift DDM(동적 데이터 마스킹)으로 역할별 마스킹 정책 적용 (원본 변경 없이 쿼리 시 마스킹)

AWS Config — 구성 변경 추적 메커니즘

🔍 AWS Config 작동 원리 활성화 시 계정 내 지원 AWS 리소스 탐색 → 각 리소스 구성 항목(Configuration Item) 생성.
리소스 변경 시 Describe/List API 직접 호출 → 구성 업데이트를 구성 스트림으로 S3 버킷에 전달.
Config 규칙 = Lambda 함수와 연결된 평가 논리. 구성 변경·알림 → SNS 주제로 스트림 가능.

---

🎯 Domain 4 시험 핵심 — 이것만 기억

• ①인증 vs 권한부여 = 인증(누구인가) / 권한부여(무엇을 할 수 있나)
• ②IAM Role 2개 정책 필수 = 신뢰 정책(수임 허용) + 자격증명 기반 정책(작업 허용)
• ③IAM User = 영구 자격증명 / IAM Role = 임시 자격증명(STS). 역할은 누구나 수임 가능
• ④Secrets Manager = 자동 교체(Rotation) 지원 / Parameter Store = 자동 교체 없음. 단순 설정값
• ⑤RBAC = 역할 기반 단순 관리 / ABAC = 태그 속성 기반 동적·세분화. Lake Formation LF-Tags
• ⑥EMR EBS 암호화 ≠ 로컬 디스크 암호화. 로컬 디스크는 보안 구성에서 별도 추가 필요
• ⑦암호화 = 수학적 복원 가능 / 토큰화 = 볼트 통해서만 복원 / 익명화 = 복원 불가 / 마스킹 = 부분 모호화
• ⑧Redshift DDM = 원본 데이터 변경 없이 쿼리 시점에 마스킹. 역할별 다른 마스킹 정책 가능
• ⑨CloudTrail Lake = 여러 계정·리전 이벤트를 SQL로 중앙 분석. Config 항목·외부 이벤트도 포함 가능
• ⑩Macie → EventBridge 자동 Push. Macie는 CloudWatch Logs로 직접 전송 X. Security Hub는 별도 설정 필요
• ⑪필드 수준 암호화 = CloudFront + Lambda@Edge. 민감 필드만 선택적 암호화. 전체 페이로드 암호화와 다름
• ⑫QuickSight 교차 서비스 권한 = 사용자 권한만으로 부족. QuickSight 자체에 S3 접근 권한을 별도 부여해야 함
• ⑬데이터 주권 = SCP로 허용 리전 외 복제 차단. AWS Backup Audit Manager로 규정 준수 감사
• ⑭AWS Config = 리소스 구성 변경 추적·규정 준수. Config 규칙 = Lambda 함수로 평가 논리 연결

AWS DEA-C01 Domain 4 압축 정리 · hyeonlee.net

Domain 1~4 전체 정리 완성! 시험 합격을 응원합니다 🎯