Passa al contenuto principale
Prodotto

Prendi il controllo: chiavi gestite dal cliente per Lakebase Postgres

Crittografia su storage e compute con controllo di revoca

di Ben Hagan

  • Lakebase CMK abilita il controllo del cliente sulle chiavi di crittografia, consentendoti di gestire le chiavi nel tuo KMS cloud anziché fare affidamento sui valori predefiniti gestiti da Databricks.
  • Proteggi l'intero ciclo di vita dei dati crittografando sia lo storage a lungo termine che le cache di compute effimere.
  • Utilizza il tuo KMS come "kill switch" tecnico per rendere i dati crittograficamente inaccessibili e terminare le istanze di compute attive, fornendo un meccanismo di fail-safe per carichi di lavoro Postgres ad alta conformità.

La crittografia a riposo è una base cloud, ma per le aziende che operano in ambienti altamente regolamentati, le organizzazioni devono controllare la radice di fiducia. Le chiavi gestite dal cliente (CMK) di Lakebase offrono questo controllo consentendo di utilizzare le proprie chiavi di crittografia dal proprio Key Management Service (KMS), ad esempio AWS KMS, Azure Key Vault o Google Cloud KMS, per proteggere e gestire i dati durante l'intero ciclo di vita di Lakebase.

Le chiavi gestite dal cliente (CMK) di Lakebase offrono una gestione e un controllo completi sull'intera architettura, a differenza dei database gestiti convenzionali. Mentre i database tradizionali crittografano tipicamente solo lo storage, Lakebase CMK gestisce sia lo storage persistente che il compute effimero.

Architettura della crittografia di Lakebase

L'architettura di Lakebase separa lo storage e il compute in livelli indipendenti, un design che consente il ridimensionamento elastico e le operazioni serverless. Il livello di storage (Pageserver e Safekeeper) mantiene i dati persistenti a lunga durata nello storage degli oggetti e nelle cache locali, mentre il livello di compute esegue istanze Postgres indipendenti che scalano verso l'alto, verso il basso o a zero in base alla domanda.

il diagramma dell'architettura illustra il meccanismo di crittografia tra i servizi di chiavi gestite dal cloud, Databricks e l'applicazione di chiavi da parte di Lakebase

