Tutorial: Begrenzen Sie den Zugriff eines KI-Agenten mit RBAC

Verwenden Sie rollenbasierte Zugriffskontrolle (RBAC), um den Zugriff eines KI-Agenten auf die Daten und Ressourcen einzuschränken, die er für eine bestimmte Aufgabe benötigt. Stellen Sie dem Agenten ein OAuth-Token zur Verfügung, das auf eine Rolle abgegrenzt ist. Anfragen, die mit diesem Token gestellt werden, verwenden die Berechtigungen der Rolle anstelle der breiteren Berechtigungen des authentifizierenden Benutzers oder Dienstprinzipals.

Scenario

Ein KI-Support-Mitarbeiter benötigt Ticketzusammenfassungen und den Status, aber keine Kundenkontaktdaten, die personenbezogene Daten (PII) enthalten. Sein authentifizierender Service-Principal hat einen breiteren Zugriff und kann beide Datensätze lesen.

In diesem Beispiel enthält das support.tickets Schema Ticketzusammenfassungen und Status ohne Kunden-PII. Kundenkontaktdaten werden separat in support.customers.contact_details gespeichert.

Du erstellst role-support-agent, gewährst ihm Lesezugriff auf support.tickets, und erteilst dem Service Principal die Berechtigung „Assume“ darauf. Mit einem Token, das auf diese Rolle zugeschnitten ist, kann der Agent Support-Tickets lesen, aber nicht auf Kundenkontaktdaten zugreifen.

Die Rolle kann Datenrechte von übergeordneten Gruppen erben, und Katalog- oder Schema-Grants können auf alle darunter liegenden Tabellen angewendet werden. Überprüfen Sie für dieses Beispiel, dass diese Berechtigungen der Rolle keinen Zugriff auf die Kundenkontakttabelle gewähren. Siehe Berechtigungsvererbung. Das Ändern von gemeinsamen Berechtigungen betrifft andere Nutzer und Rollen, daher sollten Sie einen Testarbeitsbereich verwenden, anstatt den Zugriff anderer Nutzer zu entfernen.

Dieses Tutorial richtet sich an benutzerdefinierte, selbstgehostete oder Drittanbieter-Agenten, die ein von Ihnen bereitgestelltes OAuth-Zugriffstoken akzeptieren. Für Agenten, die auf Databricks-Apps eingesetzt werden, verwenden Sie die integrierte App oder Benutzerautorisierung. Siehe Authentifizierung für Agents.

Prerequisites

• Ein Unity Catalog-fähiger Arbeitsbereich mit aktiviertem RBAC. Siehe RBAC aktivieren.
• Account-Admin- oder Workspace-Admin-Rechte, um die Rolle zu erstellen, die Assume-Berechtigung zu erteilen und sie dem Workspace zuzuweisen. Sehen Sie sich an, wer Gruppen verwalten kann?.
• Eigentum von, oder MANAGE auf, den support Katalog.
• Workspace-Admin-Berechtigungen oder Kann verwalten auf dem im Beispiel verwendeten SQL-Warehouse.
• Existierende Tabellen support.tickets.open_cases und support.customers.contact_details. Verwenden Sie fiktive Testdaten und fügen Sie bei Bedarf Ihre eigenen Namen ein.
• Ein Service Principal, der dem Arbeitsbereich zugewiesen ist, mit Databricks SQL-Zugriff, kann das Warehouse verwenden und ist berechtigt, beide Tabellen abzufragen. Es benötigt ein OAuth-Geheimnis, das für die Machine-to-Machine-(M2M-)Authentifizierung den sql Scope ermöglicht. Siehe Schritt 1: Erstellen eines OAuth-Schlüssels.
• curl In einer vertrauenswürdigen Umgebung, in der man Token anfordern und testen kann.
• Ein Audit-Reader mit Zugang zu system.access.audit zur Überprüfung der Aktivität des Agenten in der Rolle. Siehe Audit Attribution verifizieren.

Verwenden Sie für dieses OAuth M2M-Beispiel einen Azure Databricks Managed Service Principal. Microsoft Entra ID verwaltete Service-Principals verwenden eine andere Authentifizierungskonfiguration. Siehe Autorisieren des Dienstprinzipalzugriffs auf Azure Databricks mit OAuth.

Schritt 1: Erstellen der Rolle

Für dieses Tutorial erstelle eine leere Kontogruppe, die als Rolle dient.

Kontokonsole

