Databricks Apps-Benutzerautorisierung ist jetzt allgemein verfügbar, doch Identitätsgrenzen bleiben wichtig
Databricks hat die Benutzerautorisierung für Databricks Apps am 7. Oktober nach mehr als 18 Monaten öffentlicher Vorschau allgemein verfügbar gemacht. Die Funktion ermöglicht es einer Anwendung, unterstützte Plattformdienste mit der Identität des angemeldeten Benutzers aufzurufen. Das verändert eine zentrale Sicherheitsentscheidung für Datenanwendungen und KI-Agenten: Wessen Berechtigungen steuern jede Anfrage?
Bisher verließen sich Entwickler häufig auf den Service Principal einer Anwendung, eine nichtmenschliche Identität, die einer einzelnen App-Instanz zugewiesen ist. Jeder Benutzer konnte über diese gemeinsame Identität Ergebnisse erhalten, sofern Entwickler nicht Zugriffsregeln auf Benutzerebene innerhalb der Anwendung nachbildeten. Das neue Modell ermöglicht es, dass bestehende Unity Catalog-Richtlinien einem Benutzer in eine App-Anfrage folgen.
Dieses Versprechen bringt eine wichtige Einschränkung mit sich. On-Behalf-Of-User-Autorisierung, kurz OBO, macht eine Anwendung nicht automatisch sicher. Entwickler müssen benutzergesteuerte Aktionen von Hintergrundaufgaben trennen, eng gefasste Scopes anfordern, weitergeleitete Tokens schützen und Anfragen ablehnen, wenn die erwartete Identität fehlt.
Die Ankündigung positioniert Databricks in einem breiteren Wettbewerb zwischen plattformverwalteter Autorisierung und anwendungsverwalteter Berechtigungslogik. Microsoft unterstützt delegierte Identität über seinen eigenen OBO-Flow, während andere Cloud-Plattformen getrennte Identitäts- und Richtlinienkomponenten anbieten. Databricks verknüpft dieses Muster unmittelbar mit kontrollierten Unternehmensdaten, SQL Warehouses, Agenten und Anwendungen, die auf seiner Plattform laufen.
Die Benutzerautorisierung für Databricks Apps verändert, wer jede Anfrage steuert
Die GA-Version bietet Entwicklern einen unterstützten Weg, die bestehenden Datenberechtigungen eines Benutzers während einer gesamten Anwendungsanfrage zu erhalten.
Databricks Apps hostet Datenanwendungen, operative Werkzeuge, Dashboards und individuelle Agenten auf serverloser Infrastruktur. Jede bereitgestellte App erhält einen dedizierten Service Principal, der auf Ressourcen zugreifen kann, die dieser Anwendung gewährt wurden. Diese App-Autorisierung bleibt verfügbar und eignet sich weiterhin für gemeinsame oder automatisierte Vorgänge.
Die Benutzerautorisierung fügt einen zweiten Identitätspfad hinzu. Wenn eine angemeldete Person eine unterstützte Aktion auslöst, leitet Databricks ein Zugriffstoken an die Anwendungs-Laufzeit weiter. Die App kann anschließend eine zugelassene Databricks API unter der Identität und mit den Berechtigungen dieser Person aufrufen.
Das Autorisierungsmodell der Plattform verwendet OAuth 2.0, das Standardprotokoll für delegierten Zugriff. Es unterscheidet zwischen Benutzer-zu-Maschine-Autorisierung und Maschine-zu-Maschine-Autorisierung. Erstere repräsentiert einen interaktiven Benutzer, während Letztere eine Anwendung oder automatisierte Arbeitslast repräsentiert.
Unity Catalog bewertet dann die bestehenden Berechtigungen des Benutzers, wenn die App auf kontrollierte Daten zugreift. Zeilenfilter können einschränken, welche Datensätze angezeigt werden, während Spaltenmasken sensible Felder verbergen oder transformieren können. Warehouse-Berechtigungen bestimmen außerdem, ob der Benutzer die angeforderte Abfrage ausführen kann.
Das Ergebnis hängt von der Person ab, die die Anfrage stellt. Ein regionaler Vertriebsleiter könnte Daten für ein Gebiet erhalten, während eine landesweite Führungskraft alle Regionen sieht. Beide Personen können dieselbe Anwendung und denselben Anfragepfad verwenden, ohne identische Zugriffsrechte zu erhalten.
Dieses Verhalten ist wichtig, weil die App keine separate Kopie jeder Governance-Regel benötigt. Wenn ein Administrator eine Unity Catalog-Richtlinie ändert, werden spätere App-Anfragen anhand der aktualisierten Richtlinie bewertet. Entwickler vermeiden so die Pflege eines parallelen Autorisierungssystems, das sich von den Kontrollen der Plattform entfernen kann.
Databricks führte die OBO-Autorisierung für Apps erstmals am 26. März 2025 in öffentlicher Vorschau ein. Die Vorschauversion umfasste Ressourcen wie Unity Catalog-Tabellen und Model-Serving-Endpunkte. Die allgemeine Verfügbarkeit signalisiert, dass Databricks dieses Muster nun innerhalb seiner dokumentierten Grenzen als bereit für den Produktionseinsatz betrachtet.
GA beseitigt die App-Autorisierung nicht. Databricks stellt die beiden Modelle ausdrücklich als ergänzend dar. Eine Anwendung kann ihre eigene Identität für gemeinsame Konfiguration, Telemetrie oder routinemäßige Wartung verwenden und anschließend die Identität der aktuellen Person für eine kontrollierte Abfrage einsetzen.
Betrachten wir einen Vertriebsanalyse-Assistenten, der Fragen zur Account-Performance beantwortet. Seine App-Identität könnte gemeinsame Konfiguration lesen und Betriebsmetriken erfassen. Sein Benutzeridentitätspfad würde Kunden- und Vertriebsdaten abfragen, die dem anfragenden Mitarbeiter zur Verfügung stehen.
Diese Aufteilung ist die Grundlage der Veröffentlichung. Die App besitzt weiterhin eine Identität, aber diese Identität muss nicht länger zum universellen Gateway für jede interaktive Aktion werden. Entwickler können entscheiden, welcher Principal jede Operation steuert.
Die Änderung betrifft daher mehr als nur die Anmeldung. Authentifizierung stellt fest, wer anwesend ist, während Autorisierung bestimmt, was diese Identität tun darf. Die Benutzerautorisierung für Databricks Apps überträgt die zweite Entscheidung in nachgelagerte Daten- und Dienstaufrufe.
Der eigentliche Druck liegt auf anwendungsverwalteter Zugriffskontrolle
Databricks stellt die Praxis infrage, Unternehmensdatenberechtigungen in jeder Anwendung neu aufzubauen.
Eine App, die ausschließlich einen gemeinsamen Service Principal verwendet, sieht häufig einen einheitlichen Berechtigungssatz. Entwickler müssen dann entscheiden, welche Ergebnisse jeder Mitarbeiter erhalten darf. Das erfordert in der Regel individuelle Rollen, Richtlinienzuordnungen, Filterlogik oder einen weiteren Autorisierungsdienst.
Diese Kontrollen können funktionieren, führen jedoch eine zweite Quelle der Wahrheit ein. Ein Governance-Team kann eine Unity Catalog-Berechtigung aktualisieren, während die lokale Rollenzuordnung einer Anwendung unverändert bleibt. Die daraus resultierende Abweichung kann Informationen offenlegen oder rechtmäßigen Zugriff verweigern.
Die Benutzerautorisierung reduziert diese Duplizierung für unterstützte Databricks-Ressourcen. Die etablierten Berechtigungen der anfragenden Person werden Teil des Ausführungskontexts. Anwendungscode kann sich auf die angeforderte Aufgabe konzentrieren, während die Plattform den kontrollierten Zugriff bewertet.
Das gewinnt insbesondere für KI-Agenten an Bedeutung. Ein herkömmliches Dashboard stellt vordefinierte Ansichten und Abfragen bereit. Ein Agent kann offene Sprache interpretieren, Werkzeuge auswählen, Abfragen zusammenstellen und Informationen über mehrere Schritte hinweg abrufen.
Diese Flexibilität erweitert die Zahl der Wege, über die geschützte Daten erreichbar werden können. Ein Entwickler kann nicht zuverlässig jede Frage vorhersehen, die ein Mitarbeiter stellen könnte. Die Erhaltung des Autorisierungskontexts des Mitarbeiters gibt der nachgelagerten Plattform eine weitere Durchsetzungsgrenze.
Der Druck zeigt sich besonders deutlich, wenn Unternehmen Prototypen in die Produktion überführen. Frühe Demonstrationen laufen oft unter einer Entwicklerberechtigung oder einem weitreichend berechtigten Service Account. Diese Abkürzung lässt sich nur schwer rechtfertigen, wenn eine App Mitarbeiter mit unterschiedlichen Rollen, Gebieten und Vertraulichkeitsanforderungen erreicht.
Eine einzelne Anwendung kann Vertrieb, Finanzen, Betrieb und Führungskräfte bedienen. Diese Gruppen sollten nicht automatisch dieselbe Sicht auf Kundendetails, Prognosen oder Mitarbeiterinformationen erhalten. Zentrale Richtlinien werden wertvoller, wenn das Publikum wächst.
Databricks reduziert zudem die Reibung zwischen Governance-Administratoren und Anwendungsteams. Sicherheitsteams können Datenprivilegien weiterhin über Unity Catalog verwalten. Entwickler müssen nicht jede Richtlinie in frameworkspezifische Middleware übersetzen.
Das beseitigt die Entwicklungsarbeit nicht. Teams müssen weiterhin entscheiden, ob eine bestimmte Operation dem Benutzer oder der App zuzuordnen ist. Sie müssen außerdem verstehen, welche Databricks APIs OBO unterstützen und welche Autorisierungs-Scopes jede Aktion erfordert.
Den alternativen Plattformen fehlt delegierte Identität nicht. Der OBO-Flow von Microsoft übergibt die Identität und delegierten Berechtigungen eines Benutzers von einer vorgeschalteten API an eine nachgelagerte API. Google Cloud bietet identitätsbewussten Anwendungszugriff, während AWS feingranulare Autorisierungskomponenten für individuelle Anwendungen bereitstellt.
Databricks differenziert sich durch die Integration in seine Daten-Governance-Umgebung. Die Autorisierungsentscheidung ist mit Unity Catalog-Berechtigungen, SQL-Zugriff und unterstützten Plattformdiensten verbunden. Das kann den Integrationsaufwand für Anwendungen verringern, deren Daten bereits innerhalb von Databricks liegen.
Der Kompromiss ist eine stärkere Plattformabhängigkeit. Anwendungen, die auf Unity Catalog-Regeln und Databricks-spezifischen Scopes basieren, übernehmen nützliche Kontrollen, werden aber auch eng an das Identitätsmodell einer Plattform gebunden. Multicloud-Teams benötigen möglicherweise weiterhin eine weitere Autorisierungsebene für Ressourcen außerhalb von Databricks.
Für Unternehmenskäufer lautet die Frage daher nicht, ob delegierte Identität anderswo existiert. Entscheidend ist, ob Databricks die Entwicklung kontrollierter Anwendungen ausreichend vereinfachen kann, um mehr Daten- und KI-Arbeitslasten auf seiner Plattform zu halten.
Wie On-Behalf-Of-User-Autorisierung zwei Berechtigungsgrenzen schafft
Eine OBO-Anfrage ist nur innerhalb sowohl der Berechtigungen des Benutzers als auch des genehmigten API-Scopes der Anwendung erfolgreich.
Die erste Grenze betrifft Daten und Ressourcen. Ein Benutzer kann nicht auf eine Unity Catalog-Tabelle, ein SQL Warehouse oder einen unterstützten Dienst zugreifen, nur weil eine App dies anfordert. Die Person muss bereits über die erforderlichen Berechtigungen verfügen.
Die zweite Grenze betrifft die Anwendung. Entwickler deklarieren API-Scopes, die die Klassen von Operationen definieren, die eine App für einen Benutzer ausführen darf. Ein Scope gewährt der Person keinen neuen Datenzugriff, begrenzt jedoch, wie die Anwendung bestehenden Zugriff ausüben kann.
Für schreibgeschützte SQL-Analysen dokumentiert Databricks einen sql:restricted-query-Scope. Die App kann eingeschränkte Abfragen als aktueller Benutzer übermitteln, ohne weitreichende Befugnisse zur Verwaltung von Warehouses oder zur Durchführung nicht zusammenhängender administrativer Arbeiten zu erhalten.
Diese sich überschneidenden Grenzen unterstützen das Prinzip der geringsten Berechtigung, also die Praxis, nur den Zugriff zu gewähren, der für eine Aufgabe erforderlich ist. Ein hochprivilegierter Benutzer könnte direkt auf viele Datensätze zugreifen. Eine eng abgegrenzte App sollte dennoch nicht jede Berechtigung ausüben können, über die dieser Benutzer verfügt.
Workspace-Administratoren kontrollieren eine zusätzliche Obergrenze. Sie können bestimmen, welche Benutzerautorisierungs-Scopes Entwickler zu Apps im Workspace hinzufügen dürfen. Die Allowlist kann alle unterstützten APIs, ausgewählte Scopes oder keine Benutzerautorisierung umfassen.
Diese Struktur teilt die Verantwortung auf. Der Entwickler fordert die minimalen Fähigkeiten an, die das Produkt benötigt. Der Administrator entscheidet, welche Fähigkeiten Anwendungsentwickler innerhalb des Workspace anfordern dürfen.
Ein Administrator kann sich jedoch nicht allein auf die Konfiguration verlassen. Databricks zufolge können Account-Administratoren Scopes hinzufügen, selbst wenn eine Workspace-Allowlist sie ausschließt. Bestehende Apps können auch weiterlaufen, nachdem ein erlaubter Scope entfernt wurde.
Laut der Ankündigung kann eine betroffene App anschließend nicht starten, bereitgestellt oder aktualisiert werden, bis der nicht erlaubte Scope entfernt wurde. Dieses Verhalten vermeidet einen unmittelbaren Ausfall, schafft jedoch einen Zeitraum, in dem die aktuelle Ausführung und die aktuelle Richtlinie nicht vollständig übereinstimmen.
Teams sollten Scope-Änderungen daher als kontrollierte betriebliche Ereignisse behandeln. Administratoren benötigen ein Inventar bereitgestellter Apps, angeforderter Scopes, verantwortlicher Eigentümer und geschäftlicher Abhängigkeiten. Das Entfernen einer Fähigkeit ohne diesen Kontext kann die Behebung verzögern oder eine Anwendung bei ihrer nächsten Bereitstellung blockieren.
Der Anwendungscode muss die beiden Identitäten ebenfalls getrennt halten. Ein benutzerspezifischer Client sollte kontrollierte interaktive Operationen verarbeiten. Ein app-spezifischer Client sollte gemeinsame Konfiguration, Metriken und Arbeiten verarbeiten, die ohne Benutzersitzung fortgeführt werden müssen.
Dies ist mehr als eine Frage der Benennung. Ein generischer Client kann verschleiern, welche Identität einen sensiblen Pfad ausführt. Getrennte Abhängigkeiten, Tests und Request-Handler erleichtern es, unbeabsichtigte Verwendung von Anmeldedaten zu erkennen.
Die strengste Regel betrifft fehlende Benutzertokens. Wenn eine Route eine Benutzerautorisierung erfordert, aber kein weitergeleitetes Token vorhanden ist, sollte die Anwendung sicher fehlschlagen. Sie sollte die Anfrage ablehnen, statt stillschweigend zu ihrem Service Principal zu wechseln.
Ein Fallback könnte unter völlig anderen Berechtigungen eine technisch gültige Antwort liefern. Der Benutzer hätte kaum Anlass zu vermuten, dass die App auf umfassendere oder eingeschränktere Informationen als erwartet zugegriffen hat. Das macht stille Identitätswechsel besonders gefährlich.
Das weitergeleitete Token sollte nur für die aktive Anfrage existieren. Databricks rät Entwicklern, es niemals auszugeben, zu protokollieren oder dauerhaft zu speichern. Hintergrundjobs sollten die App-Autorisierung nutzen, statt das Token eines Benutzers nach Ende der interaktiven Sitzung aufzubewahren.
Für Teams, die interne KI-Tools entwickeln, gehört diese Identitätstrennung neben andere technische Kontrollmechanismen. Eine durchsuchbare technische Wissensdatenbank kann Autorisierungsentscheidungen, Bedrohungsmodelle und Prüfnachweise neben der Implementierungsdokumentation bewahren.
KI-Agenten erschweren die Wahrung der Identitätsgrenze
Agenten profitieren von benutzerspezifischen Berechtigungen, doch ihr mehrstufiges Verhalten macht Identitätsfehler folgenreicher.
Databricks erklärt, dass über Apps bereitgestellte benutzerdefinierte Agenten dasselbe Autorisierungsmodell nutzen können. Der workspacebezogene Client mit Benutzerkontext muss innerhalb des aktiven invoke- oder stream-Handlers initialisiert werden. Das weitergeleitete Token ist nur verfügbar, während die Anfrage ausgeführt wird.
Diese zeitliche Einschränkung verhindert, dass Entwickler die Benutzeridentität als globalen Anwendungsstatus behandeln. Ein Agentenprozess kann viele Personen bedienen, und der Anwendungsstart ist keinem einzelnen Benutzer zugeordnet. Wenn ein Client mit Benutzerkontext zu früh erstellt wird, besteht das Risiko, dass Anfragekontext fehlt oder vermischt wird.
Agenten-Workflows kombinieren zudem unterschiedliche Arten von Arbeit. Ein Schritt könnte über die App-Identität gemeinsame Anweisungen abrufen. Ein anderer könnte regulierte Finanzdaten im Namen des Benutzers abfragen. Ein dritter könnte allgemeine Telemetriedaten schreiben, ohne die Anmeldedaten des Benutzers aufzubewahren.
Jeder Übergang schafft eine Autorisierungsentscheidung. Entwickler müssen für jeden Tool-Aufruf Principal, Geltungsbereich, Ressource und erwartetes Fehlermuster identifizieren. Ein einzelner generischer Agentenclient kann diese Unterschiede verwischen.
Die Herausforderung wächst, wenn ein Agent einen anderen Dienst aufruft. OBO kann den Benutzerkontext nur dort bewahren, wo die nachgelagerte Integration dieses Modell unterstützt. Externe APIs können separate Anmeldedaten, Einwilligungen, Scopes und Audit-Kontrollen erfordern.
Der Agent darf nicht annehmen, dass die Autorisierung automatisch über die gesamte Tool-Kette hinweg übertragen wird. Ein Token wird für eine bestimmte Zielgruppe und einen bestimmten Zweck ausgestellt. Die OBO-Leitlinien von Microsoft warnen ebenfalls davor, Tokens der mittleren Schicht an unbeabsichtigte Empfänger weiterzugeben.
Das bedeutet, dass die Benutzerautorisierung nicht als uneingeschränkte Identitätsübernahme beschrieben werden sollte. Die Anwendung handelt nur innerhalb konfigurierter Scopes und unterstützter Anfragepfade für den Benutzer. Diese Formulierung ist wichtig, weil „im Namen des Benutzers handeln“ sonst uneingeschränkten Zugriff suggerieren kann.
Prompt Injection schafft einen weiteren Grund zur Vorsicht. Ein Angreifer könnte Anweisungen in Inhalte einbetten, die ein Agent abruft, und ihn dazu bewegen, Tools aufzurufen oder Informationen offenzulegen. OBO begrenzt die zugänglichen Daten auf den aktuellen Benutzer, entscheidet jedoch nicht, ob eine angeforderte Aktion sinnvoll ist.
Auch die eigenen Berechtigungen des Benutzers können umfangreich sein. Eine Führungskraft, ein Administrator oder ein Analyst könnte Zugriff auf sensible Datensätze über zahlreiche Geschäftsbereiche hinweg besitzen. Eine kompromittierte App, die die gültige Identität dieser Person verwendet, stellt weiterhin ein erhebliches Risiko dar.
Scopes bilden in dieser Situation eine wichtige zweite Grenze. Ein schreibgeschützter Abfrage-Scope kann nicht zusammenhängende Administration verhindern, doch er kann nicht entscheiden, ob jede erlaubte Abfrage der Absicht des Benutzers entspricht. Anwendungen benötigen weiterhin Eingabeverarbeitung, Tool-Beschränkungen, Ausgabekontrollen und Überwachung.
Auch die Einwilligung verdient eine genaue Prüfung. Benutzer können angeforderte Berechtigungen genehmigen, ohne zu verstehen, wie ein Agent Dienste kombiniert oder Ergebnisse verarbeitet. Klare Scope-Namen helfen, doch Einwilligung ist kein Ersatz für administrative Prüfung und eingeschränktes Anwendungsverhalten.
Auditierbarkeit wird unverzichtbar. Sicherheitsteams müssen zwischen Aktionen unterscheiden können, die durch die App-Identität ausgeführt werden, und Aktionen, die für eine Person ausgeführt werden. Protokolle sollten den relevanten Principal und die Operation identifizieren, ohne Bearer-Tokens oder sensible Antwortinhalte aufzuzeichnen.
Tests müssen Benutzer mit unterschiedlichen Berechtigungen einbeziehen. Ein Test, der nur mit einem Administratorkonto ausgeführt wird, kann Fehler verbergen, da dieses Konto nur selten auf Zugriffsverweigerungen stößt. Databricks empfiehlt, Tests nach Änderungen der Governance-Richtlinien zu wiederholen.
Nützliche Testfälle umfassen einen Benutzer mit regionalem Zugriff, einen Benutzer mit weiterreichendem Zugriff und eine Person, die überhaupt keinen Zugriff auf die abgefragte Tabelle hat. Teams sollten sowohl zurückgegebene Daten als auch das Ablehnungsverhalten prüfen. Sie sollten zudem bestätigen, dass fehlende Tokens niemals einen Fallback auf die App-Identität auslösen.
Die zentrale Einschränkung ist daher klar. Die Benutzerautorisierung von Databricks Apps kann bestehende Plattformberechtigungen durchsetzen, aber keine zu weit gefassten Zuweisungen korrigieren. Unternehmen müssen weiterhin präzise Gruppen, Catalog-Berechtigungen, Warehouse-Zugriff, Zeilenfilter und Spaltenmasken pflegen.
Das Sicherheitsversprechen hängt von operativer Disziplin ab
Die größte Stärke des Designs liegt in seinem mehrschichtigen Kontrollmodell, während die größte Schwäche bei Implementierung und Governance rund um dieses Modell bleibt.
Databricks kann die passende Identität weiterleiten und deklarierte Scopes durchsetzen. Es kann jedoch nicht sicherstellen, dass jedes Entwicklungsteam jeder Code-Pfad die richtige Identität zuordnet. Diese Entscheidung bleibt Teil der Anwendungsarchitektur.
Ein Team könnte OBO korrekt für eine SQL-Abfrage verwenden, aber bei einer zugehörigen Dateianfrage versehentlich die App-Identität einsetzen. Die Benutzeroberfläche könnte beide Antworten kombinieren, ohne die unterschiedlichen Autorisierungskontexte offenzulegen.
Auch die Hintergrundverarbeitung stellt eine weitere Grenze dar. Ein Benutzer könnte eine langlaufende Aufgabe starten, die nach Ende der Anfrage fortgesetzt wird. Da das weitergeleitete Token zu einer aktiven Anfrage gehört, können Entwickler es nicht einfach für die spätere Ausführung aufbewahren.
Das sicherere Design besteht darin, festzustellen, ob verzögerte Arbeit zur Anwendung gehört oder ein anderes unterstütztes delegiertes Muster erfordert. Gehört sie zur App, benötigt der Service Principal sorgfältig begrenzte Berechtigungen. Erfordert sie Benutzerkontext, müssen Entwickler dokumentiertes Plattformverhalten befolgen, statt das Token aufzubewahren.
Auch die Verfügbarkeit über verschiedene Umgebungen hinweg muss bestätigt werden. Die Databricks-Dokumentation ändert sich, wenn Dienste und Compliance-Konfigurationen erweitert werden. Teams sollten Cloud-, Regions-, Workspace- und Sicherheitsprofil-Unterstützung prüfen, bevor sie GA als universelle Verfügbarkeit behandeln.
Apps selbst können keine anonymen öffentlichen Anwendungen sein. Databricks zufolge müssen sich Benutzer authentifizieren, und externe Mitwirkende benötigen ein Onboarding über unterstützte Identitätsföderation. Damit eignet sich das Modell besonders für Belegschafts- und Partnerszenarien mit verwalteten Identitäten.
Die Trennung zwischen App-Berechtigungen und Datenautorisierung kann Prüfer verwirren. CAN USE und CAN MANAGE bestimmen, wer eine App ausführen oder verwalten darf. Sie bestimmen nicht, auf welche Tabellen oder Datensätze eine Person über sie zugreifen kann.
Eine Person könnte die Berechtigung besitzen, eine App zu nutzen, aber nicht die Berechtigung, deren zugrunde liegende Daten abzufragen. Diese Anfrage sollte fehlschlagen oder nur eingeschränkte Ergebnisse zurückgeben. Umgekehrt verleiht Datenzugriff allein nicht zwangsläufig die Berechtigung, die Anwendung zu öffnen.
Die dokumentierten Berechtigungsstufen benötigen daher separate Prüfungen von Unity Catalog-Zuweisungen. Sie als eine einzige Kontrolle zu behandeln, kann bei Audits falsche Sicherheit erzeugen.
Administrative Scope-Allowlisten führen eine weitere Governance-Aufgabe ein. Laut Ankündigung kann die Standardeinstellung alle unterstützten APIs einschließen. Sicherheitsbewusste Organisationen sollten vor einer breiten Einführung von Anwendungen entscheiden, ob diese Standardeinstellung zu ihrem Entwicklungsmodell passt.
Eine Einschränkung der Allowlist kann Risiken reduzieren, aber auch legitime Produkte blockieren. Der richtige Prozess kombiniert eine eingeschränkte Basislinie mit einem dokumentierten Ausnahmeweg. Andernfalls könnten Teams umfassendere App-Identitäten anstreben, um Scope-Beschränkungen zu umgehen.
Es gibt zudem eine Erkennungsherausforderung. Eine App kann nur genehmigte Scopes anfordern und sich innerhalb dieser dennoch fehlerhaft verhalten. Die Laufzeitüberwachung sollte ungewöhnliche Abfragemuster, wiederholte Ablehnungen, unerwartete Datenmengen und Veränderungen im Anwendungsverhalten untersuchen.
Derzeit belegt kein unabhängiger Benchmark, wie viel Entwicklungszeit das Feature spart oder wie wirksam Unternehmen Berechtigungsfehler vermeiden. Die GA-Ankündigung erklärt Mechanismus und empfohlene Praktiken, doch Adoptionsergebnisse müssen noch nachgewiesen werden.
Databricks hat außerdem ein Interesse daran, seine Governance-Schicht zur Standardgrundlage für interne Anwendungen und Agenten zu machen. Käufer sollten diesen strategischen Vorteil neben Portabilität, Integrationsaufwand und dem Reifegrad ihrer bestehenden Autorisierungssysteme bewerten.
Der relevante Vergleich ist kein vereinfachter Wettbewerb zwischen Databricks und Microsoft. Das delegierte Identitätsmuster von Microsoft ist ausgereift und breit über APIs hinweg anwendbar. Databricks bündelt ein verwandtes Prinzip rund um seine eigenen Daten-, Compute-, Governance- und Anwendungs-Laufzeitumgebungen.
Googles identitätsbewusster Zugriff konzentriert sich auf die Steuerung des Zugriffs auf gehostete Anwendungen und kontextbezogene Richtlinien. AWS bietet Autorisierungskomponenten, die Entwickler mit Identitätsanbietern und Anwendungsressourcen kombinieren können. Jeder Ansatz weist der Plattform und dem Anwendungsteam unterschiedliche Aufgaben zu.
Unternehmen sollten vergleichen, wo Richtlinien liegen, welche Ressourcen sie abdecken, wie Identitäten Dienstgrenzen überschreiten und wie Ablehnungen für Benutzer erscheinen. Sie sollten außerdem testen, ob Audit-Aufzeichnungen eine Aktion eindeutig sowohl mit der Anwendung als auch mit der auslösenden Person verknüpfen.
Das GA-Label senkt eine Adoptionshürde, beantwortet jedoch nicht diese Architekturfragen. Das Feature ist am überzeugendsten, wenn die Daten-Governance bereits in Unity Catalog verankert ist und die Anwendung überwiegend unterstützte Databricks-Dienste aufruft.
Drei Signale werden zeigen, ob die GA-Veröffentlichung liefert
Der nächste Test besteht darin, ob Unternehmen benutzerbewusste Anwendungen einführen können, ohne Token-Risiken, Richtlinienkomplexität oder Plattformbindung auszuweiten.
Das erste Signal ist die Produktivnutzung durch interne Agenten und operative Anwendungen. Databricks hat ein klares Szenario für Vertriebsanalysen beschrieben, doch reale Bereitstellungen werden komplexere Kombinationen aus SQL, Modellen, Dateien, Dashboards und externen Diensten umfassen.
Hinweise auf eine ausgereifte Einführung wären wiederholbare Architekturmuster, Referenzimplementierungen und klare Audit-Workflows. Dazu würden auch Anwendungen gehören, die Benutzer mit wesentlich unterschiedlichen Berechtigungen bedienen, ohne diese Regeln im Code zu duplizieren.
Eine schwache Einführung würde darauf hindeuten, dass unterstützte Scopes, nachgelagerte Dienste oder organisatorische Prozesse weiterhin zu begrenzt sind. Teams könnten trotz der GA-Option weiterhin Service Principals mit weitreichenden Berechtigungen oder separate Autorisierungsprodukte verwenden.
Das zweite Signal ist die Erweiterung und Verfeinerung unterstützter API-Scopes. Eng gefasste Scopes erleichtern Least-Privilege-Designs, weil Entwickler eine Fähigkeit anfordern können, ohne nicht zusammenhängende Befugnisse zu erhalten.
Breitere, aber grobe Scopes würden die zweite Berechtigungsgrenze schwächen. Granularere Scopes, bessere administrative Kontrollen und klarere Einwilligungserfahrungen würden die Aussage von Databricks stärken, dass Apps für Benutzer handeln können, ohne ihre Befugnisse zu überschreiten.
Änderungen bei der Unterstützung von Compliance-Profilen sind ebenfalls relevant. Databricks gab an, dass die Benutzerauthentifizierung Workspaces mit dem Compliance Security Profile Ende September 2026 erreichen werde. Kunden sollten Verfügbarkeit und Einschränkungen in ihren eigenen Umgebungen prüfen.
Das dritte Signal ist, wie Wettbewerber delegierte Identität in ihre Agent-Plattformen integrieren. Microsoft dokumentiert OBO bereits für herkömmliche APIs und neuere Szenarien mit gehosteten Agenten. Auch andere Plattformen verknüpfen Benutzeridentität, Tool-Nutzung, Policy-Engines und verwaltete Application Runtimes.
Wenn diese Alternativen umfangreiche kundenspezifische Integration erfordern, verschafft das Databricks einen Vorteil bei Anwendungen, die auf kontrollierten Unternehmensdaten aufbauen. Bieten Wettbewerber eine ebenso direkte Policy-Vererbung über Daten- und Agent-Tools hinweg, werden Käufer stärker auf Portabilität und die Reichweite des Ökosystems achten.
Entwickler sollten auf operative Belege statt auf Ankündigungsrhetorik achten. Vorfälle bei der Token-Verarbeitung, verwirrende Consent-Flows, ausufernde Scopes und Bugs bei der Identity-Fallback-Logik würden die Argumentation schwächen. Klare Audits und geringerer Aufwand bei der Autorisierungswartung würden sie stützen.
Die unmittelbare Engineering-Aufgabe lässt sich einfach formulieren, auch wenn ihre Umsetzung Disziplin erfordert. Ordnen Sie jede Anwendungsoperation entweder der App-Identität oder der Identität des aktuellen Benutzers zu. Vergeben Sie den engstmöglichen Scope, weisen Sie fehlende Credentials zurück und testen Sie mit tatsächlich unterschiedlichen Benutzern.
Teams sollten außerdem bestehende Unity Catalog-Berechtigungen überprüfen, bevor sie sie über einen Agenten verfügbar machen. OBO setzt diese Berechtigungen zuverlässig durch, einschließlich Berechtigungen, die bereits weiter gefasst sind als beabsichtigt. Delegierung kann eine schwache Quell-Policy nicht verbessern.
Die Benutzerauthentifizierung in Databricks Apps ist daher bedeutsam, weil sie identitätsbewusste Governance näher an Daten und Application Runtime bringt. Sie ersetzt einen Teil der doppelt gepflegten Berechtigungslogik durch Plattformdurchsetzung und bewahrt zugleich eine App-Identität für gemeinsame Aufgaben.
Ihr Erfolg wird davon abhängen, ob Entwickler diese Grenze auch dann einhalten, wenn Anwendungen komplex werden. Stellen Sie vor der Bereitstellung des nächsten internen Assistenten für jeden Request-Pfad eine Frage: Soll diese Operation als Anwendung ausgeführt werden oder als die Person, die sie verwendet?
