KEK (Key Encryption Key)

공부할게 산더미·2026년 3월 30일

KEK 보안 암호화

보안

목록 보기

1/1

핵심 한 줄 요약: KEK는 "키를 암호화하는 키"다. 데이터를 직접 암호화하지 않고, 데이터를 암호화하는 키(DEK)를 보호하는 역할을 한다.

1. 기초 개념: 암호화 키란?

암호화(Encryption)는 데이터를 읽을 수 없는 형태로 변환하는 기술이다. 이때 암호화와 복호화에 사용되는 비밀 값을 암호화 키(Encryption Key) 라고 한다.

예시:

원문: 안녕하세요
암호화 후: X9kL#2mQpZ!
복호화(키 있어야 가능): 다시 안녕하세요

2. 왜 KEK가 필요한가?

문제 상황

하나의 키로 모든 데이터를 암호화하면 어떻게 될까?

문제	설명
키 노출 시 전체 위험	키 하나가 털리면 모든 데이터가 해독됨
키 교체(로테이션) 비용	100만 건의 데이터를 모두 재암호화해야 함
관리 복잡성	하나의 키에 모든 권한이 집중됨

해결책: 키 계층 구조

3. 핵심 용어 정리

용어	풀네임	역할	보관 위치
마스터 키	Master Key	최상위 키. KEK를 보호	HSM / KMS
KEK	Key Encryption Key	DEK를 암호화해서 보호	안전한 서버 / KMS
DEK	Data Encryption Key	실제 데이터를 암호화	암호화된 상태로 DB에 저장
HSM	Hardware Security Module	물리적 하드웨어 키 보관 장치	물리적 서버 내부
KMS	Key Management Service	클라우드 기반 키 관리 서비스	AWS KMS, GCP KMS 등

3-1. HSM vs KMS 자세히 알아보기

HSM (Hardware Security Module)

물리적인 하드웨어 장치다. 암호화 키를 특수 칩 안에 가둬두는 방식이다.

핵심은 키가 장치 밖으로 절대 나오지 않는다는 것이다. "이 키로 암호화해줘"라고 요청하면 HSM이 내부에서 처리하고 결과만 돌려준다. 키 자체를 꺼낼 수 없다. 물리적으로 뜯으려고 하면 자동으로 키를 삭제하는 탬퍼 방지(Tamper-proof) 기능도 있다.

🏦 비유: 은행 금고실 안의 철제 금고. 우리 회사 건물 안에 있고 열쇠도 우리만 가진다. 가장 안전하지만 금고를 직접 사고 관리해야 한다.

적합한 곳: 은행, 정부기관, 대형 금융사 등 보안이 최우선인 곳

KMS (Key Management Service)

클라우드 기반 키 관리 서비스다. AWS, GCP, Azure 같은 클라우드 회사가 HSM을 대신 운영해주는 서비스다.

내부적으로는 HSM을 사용하지만, 개발자 입장에서는 API 호출만 하면 된다. 직접 하드웨어를 살 필요도, 관리할 필요도 없다. 대신 클라우드 회사를 신뢰해야 한다는 전제가 깔린다.

☁️ 비유: 은행의 대여 금고 서비스. 은행(클라우드)이 금고를 운영하고, 우리는 열쇠만 가지고 필요할 때 접근한다. 편리하지만 은행을 믿어야 한다.

적합한 곳: 스타트업~대기업 전반, 클라우드 인프라를 쓰는 곳

HSM vs KMS 비교

항목	HSM	KMS
형태	물리적 하드웨어	클라우드 서비스
운영 주체	우리 회사 직접	AWS / GCP / Azure
비용	초기 비용 큼 (수백~수천만 원)	사용량 기반, 저렴
편의성	낮음 (직접 관리)	높음 (API 호출)
신뢰 전제	우리 자신만 믿으면 됨	클라우드사도 믿어야 함
대표 제품	Thales Luna, AWS CloudHSM	AWS KMS, GCP Cloud KMS, Azure Key Vault

4. 동작 원리 (데이터 암호화 흐름)

데이터를 저장할 때

1. DEK 생성 (랜덤하게)
2. DEK로 실제 데이터 암호화 → 암호화된 데이터 저장
3. KEK로 DEK 암호화 → 암호화된 DEK 저장

데이터를 읽을 때

1. 암호화된 DEK 가져옴
2. KEK로 DEK 복호화 → 평문 DEK 획득 (메모리에만 존재)
3. DEK로 암호화된 데이터 복호화 → 원본 데이터 획득

⚠️ 중요: DEK는 평문 상태로 디스크에 저장되지 않는다. 반드시 KEK로 암호화된 상태로만 저장된다.

5. 키 로테이션 (Key Rotation)

키를 주기적으로 교체하는 것을 키 로테이션이라고 한다. KEK 계층 구조의 가장 큰 장점은 효율적인 로테이션이다.

KEK 로테이션 과정

[기존 KEK] → DEK 복호화 → [평문 DEK] → 새 KEK로 재암호화 → [새 암호화된 DEK]
                                               ↑
                                        실제 데이터는 변경 없음!

