Jenseits des Einbettens: So sichern Sie AI/BI-Dashboards für alle Betrachter ab

Die Herausforderung

Das Einbetten eines Databricks AI/BI-Dashboards in eine kundenorientierte Anwendung ist relativ einfach: Aktivieren Sie das Einbetten, erstellen Sie ein Scoped Token im Backend und rendern Sie das Dashboard mit dem Client-SDK. Der grundlegende Leitfaden So betten Sie Databricks AI/BI-Dashboards in kundenorientierte Anwendungen ein führt Sie Schritt für Schritt durch diesen Prozess.

Die schwierigere Frage ist die Autorisierung: Welche Zeilen soll ein Betrachter sehen, sobald ein Dashboard eingebettet ist? Ein Partner sollte nur seine eigenen Daten sehen, während ein internes Team vielleicht nur seine Region sehen darf. Dieser Leitfaden zeigt Ihnen, wie Sie diese Regeln durchsetzen.

Dieses Referenzmuster kombiniert mehrere Databricks-Funktionen: __aibi_external_value, Unity Catalog-Zeilenfilter und -Spaltenmasken sowie Gruppen, die von einem Identity Provider (IdP) synchronisiert werden. Es handelt sich um ein Entwurfsmuster (Design Pattern) und nicht um eine einzelne Funktion, die aktiviert werden muss.

Ein Regelwerk, zwei Wege zur Durchsetzung

Dieselbe Berechtigungstabelle steuert zwei Pfade: eingebettete Dashboards, auf die über die Anwendung zugegriffen wird, und direkte SQL-Abfragen, die von Databricks-Benutzern ausgeführt werden.

Ein konkretes Szenario

Stellen Sie sich ein Unternehmen vor, das ein gemeinsames Dashboard „Offene Debitorenaufgaben (AR)“ für Daten aus drei Regionen verwendet: West, East und Central. Das Dashboard bedient zwei Zielgruppen.

• Externe Betriebspartner wie Acme Ops, Bolt Partners und Core Logistics haben kein Databricks-Login und greifen über ein White-Label-Portal auf das Dashboard zu. Jeder Partner sollte nur seine eigene Region sehen, wobei die Kontakt-E-Mails maskiert sind.
• Interne Teams sind die Mitarbeiter des Unternehmens, die sich bei Databricks anmelden. Die Finanzabteilung (Finance) benötigt Zugriff auf alle Regionen, während ein regionales Betriebsteam nur seine eigene Region sieht. Ihr Zugriff wird über Identity-Provider-Gruppen wie Okta oder Entra ID gesteuert, nicht über manuell gepflegte Benutzerlisten.

Fünf Betrachter teilen sich denselben Datensatz, wobei jeder einen anderen Ausschnitt sieht: Acme Ops, Bolt Partners, Core Logistics, Finance und ein regionales Betriebsteam. Die folgenden Beispiele konzentrieren sich auf Acme und Finance; die IDs partner_acme, finance_all und West stehen stellvertretend für diese Beispiele. Acme sieht West mit maskierten E-Mails, während Finance alle drei Regionen vollständig sieht – beide über dasselbe veröffentlichte Dashboard.

Eine Tabelle, eine Ansicht, ein Dashboard

Zugriffsregeln werden an einem zentralen Ort verwaltet, anstatt über verschiedene Dashboards oder Abfragen verteilt zu sein. Ein eigenes Dashboard pro Kunde führt zu Kopien, die asynchron werden können, während das Wiederholen von Filtern in jeder Abfrage fehleranfällig ist.

Das Modell besteht aus drei Objekten:

• Basistabelle `open_ar_tasks` enthält eine Zeile pro AR-Aufgabe, versehen mit einer Region und einer Kontakt-E-Mail.

• Die Berechtigungstabelle (Entitlements Table) ist die einzige „Source of Truth“ für den Zugriff. Jede Zeile definiert, auf welche Region ein Bereich (Scope) zugreifen kann und ob sensible Werte maskiert werden sollen. Die Spalte viewer_scope speichert sowohl externe Partner-IDs wie partner_acme als auch interne Gruppennamen wie finance_all.

