Ora GA: Creare Databricks Apps che rispettano i permessi con l'autorizzazione per conto dell'utente

Databricks Apps consente agli sviluppatori di creare e distribuire applicazioni di dati e IA direttamente sulla piattaforma Databricks, dalle dashboard interattive e strumenti operativi agli agenti IA personalizzati.

Ora generalmente disponibile, l'autorizzazione on-behalf-of-user (OBO) consente di creare app che offrono esperienze personalizzate e sensibili alle autorizzazioni senza dover reimplementare le regole di governance dei dati nel codice dell'applicazione. Quando un'app chiama le API Databricks supportate con OBO, agisce utilizzando l'identità dell'utente connesso: Unity Catalog applica le autorizzazioni sui dati esistenti di quell'utente, inclusi i filtri di riga e le maschere di colonna, e gli scope delle API limitano le operazioni che l'app può eseguire per conto dell'utente. Le app possono continuare a utilizzare il proprio service principal dedicato per le operazioni di proprietà dell'app, come la lettura della configurazione condivisa o la scrittura delle metriche dell'applicazione.

Ad esempio, un assistente per i sales insight può rispondere alle domande utilizzando solo gli account e i campi a cui un venditore è autorizzato ad accedere, senza concedere all'app ampie funzionalità SQL o di amministrazione del workspace.

Inizia con l'identità che governa ciascuna operazione

Quando progetti un'app, chiediti: Quali autorizzazioni devono governare questa specifica operazione?

Databricks Apps supporta due modelli di autorizzazione complementari: l'autorizzazione dell'app e l'autorizzazione dell'utente. L'autorizzazione dell'app utilizza il service principal dedicato dell'app ed è adatta per le operazioni di proprietà dell'app o per esperienze che dovrebbero restituire lo stesso risultato a ogni utente. L'autorizzazione dell'utente utilizza l'identità dell'utente connesso quando le autorizzazioni di quell'utente devono governare un'operazione. La maggior parte delle app di produzione può utilizzare entrambi i modelli, scegliendo l'identità appropriata per ciascun percorso di richiesta. Vedi Configurare l'autorizzazione in un'app Databricks.

Considera un'app che risponde a domande come: Come stanno andando i miei account in questo trimestre e cosa spiega il cambiamento? L'app deve:

• Interrogare i dati sulle vendite e sui clienti come utente richiedente.
• Rispettare le autorizzazioni di Unity Catalog, inclusi i filtri a livello di riga e le maschere di colonna.
• Restituire analisi in sola lettura.
• Facoltativamente, chiamare un servizio separato per riepilogare i risultati.
• Evitare di modificare i dati o gestire le risorse SQL.

Questo scenario si adatta perfettamente all'autorizzazione dell'utente. L'app passa il token di accesso inoltrato dell'utente richiedente al connettore SQL e Databricks valuta la query utilizzando il warehouse esistente dell'utente e le autorizzazioni di Unity Catalog. Un manager regionale potrebbe vedere solo gli account della propria regione, mentre un responsabile nazionale vede tutte le regioni, senza che l'app debba ricreare tali regole nel codice. Quando gli amministratori aggiornano i criteri di Unity Catalog, le successive richieste dell'app rifletteranno tali modifiche. 

Le autorizzazioni dell'utente determinano quali dati la query può restituire. La decisione di progettazione successiva riguarda ciò che l'app è autorizzata a fare per conto dell'utente con il token utente inoltrato.

Usa lo scope dell'API più limitato possibile per il lavoro da svolgere

L'assistente per i sales insight deve eseguire query di sola lettura. Non ha bisogno di un ampio accesso SQL per gestire le risorse o eseguire altre operazioni SQL. Per questo motivo, dovrebbe richiedere sql:restricted-query anziché lo scope più ampio sql. 

sql:restricted-query consente all'app di eseguire query SQL di sola lettura. Non consente all'app di eseguire altre operazioni SQL. Ciò crea una migliore corrispondenza tra il comportamento del prodotto dell'app e il suo limite di autorizzazione: l'app può leggere i dati controllati per l'analisi, ma non può utilizzare l'identità dell'utente come credenziale operativa SQL generica.

Se l'app richiama anche Genie o Unity Gateway per conto di un utente, richiedi solo gli scope corrispondenti, come genie o ai-gateway. Non richiedere files, model-serving o vector-search a meno che l'app non utilizzi effettivamente tali funzionalità. 

Gli scope rappresentano un limite massimo di funzionalità, non una concessione di accesso ai dati. L'app deve disporre dello scope dell'API appropriato e l'utente deve comunque disporre dell'autorizzazione per accedere alla risorsa di destinazione. Vedi Sicurezza basata sugli scope ed escalation dei privilegi.

Configura l'app con uno scope API esplicito

Configura l'autorizzazione dell'utente nell'interfaccia utente di Databricks o in un Declarative Automation Bundle. 

Per un assistente di analisi in sola lettura, l'app può dichiarare:

Nota: lo scope dell'API fa parte della configurazione di autorizzazione dell'utente dichiarata dall'app. Non concede l'accesso a un SQL warehouse o ai dati di Unity Catalog. L'utente richiedente deve comunque essere autorizzato a utilizzare il SQL warehouse di destinazione e disporre dei privilegi di Unity Catalog richiesti sui dati oggetto della query. 

Al primo accesso a un'app autorizzata dall'utente, Databricks richiede all'utente di acconsentire agli scope dell'API richiesti. 

