Handledning: Begränsa en AI-agents åtkomst med RBAC

Använd rollbaserad åtkomstkontroll (RBAC) för att begränsa en AI-agents tillgång till den data och de resurser den behöver för en specifik uppgift. Ge agenten en OAuth-token med behörighet för en roll. Förfrågningar som görs med den token använder rollens behörigheter istället för de bredare behörigheterna hos den autentiserande användaren eller tjänstens säkerhetsobjekt.

Scenario

En AI-supportagent behöver sammanfattningar och status av ärenden, men inte kundkontaktuppgifter som innehåller personligt identifierbar information (PII). Dess service principal för autentisering har bredare åtkomst och kan läsa båda datamängderna.

I detta exempel innehåller schemat support.tickets sammanfattningar av ärenden och status utan kund-PII. Kundkontaktuppgifter sparas separat i support.customers.contact_details.

Du skapar role-support-agent, ger den läsåtkomst till support.tickets, och ger tjänstens huvudnamn Assume-behörigheten på den. Med en token kopplad till den rollen kan agenten läsa supportärenden men kan inte komma åt kundkontaktuppgifter.

Rollen kan ärva datarättigheter från föräldragrupper, och katalog- eller schemabehörigheter kan gälla för alla tabeller under dem. För detta exempel, kontrollera att dessa behörigheter inte ger rollen tillgång till kundkontakttabellen. Se Rättighetsarv. Att ändra delade behörigheter påverkar andra användare och roller, så använd en testarbetsyta istället för att ta bort andra användares åtkomst.

Denna handledning är för egenutvecklade, självhostade eller tredjepartsagenter som accepterar en OAuth-åtkomsttoken som du tillhandahåller. För agenter som distribueras på Databricks Apps, använd den inbyggda appen eller användarbehörighet. Se Autentisering för agenter.

Prerequisites

• En arbetsyta med Unity Catalog aktiverat och RBAC aktiverat. Se Aktivera RBAC.
• Behörighet som kontoadministratör eller arbetsyteadministratör för att skapa rollen, ge Assume-behörigheten och tilldela den till arbetsområdet. Se Vem kan hantera grupper?.
• Ägande av, eller MANAGE, katalogen support.
• Arbetsyteadministratörsbehörighet eller behörigheten Kan hantera på SQL-lagret som används i exemplet.
• Befintliga tabeller support.tickets.open_cases och support.customers.contact_details. Använd fiktiv testdata och ersätt med dina egna namn om det behövs.
• En tjänsteprincip som har tilldelats arbetsytan, med Databricks SQL-åtkomst, kan använda SQL-lagret och har behörighet att fråga båda tabellerna. Den behöver en OAuth-hemlighet som möjliggör sql-scope för maskin-till-maskin (M2M)-autentisering. Se Steg 1: Skapa en OAuth-hemlighet.
• curl I en betrodd miljö där du kan begära och testa tokens.
• En revisionsläsare med åtkomst till system.access.audit för att verifiera agentens aktivitet under rollen. Se Verifiera granskningsattribuering.

Använd en Azure Databricks managed service principal för detta OAuth M2M-exempel. Hanterade tjänstens huvudnamn i Microsoft Entra ID använder en annan autentiseringskonfiguration. Se Auktorisera tjänstens huvudnamnsåtkomst till Azure Databricks med OAuth.

Steg 1: Skapa rollen

För denna handledning, skapa en tom kontogrupp som fungerar som rollen.

Kontokonsol

1. Logga in på kontokonsolen som kontoadministratör.
2. I sidofältet klickar du på Användarhantering.
3. På fliken Grupper klickar du på Lägg till grupp.
4. Ange role-support-agent. Lägg inte till medlemmar.
5. Klicka på Bekräfta.
6. Tilldela gruppen till arbetsytan med Databricks SQL-åtkomst. Se Tilldela en grupp till en arbetsyta.

Administratörsinställningar för arbetsyta