1. Melden Sie sich als Kontoadministrator*in bei der Kontokonsole an.
2. Klicken Sie in der Randleiste auf Benutzerverwaltung.
3. Klicken Sie auf der Registerkarte Gruppen auf Gruppe hinzufügen.
4. Geben Sie role-support-agent ein. Fügen Sie keine Mitglieder hinzu.
5. Klicken Sie auf Bestätigen.
6. Weise die Gruppe dem Arbeitsbereich mit Databricks SQL-Zugriff zu. Siehe "Zuweisen einer Gruppe zu einem Arbeitsbereich".

Administratoreinstellungen für den Arbeitsbereich

1. Melden Sie sich als Workspace-Administrator im Test-Workspace an.
2. Klicken Sie in der oberen Leiste auf Ihren Benutzernamen, und wählen Sie "Einstellungen" aus.
3. Klicken Sie auf die Registerkarte "Identität und Zugriff ".
4. Klicken Sie neben Gruppen auf Verwalten.
5. Klicken Sie auf Gruppe hinzufügen, dann auf Neu hinzufügen.
6. Geben Sie ein und wählen Sie role-support-agent aus.
7. Klicken Sie auf Hinzufügen. Fügen Sie keine Mitglieder hinzu.

Das weist die Gruppe auch dem Arbeitsbereich zu und gibt dir die Berechtigung "Verwalten" darauf.

Die Databricks SQL-Zugriffsberechtigung gewährt Zugriff auf Databricks SQL-Funktionen, einschließlich Dashboards, Abfragen und SQL-Warehouses. Das Beispiel verwendet SQL-Abfragen. Wenn Ihr Agent auch Kernfunktionen des Workspace benötigt, wie Notizbücher, Jobs, Modelle oder Pipelines, gewähren Sie Workspace-Zugriff. Siehe Zugriffsberechtigungen. Du konfigurierst in Schritt 2 Datenrechte und Warehouse-Berechtigungen.

In diesem Beispiel erteilst du die Assume-Berechtigung separat, anstatt den Service Principal als Mitglied hinzuzufügen. Die Mitgliedschaft fügt außerdem die Berechtigungen der Gruppe zur eigenen Identität des Service-Principals hinzu.

Schritt 2: Gewähren Sie der Rolle Zugang zu Support-Tickets

Als Katalogbesitzer oder Benutzer mit MANAGE auf support führen Sie aus:

GRANT USE CATALOG ON CATALOG support TO `role-support-agent`;
GRANT USE SCHEMA, SELECT ON SCHEMA support.tickets TO `role-support-agent`;

Als Workspace-Administrator oder Benutzer mit Kann verwalten für das Warehouse gewähren Sie der Rolle Zugriff auf das Warehouse:

1. Klicken Sie in der Seitenleiste des Arbeitsbereichs auf SQL Warehouses.
2. Klicken Sie auf das 3-Punkte-Menü neben dem Warehouse und dann auf Berechtigungen.
3. Fügen Sie role-support-agent mit Kann verwenden hinzu.

Der Schema-Level-Grant SELECT gilt für alle aktuellen und zukünftigen Tabellen und Ansichten in support.tickets. Er gewährt keinen Zugriff auf support.customers oder andere Schemata. Um die Rolle auf eine Tabelle zu beschränken, gewähre SELECT stattdessen für diese Tabelle. Weitere Informationen finden Sie unter Verwalten von Berechtigungen in Unity Catalog.

Schritt 3: Erteile die Erlaubnis, die Rolle zu übernehmen

Erteile dem Service Principal die Assume-Berechtigung mit einer der beiden Methoden:

Kontokonsole

1. Als Kontoadministrator öffnen Sie die Kontokonsole und klicken Sie auf Benutzerverwaltung.
2. Klicken Sie auf der Registerkarte Gruppen auf role-support-agent.
3. Klicken Sie auf den Reiter Berechtigungen und dann auf Zugriff gewähren.
4. Suchen Sie nach dem Dienstprinzipal und wählen Sie ihn aus, wählen Sie Übernehmen aus und klicken Sie auf Speichern.

Administratoreinstellungen für den Arbeitsbereich

1. Als Workspace-Administrator mit Verwalten-Berechtigung für die Rolle, öffnen Sie die Einstellungen>Identität und Zugriff im Test-Workspace.
2. Klicken Sie neben Gruppen auf Verwalten und wählen Sie dann role-support-agent.
3. Klicken Sie auf Berechtigungen und dann auf Zugriff gewähren.
4. Suchen Sie nach dem Dienstprinzipal und wählen Sie ihn aus, wählen Sie Übernehmen aus und klicken Sie auf Speichern.