Passa l'identità dell'utente al connettore SQL

Databricks inoltra il token di accesso dell'utente corrente nell'intestazione HTTP x-forwarded-access-token. L'app deve recuperare tale token per la richiesta che necessita dell'accesso al contesto utente e passarlo al connettore SQL.

L'esempio seguente utilizza Flask e Databricks SQL Connector for Python per rendere esplicito il flusso del token. Se crei l'app con Databricks AppKit, applica lo stesso principio di autorizzazione: utilizza il client del contesto utente o l'identità al momento della richiesta per le operazioni specifiche dell'utente e mantieni le operazioni di proprietà dell'app sull'identità dell'app.

Nota: il token inoltrato ha una durata breve ed è specifico per ogni richiesta. L'app lo legge a ogni richiesta e non lo memorizza mai tra una richiesta e l'altra o in una sessione. 

La differenza importante rispetto all'autorizzazione dell'app è che il connettore riceve il token utente inoltrato tramite access_token. Lo scope API sql:restricted-query limita l'app alla funzionalità SQL di sola lettura di cui ha bisogno, mentre Unity Catalog determina a quali righe e colonne l'utente può effettivamente accedere. Vedi Query con autorizzazione utente.

Consenti agli amministratori del workspace di impostare il limite massimo

Gli sviluppatori specificano gli scope API di cui la loro app ha bisogno. Gli amministratori del workspace possono controllare quali scope API gli sviluppatori di app sono autorizzati ad aggiungere alle app nel workspace.

Questa policy consente ai team di creare esperienze di analytics e AI in sola lettura, impedendo al contempo alle app di richiedere funzionalità più ampie o non correlate. Uno sviluppatore di app non può estendere l'autorizzazione dell'app oltre il limite dello scope API configurato per il workspace.

Questo offre alle organizzazioni due livelli di controllo:

• L'app dichiara gli scope API minimi richiesti per la sua funzionalità.
• L'amministratore del workspace definisce gli scope API massimi disponibili per le app in quel workspace.

Gli amministratori del workspace configurano questa allowlist in Impostazioni > Sviluppo > App. L'impostazione predefinita prevede tutte le API supportate, ma può essere limitata a scope API selezionati o impostata su Nessuno per disabilitare l'autorizzazione utente. Vedi Limitare gli scope di autorizzazione dell'utente.

Gli amministratori dell'account possono aggiungere scope anche quando questi non sono inclusi nell'allowlist del workspace. Se un amministratore rimuove successivamente uno scope consentito, le app già in esecuzione con tale scope possono continuare a funzionare, ma non possono essere avviate, distribuite o aggiornate finché lo scope non consentito non viene rimosso.

Mantieni separate le operazioni di proprietà dell'app e quelle di proprietà dell'utente

Molte app utili necessitano di entrambi i modelli di autorizzazione. L'assistente per i sales insight potrebbe utilizzare:

• Un client con scope app per scrivere metriche dell'applicazione o leggere la configurazione condivisa.
• Un client con scope utente con sql:restricted-query per interrogare i dati per l'utente corrente.
• Uno scope API utente separato se deve richiamare un altro servizio Databricks per conto dell'utente.

È consigliabile rendere esplicito tale limite di identità nel codice dell'applicazione invece di creare un unico client generico e riutilizzarlo ovunque. Dipendenze, nomi e test separati aiutano a evitare che una credenziale dell'app venga utilizzata per un percorso specifico dell'utente o che un token utente venga conservato per attività in background.

Se una richiesta richiede l'autorizzazione dell'utente e il token inoltrato non è presente, applica una modalità fail-closed anziché passare silenziosamente al service principal dell'app. In caso contrario, l'app potrebbe restituire una risposta che sembra valida ma che è stata generata con autorizzazioni diverse. Ecco perché query_as_user nell'esempio precedente inizia con require_user_token invece di gestire l'header mancante inline.

Applica lo stesso pattern agli agenti

Gli agenti personalizzati distribuiti su Databricks Apps possono utilizzare lo stesso modello. Inizializza il client del workspace con scope utente all'interno del gestore invoke o stream al momento della richiesta (e non all'avvio dell'applicazione), poiché il token utente inoltrato è disponibile solo durante una richiesta utente attiva. Utilizza l'autorizzazione dell'app per le risorse condivise e le operazioni in background. Vedi Autenticazione per gli agenti.
 

Proteggi l'implementazione

• Richiedi solo gli scope API minimi necessari.
• Mantieni separati i client di proprietà dell'app e quelli autorizzati dall'utente nel codice, nei test e nel collegamento delle dipendenze.
• Non stampare, registrare nei log o memorizzare in modo persistente i token di accesso inoltrati.
• Limita la gestione delle app a sviluppatori attendibili e richiedi la peer review per le modifiche relative all'autorizzazione.
• Utilizza l'autorizzazione dell'app per le operazioni condivise e in background anziché conservare i token utente.
• Esegui test con utenti che hanno diversi livelli di accesso a Unity Catalog, quindi ripeti tali test dopo le modifiche alle policy.

Inizia subito

L'autorizzazione per conto dell'utente offre personalizzazione e governance tramite lo stesso meccanismo. Le autorizzazioni di Unity Catalog dell'utente decidono a quali dati può accedere un'app, mentre lo scope API corrispondente più restrittivo decide cosa l'app può fare per suo conto. Per iniziare, consulta la nostra documentazione di supporto per ulteriori risorse e best practice.

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