Derselbe Vertriebsassistent kann einem Regionalleiter und einer landesweiten Führungskraft antworten, ohne beiden dieselben Unternehmensdaten zu zeigen. Schwierig ist, diese Trennung zu erhalten, nachdem eine Anfrage die Oberfläche verlässt und zu SQL, einem Modellaufruf oder einer Agentenaktion wird.
Databricks hat die Nutzerautorisierung für Apps am 7. Oktober 2026 nach mehr als 18 Monaten öffentlicher Vorschau allgemein verfügbar gemacht. On-Behalf-of-User-Autorisierung, kurz OBO, führt unterstützte Anfragen mit der Identität der angemeldeten Person aus, statt jede Aktion über den Service Principal der App zu leiten. Bestehende Unity-Catalog-Kontrollen können der Person folgen. Das verringert doppelte Richtlinienlogik, ist aber kein Versprechen automatischer Sicherheit durch Delegation.
Ein zweiter Identitätspfad für den Produktiveinsatz
Databricks Apps betreibt Datenanwendungen, Dashboards, operative Werkzeuge und eigene Agenten auf serverloser Infrastruktur. Jede bereitgestellte App erhält einen eigenen Service Principal: eine nichtmenschliche Identität mit den dieser Instanz zugewiesenen Rechten. Für gemeinsame Konfiguration, Telemetrie, Wartung und automatische Arbeit bleibt diese App-Autorisierung sinnvoll.
Nutzerautorisierung ergänzt sie. Für eine unterstützte Aktion einer authentifizierten Person leitet Databricks ein Zugriffstoken an die Laufzeit weiter. Die App ruft eine genehmigte Databricks-API mit den Rechten dieser Person auf. Das OAuth-2.0-Modell trennt Nutzer-zu-Maschine-Delegation von Maschine-zu-Maschine-Arbeit.
Bei kontrollierten Daten bewertet Unity Catalog bestehende Zuweisungen, Zeilenfilter und Spaltenmasken. Warehouse-Rechte entscheiden zusätzlich, ob die angeforderte Abfrage ausgeführt werden darf. Ein Regionalleiter sieht ein Gebiet, eine landesweite Führungskraft mehr – über denselben App-Pfad. Spätere Anfragen folgen aktualisierten Katalogrichtlinien statt einer gesonderten App-Kopie.
Das vermeidet eine häufige Abweichung. Eine gemeinsame App-Identität präsentiert dem Backend einen Berechtigungssatz; Entwickler bauen anschließend mit Rollen, Zuordnungen, Middleware oder einem anderen Policy-Dienst nach, welche Ergebnisse jedem Beschäftigten zustehen. Solche Kontrollen können funktionieren. Ändert sich aber der Katalog, nicht die lokale Zuordnung, drohen Offenlegung oder verweigerter legitimer Zugriff.
Die öffentliche Apps-OBO-Vorschau begann am 26. März 2025 und umfasste unter anderem Unity-Catalog-Tabellen und Model-Serving-Endpunkte. GA bedeutet Produktionsreife innerhalb dokumentierter Grenzen, nicht universelle Unterstützung jeder Cloud, Region, jedes Workspace, Compliance-Profils oder nachgelagerten API. Der Ausgangsbericht nennt eine angekündigte Ausweitung auf Workspaces mit Compliance Security Profile Ende September 2026; Kunden müssen ihre Umgebung dennoch prüfen.
Eine App kann gemeinsame Anweisungen und Metriken mit eigener Identität verarbeiten und Kunden- sowie Vertriebsdaten als aktueller Nutzer abfragen. Authentifizierung bestimmt, wer anwesend ist; Autorisierung entscheidet über zulässige Folgeaktionen. Diese Unterscheidung ist der Kern der Veröffentlichung.
Nutzerrechte und App-Scopes müssen zusammenpassen
Eine App-Anforderung gibt niemandem automatisch Zugriff auf Tabelle oder Warehouse. Die Person braucht bereits die notwendigen Ressourcenrechte. Entwickler deklarieren zusätzlich API-Scopes, die festlegen, welche Operationsklassen die App für diese Person ausführen darf.
Das sind zwei Grenzen. Ein Scope erzeugt kein neues Datenrecht, sondern beschränkt dessen Ausübung durch die App. Databricks dokumentiert sql:restricted-query für schreibgeschützte SQL-Analyse: eingeschränkte Abfragen als aktueller Nutzer, ohne umfassende Warehouse-Verwaltung oder sachfremde Administration.
Das ist besonders bei privilegierten Nutzern wichtig. Eine Führungskraft oder ein Administrator darf womöglich viele sensible Daten lesen, eine eng begrenzte App sollte aber nicht jede direkt verfügbare Fähigkeit erben. Scopes begrenzen Aktionen auch dann, wenn die eigenen Nutzerrechte weit reichen.
Workspace-Administratoren setzen eine weitere Obergrenze für hinzufügbare Scopes. Die Allowlist kann alle unterstützten APIs, ausgewählte Scopes oder keine Nutzerautorisierung zulassen. Laut Ankündigung kann der Standard alle APIs umfassen. Das ist eine Governance-Entscheidung, kein Beleg einer restriktiven Ausgangsbasis.
Die Obergrenze hat wichtige Ausnahmen. Account-Administratoren können auch vom Workspace ausgeschlossene Scopes hinzufügen. Und das Entfernen eines zuvor erlaubten Scopes stoppt bestehende Apps nicht unmittelbar: Sie können weiterlaufen. Danach können sie jedoch nicht starten, bereitgestellt oder aktualisiert werden, solange der unzulässige Scope nicht entfernt ist.
Eine Allowlist-Änderung ist daher kein sofortiger Widerruf jeder laufenden Nutzung. Verzeichnisse bereitgestellter Apps, Scope-Verantwortliche und Geschäftsabhängigkeiten helfen, den Übergang und unerwartete Sperren bei der nächsten Bereitstellung zu verstehen. Eine begrenzte Basis mit dokumentiertem Ausnahmeweg ist sinnvoller als die Annahme, Konfiguration erledige jede Durchsetzung.
Tokens gehören zur Anfrage, nicht zum gesamten Agenten
Nutzerbezogene und appbezogene Clients müssen getrennt bleiben. Interaktive kontrollierte Abfragen gehören zum Nutzerpfad; gemeinsame Einstellungen und Aufgaben ohne Nutzersitzung zu einem passend begrenzten App-Pfad. Getrennte Abhängigkeiten und Handler machen unbeabsichtigte Credential-Nutzung sichtbarer als ein generischer Client mit verborgenem Principal.
Verlangt ein Pfad Nutzerautorisierung und fehlt das weitergeleitete Token, sollte er die Anfrage ablehnen. Ein stiller Fallback auf den Service Principal kann eine technisch gültige Antwort unter völlig anderen, breiteren oder engeren Rechten erzeugen. Für Nutzer ist der Identitätswechsel womöglich unsichtbar.
Weitergeleitete Tokens sollten niemals ausgegeben, protokolliert oder gespeichert werden. Bei eigenen Agenten in Apps muss der nutzerbezogene Workspace-Client laut Databricks innerhalb des aktiven invoke- oder stream-Handlers initialisiert werden. Das Token steht nur während der Anfrage bereit, nicht beim globalen Anwendungsstart.
Ein Agentenprozess bedient viele Personen. Nutzeridentität als globaler Zustand kann Anfragekontexte verlieren oder vermischen. Ein Ablauf liest etwa gemeinsame Anweisungen als App, fragt kontrollierte Finanzdaten als Nutzer ab und schreibt allgemeine Telemetrie wieder als App, ohne Nutzer-Credentials zu behalten. Jeder Übergang braucht klaren Principal und Scope.
Lange oder verzögerte Aufgaben schaffen eine weitere Grenze. Dass eine Person Arbeit startet, die ihre Anfrage überlebt, erlaubt nicht das Speichern des weitergeleiteten Tokens. App-Aufgaben benötigen einen eng berechtigten Service Principal. Erforderlicher Nutzerkontext verlangt ein anderes dokumentiertes Delegationsmuster statt Credential-Aufbewahrung.
OBO setzt sich auch nicht automatisch über externe Integrationen fort. Nachgelagerte Dienste müssen das Modell unterstützen und können eigene Credentials, Einwilligungen, Scopes und Auditkontrollen verlangen. Tokens haben festgelegte Zielgruppe und Zweck; auch Microsoft warnt vor Weitergabe von Mittelschicht-Tokens an unbeabsichtigte Empfänger. Es ist begrenzte Delegation, keine pauschale Identitätsübernahme entlang aller Werkzeuge.
Die App öffnen heißt nicht, ihre Daten lesen zu dürfen
Databricks Apps ist kein Modell für anonyme öffentliche Anwendungen. Nutzer müssen sich authentifizieren, externe Partner über unterstützte Identitätsföderation aufgenommen werden. Die natürliche Zielgruppe sind verwaltete Belegschafts- und Partneridentitäten, keine uneingeschränkten anonymen Besucher.
CAN USE und CAN MANAGE bestimmen, wer die App ausführt oder verwaltet. Sie gewähren keine Rechte auf zugrunde liegende Tabellen, Datensätze oder Warehouses. Eine Person kann die App öffnen und dennoch eine verweigerte oder eingeschränkte Datenantwort bekommen. Umgekehrt erlaubt ein Tabellenrecht nicht zwangsläufig das Öffnen der App.
Diese Kontrollen sind daher getrennt von Unity-Catalog-Zuweisungen zu prüfen. Eine korrekt delegierte SQL-Antwort kann in der Oberfläche mit einer versehentlich als App ausgeführten Dateianfrage kombiniert werden. Die Plattform kann nicht garantieren, dass Entwickler jedem Codepfad die beabsichtigte Identität zuordnen.
Agenten verstärken das Risiko durch offene Fragen, Werkzeugwahl und mehrstufige Abfragen. Prompt Injection in abgerufenen Inhalten kann Offenlegung oder ungeeignete Aktionen anregen. OBO begrenzt Daten auf die Rechte des aktuellen Nutzers, aber weder gültige Identität noch Nur-Lese-Scope beweist, dass jede erlaubte Abfrage dessen Absicht entspricht.
Einwilligung ersetzt keine administrative Prüfung. Menschen können Scopes genehmigen, ohne die Kombination von Diensten und Ergebnissen zu verstehen. Eingabeverarbeitung, Tool-Beschränkungen, Ausgabekontrollen und Laufzeitüberwachung bleiben nötig: ungewöhnliche Abfragen, wiederholte Ablehnungen, unerwartete Datenmengen und Verhaltensänderungen zählen.
Tests allein als Administrator können Fehler verbergen, weil diese Identität selten Ablehnungen erlebt. Regionale, breiter berechtigte und Nutzer ohne Zugriff auf die betreffende Tabelle zeigen verschiedene Ergebnisse; Daten und Ablehnungsverhalten sind zu prüfen. Databricks empfiehlt Wiederholung nach Governance-Änderungen. Logs sollten App-Aktionen von persönlichen unterscheiden, ohne Bearer-Tokens oder sensible Antworten zu speichern.
Weniger doppelte Richtlinien, mehr Plattformabhängigkeit
Delegation repariert keine übermäßigen Quellrechte. Gruppen, Katalogprivilegien, Warehouse-Zugriff, Zeilenfilter und Masken müssen korrekt gepflegt werden. Eine durchsuchbare technische Wissensbasis kann Bedrohungsmodelle, Entscheidungen und Prüfnachweise neben Implementierungsdokumenten halten, ist selbst aber keine Durchsetzung.
Databricks unterscheidet sich durch die Verbindung von Delegation mit eigenen kontrollierten Daten, SQL und Laufzeit, nicht durch die Erfindung des Prinzips. Microsoft dokumentiert OBO bereits über APIs. Googles identitätsbewusster Zugriff fokussiert gehostete Apps und Kontextregeln; AWS liefert Autorisierungsbausteine für eigene Systeme. Die Ansätze verteilen Integrationsverantwortung unterschiedlich.
Liegen Daten bereits in Unity Catalog, kann Databricks Übersetzungsarbeit zwischen Sicherheitsteam und App-Framework sparen. Der Preis ist engere Bindung an spezifische Scopes und Identitätsverhalten. Multicloud-Ressourcen benötigen womöglich weiterhin eine andere Autorisierungsschicht.
Kein unabhängiger Benchmark belegt eingesparte Entwicklungszeit oder vermiedene Berechtigungsfehler. Produktionsmuster für wirklich unterschiedliche Nutzer, nachvollziehbare Mischdienstabläufe, feinere Scopes und klarere Einwilligung wären stärkere Belege als GA-Sprache. Tokenvorfälle, Scope-Wildwuchs und Identitätsfallbacks würden das Gegenteil zeigen.
Die Veröffentlichung senkt eine Produktionshürde, lässt aber die zentrale Architekturentscheidung offen: Welche Operation gehört zur App, welche zur Person? Ihr Wert liegt darin, diese Trennung auch bei einem Produkt aus SQL, Agenten, Dateien und externen Diensten aufrechtzuerhalten – nicht darin, einen angemeldeten Nutzer als unbegrenzte Berechtigung zu behandeln.
Quellen und weiterführende Informationen
Databricks-GA-Ankündigung; Apps-Autorisierungsmodell; Vorschau März 2025; Microsoft-OBO-Leitfaden; Weiterführendes zu technischen Wissensbasen; Apps-Berechtigungsstufen; Google identitätsbewusster Zugriff.