Lo stesso assistente commerciale può rispondere a un responsabile regionale e a un dirigente nazionale senza mostrare loro gli stessi dati aziendali. Il problema è mantenere la differenza quando una richiesta lascia l’interfaccia e diventa SQL, una chiamata al modello o un’azione di un agente.
Databricks ha reso generalmente disponibile l’autorizzazione utenti per Apps il 7 ottobre 2026, dopo oltre 18 mesi di anteprima pubblica. L’autorizzazione on-behalf-of-user, OBO, esegue richieste supportate con l’identità della persona autenticata invece di far passare tutto per il service principal dell’app. I controlli Unity Catalog esistenti possono seguirla nella richiesta. Si riduce la duplicazione delle policy, ma la delega non rende automaticamente sicura un’applicazione.
Un secondo percorso d’identità entra in produzione
Databricks Apps esegue applicazioni dati, dashboard, strumenti operativi e agenti personalizzati su infrastruttura serverless. Ogni app distribuita riceve un service principal dedicato: un’identità non umana con i permessi concessi a quell’istanza. Questa autorizzazione resta utile per configurazione condivisa, telemetria, manutenzione e lavoro automatico.
L’autorizzazione utente aggiunge un percorso, non sostituisce il precedente. Per un’azione supportata avviata da una persona autenticata, Databricks inoltra un token al runtime. L’app chiama un’API approvata con i permessi della persona. Il modello OAuth 2.0 distingue delega utente-macchina e lavoro macchina-macchina.
Sui dati governati, Unity Catalog valuta concessioni, filtri di riga e maschere di colonna esistenti. I permessi del warehouse determinano separatamente se la query può essere eseguita. Il responsabile regionale vede un territorio, quello nazionale di più, tramite lo stesso percorso applicativo. Le richieste successive seguono policy aggiornate del catalogo, non una copia separata nell’app.
Si evita così una divergenza comune. Un’identità condivisa presenta al backend un solo insieme di diritti; gli sviluppatori ricostruiscono i risultati di ogni dipendente con ruoli, mappature, middleware o un altro servizio di policy. Questi controlli possono funzionare, ma cambiare il catalogo senza aggiornare la mappatura locale può esporre informazioni o negare accessi legittimi.
L’anteprima pubblica di Apps OBO iniziò il 26 marzo 2025 e comprendeva tabelle Unity Catalog ed endpoint di model serving. La GA indica preparazione alla produzione entro i limiti documentati, non compatibilità universale con ogni cloud, regione, workspace, profilo di conformità o API downstream. La fonte cita un’estensione prevista a fine settembre 2026 per i workspace con profilo di sicurezza per la conformità; i clienti devono comunque verificare il proprio ambiente.
Un’app può leggere istruzioni comuni e registrare metriche con la propria identità, poi interrogare clienti e vendite come utente attuale. L’autenticazione stabilisce chi è presente, l’autorizzazione cosa può fare a valle. Confonderle significa perdere il contributo principale del rilascio.
Diritti dell’utente e ambiti dell’app devono intersecarsi
Una richiesta dell’app non concede automaticamente una tabella o un warehouse. La persona deve già avere i permessi necessari. Gli sviluppatori dichiarano anche ambiti API che limitano le categorie di operazioni eseguibili in suo nome.
Sono due confini distinti. Un ambito non crea una concessione ai dati, ma limita l’uso di un accesso esistente. Databricks documenta sql:restricted-query per analisi SQL in sola lettura: query limitate come utente corrente, senza ampia amministrazione dei warehouse o attività amministrative estranee.
Questo è particolarmente importante per utenti privilegiati. Un dirigente o amministratore può accedere legittimamente a molti dataset sensibili, ma un’app ristretta non dovrebbe ereditare ogni sua capacità diretta. Gli ambiti riducono le operazioni anche quando i diritti personali sono estesi.
Gli amministratori del workspace stabiliscono un ulteriore tetto agli ambiti aggiungibili dagli sviluppatori. L’allowlist può includere tutte le API supportate, ambiti selezionati o nessuna autorizzazione utente. Secondo l’annuncio, il valore predefinito può comprendere tutte le API. È una scelta di governance, non prova di una base restrittiva.
Esistono eccezioni importanti. Gli amministratori dell’account possono aggiungere ambiti esclusi dall’allowlist del workspace. Rimuovere un ambito prima consentito non ferma immediatamente le app esistenti: possono continuare a funzionare. Non potranno però successivamente avviarsi, essere distribuite o aggiornate finché non rimuovono l’ambito vietato.
Cambiare l’allowlist non equivale quindi a revocare istantaneamente ogni utilizzo in corso. Inventari delle app, responsabili degli ambiti e dipendenze aziendali aiutano a capire la transizione ed evitare blocchi inattesi al successivo rilascio. Una base limitata con eccezioni documentate è più utile dell’idea che la configurazione risolva ogni controllo.
Il token appartiene alla richiesta, non all’intero agente
Il codice deve separare client utente e client applicativo. Le query interattive governate appartengono al percorso utente; configurazione comune e lavoro senza sessione a un percorso applicativo opportunamente limitato. Dipendenze e gestori distinti rendono più visibile l’uso accidentale di credenziali rispetto a un client generico che nasconde il principal.
Se un percorso richiede autorizzazione utente e manca il token inoltrato, deve rifiutare la richiesta. Ripiegare silenziosamente sul service principal può produrre una risposta tecnicamente valida con diritti completamente diversi, più ampi o più ristretti. L’utente potrebbe non vedere il cambio d’identità.
I token inoltrati non devono essere stampati, registrati o conservati. Per agenti personalizzati in Apps, Databricks richiede di inizializzare il client workspace utente dentro il gestore invoke o stream attivo. Il token esiste durante la richiesta, non all’avvio globale dell’applicazione.
Un processo agente serve più persone. L’identità come stato globale rischia di perdere o mescolare il contesto. Un flusso può leggere istruzioni come app, interrogare finanze governate come persona e tornare all’app per la telemetria generale senza trattenere credenziali utente. Ogni passaggio richiede principal e ambito espliciti.
I lavori lunghi o differiti aggiungono un confine. Che una persona avvii un’attività oltre la durata della richiesta non autorizza il salvataggio del token. Il lavoro dell’app richiede un service principal ristretto; quello che necessita del contesto utente deve seguire un altro schema delegato documentato e supportato, non conservare la credenziale.
OBO non attraversa automaticamente ogni integrazione esterna. Il servizio downstream deve supportarlo e può richiedere credenziali, consenso, ambiti e audit separati. I token hanno pubblico e finalità specifici; anche Microsoft avverte di non inoltrare token intermedi a destinatari impropri. È delega limitata, non impersonificazione universale della catena.
Aprire l’applicazione non autorizza a leggerne i dati
Databricks Apps non è un modello di app pubblica anonima. Gli utenti devono autenticarsi e i collaboratori esterni essere inseriti tramite federazione d’identità supportata. Il pubblico naturale è composto da dipendenti e partner con identità gestite, non visitatori anonimi senza limiti.
CAN USE e CAN MANAGE governano esecuzione e amministrazione dell’app. Non concedono accesso a tabelle, record o warehouse sottostanti. Una persona può aprire l’app e ricevere dati negati o limitati. Viceversa, un diritto sulla tabella non permette necessariamente di aprire l’app.
Questi controlli richiedono quindi una revisione distinta dalle concessioni Unity Catalog. Una risposta SQL delegata correttamente può essere combinata nell’interfaccia con un file richiesto accidentalmente come app. La piattaforma non garantisce che ogni sviluppatore assegni l’identità prevista a ogni percorso.
Gli agenti amplificano il rischio interpretando domande aperte, scegliendo strumenti e costruendo query in più passaggi. La prompt injection nei contenuti recuperati può sollecitare divulgazioni o azioni inappropriate. OBO limita i dati ai diritti attuali, ma identità valida e ambito di sola lettura non provano che ogni query serva l’intenzione della persona.
Il consenso non sostituisce la revisione amministrativa. Si possono approvare ambiti senza capire come servizi e risultati saranno combinati. Gestione degli input, vincoli degli strumenti, controlli degli output e monitoraggio restano necessari: query insolite, dinieghi ripetuti, volumi inattesi e cambiamenti di comportamento.
Provare solo con un amministratore nasconde difetti perché incontra pochi dinieghi. Utenti regionali, più ampi e senza accesso alla tabella mostrano esiti diversi; servono verifiche di dati e rifiuti. Databricks consiglia di ripetere dopo modifiche di governance. I log devono distinguere operazioni dell’app e della persona senza memorizzare bearer token o risposte sensibili.
Meno copie delle policy, più dipendenza dalla piattaforma
La delega non corregge concessioni eccessive alla fonte. Gruppi, privilegi di catalogo, accesso ai warehouse, filtri e maschere richiedono manutenzione accurata. Una base tecnica ricercabile può conservare modelli di minaccia, decisioni e prove di revisione con i documenti implementativi, ma documentare non equivale a imporre una policy.
La differenza Databricks è l’integrazione della delega con dati governati, SQL e runtime propri, non l’invenzione del principio. Microsoft documenta già OBO tra API. L’accesso consapevole dell’identità di Google si concentra su app ospitate e contesto; AWS offre componenti autorizzativi per sistemi personalizzati. Ogni approccio distribuisce diversamente l’integrazione tra piattaforma e sviluppatori.
Se i dati sono già governati in Unity Catalog, Databricks può ridurre la traduzione di policy tra sicurezza e framework applicativi. Il prezzo è maggiore dipendenza da ambiti e comportamenti specifici. Le risorse multicloud possono ancora richiedere un altro livello di autorizzazione.
Non esistono benchmark indipendenti sul tempo di sviluppo risparmiato o sulla frequenza di difetti evitati. Pattern produttivi per utenti davvero diversi, flussi misti verificabili, ambiti più fini e consenso chiaro sarebbero prove più solide della sigla GA. Incidenti sui token, proliferazione degli ambiti e bug di fallback indicherebbero il contrario.
Il rilascio riduce una barriera produttiva, lasciando visibile la decisione centrale: quali operazioni appartengono all’app e quali alla persona? Il valore dipende dal mantenere la distinzione quando SQL, agenti, file e servizi esterni diventano un prodotto, non dal trattare un utente autenticato come credenziale illimitata.
Fonti e approfondimenti
Annuncio GA Databricks; modello di autorizzazione Apps; anteprima di marzo 2025; guida OBO Microsoft; approfondimento sulle basi tecniche ricercabili; livelli di autorizzazione Apps; accesso consapevole dell’identità Google.