Schritt 4: Fordern Sie einen rollenbezogenen Token an

Legen Sie in Ihrer vertrauenswürdigen Token-Anfrageumgebung diese Umgebungsvariablen fest:

• DATABRICKS_HOST: die URL des Arbeitsbereichs, einschließlich https:// und ohne nachlaufenden Schrägstrich.
• CLIENT_ID und CLIENT_SECRET: die Anwendungs-ID und das OAuth-Geheimnis des Service-Prinzipals.
• ROLE_GROUP_ID: die numerische ID von role-support-agent. Ein Kontoadministrator kann sie am Ende der Gruppen-URL in der Kontokonsole finden. Kontoadministratoren, Arbeitsbereichsadministratoren und Gruppenmanager können ebenfalls die id der Gruppe über die Account Groups API abrufen.
• DATABRICKS_SQL_WAREHOUSE_ID: die ID des Lagers, die in Schritt 2 vergeben wurde. Sie folgt /sql/1.0/warehouses/ im HTTP-Pfad des Warehouse. Siehe Abrufen von Verbindungsdetails für eine Azure Databricks-Compute-Ressource.

Fordern Sie ein Workspace-Level-Token mit dem Parameter assume_group und dem sql OAuth-Scope an. Der Umfang begrenzt das Token auf SQL-APIs. Die Datenrechte der Rolle bestimmen, welche Tabellen sie abfragen kann. Siehe Scoped OAuth Secrets.

Um das Token anzufordern, führen Sie aus:

curl --request POST \
  --url "$DATABRICKS_HOST/oidc/v1/token" \
  --user "$CLIENT_ID:$CLIENT_SECRET" \
  --data-urlencode 'grant_type=client_credentials' \
  --data-urlencode 'scope=sql' \
  --data-urlencode "assume_group=$ROLE_GROUP_ID"

Setze DATABRICKS_TOKEN auf den access_token Wert aus der Antwort. Verwenden Sie den Wert expires_in , um zu bestimmen, wann Sie einen Ersatz anfordern sollten. Token-Anfragen auf Kontoebene unterstützen assume_group nicht. Siehe Rolle annehmen.

Schritt 5: Überprüfen Sie den Zugriff des Tokens

Führen Sie diese Prüfungen in der vertrauenswürdigen Umgebung durch, bevor Sie das Token dem Agenten zur Verfügung stellen.

Zuerst sollte man eine Ausgangsbasis mit einem Token für die eigene Identität des Service-Principals ermitteln. Wiederhole die Anfrage in Schritt 4 ohne den Parameter assume_group und setze DATABRICKS_TOKEN vorübergehend auf dieses Token. Führen Sie beide Abfragen in diesem Schritt aus und überprüfen Sie, ob sie erfolgreich sind. Setzen Sie DATABRICKS_TOKEN dann wieder auf das rollenbezogene Token und wiederholen Sie die Prüfungen.

Support-Tickets lesen

Führe diese Anfrage mit dem rollenbezogenen Token aus:

curl --request POST \
  --url "$DATABRICKS_HOST/api/2.0/sql/statements" \
  --header "Authorization: Bearer $DATABRICKS_TOKEN" \
  --header 'Content-Type: application/json' \
  --data "{
    \"warehouse_id\": \"$DATABRICKS_SQL_WAREHOUSE_ID\",
    \"statement\": \"SELECT * FROM support.tickets.open_cases LIMIT 10\",
    \"wait_timeout\": \"50s\"
  }"

Die Abfrage ist erfolgreich, weil die Rolle support.tickets lesen kann. Überprüfen Sie, ob das status.state der Antwort SUCCEEDED ist. Wenn es RUNNING oder PENDING ist, verwenden Sie das zurückgegebene statement_id, um das Ergebnis mit demselben Token abzurufen:

curl --request GET \
  --url "$DATABRICKS_HOST/api/2.0/sql/statements/<statement-id>" \
  --header "Authorization: Bearer $DATABRICKS_TOKEN"

Siehe Statement Execution API: Run SQL on warehouses für den Status von Anweisungen und die Verarbeitung von Ergebnissen.

Überprüfen Sie, ob kein Zugriff auf Kunden-PII möglich ist

Verwenden Sie denselben rollenbezogenen Token und dasselbe Warehouse, führen Sie Folgendes aus:

curl --request POST \
  --url "$DATABRICKS_HOST/api/2.0/sql/statements" \
  --header "Authorization: Bearer $DATABRICKS_TOKEN" \
  --header 'Content-Type: application/json' \
  --data "{
    \"warehouse_id\": \"$DATABRICKS_SQL_WAREHOUSE_ID\",
    \"statement\": \"SELECT 1 FROM support.customers.contact_details LIMIT 1\",
    \"wait_timeout\": \"50s\"
  }"

Wenn die Anweisung noch läuft, rufen Sie das Ergebnis wie im vorherigen Abschnitt beschrieben ab. Die Abfrage schlägt mit einem Berechtigungsfehler in status.errorfehl, obwohl sie mit dem eigenen Token des Serviceprinzipals erfolgreich ist. Eine HTTP-Erfolgsantwort allein bedeutet nicht, dass die Anfrage erfolgreich war. Eine fehlende Tabelle, ein abgelaufenes Token oder ein Warehouse-Fehler belegen nicht, dass die Datenrechte der Rolle korrekt konfiguriert sind.

Überprüfen Sie die Audit-Zuordnung

Verwenden Sie einen Audit-Reader mit dem in Audit-Zuordnung überprüfen beschriebenen Zugriff. Inspizieren Sie die Testabfrage-Ereignisse in system.access.audit: identity_metadata.run_as identifiziert die autorisierende Rolle, run_as_display_name enthält role-support-agent, und run_by identifiziert den Dienstprinzipal, der die Anfrage initiiert hat. Die Prüfungsdaten werden den ganzen Tag über aktualisiert, sodass ein aktuelles Ereignis möglicherweise nicht sofort auftaucht. Siehe Referenz zu Identitätsmetadaten.

Schritt 6: Konfigurieren Sie den Agenten

Konfigurieren Sie den Azure Databricks-Client des Agenten mit der Workspace-URL und dem verifizierten rollenbezogenen Token. Stellen Sie dem Agenten nur dieses Token zur Verfügung, nicht das OAuth-Geheimnis des Dienstprinzipals oder dessen nicht bereichsgebundenes Token. Der rollenbezogene Token begrenzt Anfragen, die mit diesem Token gestellt werden. Sie entfernt die Berechtigungen des Service-Principals in anderen Sitzungen nicht.

Für einen Agenten, der das Databricks SDK für Python verwendet, setze DATABRICKS_TOKEN und DATABRICKS_HOST in der Umgebung des Agenten und initialisiere dann den Client:

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

Das SDK liest das Token aus der Umgebung mittels unified authentication. Die Bereitstellung eines Zugriffstokens liefert dem SDK nicht die Zugangsdaten, die es braucht, um ein neues Token anzufordern. Für einen lang laufenden Agenten sollte eine vertrauenswürdige Komponente vor Ablauf des Tokens ein rollenbezogenes Ersatz-Token anfordern und bereitstellen.

Optional: Verwenden Sie das Konto eines Entwicklers

Für lokale Tests mit User-to-Machine (U2M)-Authentifizierung gewähren Sie einem teilnehmenden Entwickler die Assume-Berechtigung für role-support-agent, wie in Schritt 3. Der Entwickler installiert die Databricks-CLI wie in Install or update the Databricks CLI beschrieben und authentifiziert sich dann mit einer eigenen Anmeldung und einem separaten Profil:

databricks auth login --host <workspace-url> --profile support-agent

Der Entwickler wählt role-support-agent im Browser unter Autorisieren als... und klickt auf Weiter, dann ruft er das Token für dieses Profil ab:

databricks auth token --profile support-agent

Der Entwickler verwendet das zurückgegebene access_token als DATABRICKS_TOKEN für die rollenbezogenen Abfrageprüfungen in Schritt 5. Audit-Ereignisse für diese Anfragen identifizieren den Entwickler als run_by. Das von der Databricks-CLI zurückgegebene Token läuft ab. Der Entwickler holt bei Bedarf ein neues Token ab. Siehe API (OAuth Access Tokens).

Aufräumen

Für einen temporären Test entferne die Token-Konfiguration des Agenten und widerrufe die Erteilung der für den Test erstellten Assume-Berechtigung, wenn du abgeschlossen bist. Bevor Sie die Rolle löschen, prüfen Sie, ob sie Assets besitzt oder von anderen Workloads genutzt wird.

Nächste Schritte

Resource	Description
Einschränkungen der rollenbasierten Zugriffssteuerung (RBAC)	Überprüfen Sie, welche Funktionen nicht unterstützt werden oder sich anders verhalten, wenn Sie in einer Rolle agieren.
RBAC-Rollen wechseln	Verwenden Sie andere unterstützte Methoden, um eine Rolle zu übernehmen.