1. Som administratör för arbetsytan, logga in på testarbetsytan.
2. Klicka på ditt användarnamn i det övre fältet och välj Inställningar.
3. Klicka på fliken Identitet och åtkomst .
4. Bredvid Grupper klickar du på Hantera.
5. Klicka på Lägg till grupp, sedan Lägg till ny.
6. Ange role-support-agent och välj Databricks SQL-åtkomst.
7. Klicka på Lägg till. Lägg inte till medlemmar.

Detta tilldelar också gruppen till arbetsytan och ger dig behörighet att hantera den.

Databricks SQL-åtkomsträtt ger tillgång till Databricks SQL-funktioner, inklusive instrumentpaneler, frågor och SQL warehouses. Exemplet använder SQL-frågor. Om din agent också behöver kärnfunktioner i arbetsytan såsom anteckningsböcker, jobb, modeller eller pipelines, ge Workspace-åtkomst. Se Åtkomsträttigheter. Du konfigurerar datarättigheter och data warehouse-behörigheter i steg 2.

I detta exempel ger du Assume-behörigheten separat i stället för att lägga till tjänstens huvudnamn som medlem. Medlemskap lägger också till gruppens behörigheter till service principals egen identitet.

Steg 2: Ge rollen tillgång till supportärenden

Som katalogägare eller användare med MANAGE på support, kör:

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

Som administratör för arbetsytan eller användare med behörigheten Kan hantera för lagret, ge rollen tillgång till lagret:

1. I arbetsytans sidofält klickar du på SQL Warehouses.
2. Klicka på på kebabmenyn bredvid lagret och klicka sedan på Behörigheter.
3. Lägg till role-support-agent med Kan användas.

Behörigheten på schemanivå SELECT gäller för alla nuvarande och framtida tabeller och vyer i support.tickets. Den ger inte tillgång till support.customers eller andra scheman. För att begränsa rollen till en tabell, ge SELECT för den tabellen istället. Se avsnitt Hantera privilegier i Unity Catalog.

Steg 3: Ge tillstånd att anta rollen

Ge service principal Assume-behörigheten med någon av följande metoder:

Kontokonsol

1. Som kontoadministratör, öppna kontokonsolen och klicka på Användarhantering.
2. På fliken Grupper , klicka på role-support-agent.
3. Klicka på fliken Behörigheter och sedan Bevilja åtkomst.
4. Sök efter och välj service principal, välj Överta och klicka på Spara.

Administratörsinställningar för arbetsyta

1. Som administratör för arbetsytan med behörighet Hantera i rollen, öppna Inställningar>Identitet och åtkomst i testarbetsytan.
2. Bredvid Grupper, klicka på Hantera, och välj sedan role-support-agent.
3. Klicka på Behörigheter, sedan Bevilja åtkomst.
4. Sök efter och välj tjänstens huvudnamn, välj Överta och klicka på Spara.

Steg 4: Begär en token med rollomfång

I din betrodda token-förfrågningsmiljö, ställ in dessa miljövariabler:

• DATABRICKS_HOST: arbetsområdets URL, inklusive https:// och utan ett följande snedstreck.
• CLIENT_ID och CLIENT_SECRET: tjänstens huvudnamns applikations-ID och OAuth-hemlighet.
• ROLE_GROUP_ID: den numeriska ID:n för role-support-agent. En kontoadministratör kan hitta den i slutet av gruppens URL i kontokonsolen. Kontoadministratörer, arbetsytsadministratörer och gruppansvariga kan också hämta gruppens id via Account Groups API.
• DATABRICKS_SQL_WAREHOUSE_ID: Lagerets ID som tilldelades i steg 2. Den följer /sql/1.0/warehouses/ i lagrets HTTP-sökväg. Se Hämta anslutningsinformation för en Azure Databricks-beräkningsresurs.

Begär en arbetsytenivåtoken med parametern assume_group och OAuth-scope sql. Omfattningen begränsar token till SQL-API:er. Rollens dataprivilegier avgör vilka tabeller den kan fråga i. Se Scoped OAuth secrets.

För att begära token, kör:

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"

Ställ DATABRICKS_TOKEN in på access_token värdet från svaret. Använd expires_in värdet för att avgöra när du ska begära en ersättning. Tokenförfrågningar på kontonivå stöder inte assume_group. Se Byt roll.

Steg 5: Verifiera åtkomsten för token

