Migliori pratiche di sicurezza per Delta Sharing

 

Il lakehouse dei dati ci ha permesso di consolidare le nostre architetture di gestione dei dati, eliminando i silos e sfruttando un'unica piattaforma comune per tutti i casi d'uso. L'unificazione dei casi d'uso di data warehousing e AI su un'unica piattaforma è un enorme passo avanti per le organizzazioni, ma una volta compiuto questo passo, la domanda successiva da considerare è "come condividiamo quei dati in modo semplice e sicuro, indipendentemente dal client, dallo strumento o dalla piattaforma che il destinatario sta utilizzando per accedervi?". Fortunatamente, il lakehouse ha anche una risposta a questa domanda: la condivisione dei dati con Delta Sharing.

Delta Sharing

Delta Sharing è il primo protocollo aperto al mondo per la condivisione sicura di dati in tempo reale, internamente e tra organizzazioni, indipendentemente dalla piattaforma su cui risiedono i dati. È un componente chiave dell'apertura dell'architettura lakehouse e un abilitatore chiave per organizzare i nostri team di dati e i modelli di accesso in modi che non sono stati possibili prima, come il data mesh.

Sicuro per progettazione

È importante notare che Delta Sharing è stato costruito da zero pensando alla sicurezza, consentendoti di sfruttare le seguenti funzionalità pronte all'uso, sia che tu utilizzi la versione open source o il suo equivalente gestito:

• Crittografia TLS end-to-end dal client al server all'account di archiviazione
• Credenziali di breve durata come URL pre-firmati vengono utilizzate per accedere ai dati
• Governa, traccia e controlla facilmente l'accesso ai tuoi set di dati condivisi tramite Unity Catalog

Le best practice che condivideremo come parte di questo blog sono additive, consentendo ai clienti di allineare i controlli di sicurezza appropriati al loro profilo di rischio e alla sensibilità dei loro dati.

Best Practice di Sicurezza

Le nostre raccomandazioni sulle best practice per l'utilizzo di Delta Sharing per condividere dati sensibili sono le seguenti:

1. Valuta la versione open source rispetto alla versione gestita in base ai tuoi requisiti
2. Imposta la durata appropriata del token del destinatario per ogni metastore
3. Stabilisci un processo per la rotazione delle credenziali
4. Considera il giusto livello di granularità per Condivisioni, Destinatari e Partizioni
5. Configura gli elenchi di accesso IP
6. Configura il logging di controllo di Databricks
7. Configura restrizioni di rete sull'Account di Archiviazione
8. Configura il logging sull'Account di Archiviazione

1. Valuta la versione open source rispetto alla versione gestita in base ai tuoi requisiti

Come abbiamo stabilito in precedenza, Delta Sharing è stato costruito da zero con la sicurezza al primo posto. Tuttavia, ci sono vantaggi nell'utilizzare la versione gestita:

• Delta Sharing su Databricks è fornito da Unity Catalog, che ti consente di fornire un accesso granulare a qualsiasi set di dati tra diversi gruppi di utenti centralmente da un unico posto. Con la versione open source, dovresti separare i set di dati che hanno vari diritti di accesso ai dati tra diversi server di condivisione, e dovresti anche imporre restrizioni di accesso su quei server e sugli account di archiviazione sottostanti. Per facilità di distribuzione, un docker image è fornito con la versione open source, ma è importante notare che la scalabilità delle distribuzioni nelle grandi imprese comporterà un overhead non trascurabile per i team responsabili della loro gestione.
• Proprio come il resto della Lakehouse Platform di Databricks, Unity Catalog è fornito come servizio gestito. Non devi preoccuparti di cose come la disponibilità, l'uptime e la manutenzione del servizio perché ce ne occupiamo noi per te.
• Unity Catalog ti consente di configurare funzionalità complete di logging di controllo pronte all'uso.
• I proprietari dei dati potranno gestire le condivisioni utilizzando la sintassi SQL. Inoltre, sono disponibili API REST per gestire le condivisioni. L'utilizzo della sintassi SQL familiare semplifica il modo in cui condividiamo i dati, riducendo l'onere amministrativo.
• Utilizzando la versione open source, sei responsabile della configurazione, dell'infrastruttura e della gestione della condivisione dei dati, ma con la versione gestita tutta questa funzionalità è disponibile pronta all'uso.

