Jetzt GA: Entwickeln von berechtigungsgesteuerten Databricks Apps mit Autorisierung im Namen des Benutzers

Mit Databricks Apps können Entwickler Daten- und KI-Anwendungen direkt auf der Databricks-Plattform erstellen und bereitstellen – von interaktiven Dashboards und operativen Tools bis hin zu maßgeschneiderten KI-Agenten.

Die jetzt allgemein verfügbare On-Behalf-Of-User-Autorisierung (OBO) ermöglicht es, Apps zu entwickeln, die personalisierte, berechtigungsgesteuerte Erlebnisse bieten, ohne dass Data-Governance-Regeln im Anwendungscode neu implementiert werden müssen. Wenn eine App unterstützte Databricks-APIs mit OBO aufruft, agiert sie unter der Identität des angemeldeten Benutzers: Unity Catalog setzt die bestehenden Datenberechtigungen dieses Benutzers durch, einschließlich Zeilenfiltern und Spaltenmasken, und API-Bereiche (Scopes) begrenzen die Aktionen, die die App im Namen des Benutzers ausführen darf. Apps können weiterhin ihren dedizierten Dienstprinzipal (Service Principal) für anwendungseigene Vorgänge nutzen, wie das Lesen gemeinsamer Konfigurationen oder das Schreiben von Anwendungsmetriken.

Beispielsweise kann ein Assistent für Vertriebserkenntnisse Fragen beantworten und dabei nur auf die Konten und Felder zugreifen, für die ein Vertriebsmitarbeiter autorisiert ist, ohne der App weitreichende SQL- oder Workspace-Administrationsrechte zu gewähren.

Beginnen Sie mit der Identität, die den jeweiligen Vorgang steuert

Fragen Sie sich beim Entwurf einer App: Wessen Berechtigungen sollten diesen speziellen Vorgang steuern?

Databricks Apps unterstützt zwei komplementäre Autorisierungsmodelle: die App-Autorisierung und die Benutzerautorisierung. Die App-Autorisierung nutzt den dedizierten Dienstprinzipal der App und eignet sich für anwendungseigene Vorgänge oder Funktionen, die für jeden Benutzer das gleiche Ergebnis liefern sollen. Die Benutzerautorisierung nutzt die Identität des angemeldeten Benutzers, wenn dessen Berechtigungen einen Vorgang steuern sollen. Die meisten Produktions-Apps können beide Modelle nutzen und die passende Identität für jeden Anforderungspfad wählen. Siehe Autorisierung in einer Databricks-App konfigurieren.

Stellen Sie sich eine App vor, die Fragen beantwortet wie: Wie entwickeln sich meine Konten in diesem Quartal und was erklärt die Veränderung? Die App muss:

• Verkaufs- und Kundendaten als der anfordernde Benutzer abfragen.
• Berechtigungen in Unity Catalog berücksichtigen, einschließlich Filtern auf Zeilenebene und Spaltenmasken.
• Schreibgeschützte Analysen zurückgeben.
• Optional einen separaten Dienst aufrufen, um die Ergebnisse zusammenzufassen.
• Das Ändern von Daten oder Verwalten von SQL-Ressourcen vermeiden.

Dies ist ein idealer Anwendungsfall für die Benutzerautorisierung. Die App übergibt das weitergeleitete Zugriffstoken des anfordernden Benutzers an den SQL-Connector, und Databricks wertet die Abfrage unter Verwendung des vorhandenen Warehouses und der Unity Catalog-Berechtigungen dieses Benutzers aus. Ein Regionalleiter sieht möglicherweise nur Konten in seiner Region, während ein nationaler Leiter alle Regionen sieht, ohne dass die App diese Regeln im Code nachbilden muss. Wenn Administratoren Unity Catalog-Richtlinien aktualisieren, spiegeln nachfolgende App-Anfragen diese Änderungen wider. 

Die Berechtigung des Benutzers bestimmt, welche Daten die Abfrage zurückgeben kann. Die nächste Designentscheidung betrifft die Frage, was die App im Namen des Benutzers mit dem weitergeleiteten Benutzertoken tun darf.

Verwenden Sie den engsten API-Scope, der für die Aufgabe ausreicht

Der Assistent für Vertriebserkenntnisse muss schreibgeschützte Abfragen ausführen. Er benötigt keinen umfassenden SQL-Zugriff zur Verwaltung von Ressourcen oder zur Durchführung anderer SQL-Vorgänge. Aus diesem Grund sollte er sql:restricted-query anstelle des umfassenderen sql-Scopes anfordern. 