Kör dessa kontroller i den betrodda miljön innan du tillhandahåller token till agenten.

Först, skaffa en baslinje med en token för service principalens egen identitet. Upprepa förfrågan i steg 4 utan parametern assume_group och sätt DATABRICKS_TOKEN tillfälligt på den tokenen. Kör båda frågekörningarna i detta steg och verifiera att de lyckas. Sedan ställer du tillbaka DATABRICKS_TOKEN till det rollbegränsade tokenet och upprepar kontrollerna.

Läs supportärenden

Kör denna förfrågan med den rollbegränsade tokenen:

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\"
  }"

Sökningen lyckas eftersom rollen kan läsa support.tickets. Kontrollera att svarets status.state är SUCCEEDED. Om det är PENDING eller RUNNING, använd den returnerade statement_id för att hämta resultatet med samma token:

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

Se Statement Execution API: Kör SQL på warehouses för instruktionsstatus och resultathantering.

Kontrollera att åtkomst till kund-PII nekas

Med samma rollbegränsade token och warehouse, kör:

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\"
  }"

Om instruktionen fortfarande körs, hämta resultatet som beskrivits i föregående avsnitt. Frågan misslyckas med ett behörighetsfel i status.error, även om den lyckas med tjänstens huvudnamns egen token. Ett lyckat HTTP-svar ensamt betyder inte att förfrågan lyckades. En saknad tabell, en utgången token eller ett lagerhusfel innebär inte att rollens databehörigheter är korrekt konfigurerade.

Kontrollera attribuering för revision

Använd en granskningsläsare med åtkomsten som beskrivs i Verifiera granskningsattribuering. Inspektera testfrågehändelserna i system.access.audit: identity_metadata.run_as identifierar den auktoriserande rollen, run_as_display_name innehåller role-support-agent, och run_by identifierar tjänstens säkerhetsobjekt som initierade förfrågan. Granskningsdata uppdateras under dagen, så en nyligen inträffad händelse kanske inte dyker upp omedelbart. Se Identitetsmetadatareferens.

Steg 6: Konfigurera agenten

Konfigurera agentens Azure Databricks-klient med URL:en för arbetsytan och den verifierade role-scoped token. Lämna endast den token till agenten, inte tjänstens säkerhetsobjekts OAuth-hemlighet eller dess token utan omfång. Den rollbegränsade token begränsar förfrågningar som görs med den token. Den tar inte bort service principals behörigheter i andra sessioner.

För en agent som använder Databricks SDK för Python, sätt DATABRICKS_HOST och DATABRICKS_TOKEN i agentens miljö, initiera sedan klienten:

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

SDK:n läser token från miljön med unified authentication. Att tillhandahålla en accesstoken ger inte SDK:n de uppgifter som behövs för att begära en ny token. För en långvarig agent, ordna så att en betrodd komponent begär och tillhandahåller en ersättningstoken med rollomfång innan tokenen går ut.

Valfritt: Använd en utvecklares identitet

För lokal testning med användar-till-maskin-autentisering (U2M), ge en deltagande utvecklare behörigheten "Assume" på role-support-agent som i steg 3. Utvecklaren installerar Databricks CLI som beskrivs i Installera eller uppdatera Databricks CLI, och autentiserar sedan med sin egen inloggning och en separat profil:

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

Utvecklaren väljer role-support-agent under Auktorisera som... i webbläsaren och klickar på Fortsätt, sedan hämtar utvecklaren tokenen för den profilen:

databricks auth token --profile support-agent

Utvecklaren använder returnerade access_token som DATABRICKS_TOKEN för rollbegränsade frågekontroller i steg 5. Granskningshändelser för dessa förfrågningar identifierar utvecklaren som run_by. Token som returneras av Databricks CLI går ut. Utvecklaren hämtar en ny token vid behov. Se API (OAuth-åtkomsttokens).

Rensa

För ett tillfälligt test, ta bort agentens tokenkonfiguration och återkalla beviljandet av Assume-behörigheten som skapats för testet när du är klar. Innan du tar bort rollen, kontrollera om den äger tillgångar eller används av andra arbetslaster.

Nästa steg