03. 암호화 기초
봉투 암호화(4번)와 SKM(5번)을 이해하려면 딱 이만큼의 암호학 기초가 필요합니다. 깊게 안 들어가고 "왜 이 두 종류를 나눠 쓰는가"에 집중.
1) 대칭키 (Symmetric Key) — AES, ARIA 등
하나의 같은 키로 암호화도 하고 복호화도 함.
평문 ──[ 키 K 로 암호화 ]──► 암호문
암호문 ──[ 같은 키 K 로 복호화 ]──► 평문특징:
- 빠르다. 연산이 가벼워서 대용량 데이터 암/복호화에 적합.
- 그래서 실제 데이터(수백 MB, DB 컬럼 수억 건) 를 암호화할 땐 거의 항상 대칭키.
- 대표 알고리즘: AES(국제 표준, AES-256이 사실상 기본), ARIA/SEED(국내 국정원 검증 알고리즘, 공공기관용).
- 약점: 키 하나를 주고받는 게 어렵다. 상대에게 키를 안전하게 전달하는 것 자체가 문제(→ 비대칭키가 이걸 보완).
한 줄: "빠르지만 키를 나눠 갖는 게 골칫거리."
2) 비대칭키 (Asymmetric Key) — RSA 등
한 쌍의 키(공개키 + 개인키) 를 사용. 한쪽으로 잠그면 반드시 다른 쪽으로만 풀림.
공개키(Public) : 누구에게나 공개해도 됨
개인키(Private) : 절대 노출 X, 소유자만 보관두 가지 대표 용도:
1. 암호화 용도: 공개키로 암호화 → 개인키로만 복호화. (상대에게 키를 미리 안 나눠줘도 됨 → 대칭키의 전달 문제 해결)
2. 서명/검증 용도 (SKM에서 쓰는 방식):
- 개인키로 데이터에 서명 → 공개키로 검증.
- "이 데이터가 정말 그 사람이 보냈고, 중간에 위·변조되지 않았다"를 증명.
특징:
- 느리다. 연산이 무거워서 대용량 데이터 자체를 암호화하는 데는 부적합.
- 그래서 실무에선 작은 데이터의 서명/검증이나, 대칭키를 안전하게 주고받는 용도로 씀.
한 줄: "느리지만 키를 미리 안 나눠도 되고, '누가 보냈는지'를 증명할 수 있다."
3) 그래서 실무는 둘을 섞어 쓴다 (하이브리드)
- 데이터 암호화 = 대칭키 (빠름)
- 그 대칭키를 보호/전달 = 비대칭키 or 상위 대칭키
이 조합의 정점이 다음 장의 봉투 암호화입니다. 여기까지 오면 4번이 자연스럽게 연결됩니다.
4) SKM은 데이터를 왜 3종류로 나눴나 — 용도별 분리
NHN Cloud SKM은 보관하는 데이터를 기밀 데이터 / 대칭 키 / 비대칭 키 세 가지로 구분합니다. 각각 "무엇을 하고 싶은가"에 대응합니다.
| SKM 데이터 유형 | 무엇인가 | 대표 용도 | 제공 API |
|---|---|---|---|
| 기밀 데이터 (Confidential Data) | 임의의 민감 텍스트 (32KB 이하) | DB 접속정보, API 앱키 등 "그냥 안전하게 보관하고 꺼내 쓰고 싶은 값" | 조회 |
| 대칭 키 (Symmetric Key) | AES-256(공공기관용은 ARIA-256) 키 | 데이터 암호화 / 복호화 | 암호화 / 복호화 / (봉투용) 로컬키 생성 / 조회 |
| 비대칭 키 (Asymmetric Key) | RSA 계열 키 쌍 | 데이터 서명 / 검증 (위·변조 확인) | 서명 / 검증 |
이렇게 나눈 이유를 발표에서 이렇게 설명하면 깔끔합니다:
"사용자가 원하는 건 결국 세 가지입니다.
① 값을 그냥 안전하게 보관하고 싶다 → 기밀 데이터.
② 데이터를 암·복호화하고 싶다 → 대칭 키.
③ 데이터가 위·변조 안 됐는지 검증하고 싶다 → 비대칭 키.
SKM은 이 세 가지 니즈에 맞춰 데이터 타입과 API를 분리해 둔 겁니다."
중요 포인트 (5번의 복선):
- 대칭 키·비대칭 키는 키 값 자체가 클라이언트로 직접 노출되지 않고, 오직 API를 통해서만 사용됩니다.
즉 "키를 받아와서 내가 쓴다"가 아니라 "SKM에게 암호화/복호화/서명을 시킨다"에 가까움. - 덕분에 키가 외부로 새지 않고, 키 순환도 클라이언트 코드 변경 없이 가능. (2번에서 말한 딜레마의 해법!)
요약 체크
- 대칭 vs 비대칭을 "속도"와 "용도" 두 축으로 설명할 수 있다.
- 비대칭키의 서명/검증이 "위·변조 확인"임을 안다.
- SKM의 3종 데이터가 각각 어떤 사용자 니즈에 대응하는지 매핑할 수 있다.
04. 봉투 암호화 (Envelope Encryption)
발표의 하이라이트. 다이어그램 한 장으로 승부하세요. 이 개념만 청중이 이해하면 5·6번은 술술 풀립니다.
1) 왜 필요한가 — "매번 KMS로 보내면 느리다"
가장 순진한 발상: "데이터를 통째로 KMS에 보내서 암호화해 달라고 하자."
문제:
- KMS/HSM 같은 키 관리 시스템은 보통 작은 데이터만 직접 암호화하도록 설계됨 (예: AWS KMS는 직접 암호화가 4KB까지).
- 수백 MB 파일이나 대용량 컬럼을 매번 네트워크로 KMS에 왕복시키면 → 느리고, 대역폭 낭비, 지연 폭증.
- 게다가 KMS가 단일 병목이 됨.
봉투 암호화는 이걸 이렇게 뒤집습니다:
"데이터는 내 서버에서 (빠른) 로컬 키(DEK) 로 직접 암호화하자.
그리고 그 DEK만 KMS의 상위 키(KEK)로 암호화해서 같이 보관하자."
→ 네트워크로는 작은 키만 오가고, 무거운 데이터 암호화는 로컬에서 처리.
2) 핵심 두 키: DEK와 KEK
| 약어 | 이름 | 역할 | 어디에 있나 |
|---|---|---|---|
| DEK | Data Encryption Key | 실제 데이터를 암호화하는 키 | 애플리케이션(로컬)에서 잠깐 사용 후 메모리에서 폐기 |
| KEK | Key Encryption Key | DEK를 암호화(보호)하는 키 | KMS/SKM 안에서만 존재, 절대 밖으로 안 나옴 |
한 문장 정리:
"DEK로 데이터를 잠그고, 그 DEK를 다시 KEK로 잠근다." — 봉투(편지)를 봉투(더 큰 봉투)에 넣는 느낌이라 '봉투' 암호화.
핵심 규칙:
- 평문 DEK는 저장하지 않는다. 쓰고 나면 메모리에서 즉시 폐기.
- 저장하는 건 암호화된 DEK(encrypted DEK) 뿐. 이건 데이터 옆에 같이 저장해도 안전(KEK 없이는 못 품).
- KEK는 KMS 밖으로 절대 안 나온다. DEK 복호화는 항상 KMS에게 시킨다.
3) 암호화 플로우
flowchart TD
A["애플리케이션: 데이터 D 를 저장하려 함"] --> B["KMS/SKM에 'DEK 하나 만들어줘' 요청"]
B --> C["KMS: DEK 생성 후 두 형태로 반환<br/>① 평문 DEK ② KEK로 암호화된 DEK"]
C --> D["① 평문 DEK로 데이터 D를 로컬에서 암호화 → 암호문 C"]
D --> E["평문 DEK는 메모리에서 즉시 폐기 🔥"]
E --> F["저장소에 함께 저장:<br/>암호문 C + 암호화된 DEK"]말로 풀면:
1. 데이터를 저장할 일이 생김.
2. KMS/SKM에 "데이터 키(DEK) 하나 발급해줘" 요청.
3. KMS는 평문 DEK(지금 쓸 것)와 암호화된 DEK(저장할 것)를 함께 돌려줌.
4. 평문 DEK로 로컬에서 데이터를 빠르게 암호화.
5. 평문 DEK는 즉시 폐기. (메모리에만 잠깐 있었음)
6. 저장소에는 암호문 + 암호화된 DEK를 나란히 저장.
4) 복호화 플로우
flowchart TD
A["저장소에서 읽기:<br/>암호문 C + 암호화된 DEK"] --> B["KMS/SKM에 '이 암호화된 DEK 풀어줘' 요청"]
B --> C["KMS: KEK로 DEK 복호화 → 평문 DEK 반환"]
C --> D["평문 DEK로 암호문 C를 로컬에서 복호화 → 데이터 D"]
D --> E["평문 DEK는 다시 즉시 폐기 🔥"]말로 풀면:
1. 저장소에서 암호문 + 암호화된 DEK를 함께 읽음.
2. KMS/SKM에 "이 암호화된 DEK 좀 풀어줘" 요청 (여기만 네트워크 왕복, 작은 데이터).
3. KMS가 내부 KEK로 DEK를 복호화해서 평문 DEK를 돌려줌.
4. 그 평문 DEK로 로컬에서 암호문을 복호화.
5. 평문 DEK 즉시 폐기.
발표 포인트: 네트워크를 타는 건 항상 "작은 DEK"뿐, 무거운 데이터는 로컬에서 처리. 이 한 문장이 봉투 암호화의 전부입니다.
5) 이 구조의 이점 (발표 핵심 3가지)
① 성능
- 대용량 데이터는 빠른 로컬 대칭키(DEK)로 처리.
- KMS에는 작은 키만 오감 → 네트워크 부하·지연 최소화, KMS 병목 해소.
② 키 순환 용이성 (2번에서 말한 딜레마의 진짜 해법)
- 키를 바꾼다 = KEK만 새 걸로 바꾸면 됨.
- 그럼 저장돼 있는 "암호화된 DEK"들만 새 KEK로 다시 암호화하면 끝.
- 거대한 실제 데이터는 하나도 안 건드려도 됨!
(수억 건 데이터 재암호화 → 작은 DEK 몇 개만 재암호화로 축소)
[순진한 재암호화] 전체 데이터 복호화 → 재암호화 (수 시간~며칠)
[봉투 암호화 순환] 암호화된 DEK 들만 KEK로 재암호화 (거의 즉시)- DEK는 키 순환을 하지 않는 것인가?
정리하면 "DEK도 순환할 수 있지만, KEK 순환과는 별개의 문제이고 목적도 다르다" 입니다. 이 둘을 구분 못 하면 헷갈리기 딱 좋은 지점이에요.
두 가지 순환은 서로 다른 질문에 답합니다
즉 제가 전에 "봉투 암호화 순환은 거의 즉시"라고 한 건 KEK 순환의 얘기였고, DEK 자체를 바꾸는 건 결국 다시 "실제 데이터 재암호화" 문제로 돌아갑니다. DEK가 이 딜레마를 완전히 없앤 게 아니라, "어느 계층에서 순환이 발생하느냐"를 옮겨놓은 것이에요.
③ 노출 범위 최소화 (blast radius 축소)
- 평문 DEK는 메모리에 잠깐만 존재 → 훔칠 틈이 좁음.
- 저장소가 통째로 유출돼도 거기엔 암호문 + 암호화된 DEK뿐 → KEK 없이는 무의미.
- KEK는 KMS 밖으로 안 나오므로 가장 중요한 키 하나만 집중 보호하면 됨.
6) 이게 업계 표준 패턴임을 보여주기 (사례)
"우리만의 특이한 방식이 아니라, 주요 클라우드가 다 쓰는 정석"이라고 말할 수 있는 근거들:
- AWS KMS:
GenerateDataKeyAPI가 정확히 이 패턴 — 평문 DEK와 암호화된 DEK를 함께 돌려주고, 개발자는 평문 DEK로 로컬 암호화 후 폐기, 암호화된 DEK만 저장. KMS 직접 암호화는 4KB 한계라 대용량은 봉투 방식 권장. - AWS EKS: 쿠버네티스 시크릿(etcd)을 기본적으로 봉투 암호화로 보호 — DEK로 리소스 암호화, KEK(KMS)로 DEK 보호하는 다중 방어(defense-in-depth) 로 설명됨.
- Google Cloud KMS: 저장 데이터 암호화에 KEK/DEK 계층과 "논리적 데이터 분리"를 동일하게 사용.
- NHN Cloud SKM: 대칭 키 API에 로컬 키 생성(create-local-key) 기능을 제공 — 평문 로컬키(바로 사용)와 SKM 대칭키로 암호화된 로컬키(저장용)를 함께 반환. 이름만 다를 뿐 정확히 DEK/KEK 봉투 패턴. (자세한 건 05번)
발표 멘트:
"AWS, GCP, 그리고 우리가 쓰는 NHN Cloud까지 — 이름(Data Key, 로컬 키)만 다를 뿐 똑같은 봉투 암호화 패턴을 씁니다. 즉 이건 특정 벤더 기술이 아니라 업계 표준 설계입니다."
요약 체크
- DEK와 KEK의 역할을 한 문장씩 구분해서 말할 수 있다.
- 암호화·복호화 플로우를 화이트보드에 그릴 수 있다.
- "성능 / 키 순환 / 노출 최소화" 3대 이점을 각각 근거와 함께 설명할 수 있다.
- 봉투 암호화가 업계 표준임을 사례 2개 이상으로 말할 수 있다.