DEK 로테이션 과정 (필요시)

1. 새 DEK 생성
2. 새 DEK로 실제 데이터 재암호화
3. 새 DEK를 KEK로 암호화해서 저장

비교

방식	작업 범위	비용
KEK 교체	DEK만 재암호화	매우 낮음
DEK 교체	실제 데이터 전체 재암호화	높음

6. 실제 사용 사례

클라우드 환경 (AWS KMS 예시)

AWS KMS (마스터 키 보관)
    └── CMK (Customer Master Key) = KEK 역할
            └── Data Key (DEK) - KMS가 생성해줌
                    └── S3 파일, RDS 데이터, EBS 볼륨 등

GenerateDataKey API 호출 → KMS가 DEK 생성 + KEK로 암호화된 DEK 반환
평문 DEK는 메모리에서만 사용, 암호화된 DEK만 저장

데이터베이스 암호화 (TDE - Transparent Data Encryption)

마스터 키 → KEK(서버 키) → DEK(테이블스페이스 키) → 실제 DB 데이터

Oracle, MySQL, SQL Server 모두 이 방식 사용

파일 시스템 암호화

사용자 비밀번호 → KEK 파생 → 파일별 DEK → 실제 파일 내용

macOS FileVault, Windows BitLocker가 이 방식

7. 보안 고려사항

KEK 보호 방법

방법	설명	수준
HSM 사용	물리적 하드웨어에 키 저장, 추출 불가	최고
KMS 서비스	AWS/GCP/Azure의 관리형 키 서비스	높음
접근 제어 (IAM)	KEK에 접근 가능한 서비스/사람 제한	기본
감사 로그	KEK 사용 기록 모두 로깅	기본

키 보관 원칙

분리 보관: KEK와 암호화된 DEK를 같은 위치에 저장하지 않는다
최소 권한: KEK에 접근할 수 있는 권한을 최소화한다
오프라인 백업: 마스터 키는 에어갭(인터넷 단절) 환경에 백업
키 만료: 모든 키에 유효기간을 설정하고 주기적으로 교체

8. 관련 알고리즘

KEK에 자주 쓰이는 알고리즘

알고리즘	종류	키 길이	특징
AES-256	대칭키	256비트	가장 널리 쓰임, 빠름
RSA-2048	비대칭키	2048비트	키 교환에 활용
AES-GCM	대칭키	128/256비트	무결성 검증 포함

키 래핑(Key Wrapping)

KEK로 DEK를 암호화하는 것을 키 래핑(Key Wrapping) 이라고 한다. 표준 알고리즘으로는 AES Key Wrap (RFC 3394) 이 있다.

Wrapped DEK = AES_KEYWRAP(KEK, DEK)
DEK = AES_KEYUNWRAP(KEK, Wrapped_DEK)

9. 실무 체크리스트

설계 단계

데이터 민감도 분류 (공개 / 내부 / 기밀 / 극비)
암호화 범위 결정 (전체 DB? 특정 컬럼? 파일?)
키 계층 설계 (마스터 키 - KEK - DEK 레벨 정의)
KMS 서비스 선택 (AWS KMS / GCP Cloud KMS / Azure Key Vault)

구현 단계

마스터 키를 HSM 또는 관리형 KMS에 보관
DEK는 항상 암호화된 상태로만 디스크에 저장
평문 DEK는 메모리에서만 사용, 사용 후 즉시 제거
KEK와 암호화된 DEK를 물리적으로 분리 저장

운영 단계

키 로테이션 주기 설정 (KEK: 1년, DEK: 3-6개월)
모든 키 사용 접근 로그 기록
키 백업 및 복구 절차 문서화
키 유출 시 대응 절차(Key Revocation) 수립

10. 관련 표준 및 규정

표준/규정	키 관리 요구사항
PCI DSS	카드 데이터 암호화, KEK와 DEK 분리 필수
ISO 27001	키 관리 정책 수립 및 주기적 교체 요구
NIST SP 800-57	키 관리 가이드라인 (알고리즘, 키 길이, 수명)
FIPS 140-2	암호화 모듈(HSM) 검증 기준
GDPR	개인정보 암호화 및 키 관리 책임

11. 자주 하는 실수

❌ 잘못된 방식

# 절대 이렇게 하면 안 됨
KEK와 암호화된 DEK를 같은 DB에 저장
→ DB가 털리면 KEK와 DEK 동시에 노출

코드에 KEK를 하드코딩
→ 소스코드 노출 시 모든 데이터 복호화 가능

DEK를 평문으로 저장
→ KEK 없이도 데이터 복호화 가능

✅ 올바른 방식

KEK → KMS/HSM에 보관 (별도 시스템)
암호화된 DEK → 애플리케이션 DB에 저장
실제 데이터 → 별도 스토리지에 저장

참고 자료

NIST SP 800-57: https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final
AWS KMS 문서: https://docs.aws.amazon.com/kms/
RFC 3394 (AES Key Wrap): https://www.rfc-editor.org/rfc/rfc3394
Google Cloud KMS: https://cloud.google.com/kms/docs

마지막 업데이트: 2026년 3월

공부할게 산더미