Per questi motivi, raccomandiamo di valutare entrambe le versioni e prendere una decisione basata sui tuoi requisiti. Se la facilità di configurazione e utilizzo, la governance e il controllo pronti all'uso e la gestione del servizio esternalizzata sono importanti per te, la versione gestita sarà probabilmente la scelta giusta.

2. Imposta la durata appropriata del token del destinatario per ogni metastore

Quando abiliti Delta Sharing, configuri la durata del token per le credenziali del destinatario. Se imposti la durata del token a 0, i token dei destinatari non scadono mai.

Impostare la durata appropriata del token è di fondamentale importanza dal punto di vista normativo, della conformità e della reputazione. Avere un token che non scade mai è un rischio enorme; pertanto, si raccomanda di utilizzare token di breve durata come best practice. È molto più facile concedere un nuovo token a un destinatario il cui token è scaduto piuttosto che indagare sull'uso di un token la cui durata è stata impostata in modo errato.

Vedi la documentazione (AWS, Azure) per configurare i token in modo che scadano dopo il numero appropriato di secondi, minuti, ore o giorni.

3. Stabilisci un processo per la rotazione delle credenziali

Ci sono una serie di motivi per cui potresti voler ruotare le credenziali, dalla scadenza di un token esistente, alla preoccupazione che una credenziale possa essere stata compromessa, o anche solo perché hai modificato la durata del token e vuoi emettere nuove credenziali che rispettino quel tempo di scadenza.

Per garantire che tali richieste vengano soddisfatte in modo prevedibile e tempestivo, è importante stabilire un processo, preferibilmente con un SLA definito. Questo potrebbe essere ben integrato nel tuo processo di gestione dei servizi IT, con l'azione appropriata completata dal proprietario dei dati designato, dallo steward dei dati o dal DBA per quel metastore.

Vedi la documentazione (AWS, Azure) su come ruotare le credenziali. In particolare:

• Se è necessario ruotare immediatamente una credenziale, imposta --existing-token-expire-in-seconds su 0, e il token esistente scadrà immediatamente.
• Databricks raccomanda le seguenti azioni quando ci sono preoccupazioni che le credenziali possano essere state compromesse:
  1. Revoca l'accesso del destinatario alla condivisione.
  2. Ruota il destinatario e imposta --existing-token-expire-in-seconds su 0 in modo che il token esistente scada immediatamente.
  3. Condividi il nuovo link di attivazione con il destinatario previsto tramite un canale sicuro.
  4. Dopo aver acceduto all'URL di attivazione, concedi nuovamente al destinatario l'accesso alla condivisione.

4. Considera il giusto livello di granularità per Condivisioni, Destinatari e Partizioni

Nella versione gestita, ogni condivisione può contenere una o più tabelle e può essere associata a uno o più destinatari, utilizzando controlli granulari per gestire chi o come vengono acceduti i set di dati multipli. Ciò ci consente di fornire un accesso granulare a più set di dati in un modo che sarebbe molto più difficile da ottenere utilizzando solo l'open source. E possiamo anche andare un passo oltre, aggiungendo solo una parte di una tabella da condividere fornendo una specifica di partizione (vedi la documentazione su AWS, Azure).

Vale la pena sfruttare queste funzionalità implementando le tue condivisioni e i tuoi destinatari in modo che seguano il principio del privilegio minimo, in modo tale che se una credenziale del destinatario viene compromessa, sia associata al minor numero di set di dati o alla più piccola sotto-porzione di dati possibile.

5. Configura elenchi di accesso IP

