制御を握る：Lakebase Postgres の顧客管理キー

暗号化はクラウドの基本ですが、規制の厳しい環境で事業を行う企業にとっては、信頼の基盤を組織が管理する必要があります。Lakebase の顧客管理キー (CMK) は、Key Management Service (KMS) (例: AWS KMS、Azure Key Vault、Google Cloud KMS) から独自の暗号化キーを使用して、Lakebase のライフサイクル全体でデータを保護および管理できるようにすることで、この制御を提供します。

Lakebase 顧客管理キー (CMK) は、従来のマネージドデータベースとは異なり、アーキテクチャ全体にわたる包括的な管理と制御を提供します。従来のデータベースは通常ストレージのみを暗号化しますが、Lakebase CMK は永続ストレージと一時的なコンピューティングの両方を管理します。

Lakebase 暗号化のアーキテクチャ

Lakebase のアーキテクチャ は、ストレージとコンピューティングを独立したレイヤーに分離しています。この設計により、弾力的なスケーリングとサーバーレス操作が可能になります。ストレージレイヤー (Pageserver および Safekeeper) は、オブジェクトストレージとローカルキャッシュに長期的な永続データを維持しますが、コンピューティングレイヤーは独立した Postgres インスタンスを実行し、需要に応じてスケールアップ、ダウン、またはゼロにスケールします。

この分離により、暗号化のユニークな課題が生じます。両方のレイヤー (およびアーキテクチャ全体にわたるすべてのキャッシュ) は暗号化され、顧客の管理下にある必要があります。Lakebase CMK は、階層的なエンベロープ暗号化モデルを通じてこれを実現します。

キーの階層

エンベロープ暗号化は、データが独自のデータキー (DEK) で暗号化され、それらのキー自体が上位キーで暗号化されるセキュリティモデルです。この階層により、CMK がクラウド KMS から離れることはありません。Databricks は、データを復号化するために必要なキーのラップされた (暗号化された) バージョンのみを受け取ります。このモデルは、KMS がすべてのデータブロックを暗号化するためではなく、キーをアンラップするためにのみ連絡されるため、大規模な高性能暗号化も可能にします。このアーキテクチャにより、シームレスなキーローテーションと、必要に応じたタイムリーな失効が可能になります。

階層は 3 つのレベルで構成されます。

1. 顧客管理キー (CMK): クラウド KMS (AWS KMS、Azure Key Vault、または Google Cloud KMS) に存在する信頼の基盤。Databricks はこのキーの平文を見ることはありません。
2. キー暗号化キー (KEK): Databricks Key Manager Service がデータキーをラップするために使用する一時的なキー。
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 をローテーションすると、次のようになります。

• エンベロープ暗号化階層により、シームレスなローテーションが可能になります。CMK は、データを再暗号化したり DEK を変更したりすることなく、クラウド KMS でローテーションできます。
• ダウンタイムや手動での再暗号化は一切不要です。

セキュリティ監査可能性

CMK はお客様のクラウドアカウントに常駐するため、キーに対する暗号操作は、プロバイダーの監査サービス (AWS CloudTrail、Azure Monitor、または Google Cloud Audit Logs) に記録されます。

データ主権の強化を始めましょう

お客様の組織が Postgres ワークロードに対する暗号制御の最高レベルを必要とする場合、Lakebase CMK が Enterprise ティアのお客様向けに利用可能になりました。

データの保護を始めますか？ Databricks アカウントチームに連絡して、ワークスペースの顧客管理キーを有効にするか、技術ドキュメント を参照して、前提となる IAM ポリシーと KMS 構成を確認してください。

まだ Databricks のお客様ではありませんか？トライアル で始めましょう。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事