Crittografia su storage e compute con controllo di revoca
di Ben Hagan
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.
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.

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 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:

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.
L'implementazione pratica differisce tra storage e compute:
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.
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:
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.
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.
La configurazione viene quindi mappata a uno specifico Workspace. Per Lakebase, ciò significa:
Lakebase supporta la rotazione trasparente delle chiavi. Quando ruoti la tua CMK nella console del tuo provider cloud:
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).
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
Iscriviti al nostro blog e ricevi gli ultimi articoli direttamente nella tua casella di posta.