Per impostazione predefinita, tutto ciò che è necessario per accedere alle tue condivisioni è un file di credenziali Delta Sharing valido, pertanto è fondamentale ridurre al minimo la possibilità che le credenziali vengano compromesse implementando limiti a livello di rete su dove possono essere utilizzate.

Configura gli elenchi di accesso IP di Delta Sharing (vedi la documentazione per AWS, Azure) per limitare l'accesso dei destinatari a indirizzi IP attendibili, ad esempio, l'IP pubblico della tua VPN aziendale.

Combinando gli elenchi di accesso IP con il token di accesso si riducono considerevolmente i rischi di accesso non autorizzato. Affinché qualcuno possa accedere ai dati in modo non autorizzato, deve aver acquisito una copia del tuo token ed essere sulla stessa rete autorizzata, il che è molto più difficile che acquisire semplicemente il token stesso.

6. Configura il logging di controllo di Databricks

I log di controllo sono il tuo record autorevole di ciò che accade sulla tua Databricks Lakehouse Platform, incluse tutte le attività relative a Delta Sharing. Pertanto, raccomandiamo vivamente di configurare i log di controllo di Databricks per ogni cloud (vedi la documentazione per AWS, Azure) e impostare pipeline automatizzate per elaborare tali log e monitorare/segnalare eventi importanti.

Dai un'occhiata al nostro blog di accompagnamento, Monitorare la tua Databricks Lakehouse Platform con i log di controllo per un'analisi più approfondita di questo argomento, incluso tutto il codice necessario per configurare le pipeline di Delta Live Tables, configurare gli avvisi di Databricks SQL ed eseguire query SQL per rispondere a domande importanti come:

• Quali delle mie condivisioni Delta sono le più popolari?
• Da quali paesi vengono accedute le mie condivisioni Delta?
• I destinatari di Delta Sharing vengono creati senza l'applicazione di restrizioni di accesso IP?
• I destinatari di Delta Sharing vengono creati con restrizioni di accesso IP che si trovano al di fuori del mio intervallo IP attendibile?
• I tentativi di accedere alle mie condivisioni Delta non rispettano le restrizioni di accesso IP?
• I tentativi di accedere alle mie condivisioni Delta falliscono ripetutamente l'autenticazione?

7. Configura restrizioni di rete sull'account di archiviazione

Una volta che una richiesta di delta sharing è stata autenticata con successo dal server di condivisione, vengono generati e restituiti al client una serie di credenziali di breve durata. Il client utilizza quindi questi URL per richiedere i file pertinenti direttamente dal provider cloud. Questo design significa che il trasferimento può avvenire in parallelo a larghezza di banda massiccia, senza lo streaming dei risultati attraverso il server. Significa anche che, dal punto di vista della sicurezza, probabilmente vorrai implementare restrizioni di rete simili sull'account di archiviazione come sul destinatario di delta sharing stesso: non ha senso proteggere la condivisione a livello di destinatario, se i dati stessi sono ospitati in un account di archiviazione a cui chiunque può accedere da qualsiasi luogo.

Azure

Su Azure, Databricks consiglia di utilizzare Managed Identities (attualmente in anteprima pubblica) per accedere all'Account di archiviazione sottostante per conto di Unity Catalog. I clienti possono quindi configurare firewall di archiviazione per limitare tutti gli altri accessi agli endpoint privati attendibili, alle reti virtuali o agli intervalli IP pubblici che i client di delta sharing possono utilizzare per accedere ai dati. Contatta il tuo rappresentante Databricks per maggiori informazioni.

Nota importante: Ancora una volta, è importante considerare tutti i potenziali casi d'uso quando si determinano le restrizioni a livello di rete da applicare. Ad esempio, oltre ad accedere ai dati tramite delta sharing, è probabile che uno o più workspace Databricks richiederanno l'accesso ai dati, e quindi dovresti consentire l'accesso dagli endpoint privati attendibili pertinenti, dalle reti virtuali o dagli intervalli IP pubblici utilizzati da tali workspace.