sql:restricted-query ermöglicht es der App, schreibgeschützte SQL-Abfragen auszuführen. Es erlaubt der App nicht, andere SQL-Vorgänge durchzuführen. Dies sorgt für eine bessere Abstimmung zwischen dem Produktverhalten der App und ihren Autorisierungsgrenzen: Die App kann verwaltete Daten für Analysen lesen, aber sie kann die Identität des Benutzers nicht als allgemeine SQL-Anmeldeinformation verwenden.

Wenn die App auch Genie oder Unity Gateway im Namen eines Benutzers aufruft, fordern Sie nur die entsprechenden Scopes an, wie z. B. genie oder ai-gateway. Fordern Sie files, model-serving oder vector-search nur an, wenn die App diese Funktionen tatsächlich nutzt. 

Scopes sind eine Obergrenze für Funktionen, keine Gewährung von Datenzugriff. Die App muss über den entsprechenden API-Scope verfügen, und der Benutzer muss weiterhin die Berechtigung für den Zugriff auf die Zielressource besitzen. Siehe Scope-basierte Sicherheit und Privilegienerweiterung.

Konfigurieren Sie die App mit einem expliziten API-Scope

Konfigurieren Sie die Benutzerautorisierung in der Databricks-UI oder in einem Declarative Automation Bundle. 

Für einen schreibgeschützten Analyse-Assistenten kann die App Folgendes deklarieren:

Hinweis: Der API-Scope ist Teil der deklarierten Benutzerautorisierungskonfiguration der App. Er gewährt keinen Zugriff auf ein SQL-Warehouse oder Unity Catalog-Daten. Der anfordernde Benutzer muss weiterhin berechtigt sein, das Ziel-SQL-Warehouse zu verwenden, und die erforderlichen Unity Catalog-Berechtigungen für die abgefragten Daten besitzen. 

Wenn ein Benutzer zum ersten Mal auf eine benutzerautorisierte App zugreift, fordert Databricks ihn auf, den angeforderten API-Scopes zuzustimmen. 

Übergeben Sie die Benutzeridentität an den SQL-Connector

Databricks leitet das Zugriffstoken des aktuellen Benutzers im HTTP-Header x-forwarded-access-token weiter. Die App sollte dieses Token für die Anfrage abrufen, die Zugriff auf den Benutzerkontext benötigt, und es an den SQL-Connector übergeben.

Das folgende Beispiel verwendet Flask und den Databricks SQL Connector for Python, um den Token-Fluss zu verdeutlichen. Wenn Sie die App mit Databricks AppKit erstellen, wenden Sie dasselbe Autorisierungsprinzip an: Verwenden Sie den Benutzerkontext-Client oder die Identität zum Anforderungszeitpunkt für benutzerspezifische Vorgänge, und belassen Sie anwendungseigene Vorgänge auf der App-Identität.

Hinweis: Der weitergeleitete Token ist kurzlebig und gilt pro Anfrage. Die App liest ihn bei jeder Anfrage aus und speichert ihn niemals anfrageübergreifend oder in einer Sitzung. 

Der wichtige Unterschied zur App-Autorisierung besteht darin, dass der Connector den weitergeleiteten Benutzertoken über access_token erhält. Der API-Scope sql:restricted-query beschränkt die App auf die benötigten schreibgeschützten SQL-Funktionen, während Unity Catalog bestimmt, auf welche Zeilen und Spalten dieser Benutzer tatsächlich zugreifen kann. Siehe Abfrage mit Benutzerautorisierung.

Workspace-Administratoren die Obergrenze festlegen lassen

Entwickler geben an, welche API-Scopes ihre App benötigt. Workspace-Administratoren können steuern, welche API-Scopes App-Entwickler zu Apps im Workspace hinzufügen dürfen.

Diese Richtlinie ermöglicht es Teams, schreibgeschützte Analyse- und KI-Anwendungen zu erstellen, während gleichzeitig verhindert wird, dass Apps umfassendere oder nicht damit zusammenhängende Berechtigungen anfordern. Ein App-Entwickler kann die Autorisierung der App nicht über die konfigurierte API-Scope-Grenze des Workspace hinaus erweitern.

Dies bietet Organisationen zwei Kontrollebenen:

• Die App deklariert die für ihre Funktionalität erforderlichen Mindest-API-Scopes.
• Der Workspace-Administrator definiert die maximalen API-Scopes, die Apps in diesem Workspace zur Verfügung stehen.