• Sichere Ansicht (Secured View) verknüpft die Basistabelle mit den Berechtigungen, sodass ein Betrachter nur die Regionen sieht, für die er berechtigt ist, wobei E-Mails maskiert werden, wenn das entsprechende Flag gesetzt ist.

In den meisten Bereitstellungen befüllt ein vorgelagertes Berechtigungssystem oder eine anwendungseigene Zuordnung von Gruppen zu Regionen diese Tabelle; sie wird nicht für jeden Betrachter manuell bearbeitet.

Dies vermeidet kundenspezifische Dashboards und Filter, die in allen Abfragen wiederholt werden müssen. Die Regeln befinden sich in einer Tabelle, die abgefragt, geprüft und geändert werden kann, ohne das Dashboard anzupassen.

Auf den jeweiligen Betrachter angewendet, gibt die sichere Ansicht nur das zurück, wozu dieser Betrachter berechtigt ist:

Acme (external_value = partner_acme): Nur West, Kontakt-E-Mail maskiert.

Finance (external_value = finance_all): alle drei Regionen, Kontakt-E-Mail vollständig sichtbar.

Woher __aibi_external_value stammt

Das Backend legt diesen Wert fest, wenn es das Einbettungs-Token (Embed Token) generiert. Es authentifiziert sich als Dienstprinzipal (Service Principal) und fordert von Databricks ein Scoped Token mit zwei Werten an: external_viewer_id, das den Betrachter für Auditing-Zwecke identifiziert, und external_value, das den Bereich (Scope) des Betrachters darstellt. Databricks signiert das Token, und der Betrachter kann den eingebetteten Wert nicht ändern, der dem Dashboard-SQL als __aibi_external_value zur Verfügung gestellt wird. Da dieses Backend die Anmeldedaten des Dienstprinzipals enthält, handelt es sich um eine vertrauenswürdige serverseitige Komponente (niemals den Browser), wobei diese Anmeldedaten in einem Secrets Manager und nicht in der Versionsverwaltung aufbewahrt werden.

Das entscheidende Detail ist, unter welcher Identität die Abfrage ausgeführt wird. Eingebettete Abfragen werden unter der konfigurierten Veröffentlichungsidentität ausgeführt, nicht unter der Databricks-Identität des Betrachters.

Für das externe Einbetten empfiehlt Databricks individuelle Datenberechtigungen und die Erteilung eines eigenen Datenzugriffs für den Dienstprinzipal, sodass Abfragen als Dienstprinzipal ausgeführt werden. (Beim Veröffentlichen mit freigegebenen Datenberechtigungen werden Abfragen stattdessen mit den Anmeldedaten des Herausgebers ausgeführt.) Die Ansicht schränkt diesen Zugriff dann für jeden Betrachter über __aibi_external_value ein. Da die Abfrage als Dienstprinzipal ausgeführt wird, kann is_account_group_member() die tatsächliche Person, die das Dashboard über den Einbettungspfad anzeigt, nicht identifizieren.

Das wichtige Detail ist, dass external_value nicht auf eine Partner-ID beschränkt ist. Es kann sich um jeden Bereich handeln, den das Backend in das Token einträgt, beispielsweise partner_acme für einen externen Partner oder finance_all für eine interne Gruppe (deren Gruppenname).

Da die Berechtigungstabelle Partner-IDs und Gruppennamen in derselben Spalte enthält, decken ein Dashboard, eine Ansicht und ein Filter beides ab.

Da der Betrachter den signierten Wert weder sieht noch festlegt, kann er ihn auch nicht ändern. Ein unbekannter Bereich stimmt mit keiner Zeile überein, was standardmäßig zu einer Verweigerung des Zugriffs (Default-Deny-Verhalten) führt.

Dieselbe Ansicht und derselbe Filter (WHERE viewer_scope = __aibi_external_value) bedienen beide Zielgruppen. Lediglich die Quelle dieses Bereichs unterscheidet sich:

Zugriff für Gruppen gewähren, nicht für Personen

