Oltre l'embedding: come rendere sicure le dashboard AI/BI per ogni visualizzatore

La sfida

Integrare una dashboard AI/BI di Databricks in un'applicazione rivolta ai clienti è relativamente semplice: basta abilitare l'incorporamento, generare un token con ambito definito nel backend e visualizzare la dashboard con l'SDK client. La guida fondamentale, Come incorporare le dashboard AI/BI di Databricks nelle applicazioni rivolte ai clienti illustra questo processo dall'inizio alla fine.

La questione più complessa riguarda l'autorizzazione: una volta incorporata una dashboard, quali righe deve visualizzare ciascun utente? Un partner dovrebbe vedere solo i propri dati, mentre un team interno potrebbe vedere solo la propria area geografica. Questa guida mostra come applicare queste regole.

Questo modello di riferimento combina diverse funzionalità di Databricks: __aibi_external_value, i filtri di riga e le maschere di colonna di Unity Catalog e i gruppi sincronizzati da un provider di identità (IdP). Si tratta di un modello di progettazione, non di una singola funzionalità da abilitare.

Un unico set di regole, due percorsi di applicazione

La stessa tabella delle autorizzazioni gestisce due percorsi: le dashboard incorporate a cui si accede tramite l'applicazione e le query SQL dirette eseguite dagli utenti di Databricks.

Uno scenario concreto

Consideriamo un'azienda che utilizza una dashboard condivisa "Attività di contabilità clienti (AR) aperte" per i dati di tre aree geografiche: West, East e Central. La dashboard si rivolge a due tipi di pubblico.

• I partner operativi esterni, come Acme Ops, Bolt Partners e Core Logistics, non dispongono di un account Databricks e accedono alla dashboard tramite un portale white-label. Ciascun partner deve vedere solo la propria area geografica, con gli indirizzi e-mail di contatto mascherati.
• I team interni sono i dipendenti dell'azienda, che effettuano l'accesso a Databricks. Il team Finance ha bisogno di accedere a tutte le aree geografiche, mentre un team operativo locale vede solo la propria. Il loro accesso deriva dai gruppi del provider di identità come Okta o Entra ID, non da elenchi di utenti gestiti manualmente.

Cinque utenti condividono lo stesso set di dati, ma ognuno ne vede una parte diversa: Acme Ops, Bolt Partners, Core Logistics, Finance e un team operativo locale. Gli esempi seguenti si concentrano su Acme e Finance; gli identificatori partner_acme, finance_all e West rappresentano questi esempi. Acme vede West con le e-mail mascherate, mentre Finance vede tutte e tre le aree geografiche per intero, entrambi a partire dalla stessa dashboard pubblicata.

Una tabella, una vista, una dashboard

Le regole di accesso risiedono in un unico punto, anziché essere sparse tra dashboard o query. Creare una dashboard per ciascun cliente genera copie che possono andare fuori sincrono, mentre ripetere i filtri in ogni query aumenta la possibilità di commettere errori.

Il modello è composto da tre oggetti:

• La tabella di base `open_ar_tasks` contiene una riga per ogni attività AR, contrassegnata con un'area geografica e un'e-mail di contatto.

• La tabella delle autorizzazioni è l'unica fonte di verità per l'accesso. Ogni riga identifica l'area geografica a cui un ambito (scope) può accedere e se i valori sensibili devono essere mascherati. La colonna viewer_scope memorizza sia gli ID dei partner esterni, come partner_acme, sia i nomi dei gruppi interni, come finance_all.

• La vista protetta (secured view) unisce la tabella di base a quella delle autorizzazioni, in modo che l'utente veda solo le aree geografiche autorizzate, con le e-mail mascherate quando il flag è impostato.

Nella maggior parte delle distribuzioni, questa tabella viene popolata da un sistema di autorizzazioni a monte o da una mappatura gruppo-area geografica di proprietà dell'applicazione; non viene modificata manualmente per ogni utente.

In questo modo si evita di avere dashboard specifiche per cliente e filtri ripetuti in tutte le query. Le regole risiedono in una tabella che può essere interrogata, controllata e modificata senza dover intervenire sulla dashboard.

Applicata per ciascun utente, la vista protetta restituisce solo i dati a cui l'utente ha diritto di accedere:

Acme (external_value = partner_acme): solo West, e-mail di contatto mascherata.

Finance (external_value = finance_all): tutte e tre le aree geografiche, e-mail di contatto completa.

Da dove proviene __aibi_external_value

Il backend imposta questo valore quando genera il token di incorporamento. Si autentica come service principal e richiede a Databricks un token con ambito definito contenente due valori: external_viewer_id, che identifica l'utente a scopo di controllo, ed external_value, che rappresenta l'ambito dell'utente. Databricks firma il token e l'utente non può modificare il valore incorporato, che viene esposto al codice SQL della dashboard come __aibi_external_value. Poiché contiene le credenziali del service principal, questo backend è un componente lato server attendibile, mai il browser, e tali credenziali vengono conservate in un gestore di segreti (secrets manager) anziché nel controllo del codice sorgente.

Il dettaglio fondamentale è l'identità con cui viene eseguita la query. Le query incorporate vengono eseguite con l'identità di pubblicazione configurata, non con l'identità Databricks dell'utente.

Per l'incorporamento esterno, Databricks consiglia di utilizzare autorizzazioni sui dati individuali e di concedere al service principal il proprio accesso ai dati, in modo che le query vengano eseguite come service principal. (La pubblicazione con autorizzazioni sui dati condivise esegue invece le query con le credenziali del pubblicatore). La vista limita quindi tale accesso per ciascun utente tramite __aibi_external_value. Poiché la query viene eseguita come service principal, is_account_group_member() non può identificare la persona reale che visualizza la dashboard nel percorso di incorporamento.

Il dettaglio importante è che external_value non è limitato a un ID partner. Può essere qualsiasi ambito che il backend inserisce con firma nel token, ad esempio partner_acme per un partner esterno o finance_all per un gruppo interno (il nome del loro gruppo).

Poiché la tabella delle autorizzazioni contiene gli ID dei partner e i nomi dei gruppi nella stessa colonna, un'unica dashboard, un'unica vista e un unico filtro coprono entrambi i casi.

Poiché l'utente non vede né imposta mai il valore firmato, non può modificarlo. Un ambito sconosciuto non corrisponde a nessuna riga, il che garantisce un comportamento di negazione predefinito (default-deny).

La stessa vista e lo stesso filtro (WHERE viewer_scope = __aibi_external_value) servono entrambi i tipi di pubblico. Cambia solo l'origine di tale ambito:

Concedere l'accesso ai gruppi, non alle singole persone

Le organizzazioni in genere gestiscono l'accesso tramite gruppi sincronizzati da un provider di identità. Quando qualcuno entra a far parte del gruppo Finance in Okta, il suo accesso viene mappato automaticamente su finance_all, senza dover modificare alcuna tabella di dati. In questo esempio, finance_all è mappato su tutte le aree geografiche e ops_west è mappato sull'area geografica West.

In che modo l'applicazione apprende a quali gruppi appartiene il visualizzatore? Non può fare affidamento su SQL durante l'incorporamento, perché la query viene eseguita come entità servizio e is_account_group_member() verificherebbe l'identità errata. L'applicazione deve risolvere i gruppi del visualizzatore nel backend, che può vedere il visualizzatore, prima di generare il token.

Un'opzione consiste nell'eseguire l'applicazione su Databricks Apps con l'autorizzazione utente abilitata.

Per un utente interno che ha effettuato l'accesso, la piattaforma inoltra il contesto di identità attendibile al backend, inclusi l'indirizzo e-mail del visualizzatore e un token on-behalf-of (OBO). Il backend utilizza tale token per chiamare SCIM /Me come visualizzatore e leggerne i gruppi.

Questo approccio non richiede diritti di amministratore sull'entità servizio, poiché l'utente sta leggendo il proprio record. Richiede ambiti di autorizzazione utente e Apps OBO è ancora in fase di sviluppo, quindi convalidalo rispetto alla distribuzione di destinazione prima di fare affidamento su di esso.

Se non viene trovato alcun gruppo autorizzato, blocca l'accesso per sicurezza e rifiuta di generare un token anziché ripiegare su un'identità più ampia come l'e-mail non elaborata.