Workspace-Administratoren konfigurieren diese Zulassungsliste unter Einstellungen > Entwicklung > Apps. Die Einstellung ist standardmäßig auf alle unterstützten APIs festgelegt, kann auf ausgewählte API-Scopes eingegrenzt oder auf None gesetzt werden, um die Benutzerautorisierung zu deaktivieren. Siehe Benutzerautorisierungs-Scopes einschränken.

Konto-Administratoren können Scopes auch dann hinzufügen, wenn diese nicht in der Workspace-Zulassungsliste enthalten sind. Wenn ein Administrator später einen zulässigen Scope entfernt, können bereits mit diesem Scope ausgeführte Apps weiterhin ausgeführt werden. Sie können jedoch erst gestartet, bereitgestellt oder aktualisiert werden, wenn der nicht zulässige Scope entfernt wurde.

App-eigene und benutzer-eigene Vorgänge getrennt halten

Viele nützliche Apps benötigen beide Autorisierungsmodelle. Der Assistent für Vertriebserkenntnisse könnte Folgendes verwenden:

• Einen Client mit App-Scope, um Anwendungsmetriken zu schreiben oder freigegebene Konfigurationen zu lesen.
• Einen Client mit Benutzer-Scope mit sql:restricted-query, um Daten für den aktuellen Benutzer abzufragen.
• Einen separaten Benutzer-API-Scope, falls ein anderer Databricks-Dienst im Namen des Benutzers aufgerufen werden muss.

Es wird empfohlen, diese Identitätsgrenze im Anwendungscode explizit zu machen, anstatt einen einzigen generischen Client zu erstellen und diesen überall wiederzuverwenden. Separate Abhängigkeiten, Namen und Tests tragen dazu bei, zu verhindern, dass App-Anmeldedaten für einen benutzerspezifischen Pfad verwendet werden oder ein Benutzertoken für Hintergrundarbeiten aufbewahrt wird.

Wenn eine Anfrage eine Benutzerautorisierung erfordert und der weitergeleitete Token fehlt, sollte die Anfrage fehlschlagen („Fail Closed“), anstatt stillschweigend auf den Dienstprinzipal der App umzuschalten. Andernfalls könnte die App eine Antwort zurückgeben, die zwar gültig aussieht, aber mit anderen Berechtigungen generiert wurde. Aus diesem Grund beginnt query_as_user im obigen Beispiel mit require_user_token, anstatt den fehlenden Header inline zu verarbeiten.

Dasselbe Muster auf Agenten anwenden

Benutzerdefinierte Agenten, die auf Databricks-Apps bereitgestellt werden, können dasselbe Modell verwenden. Initialisieren Sie den Workspace-Client mit Benutzer-Scope innerhalb des invoke- oder stream-Handlers zum Zeitpunkt der Anfrage – nicht beim Anwendungsstart –, da der weitergeleitete Benutzertoken nur während einer aktiven Benutzeranfrage verfügbar ist. Verwenden Sie die App-Autorisierung für freigegebene Ressourcen und Hintergrundvorgänge. Siehe Authentifizierung für Agenten.
 

Die Implementierung absichern

• Fordern Sie nur die minimal erforderlichen API-Scopes an.
• Halten Sie App-eigene und benutzerautorisierte Clients in Code, Tests und Abhängigkeitsverdrahtungen getrennt.
• Geben Sie weitergeleitete Zugriffstoken niemals aus, protokollieren Sie sie nicht und speichern Sie sie nicht dauerhaft.
• Beschränken Sie die App-Verwaltung auf vertrauenswürdige Entwickler und fordern Sie Peer-Reviews für autorisierungsbezogene Änderungen an.
• Verwenden Sie die App-Autorisierung für freigegebene und Hintergrundvorgänge, anstatt Benutzertoken aufzubewahren.
• Testen Sie mit Benutzern, deren Unity Catalog-Zugriff sich unterscheidet, und wiederholen Sie diese Tests nach Richtlinienänderungen.

Erste Schritte

Die Autorisierung im Namen des Benutzers bietet Ihnen Personalisierung und Governance über denselben Mechanismus. Die Unity Catalog-Berechtigungen des Benutzers entscheiden, auf welche Daten eine App zugreifen kann, und der engste passende API-Scope bestimmt, was sie in seinem Namen tun kann. Um zu beginnen, lesen Sie unsere Hilfedokumentation für weitere Ressourcen und Best Practices.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag