AX개발팀 인턴 정세현 — 민감 데이터 관리 리서치
"먼저 내가 이해하기 위한" 공부용 노트입니다. 발표 대본이 아니라, 각 개념을 스스로 설명할 수 있게 되는 걸 목표로 씀.
파일 구성 (발표 목차와 1:1 매핑)
| 파일 | 발표 섹션 | 한 줄 목표 |
|---|---|---|
인트로 | 1. 인트로 | "왜 이 얘기를 하는지" 청중을 설득 |
키관리_난제 | 2. 왜 키 관리가 어려운가 | 순진한 방법들이 왜 다 깨지는지 |
암호화_기초 | 3. 암호화 기초 | 대칭/비대칭, SKM 데이터 3종 |
봉투암호화 | 4. 봉투 암호화 | DEK/KEK 구조와 그 이점 |
NHN_SKM | 5. NHN Cloud SKM 구현 | 3단 키 계층·인증·API |
실무적용 | 6. 실무 적용 관점 | 키 순환 + Spring 연동 |
정리_QnA | 7. 정리 & Q&A | 3줄 요약 + 예상 질문 방어 |
이 발표의 큰 스토리라인 (한 문장씩)
- 데이터를 평문으로 두면 DB 한 번 뚫리면 끝이다 → 암호화하자.
- 암호화하면 이제 "키를 어디 두지?" 라는 새 문제가 생긴다.
- 키를 그냥 코드/파일/환경변수에 두는 건 다 한계가 있다 → 전용 키 관리 시스템(KMS) 이 필요.
- 대량 데이터를 매번 KMS로 보내 암호화하면 느리다 → 봉투 암호화(DEK/KEK) 로 푼다.
- NHN Cloud SKM은 이걸 3단 키 계층 + 물리적 분리 + 클라이언트 인증으로 구현했다.
- 실무에선 키 순환과 Spring 연동이 핵심 접점이다.
- 결국 "키를 코드에서 분리하고, 접근을 통제하고, 갈아끼울 수 있게" 만드는 게 핵심.
핵심 용어집 (발표 전 이 정도는 입에 붙이기)
| 용어 | 풀이 | 한 줄 설명 |
|---|---|---|
| 평문 (Plaintext) | - | 암호화 안 된 원본 데이터 |
| 암호문 (Ciphertext) | - | 암호화된 데이터 |
| 대칭키 | Symmetric Key | 암호화·복호화에 같은 키 사용 (AES, ARIA) |
| 비대칭키 | Asymmetric Key | 공개키/개인키 쌍 사용 (RSA) |
| KMS | Key Management Service | 키 생성·보관·접근제어를 전담하는 시스템 |
| DEK | Data Encryption Key | 실제 데이터를 암호화하는 키 |
| KEK | Key Encryption Key | DEK를 암호화(보호)하는 키 |
| 봉투 암호화 | Envelope Encryption | DEK로 데이터 암호화 → KEK로 DEK 암호화 |
| 키 순환 | Key Rotation | 키를 주기적으로 새 버전으로 교체 |
| HSM | Hardware Security Module | 키를 하드웨어 안에서만 다루는 전용 장비 |
| 기밀 데이터 | Confidential Data | SKM이 보관하는 임의의 민감 텍스트(예: DB 접속정보) |
발표 시 밸런스
- 이론(3·4번)에서 너무 오래 끌면 지루해집니다. 봉투 암호화 다이어그램 1장으로 승부.
- 진짜 청중이 궁금해하는 건 5·6번 ("우리 것은 어떻게 돌아가냐"). 여기 시간 배분을 넉넉히.
- 인턴 발표의 장점: "제가 초기 프로젝트에서 실제로 SKM을 붙여봤다"는 경험담이 슬라이드 10장보다 강함.
01. 인트로 — 왜 키 관리 이야기를 하는가
1) 문제 제기: 데이터베이스는 언젠가 뚫린다
발표의 출발점은 겁을 주는 게 아니라 "어차피 뚫린다고 가정하면 그 다음이 갈린다" 는 관점입니다.
- 방화벽, WAF, 접근제어 다 해도 유출 사고는 계속 일어납니다. (SQL Injection, 내부자, 백업 파일 방치, 클라우드 버킷 오설정, 탈취된 관리자 계정 등)
- 그래서 보안 업계의 전제는 "침해는 불가피하다(assume breach)" 로 이동했습니다.
- 핵심 질문이 바뀝니다: "어떻게 안 뚫리게 하지?" → "뚫려도 데이터가 안 새게 하려면?"
발표 멘트 예시:
"완벽하게 막는 건 불가능합니다. 그래서 질문을 바꿔야 합니다. DB가 통째로 유출돼도, 그 안의 데이터가 쓸모없는 상태로 있게 하려면? 그 답이 암호화이고, 오늘 이야기의 시작점입니다."
사례를 언급할 때 주의 (발표자 노트)
구체적인 사고명·피해 규모 숫자는 틀리면 신뢰가 깨지므로, 확실한 것만 말하세요.
안전하게 쓸 수 있는 사실 두 가지:
- 과거 대형 유출 사고들에서 비밀번호가 평문 또는 약한 방식으로 저장돼 있어 피해가 커진 경우가 많았다. (일반적으로 알려진 사실)
- 국내 개인정보보호법은 비밀번호·고유식별정보(주민번호 등) 같은 민감 항목의 암호화 저장을 의무화한다. → "법적으로도 암호화는 선택이 아니라 필수"라는 근거로 활용.
숫자·회사명을 꼭 넣고 싶으면 발표 전에 1차 출처(뉴스·보안기관 보고서)로 재확인하고 넣으세요.
2) 암호화가 안 되어 있으면 = 평문 그대로 노출
간단하지만 강력한 대비 그림입니다.
[암호화 X] DB 유출 → 이름: 홍길동 / 주민번호: 900101-1... / 비밀번호: password123
→ 그대로 읽힘. 끝.
[암호화 O] DB 유출 → 이름: 8f3a9c... / 주민번호: b21e77... / 비밀번호: 5d41402a...
→ 키가 없으면 의미 없는 바이트 덩어리.포인트: 암호화의 목적은 "유출을 막는 것"이 아니라 "유출됐을 때 무의미하게 만드는 것".
즉 최후의 방어선(last line of defense)입니다.
3) 그러면 암호화 키는 어디에 두지? — 오늘의 진짜 주제
여기서 자연스럽게 역설이 등장합니다.
- 데이터를 암호화하면 안전해진다.
- 그런데 그 암호화를 풀 수 있는 키가 있어야 정상적으로 서비스가 돌아간다.
- 키가 데이터 바로 옆에(코드/DB/서버) 같이 있으면? → 유출 시 키도 같이 털린다 → 암호화한 의미가 사라짐.
발표 전환 멘트:
"암호화는 문제를 푸는 동시에 새 문제를 만듭니다. 자물쇠는 채웠는데, 열쇠를 문 옆 화분 밑에 두면 아무 소용이 없죠. 그래서 오늘 진짜 주제는 암호화 자체가 아니라 '키를 어떻게, 어디에 둘 것인가' 입니다."
이 한 문장이 발표 전체를 관통하는 축입니다. 인트로의 마지막은 반드시 이 질문으로 닫으세요.
인트로 요약 (스스로 설명 체크)
- "assume breach" 관점을 한 문장으로 말할 수 있다.
- 암호화의 목적이 "유출 방지"가 아니라 "유출 무력화"임을 설명할 수 있다.
- 암호화가 곧바로 "키를 어디 두지?"라는 새 문제를 낳는다는 흐름을 만들 수 있다.
02. 왜 키 관리가 어려운가
인트로에서 던진 질문 "키를 어디 두지?"에 대해, 사람들이 흔히 시도하는 방법들이 왜 하나씩 깨지는지를 보여주는 섹션입니다. 이 섹션의 목적은 "그래서 전용 시스템(KMS/SKM)이 필요하다"로 자연스럽게 몰아가는 것.
1) 순진한 저장 방법 3종과 각각의 한계
(A) 하드코딩 — 소스코드에 키를 박아둠
// 최악의 예시
String secretKey = "my-super-secret-key-1234";한계:
- 소스 저장소(Git)에 그대로 커밋 → 사내 개발자 전원, 협력사, (실수 시) 공개 저장소에 노출.
- Git은 히스토리가 영구 보존 → 나중에 키만 지워도 과거 커밋에 남아있음.
- 배포된 바이너리/JAR를 디컴파일하면 문자열이 그대로 드러남.
- 키를 바꾸려면 코드 수정 → 재빌드 → 재배포. 사실상 못 바꿈.
(B) 설정 파일 — application.yml, .properties 등
db:
password: "P@ssw0rd!"
crypto:
key: "base64EncodedKey=="한계:
- 하드코딩보다 낫지만 여전히 파일 = 평문. 서버 침투 시 그냥 읽힘.
- 설정 파일도 실수로 Git에 올라가는 사고가 매우 흔함.
- 파일에 접근 가능한 사람 = 키에 접근 가능한 사람. 권한 분리가 안 됨.
(C) 환경변수 — export DB_KEY=...
export CRYPTO_KEY="base64EncodedKey=="한계:
- 파일 커밋 사고는 줄지만, 프로세스 환경은 생각보다 잘 샌다:
/proc/<pid>/environ로 같은 서버의 다른 프로세스/사용자가 조회 가능.- 에러 로그·크래시 덤프·APM 툴이 환경변수를 통째로 찍는 경우.
- 하위 프로세스에 자동 상속 → 의도치 않은 전파.
- 컨테이너 오케스트레이션에서 평문 상태로 기록/노출되기 쉬움.
정리 멘트:
"세 방법의 공통 문제는 결국 키가 애플리케이션과 같은 신뢰 경계 안에 평문으로 존재한다는 겁니다. 앱이 뚫리면 키도 같이 뚫립니다."
2) "안전하게 둬도" 남는 문제 — 인증(누가 꺼내 쓰냐)
키를 아주 안전한 금고에 넣었다고 칩시다. 그래도 끝이 아닙니다.
- 금고가 있어도 아무나 문을 열 수 있으면 금고가 아닙니다.
- 즉 "저장의 안전성"과 별개로 "접근 통제(인증/인가)" 가 필요합니다.
- 이 요청이 정말 우리 애플리케이션 서버가 보낸 게 맞나?
- 탈취된 자격증명으로 아무 데서나 키를 꺼내가는 건 아닌가?
- 그래서 좋은 키 관리 시스템은 "키를 안전하게 보관" + "요청자를 확실히 검증" 을 함께 제공합니다.
- (5번에서 볼 SKM의 IPv4/MAC/인증서 인증이 바로 이 지점입니다.)
3) 키를 바꿔야 할 때 — 키 순환(rotation)과 기존 데이터 문제
이게 실무에서 진짜 골치 아픈 부분이고, 발표에서 짚으면 "깊이 있다"는 인상을 줍니다.
키는 언젠가 반드시 바꿔야 합니다. 왜?
- 키가 유출됐거나 유출이 의심될 때
- 규정(컴플라이언스)상 주기적 교체가 요구될 때
- 담당자 퇴사 등 인적 리스크가 생겼을 때
그런데 키를 바꾸면 곧바로 딜레마가 생깁니다:
기존 데이터는 "옛날 키"로 암호화돼 있음.
새 데이터는 "새 키"로 암호화하고 싶음.
→ 그럼 옛날 데이터는 새 키로 못 푸는데?순진한 해법의 한계:
- 전체 데이터를 옛 키로 복호화 → 새 키로 재암호화? 데이터가 수억 건이면 몇 시간~며칠, 그 사이 서비스 영향.
- 키를 바꾸려면 모든 애플리케이션 서버의 설정을 동시에 교체해야 함 → 배포 지옥.
좋은 KMS는 이 문제를:
- 키에 버전을 매겨서 (v1, v2 …) 옛 데이터는 옛 버전으로, 새 데이터는 새 버전으로 관리하고,
- 애플리케이션은 키 값 자체를 몰라도 되게 만들어(참조만 함) "클라이언트 코드 변경 없이 키만 교체"가 가능하게 합니다.
- (뒤에서 볼 봉투 암호화가 이 재암호화 비용을 극적으로 줄여줍니다.)
이 섹션이 만드는 결론 (다음 섹션으로의 다리)
하드코딩·설정파일·환경변수 전부 (1) 저장 안전성, (2) 접근 통제, (3) 키 교체
세 가지를 동시에 만족 못 시킨다.
→ 이 세 가지를 전담하는 시스템이 필요하다 = KMS / Secure Key Manager.
요약 체크
- 하드코딩/설정파일/환경변수의 한계를 각각 1개씩 즉답할 수 있다.
- "저장 안전성 ≠ 접근 통제"를 구분해서 설명할 수 있다.
- 키 순환이 왜 어려운지(기존 데이터 재암호화 문제)를 그림으로 그릴 수 있다.
