> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sifi.life/llms.txt
> Use this file to discover all available pages before exploring further.

# Lakebase Postgres 고객 관리 키(CMK) — 암호화에 대한 완전한 통제권

작성자: Databricks Lakebase 팀 | 2026년 4월 20일

원문: [https://www.databricks.com/blog/take-control-customer-managed-keys-lakebase-postgres](https://www.databricks.com/blog/take-control-customer-managed-keys-lakebase-postgres)

***

> **참고**
> **요약**

* **저장소와 컴퓨트 모두 암호화**: 기존 관리형 DB가 영구 저장소만 암호화하는 것과 달리, Lakebase CMK는 **영구 저장소와 단명 컴퓨트(ephemeral compute)** 모두를 고객이 관리하는 키로 보호합니다.
* **봉투 암호화(Envelope Encryption) 3계층**: CMK → KEK(Key Encryption Key) → DEK(Data Encryption Key) 구조로, KMS 호출을 최소화하면서 강력한 격리와 회전을 보장합니다.
* **Kill Switch와 감사 통합**: 키 회전은 다운타임 없이 진행되고, 모든 암호화 작업은 자체 클라우드 KMS의 감사 로그에 남으며, 키 폐기로 데이터 접근을 즉시 중단할 수 있습니다.

***

데이터에 대한 기술적 통제권은 규제 산업과 보안 민감 조직의 핵심 요구사항입니다. 클라우드 관리형 데이터베이스의 편리함을 누리되 암호화 키만큼은 자체 KMS에서 직접 보유·관리하고 싶다는 요구가 있습니다. **Lakebase Customer-Managed Keys (CMK)** 는 이 요구를 정면으로 해결합니다.

## 무엇이 다른가 — 저장소뿐 아니라 컴퓨트까지

대부분의 관리형 데이터베이스 CMK 구현은 **영구 저장소(persistent storage)** 만 고객 키로 암호화합니다. 즉 디스크에 쓰여지는 블록과 트랜잭션 로그는 보호되지만, 메모리에서 실행 중인 Postgres 인스턴스 자체와 임시 작업 영역은 그렇지 않습니다.

Lakebase CMK는 다릅니다:

> "Lakebase CMK는 **영구 저장소와 단명 컴퓨트** 모두를 관리합니다."

부팅 시점에 컴퓨트 인스턴스가 자체적으로 고유 키를 생성하고, 종료 시 메모리 내 키가 파괴됩니다. 키 폐기 시 인스턴스가 자동 종료되어 메모리에서도 접근이 차단됩니다.

## 기술 아키텍처 — 봉투 암호화 3계층

성능과 보안을 동시에 달성하기 위해 **봉투 암호화(Envelope Encryption)** 가 사용됩니다:

```
┌──────────────────────────────────────────┐
│ 1. Customer Managed Key (CMK)            │  ← 고객 KMS에 저장. Databricks에 노출되지 않음
│    AWS KMS / Azure Key Vault / GCP KMS   │
└──────────────────────────────────────────┘
                    │ wraps
                    ▼
┌──────────────────────────────────────────┐
│ 2. Key Encryption Key (KEK)              │  ← 단명. 데이터 키를 감싸는 일회성 키
└──────────────────────────────────────────┘
                    │ wraps
                    ▼
┌──────────────────────────────────────────┐
│ 3. Data Encryption Keys (DEKs)           │  ← 데이터 세그먼트마다 고유
└──────────────────────────────────────────┘
```

이 분리가 만드는 것:

* **KMS는 외부**에 머무름. Databricks는 CMK 자체에 접근하지 않음
* **모든 데이터 블록마다 KMS를 호출하지 않음** — 고성능 암호화 작업 가능
* **각 DEK는 독립적**으로 회전·폐기 가능

## 실무적 구현

### 저장소 계층

* 영구 데이터 세그먼트와 트랜잭션 로그 모두 CMK로 보호된 키로 암호화
* 백업도 동일한 키 계층으로 보호

### 컴퓨트 계층

* 단명(ephemeral) Postgres 인스턴스가 부팅 시점에 고유 per-boot 키 생성
* 키 폐기 시 자동 종료 → 메모리 내 키 파괴 → 데이터 접근 차단

### 워크플로우

1. **Account Admin**이 CMK를 자체 KMS에 구성 (AWS KMS / Azure Key Vault / GCP KMS)
2. Databricks 계정에 KMS 키 ARN/URL과 IAM 권한 연결
3. **Workspace 수준 바인딩**으로 워크스페이스에 키를 연결하면, 새 Lakebase 프로젝트가 자동으로 해당 CMK를 상속

## 보안 기능

### 다운타임 없는 키 회전

키를 회전해도 데이터 전체를 재암호화하지 않습니다. KEK 계층의 재래핑(rewrap)만으로 충분하므로 운영 중단 없이 회전이 가능합니다.

### 감사 로그 통합

모든 암호화 작업—키 사용, 회전, 정책 변경—은 자체 클라우드 KMS 제공자의 감사 서비스에 기록됩니다 (AWS CloudTrail, Azure Monitor, Google Cloud Audit Logs).

### 기술적 Kill Switch

KMS에서 키를 폐기하면 Lakebase가 데이터를 복호화할 수 없게 됩니다. 데이터 자체를 삭제하지 않고도 접근을 즉시 차단할 수 있는 강력한 메커니즘입니다.

### 멀티 테넌트 격리

워크스페이스마다 다른 CMK를 할당할 수 있어, 동일 계정 내에서도 데이터 보안 경계를 명확히 분리할 수 있습니다.

## 누구에게 적용되나

Lakebase CMK는 **Enterprise 티어** 고객에게 제공됩니다. 다음과 같은 경우에 특히 유용합니다:

* 금융, 의료, 정부 등 규제 산업
* BYOK(Bring Your Own Key) 정책을 가진 조직
* 데이터 거주성(Data Residency)과 키 거주성을 분리해서 관리해야 하는 글로벌 조직
* 보안 사고 대응 시 즉시 데이터 접근을 차단해야 하는 환경

## 시작하기

기존 Lakebase 프로젝트에 CMK를 적용하려면 KMS에서 키를 생성하고, Databricks 계정에 등록한 뒤 워크스페이스에 바인딩합니다. 자세한 단계별 절차는 [Lakebase 문서](https://docs.databricks.com/aws/en/oltp/security/cmk)를 참조하세요.