Organisationen verwalten den Zugriff in der Regel über Gruppen, die von einem Identity Provider synchronisiert werden. Wenn jemand der Finance-Gruppe in Okta beitritt, wird sein Zugriff automatisch auf finance_all abgebildet, ohne dass eine Datentabelle angepasst werden muss. In diesem Beispiel wird finance_all allen Regionen und ops_west der Region West zugeordnet.

Wie erfährt die Anwendung, welche Gruppen dem Betrachter angehören? Sie kann sich beim Einbetten nicht auf SQL verlassen, da die Abfrage als Service Principal ausgeführt wird und is_account_group_member() die falsche Identität prüfen würde. Die Anwendung muss die Gruppen des Betrachters im Backend auflösen, das den Betrachter sehen kann, bevor das Token generiert wird.

Eine Option besteht darin, die Anwendung auf Databricks Apps mit aktivierter Benutzerautorisierung auszuführen.

Für einen angemeldeten internen Benutzer leitet die Plattform den vertrauenswürdigen Identitätskontext an das Backend weiter, einschließlich der E-Mail-Adresse des Betrachters und eines On-Behalf-Of-Tokens (OBO). Das Backend verwendet dieses Token, um SCIM /Me als der Betrachter aufzurufen und dessen Gruppen auszulesen.

Dieser Ansatz erfordert keine Administratorrechte für den Service Principal, da der Benutzer seinen eigenen Datensatz liest. Er erfordert jedoch Benutzerautorisierungs-Scopes, und Apps OBO befindet sich noch in der Entwicklung. Validieren Sie dies daher vor der Verwendung für die Zielbereitstellung.

Wenn keine berechtigte Gruppe gefunden wird, brechen Sie sicher ab (Fail-Closed) und verweigern Sie die Generierung eines Tokens, anstatt auf eine allgemeinere Identität wie die reine E-Mail-Adresse zurückzugreifen.

Wenn ein Betrachter mehreren berechtigten Gruppen angehört, lösen Sie das Ergebnis deterministisch auf. Definieren Sie eine Rangfolge oder ordnen Sie mehrere Gruppen einem einzigen kanonischen Scope zu, bevor Sie das Token generieren, damit derselbe Betrachter immer konsistenten Zugriff erhält.

Externe Partner sind einfacher. Ohne Databricks-Identität ist ihr Scope eine feste Partner-ID, die bei der Anmeldung zugewiesen wird. Gleiches Token, gleicher Filter, keine Suche.

Eine Einschränkung, die beim Entwurf berücksichtigt werden muss: Ein signiertes Token enthält nur einen einzigen external_value. Wenn ein Betrachter mehreren Gruppen mit unterschiedlichen Berechtigungen angehört, kann ein Token dennoch nur einen Scope darstellen. Für den häufigen Fall von einer Rolle pro Person ist das in Ordnung.

Für eine echte Vereinigung mehrerer Gruppen verwenden Sie eine All-Access-Gruppe oder den unten beschriebenen direkten SQL-Pfad, bei dem ein Zeilenfilter eine ODER-Verknüpfung über alle Gruppen hinweg durchführen kann. Ein zusammengesetzter Scope (wie JSON) kann in external_value gepackt werden, aber dann verschieben sich das Parsen und Abgleichen in das Dataset-SQL und bleiben an das Payload-Limit von 1 KB gebunden.

Sicherheitsgarantien verstärken

Die Zeilenfilterung liefert das grundlegende Verhalten: Jeder Betrachter sieht nur seine eigenen Zeilen. Drei zusätzliche Ebenen verstärken die Kontrollen, und alle drei lesen aus derselben Berechtigungstabelle.

Sensible Spalten pro Betrachter maskieren

Die Sicherheit auf Zeilenebene (Row-Level Security) bestimmt, auf welche Zeilen ein Betrachter zugreifen kann. Die Maskierung bestimmt, welche Spalten er sehen kann, da externe Partner in der Regel nicht denselben Detailgrad benötigen wie interne Teams.

Das mask_pii-Flag (true für Partner und false für interne Gruppen) steuert die Maskierungslogik in der abgesicherten Ansicht (der CASE-Ausdruck im obigen SQL). Dasselbe Dashboard kann einem internen Betrachter die vollständige E-Mail-Adresse anzeigen, während einem Partner ein maskierter Wert wie ****@example.com angezeigt wird. Wenn Maskierungsregeln über viele Tabellen hinweg verlaufen und komplex werden, sind Spaltenmasken in Unity Catalog und die attributbasierte Zugriffskontrolle (ABAC) langfristig die bessere Wahl. Hier hält die Ansicht das Beispiel in sich geschlossen.

Standardmäßig verbieten (Default-Deny) und nachweisen

Ein unbekannter Scope sollte keine Dashboard-Zeilen zurückgeben und nichts über die zugrunde liegende Datenstruktur verraten: kein Fehler, der auf die Struktur hindeutet, keine unvollständigen Daten, sondern nur ein leeres Ergebnis. Ein noch früherer Abbruch ist sauberer: Bevor das Backend ein Token generiert, prüft es die Berechtigungstabelle und verweigert jeden Scope, der für null Zeilen berechtigt ist. Ebenso wichtig ist, dass der Scope vom authentifizierten Betrachter abgeleitet wird und niemals von einem vom Client bereitgestellten Parameter. So kann ein Betrachter nicht den Scope eines anderen Mandanten anfordern.

Die Zugriffskontrolle bei der Token-Ausstellung verhindert, dass ein abgewiesener Betrachter überhaupt ein Token erhält. Das ist besser, als sich nur auf den SQL-Filter als Schutzmaßnahme zu verlassen. Die Protokollierung sowohl erfolgreicher Token-Ausstellungen als auch abgelehnter Anforderungen macht Autorisierungsentscheidungen überprüfbar: Der abgewiesene Betrachter taucht einfach nie auf, und selbst wenn eine Anforderung durchschlüpfen würde, würde ein unbekannter Scope immer noch keine Dashboard-Zeilen zurückgeben. Durch die Aufzeichnung der external_viewer_id und ihres Scopes in diesen Protokollen kann jede Autorisierungsentscheidung bei einer Überprüfung auf einen echten Kunden oder Benutzer zurückgeführt werden.

Den direkten SQL-Pfad schützen

Die Einbettungssteuerungen schützen den Anwendungspfad. Ein Databricks-Benutzer, der die Basistabelle direkt abfragt, stellt eine separate Bedrohung dar. Fügen Sie der Basistabelle einen Unity Catalog-Zeilenfilter hinzu, der auf die Identität und die Gruppen des abfragenden Benutzers abgestimmt ist. In diesem Pfad für direkte Abfragen wertet is_account_group_member() den tatsächlichen Benutzer aus und kann alle seine berechtigten Gruppen kombinieren. Die Publisher-Ausnahme in der folgenden Funktion (current_user() entspricht der Publishing-Identität) ist eine bewusste Notfallregelung (Break-Glass) für die Identität, die das Dashboard veröffentlicht oder aktualisiert, und keine allgemeine Umgehung für Operatoren. Sie ist optional und birgt ein hohes Risiko. Fügen Sie sie daher nur ein, wenn sie gerechtfertigt ist, und genehmigen Sie sie pro Bereitstellung.

Eine Spaltenmaske für sensible Felder funktioniert auf dieselbe Weise. Diese Unity Catalog-Kontrollen sind vom Einbettungspfad getrennt: Eingebettete Betrachter werden über __aibi_external_value und die Berechtigungsansicht gesteuert, während direkte Workspace-Abfragen durch den Unity Catalog-Zeilenfilter geschützt sind, der die Identität und die Gruppen des Aufrufers auswertet. Beide Durchsetzungspunkte verwenden dieselbe Berechtigungstabelle.

Vor dem Erstellen

Zum Thema „Multi-Tenancy“: Hierbei handelt es sich um eine gemeinsame, logische Mandantenfähigkeit: Externe Partner sind voneinander isoliert, während interne Mitarbeiter gruppenbasierten (rollenbasierten) Zugriff innerhalb des eigenen Mandanten des Unternehmens erhalten. Alle Daten verbleiben in gemeinsam genutzten Tabellen. Das Token, der Ansichtsfilter und die Berechtigungstabelle erzwingen die Trennung. Der direkte SQL-Zeilenfilter erweitert dieselbe Garantie außerhalb der App.

Wann dieses Muster verwendet werden sollte: Verwenden Sie dieses Muster, wenn externe Partner ohne Databricks-Konten und interne Mitarbeiter dasselbe Dashboard gemeinsam nutzen müssen. Wenn jeder Betrachter ein interner Databricks-Benutzer ist, reicht eine einfache Einbettung mit der Zeilen- und Spaltensicherheit von Unity Catalog möglicherweise aus.

Praktische Einschränkungen und Fallstricke: Überprüfen Sie vor der Veröffentlichung die folgenden Produktlimits und betrieblichen Details anhand der aktuellen Dokumentation:

• Token sind kurzlebig (1 Stunde), daher muss die App sie aktualisieren, insbesondere wenn ein Tab geöffnet bleibt. Das Client-SDK macht dies einfach: Ein getNewToken-Callback ruft das Token erneut vom Endpunkt /api/token ab, wenn das Token fast abgelaufen ist.
• Halten Sie `external_viewer_id` + `external_value` zusammen unter 1 KB: Verwenden Sie kompakte Bezeichner, keine JSON-Blobs oder langen E-Mail-Adressen.
• Ratenbegrenzung von 20 Dashboard-Ladevorgängen pro Sekunde und Workspace für externes Einbetten. Wichtig zu wissen für ein großes B2B-Portal.
• Verwenden Sie eine `external_viewer_id` ohne PII. Da sie in Audit-Protokollen landet, ist eine stabile Kunden- oder Benutzer-ID besser als ein vollständiger Name oder eine reine E-Mail-Adresse.
• Downloads sind standardmäßig aktiviert. Eingebettete Viewer können CSV, TSV, Excel und PNG exportieren, es sei denn, ein Workspace-Admin deaktiviert die Downloads. Stellen Sie sicher, dass die exportierten Ergebnisse den erwarteten, für den Viewer eingeschränkten Daten entsprechen.
• Richten Sie Gruppen auf Kontoebene für den direkten SQL-Pfad ein. UC-Zeilenfilter und -Masken werten is_account_group_member() für Gruppen auf Kontoebene aus, nicht für Workspace-lokale Gruppen. Der Einbettungspfad ruft diese Funktion niemals auf.
• Achten Sie auf große Berechtigungstabellen. Halten Sie bei Tausenden von Scopes oder tiefen Hierarchien die Join- und Maskierungsausdrücke einfach und weichen Sie auf ABAC aus, sobald die Regeln komplex werden.

Wichtigste Erkenntnisse

• Speichern Sie Zugriffsregeln in einer einzigen Berechtigungstabelle und verwenden Sie diese sowohl für eingebettete Dashboards als auch für den direkten SQL-Schutz.
• Signieren Sie einen Viewer- oder Gruppen-Scope in __aibi_external_value; verlassen Sie sich nicht auf vom Benutzer bearbeitbare Filter.
• Verwenden Sie Default-Deny, Maskierung und Unity Catalog-Zeilenfilter als mehrschichtige Sicherheitskontrollen.
• Das Einbetten ist nur der erste Schritt; das Entwerfen und Validieren der Zugriffskontrollen ist die entscheidende Aufgabe.

Nächste Schritte

Beginnen Sie mit dem grundlegenden Leitfaden Einbetten von Databricks AI/BI-Dashboards in kundenorientierte Anwendungen und wenden Sie dann die in diesem Beitrag beschriebenen Berechtigungs-, Maskierungs- und Default-Deny-Muster an. Weitere Informationen zu den zugrunde liegenden Governance-Kontrollen finden Sie in der Dokumentation zur AI/BI-Einbettung sowie unter Unity Catalog-Zeilenfilter und -Spaltenmasken und den ABAC-Richtlinien.

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