클라우드 KMS와 봉투 암호화: DEK·KEK·BYOK의 차이

1장 개념과 보호 목표#

봉투 암호화는 데이터 암호화 키(DEK)로 데이터를 보호하고 키 암호화 키(KEK)로 DEK를 감싸는 구조입니다. 클라우드 KMS를 이용하면 키 사용 권한·감사·수명주기를 통제할 수 있지만 실제 데이터 처리 경로를 함께 이해해야 합니다.


2장 원리와 구분#

공급자 관리 키와 고객 관리 키는 고객이 통제하는 범위가 다릅니다. BYOK는 외부에서 만든 키 재료를 가져오는 접근이며 HYOK는 키를 외부에 유지하는 구성으로 사용되지만 지원·의미는 서비스별로 확인해야 합니다. 키를 고객이 관리해도 권한 있는 서비스가 복호화를 요청할 수 있으므로 IAM과 키 정책이 중요합니다.


3장 비교와 판단 기준#

용어 의미 운영에서 확인할 점
DEK 데이터 암호화 키 생성·데이터 범위·유출
KEK DEK 등 키를 감싸는 키 권한·버전·복호화 로그
BYOK 키 재료를 외부에서 가져옴 가져오기·교체·복구
HYOK 외부 유지 키 구성 서비스 지원·통신·가용성

4장 DEK와 KEK를 분리하는 이유#

데이터 본문을 암호화하는 DEK와 그 키를 감싸는 KEK는 용도가 다릅니다. 큰 데이터의 연산과 키의 보관·권한·교체를 나눌 수 있습니다. 키가 두 종류라는 사실 자체보다 어느 서비스가 평문 키를 언제 사용하고 어디서 관리하는지가 중요합니다.

문서 → DEK로 AEAD → 문서 암호문
DEK → KEK로 포장 → 감싼 DEK
보관 → 암호문·감싼 키·키 식별자·Nonce·태그·형식 정보

5장 생성부터 저장까지의 순서#

안전한 데이터 키를 생성하고 문서를 인증 암호화합니다. KEK로 DEK를 감싼 뒤 필요한 메타데이터와 함께 저장합니다. 평문 DEK의 메모리 사용·캐시·로그·덤프를 보호하고 필요 없는 보관을 줄입니다. 키 재료와 키 ID를 같은 비밀 정보로 혼동하지 않습니다.

사용 서비스의 API가 어떤 형식과 키 반환을 제공하는지 확인해야 합니다. KMS라는 이름만으로 모든 평문 키가 애플리케이션 밖에만 존재한다고 설명하면 부정확합니다.


6장 읽기 경로에서 KMS가 하는 일#

애플리케이션이 감싼 DEK의 복원을 KMS에 요청하고, 얻은 DEK로 데이터 본문을 복호화하는 구성이 가능합니다. 이때 KMS 요청의 권한과 데이터의 읽기 권한이 함께 필요할 수 있습니다. 정상 애플리케이션이 처리하는 평문도 보호해야 합니다.

flowchart LR
 S["암호문·감싼 DEK 읽기"] --> K["허용된 KMS 복호화 요청"]
 K --> D["복원한 DEK"]
 D --> A["AEAD 인증 복호화"]
 S --> A
 A --> V["태그 성공 후 데이터 사용"]

7장 데이터 권한과 키 권한#

객체 접근만 있거나 키 접근만 있을 때 기대한 결과를 시험합니다. 서비스·관리자·백업 복구·긴급 작업의 권한을 분리합니다. 키 정책·IAM·서비스의 처리 경로·외부 연동을 실제 요청으로 확인해야 합니다.

한 관리자가 모든 데이터와 키를 읽고 로그도 지울 수 있다면 분리의 효과가 제한될 수 있습니다. 역할·승인·감사와 지원 업무까지 함께 설계합니다.


8장 공급자 관리와 고객 관리#

생성·사용·정책·교체·삭제·감사의 통제 범위가 서비스마다 다릅니다. 고객 관리 키라는 표현도 공급자 서비스가 권한을 받아 복호화를 수행할 수 없는 뜻은 아닙니다. 계약과 실제 키 정책을 확인합니다.

통제 확인할 질문
생성 누가 만들고 어느 보호 경계에 있는가?
사용 어떤 주체와 서비스가 요청하는가?
변경 버전·권한·교체는 누가 관리하는가?
삭제 승인·대기·복구·보존은 어떻게 처리하는가?

9장 BYOK의 가져오기와 복구#

외부에서 만든 키 재료를 서비스로 가져오는 방식은 가져오기·저장·만료·재가져오기·교체의 조건을 확인해야 합니다. 외부 생성이었다는 사실이 클라우드에서 키 사용을 전혀 하지 않는다는 뜻은 아닙니다. 서비스별 통제와 지원이 중요합니다.

가져온 원본의 보호·백업·폐기와 장애 복원도 정합니다. 원본을 안전하게 보관해야 할 필요와 불필요한 복사본의 노출 위험을 함께 판단합니다.


10장 HYOK와 외부 키 서비스#

키를 외부에 유지하는 구성은 통제권과 함께 외부 통신·지연·가용성·복구의 의존성을 가져올 수 있습니다. 용어와 실제 지원 기능은 서비스별로 다를 수 있어 동작 경로를 확인해야 합니다. 외부 유지가 데이터 처리의 평문 경로를 모두 없애지는 않습니다.

외부 키 시스템 장애·인증·회수·복구를 실제 서비스와 시험합니다. 계약상 가용성과 업무의 RTO·RPO도 연결합니다.


11장 키 회전·재포장·재암호화의 차이#

새 쓰기에 새 키 버전을 쓰는 작업, 감싼 DEK를 다른 KEK로 포장하는 작업, 데이터 본문을 새 DEK로 다시 암호화하는 작업은 다릅니다. 서비스가 자동으로 어느 작업을 하는지 확인해야 합니다. 키 회전 버튼만으로 기존 데이터가 모두 새 키로 바뀐다고 설명하지 않습니다.

flowchart TB
 R["교체의 목적"] --> N["신규 데이터의 키 변경"]
 R --> W["DEK의 키 포장 변경"]
 R --> D["데이터 본문의 재암호화"]
 N --> V["과거 읽기와 새 쓰기 검증"]
 W --> V
 D --> V

12장 삭제는 데이터 복구 가능성을 바꾼다#

필요 키를 잃으면 정상 암호문·백업도 읽지 못할 수 있습니다. 삭제 전 연결 데이터·백업·보존 의무·복구 경로를 조사합니다. 승인과 대기·복구 조건을 정하고 실제 시험으로 확인합니다. 비활성화와 영구 삭제도 다른 상태입니다.

암호학적 삭제의 효과를 평가할 때 키 사본·캐시·다른 포장·평문 사본을 조사해야 합니다. 키 하나를 지웠다는 기록만으로 모든 정보가 사라졌다고 판단하지 않습니다.


13장 감사기록과 복구 시험#

누가 어떤 키로 어떤 요청을 했는지와 데이터·작업을 연결합니다. 로그의 무결성·보존·조회 권한을 관리하고 비밀 키나 민감 원문은 남기지 않습니다. 정상 복원 외에 비허용 계정·비활성 키·다른 버전·외부 서비스 장애도 시험합니다.

봉투 암호화의 효과는 알고리즘뿐 아니라 실제 권한·평문 경로·수명주기·복구가 함께 맞는 상태로 설명해야 합니다.


14장 적용 사례와 운영 방법#

객체 저장소에서는 암호화 여부 외에 데이터 접근 권한과 KMS 복호화 권한을 함께 검증합니다. 키 교체가 기존 데이터 전체를 즉시 재암호화한다는 뜻은 아닙니다. 키 비활성화·삭제·외부 키 서비스 장애가 백업 복원에 미치는 영향을 시험하고 암호문에 키 식별 정보를 유지합니다.


15장 봉투 암호화#

flowchart LR
 D["평문 데이터"] --> E["DEK로 암호화"]
 E --> C["암호문"]
 K["DEK"] --> E
 K --> W["KMS의 KEK로 감싸기"]
 W --> B["암호화된 DEK"]
 C --> S["암호문·감싼 DEK·키 ID 저장"]
 B --> S

16장 봉투 암호화의 저장 형식과 복호화 경로#

DEK로 데이터 본문을 암호화하고 KEK로 DEK를 감싸면 데이터 크기와 키 보호의 책임을 나눌 수 있습니다. 저장소에는 데이터 암호문·감싼 DEK·키 식별자·알고리즘·Nonce·태그 등 복원에 필요한 정보를 둡니다. 구체적인 형식은 사용하는 암호 라이브러리와 서비스 규약을 따라야 합니다.

복호화 시 KMS에 감싼 DEK를 보내 복원한 뒤 애플리케이션이 데이터 복호화를 수행하는 구성이 있을 수 있습니다. 이 경우 평문 DEK가 애플리케이션 메모리에 나타나는 경로를 이해해야 합니다. KMS를 쓴다는 이유로 모든 키와 평문이 언제나 애플리케이션 밖에만 있다고 설명하면 부정확합니다.


17장 데이터 권한과 키 권한을 함께 시험하기#

객체 읽기 권한만 있거나 키 복호화 권한만 있을 때 각각 어떤 결과가 나는지 확인합니다. 관리자·서비스 계정·백업 복구 계정의 권한을 나누고 KMS 사용 로그를 실제 자산과 연결합니다. 키 교체·재포장·데이터 재암호화는 서로 다른 작업입니다.

키 삭제는 데이터를 읽을 수 없게 만들 수 있으므로 보존·법적 의무·백업 의존성을 확인하고 승인합니다. BYOK는 가져온 키 재료의 복구·재가져오기 조건, HYOK는 외부 키 서비스의 장애와 지연을 시험합니다. 외부 유지가 통제권을 높일 수 있어도 가용성 책임이 자동으로 없어지지는 않습니다.


18장 적용 전 확인할 사항#

  • 키 생성·사용·교체·삭제 권한을 분리한다
  • 키 정책과 데이터 접근 정책을 함께 점검한다
  • 과거 키를 요구하는 백업과 장애 복원을 확인한다

19장 자주 묻는 질문#

KMS 키를 교체하면 기존 암호문이 자동으로 새 키를 쓰나요?#

서비스의 키 버전 관리와 재암호화 방식에 따라 다릅니다. 새 데이터 처리, 기존 암호문 복호화, 실제 재암호화를 구분해 확인해야 합니다.

KEK를 바꾸려면 큰 파일을 언제나 다시 암호화해야 하나요?#

구성에 따라 감싼 DEK를 새 KEK로 재포장할 수 있습니다. 데이터 자체의 암호화 변경과 키 포장 변경을 서비스가 어떻게 지원하는지 확인해야 합니다.

고객 관리 키면 공급자 서비스는 데이터에 접근할 수 없나요?#

권한 있는 서비스가 복호화를 요청할 수 있는 구성이 있습니다. 키 정책·IAM·서비스 처리 경로와 계약상 보호 범위를 함께 확인해야 합니다.


함께 읽기#