AWS

Su AWS, Databricks consiglia di utilizzare le policy dei bucket S3 per limitare l'accesso ai tuoi bucket S3. Ad esempio, la seguente istruzione Deny potrebbe essere utilizzata per limitare l'accesso a indirizzi IP e VPC attendibili.

Nota importante: È importante considerare tutti i potenziali casi d'uso quando si determinano le restrizioni a livello di rete da applicare. Ad esempio:

• Quando si utilizza la versione gestita, gli URL pre-firmati vengono generati da Unity Catalog, e quindi dovrai consentire l'accesso dall'IP NAT del piano di controllo Databricks per la tua regione.
• È probabile che uno o più workspace Databricks richiederanno l'accesso ai dati, e quindi dovresti consentire l'accesso dagli ID VPC pertinenti se il bucket S3 sottostante si trova nella stessa regione e stai utilizzando VPC Endpoints per connetterti a S3 o all'indirizzo IP pubblico a cui il traffico del piano dati si risolve (ad esempio tramite un NAT Gateway).
• Per evitare di perdere la connettività dalla tua rete aziendale, Databricks consiglia di consentire sempre l'accesso da almeno un indirizzo IP noto e attendibile, come l'IP pubblico della tua VPN aziendale. Questo perché le condizioni Deny si applicano anche all'interno della console AWS.

Oltre alle restrizioni a livello di rete, si raccomanda anche di limitare l'accesso ai bucket S3 sottostanti al ruolo IAM utilizzato da Unity Catalog. Il motivo è che, come abbiamo visto, Unity Catalog fornisce un accesso granulare ai tuoi dati in un modo che non è possibile con le autorizzazioni a grana grossa fornite da AWS IAM/S3. Pertanto, se qualcuno riuscisse ad accedere direttamente al bucket S3, potrebbe aggirare tali autorizzazioni granulari e accedere a più dati di quanto previsto.

Nota importante: Come sopra, le condizioni di Deny si applicano anche all'interno della console AWS, quindi si raccomanda di consentire l'accesso anche a un ruolo di amministratore che un piccolo numero di utenti privilegiati può utilizzare per accedere all'interfaccia utente/API AWS.

8. Configura il logging sull'account di archiviazione

Oltre a imporre restrizioni a livello di rete sull'account di archiviazione sottostante, probabilmente vorrai monitorare se qualcuno sta cercando di aggirarle. Pertanto, Databricks raccomanda:

• Impostare il logging degli accessi ai server S3 su AWS, nonché il monitoraggio e gli avvisi appropriati
• Impostare il logging di diagnostica su Azure, nonché il monitoraggio e gli avvisi appropriati

Conclusione

Il lakehouse ha risolto la maggior parte dei problemi di gestione dei dati che hanno portato ad architetture dati e modelli di accesso frammentati, e ha gravemente limitato il time-to-value che un'organizzazione poteva aspettarsi dai propri dati. Ora che i team di dati sono stati liberati da questi problemi, la condivisione dati aperta ma sicura è diventata la prossima frontiera.

Delta Sharing è il primo protocollo aperto al mondo per la condivisione sicura di dati in tempo reale, internamente e tra organizzazioni, indipendentemente dalla piattaforma su cui risiedono i dati. E utilizzando Delta Sharing in combinazione con le best practice sopra descritte, le organizzazioni possono scambiare dati in modo semplice ma sicuro con i propri utenti, partner e clienti su scala enterprise.

I marketplace di dati esistenti non sono riusciti a massimizzare il valore aziendale per i fornitori e i consumatori di dati, ma con Databricks Marketplace puoi sfruttare la Databricks Lakehouse Platform per raggiungere più clienti, ridurre i costi e fornire più valore attraverso tutti i tuoi prodotti di dati.

Se sei interessato a diventare un Data Provider Partner, ci piacerebbe sentirti!

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