Questa separazione crea una sfida unica per la crittografia: entrambi i livelli (così come tutte le loro cache nell'architettura) devono essere crittografati e rimanere sotto il controllo del cliente. Lakebase CMK affronta questo problema attraverso un modello gerarchico di crittografia a busta.

La gerarchia delle chiavi

La crittografia a busta è un modello di sicurezza in cui i dati vengono crittografati con chiavi di dati univoche (DEK) e tali chiavi vengono a loro volta crittografate da chiavi di livello superiore. Questa gerarchia garantisce che la tua CMK non lasci mai il tuo KMS cloud: Databricks riceve solo versioni crittografate (wrapped) delle chiavi necessarie per decrittografare i dati. Il modello consente inoltre una crittografia ad alte prestazioni su larga scala, poiché il KMS viene contattato solo per decrittografare le chiavi, non per crittografare ogni blocco di dati. Questa architettura consente la rotazione trasparente delle chiavi e la revoca tempestiva, se mai necessario.

La gerarchia è composta da tre livelli:

  1. Chiave gestita dal cliente (CMK): La radice di fiducia che risiede nel tuo KMS cloud (AWS KMS, Azure Key Vault o Google Cloud KMS). Databricks non vede mai il testo in chiaro di questa chiave.
  2. Chiave di crittografia delle chiavi (KEK): Una chiave transitoria utilizzata dal servizio di gestione delle chiavi di Databricks per crittografare le chiavi dei dati.
  3. Chiavi di crittografia dei dati (DEK): Chiavi univoche generate per ogni segmento di dati. Queste vengono archiviate insieme ai dati in uno stato crittografato (wrapped).
gerarchia della crittografia a busta

Quando i dati devono essere accessibili, i componenti di Lakebase decrittografano la DEK necessaria utilizzando le chiavi ottenute dal tuo KMS. In caso di revoca, la decrittografia fallirà, rendendo i dati crittograficamente inaccessibili. Come parte di questo processo, tutte le istanze di compute effimere vengono terminate per rimuovere l'accesso ai dati memorizzati nella cache.

CMK in pratica: storage e compute

L'implementazione pratica differisce tra storage e compute:

1. Livello di persistenza (Storage)

Tutti i segmenti di dati gestiti da Lakebase, inclusi i segmenti WAL (log delle transazioni archiviati da Safekeeper) e i file di dati, vengono crittografati con chiavi protette dalla tua CMK. Ciò fornisce una difesa in profondità: i dati a riposo sono protetti da chiavi di crittografia sotto il tuo controllo, non da Databricks.

2. Livello effimero (Compute)

La VM di compute Postgres contiene dati effimeri utilizzati dal sistema operativo e da PostgresSQL, ad esempio cache delle prestazioni, artefatti WAL, file temporanei, ecc. Pertanto, è fondamentale che tutti questi dati siano gestiti anche sotto una CMK. La CMK protegge questi dati di compute effimeri con:

  • Chiavi per avvio: Ogni volta che un'istanza di compute Lakebase si avvia, genera una chiave effimera univoca.
  • Distruzione automatica: Alla revoca della CMK, Lakebase Manager termina l'istanza, distruggendo le chiavi effimere in memoria e rendendo inaccessibili i dati su disco locale.

Implementazione della CMK nel flusso di lavoro di Lakebase

L'implementazione segue il modello standard di delega da account Databricks a workspace. Questa separazione dei compiti garantisce che gli amministratori della sicurezza possano gestire le chiavi senza dover accedere ai dati stessi. Una volta configurata una chiave a livello di workspace, tutti i progetti Lakebase utilizzano la CMK come parte del flusso di lavoro di crittografia.

Passaggio 1: Configurazione della chiave

Un amministratore dell'account crea una configurazione della chiave nella console dell'account Databricks. Questo oggetto contiene l'identificatore della chiave (ARN per AWS KMS, URL di Key Vault per Azure o ID chiave per Google Cloud KMS) e il ruolo IAM o il principal del servizio che Lakebase assumerà per eseguire le operazioni di Wrap e Unwrap.

Passaggio 2: Associazione al workspace

La configurazione viene quindi mappata a uno specifico Workspace. Per Lakebase, ciò significa:

  • Nuovi progetti: Tutti i nuovi progetti Lakebase ereditano automaticamente la CMK del workspace.
  • Isolamento: Diversi workspace possono utilizzare CMK diverse per soddisfare requisiti di sicurezza multi-tenant o multi-dipartimentali.

Passaggio 3: Gestione del ciclo di vita e rotazione

Lakebase supporta la rotazione trasparente delle chiavi. Quando ruoti la tua CMK nella console del tuo provider cloud:

  • La gerarchia di crittografia a busta consente una rotazione trasparente: la tua CMK può essere ruotata nel tuo KMS cloud senza ricrittografare i dati o modificare le DEK.
  • Non è richiesto alcun tempo di inattività o ricrittografia manuale.

Auditabilità della sicurezza

Poiché la CMK risiede nel tuo account cloud, le operazioni crittografiche sulla tua chiave vengono registrate nel servizio di audit del tuo provider (AWS CloudTrail, Azure Monitor o Google Cloud Audit Logs).

Inizia con una sovranità dei dati avanzata

Se la tua organizzazione richiede il massimo livello di controllo crittografico sui tuoi carichi di lavoro Postgres, Lakebase CMK è ora disponibile per i clienti di livello Enterprise.

Pronto a proteggere i tuoi dati? Contatta il tuo team account Databricks per abilitare le chiavi gestite dal cliente per il tuo workspace, o visita la nostra documentazione tecnica per rivedere le policy IAM e le configurazioni KMS prerequisiti.

Non sei ancora un cliente Databricks? Inizia con una prova gratuita.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale

Ricevi gli ultimi articoli nella tua casella di posta

Iscriviti al nostro blog e ricevi gli ultimi articoli direttamente nella tua casella di posta.