AX개발팀 인턴 정세현 · 리서치 본문
발표일: 2025-08-04
1. 인트로 — 왜 키 관리인가
문제 제기: 데이터베이스는 언젠가 뚫린다
방화벽, WAF, 접근제어를 아무리 촘촘히 해도 데이터 유출 사고는 계속 발생한다. SQL Injection, 내부자, 방치된 백업 파일, 클라우드 스토리지 오설정, 탈취된 관리자 계정 등 경로도 다양하다. 그래서 오늘날 보안 설계의 전제는 "완벽히 막는다"가 아니라 "침해는 불가피하다(assume breach)" 로 이동했다. 핵심 질문도 "어떻게 안 뚫리게 하지?" 에서 "뚫려도 데이터가 새지 않게 하려면?" 으로 바뀐다.
법적으로도 암호화는 선택이 아니다. 국내 개인정보보호법은 비밀번호·고유식별정보 등 민감 항목의 암호화 저장을 의무화하고 있다.
암호화가 없으면 = 평문 그대로 노출
[암호화 X] DB 유출 → 홍길동 / 900101-1****** / password123 → 그대로 읽힘. 끝.
[암호화 O] DB 유출 → 8f3a9c… / b21e77… / 5d41402a… → 키가 없으면 무의미한 바이트.암호화의 목적은 "유출을 막는 것"이 아니라 "유출됐을 때 무의미하게 만드는 것", 즉 최후의 방어선(last line of defense)이다.
그러면 암호화 키는 어디에 두는가 — 이 문서의 주제
암호화는 문제를 푸는 동시에 새 문제를 낳는다. 데이터를 잠갔어도 그것을 풀 키가 있어야 서비스가 돌아가는데, 그 키가 데이터 바로 옆(코드·DB·서버)에 있으면 유출 시 함께 털린다. 자물쇠를 채워도 열쇠를 문 옆 화분 밑에 두면 소용없다. 따라서 진짜 주제는 암호화 자체가 아니라 "키를 어떻게, 어디에 둘 것인가" 이다.
2. 왜 키 관리가 어려운가
순진한 저장 방법과 한계
하드코딩 — 소스코드에 키를 박아두면 Git 저장소에 그대로 커밋되고, Git은 히스토리가 영구 보존되어 나중에 지워도 과거 커밋에 남는다. 배포된 바이너리를 디컴파일하면 문자열이 드러나며, 키를 바꾸려면 코드 수정→재빌드→재배포가 필요해 사실상 교체가 어렵다.
설정 파일(application.yml 등) — 하드코딩보다 낫지만 파일은 여전히 평문이라 서버 침투 시 그대로 읽힌다. 설정 파일이 실수로 Git에 올라가는 사고도 흔하며, 파일에 접근 가능한 사람이 곧 키에 접근 가능한 사람이 되어 권한 분리가 안 된다.
환경변수 — 커밋 사고는 줄지만 /proc/<pid>/environ으로 같은 서버의 다른 프로세스가 조회할 수 있고, 에러 로그·크래시 덤프·APM 툴이 환경변수를 통째로 기록하는 경우가 있으며, 하위 프로세스로 자동 상속되어 의도치 않게 전파된다.
세 방법의 공통 문제는 키가 애플리케이션과 같은 신뢰 경계 안에 평문으로 존재한다는 점이다. 앱이 뚫리면 키도 함께 뚫린다.
저장 안전성 ≠ 접근 통제
키를 안전한 금고에 넣어도, 그 금고 문을 아무나 열 수 있으면 금고가 아니다. 저장의 안전성과는 별개로 "이 요청이 정말 우리 서버가 보낸 것인가" 를 검증하는 접근 통제(인증/인가)가 필요하다.
키 교체(순환)와 기존 데이터 문제
키는 유출·유출 의심, 컴플라이언스 요구, 인적 리스크 등으로 언젠가 반드시 교체해야 한다. 그런데 키를 바꾸면 딜레마가 생긴다.
기존 데이터는 "옛 키"로 암호화돼 있음.
새 데이터는 "새 키"로 암호화하고 싶음.
→ 옛 데이터는 새 키로 못 푸는데?전체 데이터를 복호화 후 재암호화하면 수억 건 규모에서 수 시간~며칠이 걸리고, 모든 서버 설정을 동시에 교체해야 해 배포 부담도 크다. 결국 하드코딩·설정파일·환경변수는 (1) 저장 안전성, (2) 접근 통제, (3) 키 교체 세 가지를 동시에 만족시키지 못한다. 이 세 가지를 전담하는 시스템이 바로 KMS(Key Management Service) 이고, 그 구현체 중 하나가 NHN Cloud의 Secure Key Manager(SKM) 이다.
3. 암호화 기초
대칭키 vs 비대칭키
대칭키(AES, ARIA 등)는 하나의 같은 키로 암호화와 복호화를 모두 수행한다. 연산이 가벼워 빠르므로 대용량 데이터 암·복호화에 적합하다. 약점은 상대에게 키를 안전하게 전달하는 것 자체가 어렵다는 점이다.
비대칭키(RSA 등)는 공개키·개인키 한 쌍을 사용한다. 한쪽으로 잠그면 다른 쪽으로만 풀린다. 연산이 무거워 대용량에는 부적합하지만, 키를 미리 나누지 않아도 되고 무엇보다 서명/검증(개인키로 서명 → 공개키로 검증)으로 "이 데이터가 위·변조되지 않았음"을 증명할 수 있다.
정리하면 대칭키는 "빠르지만 키 전달이 골칫거리", 비대칭키는 "느리지만 키를 안 나눠도 되고 위·변조를 증명한다". 실무는 데이터 암호화에는 대칭키, 그 대칭키의 보호·전달에는 상위 키를 쓰는 하이브리드 방식을 취하며, 그 정점이 4장의 봉투 암호화다.
SKM이 데이터를 3종으로 나눈 이유
NHN Cloud SKM은 보관 데이터를 기밀 데이터 / 대칭 키 / 비대칭 키 세 가지로 구분한다. 사용자의 니즈가 세 가지이기 때문이다.
| 데이터 유형 | 무엇인가 | 대표 용도 | API |
|---|---|---|---|
| 기밀 데이터 | 임의 민감 텍스트(32KB 이하) | DB 접속정보, 앱키 등 값 보관 | 조회 |
| 대칭 키 | AES-256(공공기관용 ARIA-256) | 데이터 암호화/복호화 | 암호화·복호화·로컬키 생성·조회 |
| 비대칭 키 | RSA 계열 키 쌍 | 데이터 서명/검증 | 서명·검증 |
① 값을 그냥 안전하게 보관하고 싶다 → 기밀 데이터, ② 암·복호화하고 싶다 → 대칭 키, ③ 위·변조를 검증하고 싶다 → 비대칭 키. 중요한 점은 대칭 키·비대칭 키의 키 값 자체가 클라이언트로 직접 노출되지 않고 오직 API를 통해서만 사용된다는 것이다. "키를 받아와 내가 쓴다"가 아니라 "SKM에게 작업을 시킨다"에 가깝고, 덕분에 키가 외부로 새지 않으며 키 순환도 클라이언트 코드 변경 없이 가능하다.
4. 봉투 암호화(Envelope Encryption)
왜 필요한가
가장 순진한 발상은 "데이터를 통째로 KMS에 보내 암호화해 달라"는 것이다. 그러나 KMS/HSM은 보통 작은 데이터만 직접 암호화하도록 설계돼 있고(예: AWS KMS는 직접 암호화 4KB 한계), 대용량을 매번 네트워크로 왕복시키면 느리고 KMS가 병목이 된다. 봉투 암호화는 이를 뒤집는다. 데이터는 내 서버에서 빠른 로컬 키(DEK)로 직접 암호화하고, 그 DEK만 KMS의 상위 키(KEK)로 암호화해 보관한다. 네트워크에는 작은 키만 오가고, 무거운 데이터 암호화는 로컬에서 처리된다.
두 개의 키: DEK와 KEK
| 약어 | 이름 | 역할 | 위치 |
|---|---|---|---|
| DEK | Data Encryption Key | 실제 데이터를 암호화 | 애플리케이션에서 잠깐 사용 후 폐기 |
| KEK | Key Encryption Key | DEK를 암호화(보호) | KMS/SKM 내부에만 존재, 밖으로 안 나감 |
핵심 규칙은 세 가지다. 평문 DEK는 저장하지 않고 사용 즉시 메모리에서 폐기한다. 저장하는 것은 암호화된 DEK뿐이며 이는 데이터 옆에 두어도 KEK 없이는 풀 수 없다. KEK는 KMS 밖으로 절대 나오지 않으며, DEK 복호화는 항상 KMS에게 요청한다.
- 클라이언트가 KMS에 "DEK 하나 만들어줘"라고 요청한다 (아직 DEK가 없는 상태).
- KMS가 내부적으로 평문 DEK를 생성하고, 그 자리에서 KEK로 암호화한 버전도 함께 만든다.
- KMS는 두 가지를 클라이언트에게 반환한다: 평문 DEK, 암호화된 DEK.
- 클라이언트는 평문 DEK로 데이터를 암호화한 뒤 즉시 메모리에서 폐기하고, 암호화된 DEK만 데이터 옆에 저장한다.
- 암호화된 DEK를 저장소에서 꺼낸다 → KMS에 "이 암호화된 DEK를 복호화해줘"라고 요청 → KMS가 내부의 KEK로 풀어서 평문 DEK를 반환 → 그 평문 DEK로 데이터를 복호화 → 다 쓰고 나면 메모리에서 즉시 폐기.
암호화 · 복호화 플로우
네트워크를 타는 것은 항상 작은 DEK뿐이고, 무거운 데이터는 로컬에서 처리된다는 것이 봉투 암호화의 핵심이다.
구조의 이점
성능 — 대용량 데이터는 빠른 로컬 대칭키로 처리하고 KMS에는 작은 키만 오가므로 네트워크 부하·지연과 KMS 병목이 최소화된다.
키 순환 용이성 — 여기서 순환에는 두 계층이 있고, 둘을 구분하는 것이 중요하다.
- KEK 순환: KEK만 새 것으로 바꾸고 저장된 "암호화된 DEK"들만 새 KEK로 재암호화하면 된다. 거대한 실제 데이터는 건드리지 않으므로 거의 즉시 끝난다.
- DEK 순환: DEK를 바꾸는 것은 결국 그 DEK가 암호화한 실제 데이터를 다시 암호화하는 일이므로 여전히 비싸다. 봉투 암호화가 이 비용을 없앤 것이 아니라, 재암호화가 어느 계층에서 일어나는지를 분리한 것이다.
[KEK 순환] 암호화된 DEK만 재암호화 → 작고 빠름 (자주 있을 대응 시나리오)
[DEK 순환] DEK가 감싼 실제 데이터 재암호화 → 크고 느림 (드물게 발생)실무에서는 아예 데이터 1건(또는 1레코드/1파일)마다 새 DEK를 발급해 쓰고 버리는 식으로 DEK를 잘게 쪼개 재사용하지 않음으로써 "DEK 순환"이라는 개념 자체를 최소화하는 전략을 흔히 쓴다. 결국 봉투 암호화는 자주 대응해야 할 사고(KEK 의심)를 값싸게 만들고, 드문 사고(DEK 유출)는 발생 확률 자체를 낮추는 설계다.
노출 범위 최소화(blast radius) — 평문 DEK는 메모리에 잠깐만 존재하므로 훔칠 틈이 좁다. 저장소가 통째로 유출돼도 거기엔 암호문과 암호화된 DEK뿐이라 KEK 없이는 무의미하다. 가장 중요한 KEK 하나에 보호를 집중하면 된다.
평문 DEK가 오가는 것은 위험하지 않은가
봉투 암호화에서 KMS가 평문 DEK를 애플리케이션에 내려주는 순간이 존재하는 것은 사실이다. 다만 이는 "위험 0"이 아니라 관리 가능한 수준으로 축소된 위험이다. ① KMS 호출은 TLS 위에서 이뤄져 전송 중 도청으로는 평문 DEK가 드러나지 않는다. ② 설령 그 순간 평문 DEK를 탈취당해도 그 DEK가 암호화한 데이터 일부만 풀릴 뿐, KEK와 다른 DEK는 안전하다(피해가 전체로 번지지 않는다). ③ 평문 DEK는 메모리에만 잠깐 존재하고 즉시 폐기되어 노출 시간이 극히 짧다. ④ DEK 요청 자체가 인증된 클라이언트에게만 허용된다. 평문이 필요 없다면 AWS KMS의 GenerateDataKeyWithoutPlaintext처럼 암호화된 DEK만 받는 방법도 있다. 요컨대 위험을 0으로 만드는 것이 아니라 감당 가능한 크기로 쪼개는 보안 설계다.
업계 표준 패턴
봉투 암호화는 특정 벤더 기술이 아니라 주요 클라우드의 공통 설계다. AWS KMS의 GenerateDataKey가 정확히 이 패턴이며(평문 DEK와 암호화된 DEK를 함께 반환), AWS EKS는 쿠버네티스 시크릿을 기본적으로 봉투 암호화로 보호한다. Google Cloud KMS도 KEK/DEK 계층과 논리적 데이터 분리를 동일하게 사용한다. NHN Cloud SKM 역시 대칭 키의 로컬 키 생성 기능으로 같은 패턴을 제공한다.
5. NHN Cloud SKM은 어떻게 구현했나
아래 내용은 NHN Cloud 공식 문서(SKM 개요·콘솔·API 가이드) 기준이다. 제품 스펙은 갱신될 수 있으므로 발표 직전 최신 문서로 대조한다.
3단 키 계층
SKM은 키를 3단으로 겹쳐 보호한다. 상위 키가 하위 것을 암호화하는 구조다.
루트 키는 시스템 키를, 시스템 키는 사용자 데이터를 보호한다. 시스템 키는 루트 키로 암호화된 상태로 별도의 시스템 키 관리 서버에 저장되며, SKM 서버는 서비스 시작 시 인증을 거쳐 암호화된 시스템 키를 받아와 루트 키로 복호화해야 비로소 사용할 수 있다. SKM에서 생성된 모든 사용자 데이터는 시스템 키로 암호화되어 저장된다. 4장의 봉투 암호화를 제품 전체 구조로 확장한 형태다.
KEK는 결국 어디에 저장되는가 — HSM
"KEK를 어디 두는가"라는 질문은 재귀적이다. 시스템 키(KEK 역할)도 루트 키로 암호화되어 저장되고, 루트 키를 지키는 상위 키를 계속 따라가면 소프트웨어로는 무한 반복된다. 이 사슬은 HSM(Hardware Security Module) 이라는 전용 물리 장비에서 끊긴다. HSM은 키를 하드웨어 칩 내부에서만 생성·보관·연산하며 키가 평문으로 밖으로 나오지 않는다(암호화 연산만 요청하고 결과만 받는다). 물리적 변조를 감지하면 키를 자동 파기하기도 한다. SKM의 "물리적으로 분리된 시스템"도 이러한 하드웨어/전용 인프라를 기반으로 한다.
물리적 분리
SKM에 저장한 사용자 데이터를 비정상적으로 얻으려면 물리적으로 분리된 세 개의 시스템에서 루트 키·시스템 키·사용자 데이터를 모두 획득해야 한다.
하나만 뚫려서는 아무것도 얻지 못하므로 공격 난이도가 곱셈으로 증가한다. 4장의 노출 범위 최소화를 인프라 레벨로 구현한 것이다.
클라이언트 인증
SKM은 저장 안전성과 별개로 접근 통제를 위해 세 가지 인증을 제공한다.
| 인증 방법 | 확인 대상 |
|---|---|
| IPv4 주소 인증 | 클라이언트의 IPv4 주소 |
| MAC 주소 인증 | 클라이언트의 MAC 주소(헤더 X-TOAST-CLIENT-MAC-ADDR) |
| 클라이언트 인증서 인증 | 통신에 사용하는 클라이언트 인증서 |
최소 한 개 이상을 선택해야 하며, 두 개 이상 선택하면 모두 통과(AND 조건) 해야 한다. IP 스푸핑이 우려되면 인증서 인증을 조합해 하나의 위조만으로는 통과할 수 없게 만든다. 즉 DB 접속정보 같은 값을 SKM에 넣어두면 정해진 우리 서버에서만 꺼낼 수 있다.
키 3종류와 API
기밀 데이터는 32KB 이하 텍스트를 안전 보관하며(대표 용도 DB 접속정보·앱키) 조회 API를 제공한다. 대칭 키(AES-256, 공공기관용 ARIA-256)는 암호화·복호화 API와 조회 API, 그리고 봉투 암호화용 로컬 키 생성(create-local-key) API를 제공한다. 비대칭 키는 서명·검증 API를 제공한다(서명 대상 245Byte 이하). 이 밖에 호출 클라이언트가 어떻게 인식되는지 확인하는 클라이언트 정보 조회 API가 있어 인증 디버깅에 유용하다.
create-local-key가 곧 SKM식 봉투 암호화다. 응답의 localKeyPlaintext는 Base64 디코딩 후 바로 데이터 암호화에 쓰는 평문 DEK이고, localKeyCiphertext는 그 로컬키를 SKM 대칭키(KEK 역할)로 암호화한 값으로 스토리지에 저장할 암호화된 DEK다. 복호화가 필요하면 저장한 localKeyCiphertext를 복호화 API로 풀어 다시 로컬키를 얻는다.
| 봉투 암호화 용어 | SKM 대응 |
|---|---|
| DEK(평문) | localKeyPlaintext |
| 암호화된 DEK(저장용) | localKeyCiphertext |
| KEK | SKM에 저장된 사용자 대칭 키 |
추가로 알아둘 점: 상용 엔드포인트는 api-keymanager.cloud.toast.com, 공공기관용은 api-keymanager.gov-nhncloudservice.com이며 앱키(appkey) 기반 경로를 쓴다. 공공기관용은 국정원 검증 알고리즘(ARIA, SEED, RSA-PSS)을 탑재한다. 키 순환(회전)을 제공하지만 "키 가져오기(import)"로 넣은 키는 회전되지 않는다. 또한 승인 기능(approval)으로 승인자·요청자 역할을 분리해 ISMS-P·ISO 등 인증 심사의 키 관리 요구사항과 직무 분리를 충족한다.
6. 실무 적용 관점
키 순환 시나리오 — KEK 유출 의심 시
봉투 암호화와 SKM 구조 덕분에 대응이 "전체 데이터 재암호화"가 아니라 "키 계층만 손보기"로 축소된다.
핵심은 네 가지다. 버전을 올려 회전하고(SKM은 키에 버전을 매긴다), 봉투 구조라 재암호화 대상은 작은 "암호화된 DEK"뿐이며 실제 데이터 본문은 건드리지 않는다. 구 버전 키를 성급히 삭제하지 않는다 — 예컨대 로그 암호화에 쓰던 대칭키를 회전한 뒤 이전 버전을 바로 삭제하면 그 키로 암호화된 로그를 영영 복호화할 수 없으므로, 구 데이터가 모두 새 키로 이전됐는지 확인 후 폐기한다. 마지막으로 SKM이 키 값을 감추고 API로만 다루므로 애플리케이션은 재배포 없이 키가 교체된다.
7. 정리
핵심 3줄 요약
- 데이터는 언젠가 유출된다. 그래서 암호화로 "유출돼도 무의미하게" 만들되, "키를 어디 두나"라는 새 문제가 생긴다.
- 이 문제는 봉투 암호화(DEK로 데이터, KEK로 DEK)와 전용 키 관리 시스템으로 푼다 — 성능·키순환·노출최소화를 동시에 잡는 업계 표준이다.
- NHN Cloud SKM은 이를 3단 키 계층 + 물리적 분리 + 클라이언트 인증(IP/MAC/인증서)으로 구현했고, 실무 가치는 "키를 코드에서 분리하고 재배포 없이 순환"하는 데 있다.
한 문장으로: 키를 코드에서 떼어내고, 접근을 통제하고, 언제든 갈아끼울 수 있게 만드는 것.
AX 팀 관점 적용
AI/데이터 파이프라인에서 모델 API 키, 외부 LLM·벤더 토큰, 데이터소스 접속정보가 코드·노트북·환경변수에 흩어져 있지 않은지 점검하고 기밀 데이터로 통합 관리할 수 있다. 개인정보가 포함된 데이터셋의 민감 필드는 봉투 암호화로 저장해 유출 시 원본 노출을 막는다. 데이터·모델을 다루는 사람과 키를 관리·승인하는 사람을 분리(승인 기능)해 컴플라이언스에 대응하고, 실험 재현을 위해 비밀을 평문 공유하려는 유혹을 SKM 조회로 대체해 재현성과 보안을 함께 챙긴다. 다만 부팅 시 SKM 의존이 서비스 장애로 전이될 수 있으므로 캐싱·재시도 전략을 팀 표준으로 둔다.
본 문서의 제품 스펙(엔드포인트·알고리즘·API명)은 발표 직전 NHN Cloud 공식 문서로 재확인할 것.
