728x90
데이터 암호화는 단일 기술이 아니라 “계층형 방어 체계”입니다.
300x250
아래 3개 축은 서로 대체 관계가 아니라 반드시 함께 작동해야 합니다.
- 전송 암호화 (In Transit)
- 저장 암호화 (At Rest)
- 키 관리 (KMS · 엔벨로프 암호화 · 키 수명주기)
핵심 원칙
“데이터는 항상 암호화되어 있어야 하고,
그 암호화 키는 데이터와 분리되어 중앙에서 통제되어야 한다.”
전송 암호화 (Encryption In Transit)
1. 개념과 배경
전송 암호화는 네트워크를 이동 중인 데이터를 보호합니다.
- 공격 시나리오
- 내부망 스니핑
- 중간자 공격(MITM)
- 프록시/로드밸런서 구간 도청
- 전송 암호화가 없으면
→ 내부망 침해 시 모든 인증 정보·API Payload가 평문 노출
2. 적용 대상
- 클라이언트 ↔ 서버 (웹/모바일)
- 서버 ↔ 서버 (마이크로서비스)
- 서버 ↔ DB
- 서버 ↔ MQ / Cache (Kafka, Redis 등)
“내부 트래픽은 안전하다”는 가정은 Zero Trust 시대에 폐기
3. 기술 요소
| 영역 | 기술 |
|---|---|
| 웹/API | HTTPS (TLS 1.2+) |
| 내부 서비스 | TLS / mTLS |
| VPN | TLS 기반 VPN |
| 메시지 | TLS + (필요 시) 메시지 레벨 E2E |
4. 설계·보안 가이드
강제 사항
- TLS 1.0 / 1.1 완전 차단
- HSTS 활성화
- 인증서 자동 갱신 (ACM, Cert Manager)
점검 포인트
- 내부 API 중 HTTP 남아있는지
- DB/MQ 접속 문자열에
ssl=true적용 여부 - 프록시–백엔드 구간 TLS 여부
전송 암호화의 한계
도착 후 메모리·디스크에 쓰인 순간부터는 보호되지 않음
→ 반드시 저장 암호화가 필요
저장 암호화 (Encryption At Rest)
1. 개념과 위협 모델
저장 암호화는 “유출된 저장 매체”를 가정합니다.
- 디스크 탈취
- 백업 파일 유출
- 스냅샷/오브젝트 스토리지 오픈
- 내부 관리자 오남용
전송 암호화만 있고 저장 암호화가 없으면
→ 백업 하나로 전체 개인정보 유출 가능
2. 저장 암호화 레벨 3단계
① 인프라/볼륨 레벨
- EBS, LUKS, 디스크 전체 암호화
- 장점: 투명, 성능 영향 적음
- 한계: 관리자 접근 시 평문 가능
② 스토리지/서비스 레벨
- S3, RDS, GCS 등
- KMS 연동 기본 암호화
- 대부분 컴플라이언스 최소 요건 충족
③ 애플리케이션 레벨 (가장 중요)
- 주민번호, 카드번호, 토큰 등
- 컬럼 단위 암호화
- KMS 기반 엔벨로프 암호화 사용
“민감정보는 반드시 앱 레벨 암호화”
3. 내부 보안 점검 포인트
- 모든 DB/스토리지 암호화 활성화 여부
- 로그/백업/스냅샷 암호화 포함 여부
- 개인정보 컬럼 평문 저장 여부
- 운영자 SQL 조회로 복호화 가능한지
KMS 기반 키 관리 (가장 핵심)
1. 왜 KMS가 필요한가
암호화 실패의 90%는 알고리즘이 아니라 키 관리 실패입니다.
❌ 하드코딩
❌ 설정 파일 저장
❌ 동일 키 장기 사용
→ KMS는 키를 “사용만” 하게 하고 “보지 못하게” 합니다
2. 엔벨로프 암호화 구조 (표준 패턴)
[KMS Master Key]
↓
[Encrypted Data Key] ----> 저장
↓
[Plain Data Key] (메모리에서만 사용 후 폐기)
↓
[Actual Data Encryption]핵심 포인트
- KMS 키는 데이터 직접 암호화 X
- 데이터 키는 매번 생성
- 평문 키는 절대 저장 금지
3. 키 수명주기 관리 (Lifecycle)
① 생성
- 서비스/환경/테넌트 단위 분리
- prod / stage / dev 키 분리 필수
② 사용
- Encrypt / Decrypt 권한 분리
- 조건부 정책 (VPC, IP, 서비스 계정)
③ 로테이션
- 자동 로테이션: 키 재료 교체
- 수동 로테이션: 새 키 + alias 전환
④ 삭제
- 즉시 삭제 금지
- 7~30일 삭제 대기
- 사고 대응 시 “키 파쇄” 가능
AWS KMS 키 로테이션 전략의 위치
1. 자동 로테이션 (기본 전략)
- 대상: AWS 생성 대칭 CMK
- 주기: 기본 365일 (90~2560일)
- 장점
- 앱 수정 없음
- 기존 암호문 자동 호환
- 대부분의 서비스에서 권장
aws kms enable-key-rotation --key-id <KEY_ID>
2. 수동 로테이션 (고급/사고 대응)
- 사용 사례
- 키 유출 의심
- 테넌트 분리
- 암호화 경계 재설계
- 방식
- 새 키 생성
- alias만 스위칭
- 점진적 재암호화
aws kms update-alias \ --alias-name alias/my-app-key \ --target-key-id <NEW_KEY>
3. 내부 통제 포인트
- 누가 로테이션 설정 변경 가능한가
- RotationPeriod 제한 정책
- 로테이션 이벤트 감사 로그 확인
실서비스 기준 통합 아키텍처
[Client]
↓ TLS
[API Gateway]
↓ mTLS
[Backend Service]
↓ TLS + App-level Encryption (KMS)
[DB / Storage]
↓ At-rest Encryption (KMS)✔ 전송 중 보호
✔ 저장 시 보호
✔ 키는 중앙 통제
→ 단일 계층 침해로 전체 유출 불가
728x90
그리드형(광고전용)
댓글