Se un visualizzatore appartiene a più gruppi autorizzati, risolvi il risultato in modo deterministico. Definisci un ordine di precedenza o mappa diversi gruppi a un unico ambito canonico prima di generare il token, in modo che lo stesso visualizzatore riceva sempre un accesso coerente.

I partner esterni sono più semplici. Senza un'identità Databricks, il loro ambito è un ID partner fisso assegnato al momento dell'accesso. Stesso token, stesso filtro, nessuna ricerca.

Una limitazione da considerare nella progettazione: un token firmato contiene un singolo external_value. Se un visualizzatore appartiene a diversi gruppi con autorizzazioni differenti, un token può comunque rappresentare un solo ambito. Per il caso comune di un singolo ruolo per persona, questo va bene.

Per una vera unione multi-gruppo, utilizza un gruppo con accesso completo o il percorso SQL diretto descritto di seguito, in cui un filtro di riga può applicare l'operatore OR a tutti i gruppi. Un ambito composito (come JSON) può essere inserito in external_value, ma in tal caso l'analisi e la corrispondenza si spostano nel codice SQL del dataset e rimangono vincolate al limite di payload di 1 KB.

Rafforzare le garanzie

Il filtraggio delle righe fornisce il comportamento di base: ogni visualizzatore vede solo le proprie righe. Tre livelli aggiuntivi rafforzano i controlli, e tutti e tre leggono dalla stessa tabella delle autorizzazioni.

Mascherare le colonne sensibili per visualizzatore

La sicurezza a livello di riga determina a quali righe può accedere un visualizzatore. Il mascheramento determina quali colonne può vedere, poiché i partner esterni di solito non hanno bisogno dello stesso livello di dettaglio dei team interni.

Il flag mask_pii, impostato su true per i partner e su false per i gruppi interni, guida la logica di mascheramento nella vista protetta (l'espressione CASE nel codice SQL sopra). La stessa dashboard può mostrare a un visualizzatore interno l'e-mail completa, mostrando invece a un partner un valore mascherato come ****@example.com. Quando le regole di mascheramento interessano molte tabelle e diventano complesse, le maschere di colonna di Unity Catalog e il controllo dell'accesso basato sugli attributi (ABAC) rappresentano la soluzione migliore a lungo termine; in questo caso, la vista mantiene l'esempio autonomo.

Negazione predefinita e dimostrazione

Un ambito sconosciuto non dovrebbe restituire alcuna riga della dashboard e non dovrebbe rivelare nulla sulla struttura dei dati sottostante: nessun errore che alluda alla struttura, nessun dato parziale, solo un risultato vuoto. Interrompere il processo in anticipo è ancora più pulito: prima che il backend generi un token, controlla la tabella delle autorizzazioni e rifiuta qualsiasi ambito che abbia diritto a zero righe. Altrettanto importante, l'ambito deriva dal visualizzatore autenticato, mai da un parametro fornito dal client, in modo che un visualizzatore non possa richiedere l'ambito di un altro tenant.

Il controllo in fase di emissione del token impedisce a un visualizzatore non autorizzato di ricevere un token, il che è preferibile rispetto all'affidarsi al filtro SQL come unica protezione. La registrazione sia dell'emissione corretta dei token sia delle richieste negate rende verificabili le decisioni di autorizzazione: il visualizzatore negato semplicemente non compare mai e, anche se una richiesta dovesse sfuggire, un ambito sconosciuto non restituirebbe comunque alcuna riga della dashboard. La registrazione di external_viewer_id e del relativo ambito in tali log consente di ricondurre ogni decisione di autorizzazione a un cliente o utente reale durante un audit.

Proteggere il percorso SQL diretto

I controlli di incorporamento proteggono il percorso dell'applicazione. Un utente Databricks che interroga direttamente la tabella di base rappresenta una minaccia separata. Aggiungi un filtro di riga di Unity Catalog alla tabella di base, associato all'identità e ai gruppi dell'utente che esegue la query. In questo percorso di query diretta, is_account_group_member() valuta l'utente effettivo e può combinare tutti i suoi gruppi autorizzati. L'eccezione del publisher nella funzione seguente (current_user() uguale all'identità di pubblicazione) è una concessione di emergenza deliberata per l'identità che pubblica o aggiorna la dashboard, non un bypass generale per l'operatore. È opzionale e ad alto rischio, quindi includila solo se giustificata e approvala per ogni distribuzione.

Una maschera di colonna per i campi sensibili funziona allo stesso modo. Questi controlli di Unity Catalog sono separati dal percorso di incorporamento: i visualizzatori incorporati sono limitati tramite __aibi_external_value e la vista delle autorizzazioni, mentre le query dirette dell'area di lavoro sono protette dal filtro di riga di Unity Catalog, che valuta l'identità e i gruppi del chiamante. Entrambi i punti di applicazione utilizzano la stessa tabella delle autorizzazioni.

Prima di procedere alla creazione

Informazioni sulla "multi-tenancy". Si tratta di una multi-tenancy logica e condivisa: i partner esterni sono isolati gli uni dagli altri, mentre i dipendenti interni ricevono un accesso basato sui gruppi (basato sui ruoli) all'interno del tenant dell'azienda. Tutti i dati rimangono in tabelle condivise; il token, il filtro della vista e la tabella delle autorizzazioni impongono la separazione. Il filtro di riga SQL diretto estende la stessa garanzia all'esterno dell'app.

Quando utilizzare questo pattern. Utilizza questo pattern quando i partner esterni senza account Databricks e i dipendenti interni devono condividere la stessa dashboard. Se ogni visualizzatore è un utente Databricks interno, l'incorporamento di base con la sicurezza a livello di riga e colonna di Unity Catalog potrebbe essere sufficiente.

Vincoli pratici e aspetti da considerare. Verifica i seguenti limiti del prodotto e dettagli operativi rispetto alla documentazione corrente prima della pubblicazione:

• I token hanno una durata breve (1 ora), quindi l'app deve aggiornarli, specialmente se una scheda viene lasciata aperta. L'SDK client semplifica questo processo: una callback getNewToken esegue nuovamente il recupero dall'endpoint /api/token quando il token è prossimo alla scadenza.
• Mantieni la combinazione di `external_viewer_id` + `external_value` inferiore a 1 KB: utilizza identificatori compatti, non blob JSON o e-mail lunghe.
• Limite di frequenza di 20 caricamenti di dashboard al secondo per area di lavoro per l'incorporamento esterno. Un aspetto importante da conoscere per un portale B2B di grandi dimensioni.
• Utilizza un `external_viewer_id` non PII. Poiché viene registrato nei log di audit, un ID utente o cliente stabile è preferibile a un nome completo o a un'e-mail non elaborata.
• I download sono abilitati per impostazione predefinita. I visualizzatori incorporati possono esportare CSV, TSV, Excel e PNG, a meno che un amministratore dell'area di lavoro non disabiliti i download. Verifica che i risultati esportati corrispondano ai dati con restrizioni per il visualizzatore previsti.
• Configura i gruppi a livello di account per il percorso SQL diretto. I filtri di riga e le maschere di UC valutano is_account_group_member() rispetto ai gruppi a livello di account, non a quelli locali dell'area di lavoro. Il percorso di incorporamento non chiama mai questa funzione.
• Presta attenzione alle tabelle di autorizzazioni di grandi dimensioni. In caso di migliaia di ambiti o gerarchie profonde, mantieni semplici le espressioni di join e maschera e affidati ad ABAC quando le regole diventano complesse.

Punti chiave

• Mantieni le regole di accesso in un'unica tabella delle autorizzazioni e utilizzala sia per i dashboard incorporati sia per la protezione SQL diretta.
• Firma un ambito di visualizzatore o gruppo in __aibi_external_value; non fare affidamento su filtri modificabili dall'utente.
• Utilizza il rifiuto predefinito, il mascheramento e i filtri di riga di Unity Catalog come controlli a più livelli.
• L'incorporamento è solo il primo passo; la progettazione e la convalida dei controlli di accesso rappresentano il lavoro cruciale.

Invito all'azione

Inizia con la guida fondamentale, Come incorporare i dashboard Databricks AI/BI nelle applicazioni rivolte ai clienti, quindi applica i pattern di autorizzazione, mascheramento e rifiuto predefinito descritti in questo post. Per i controlli di governance sottostanti, consulta la documentazione sull'incorporamento di AI/BI, oltre ai filtri di riga e alle maschere di colonna di Unity Catalog e alla guida ad ABAC.

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