제어권 확보: Lakebase Postgres를 위한 고객 관리 키

저장 데이터 암호화는 클라우드의 기본 기능이지만, 규제가 엄격한 환경에서 운영되는 기업의 경우 조직이 신뢰의 근원을 제어해야 합니다. Lakebase 고객 관리 키(CMK)는 AWS KMS, Azure Key Vault 또는 Google Cloud KMS와 같은 자체 키 관리 서비스(KMS)의 암호화 키를 사용하여 전체 Lakebase 수명 주기 동안 데이터를 보호하고 관리할 수 있도록 하여 이러한 제어를 제공합니다.

Lakebase 고객 관리 키(CMK)는 기존 관리형 데이터베이스와 달리 전체 아키텍처에 걸쳐 포괄적인 관리 및 제어를 제공합니다. 기존 데이터베이스는 일반적으로 스토리지만 암호화하는 반면, Lakebase CMK는 영구 스토리지와 임시 컴퓨팅 모두를 관리합니다.

Lakebase 암호화 아키텍처

Lakebase 아키텍처는 스토리지와 컴퓨팅을 독립적인 계층으로 분리하여 탄력적인 확장 및 서버리스 운영을 가능하게 합니다. 스토리지 계층(Pageserver 및 Safekeeper)은 객체 스토리지 및 로컬 캐시에 장기적인 영구 데이터를 유지하는 반면, 컴퓨팅 계층은 수요에 따라 확장, 축소 또는 제로로 조정되는 독립적인 Postgres 인스턴스를 실행합니다.

이 분리는 암호화에 대한 고유한 과제를 만듭니다. 즉, 두 계층(및 아키텍처 전반의 모든 캐시) 모두 암호화되어야 하며 고객 제어 하에 있어야 합니다. Lakebase CMK는 계층적 봉투 암호화 모델을 통해 이를 해결합니다.

키 계층 구조

봉투 암호화는 데이터 키(DEK)로 데이터를 암호화하고 해당 키 자체는 상위 키로 암호화되는 보안 모델입니다. 이 계층 구조는 CMK가 클라우드 KMS를 벗어나지 않도록 보장합니다. Databricks는 데이터 해독에 필요한 키의 래핑된(암호화된) 버전만 받습니다. 이 모델은 KMS가 모든 데이터 블록을 암호화하는 것이 아니라 키를 해제하는 데만 사용되므로 대규모 고성능 암호화를 가능하게 합니다. 이 아키텍처는 원활한 키 로테이션과 필요한 경우 시기적절한 해지를 가능하게 합니다.

계층 구조는 세 가지 수준으로 구성됩니다.

1. 고객 관리 키(CMK): 클라우드 KMS(AWS KMS, Azure Key Vault 또는 Google Cloud KMS)에 있는 신뢰의 근원입니다. Databricks는 이 키의 일반 텍스트를 보지 못합니다.
2. 키 암호화 키(KEK): Databricks 키 관리자 서비스에서 데이터 키를 래핑하는 데 사용되는 임시 키입니다.
3. 데이터 암호화 키(DEK): 모든 데이터 세그먼트에 대해 생성되는 고유한 키입니다. 이들은 암호화된(래핑된) 상태로 데이터와 함께 저장됩니다.

데이터 액세스가 필요한 경우 Lakebase 구성 요소는 KMS에서 가져온 키를 사용하여 필요한 DEK를 해제합니다. 해지 시 해제가 실패하여 데이터가 암호적으로 액세스할 수 없게 됩니다. 이 프로세스의 일부로 모든 임시 컴퓨팅 인스턴스가 종료되어 캐시된 데이터에 대한 액세스가 제거됩니다.

실제 CMK: 스토리지 및 컴퓨팅

실제 구현은 스토리지와 컴퓨팅 간에 다릅니다.

1. 영구 계층(스토리지)

WAL 세그먼트(Safekeeper에서 저장한 트랜잭션 로그) 및 데이터 파일을 포함하여 Lakebase에서 관리하는 모든 데이터 세그먼트는 CMK로 보호되는 키로 암호화됩니다. 이는 심층 방어를 제공합니다. 즉, 저장된 데이터는 Databricks가 아닌 사용자가 제어하는 암호화 키로 보호됩니다.

2. 임시 계층(컴퓨팅)

Postgres 컴퓨팅 VM에는 운영 체제 및 PostgresSQL에서 사용하는 임시 데이터(예: 성능 캐시, WAL 아티팩트, 임시 파일 등)가 포함됩니다. 따라서 이 모든 데이터가 CMK로 관리되는 것이 중요합니다. CMK는 다음을 사용하여 이 임시 컴퓨팅 데이터를 보호합니다.

• 부팅당 키: Lakebase 컴퓨팅 인스턴스가 시작될 때마다 고유한 임시 키를 생성합니다.
• 자동 삭제: CMK 해지 시 Lakebase Manager는 인스턴스를 종료하여 메모리 내 임시 키를 파기하고 로컬 디스크 데이터를 액세스할 수 없게 만듭니다.

Lakebase 워크플로에서 CMK 구현

구현은 표준 Databricks 계정-워크스페이스 위임 모델을 따릅니다. 이 역할 분리는 보안 관리자가 데이터 자체에 액세스할 필요 없이 키를 관리할 수 있도록 보장합니다. 키가 워크스페이스 수준에서 구성되면 모든 Lakebase 프로젝트는 암호화 워크플로의 일부로 CMK를 사용합니다.

1단계: 키 구성

계정 관리자는 Databricks 계정 콘솔에서 키 구성을 만듭니다. 이 개체에는 키 식별자(AWS KMS의 ARN, Azure의 Key Vault URL 또는 Google Cloud KMS의 키 ID)와 래핑 및 해제 작업을 수행하기 위해 Lakebase가 사용할 IAM 역할 또는 서비스 주체가 포함됩니다.

2단계: 워크스페이스 바인딩

그런 다음 구성이 특정 워크스페이스에 매핑됩니다. Lakebase의 경우 다음을 의미합니다.

• 새 프로젝트: 모든 새 Lakebase 프로젝트는 워크스페이스의 CMK를 자동으로 상속합니다.
• 격리: 다른 워크스페이스는 다른 CMK를 사용하여 다중 테넌트 또는 다중 부서 보안 요구 사항을 충족할 수 있습니다.

3단계: 수명 주기 관리 및 로테이션

Lakebase는 원활한 키 로테이션을 지원합니다. 클라우드 공급자 콘솔에서 CMK를 로테이션하면 다음과 같습니다.

• 봉투 암호화 계층 구조는 원활한 로테이션을 가능하게 합니다. 즉, 데이터를 다시 암호화하거나 DEK를 변경하지 않고도 클라우드 KMS에서 CMK를 로테이션할 수 있습니다.
• 다운타임이나 수동 다시 암호화가 필요하지 않습니다.

보안 감사 가능성

CMK는 클라우드 계정에 있으므로 키에 대한 암호화 작업은 클라우드 공급자의 감사 서비스(AWS CloudTrail, Azure Monitor 또는 Google Cloud 감사 로그)에 기록됩니다.

향상된 데이터 주권으로 시작하기

조직에서 Postgres 워크로드에 대한 최고 수준의 암호화 제어가 필요한 경우 Lakebase CMK를 이제 Enterprise 등급 고객에게 제공합니다.

데이터를 안전하게 보호할 준비가 되셨습니까? Databricks 계정 팀에 문의하여 워크스페이스에 대한 고객 관리 키를 활성화하거나 기술 설명서를 방문하여 필수 IAM 정책 및 KMS 구성을 검토하십시오.

아직 Databricks 고객이 아니신가요? 평가판으로 시작하세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)