Åtkomstkontroll på dokumentnivå i Azure AI-sökning

Note

Azure AI-sökning är tillgängligt via Azure-portalen, REST-API:er och Azure-SDK:er. Den ligger också till grund för Foundry IQ, det hanterade kunskapsskiktet som omvandlar företagsinnehåll till återanvändbara, behörighetsmedvetna kunskapsbaser för agenter i Microsoft Foundry-portalen.

Important

Funktioner, funktioner eller egenskaper som har markerats (förhandsversion) omfattas inte av ett serviceavtal, rekommenderas inte för produktionsarbetsbelastningar och kan ändras eller begränsas innan de blir allmänt tillgängliga. Villkoren för Azure AI-sökning förhandsgranskning gäller för alla förhandsgranskningsfunktioner, oavsett om de är fristående eller en del av en allmänt tillgänglig funktion.

Azure AI-sökning stöder åtkomstkontroll på dokumentnivå, vilket gör det möjligt för organisationer att framtvinga detaljerade behörigheter på dokumentnivå, från datainmatning till frågekörning. Den här funktionen är viktig för att skapa säkra AI-agentiska system som jordar data, hämtningsförhöjda genereringsprogram (RAG) och lösningar för företagssökning som kräver auktoriseringskontroller på dokumentnivå.

Metoder för åtkomstkontroll på dokumentnivå

Azure AI-sökning innehåller fyra primära metoder för att framtvinga behörigheter på dokumentnivå, som var och en passar för olika datakällor och identitetsmodeller.

Angreppssätt	Beskrivning
Säkerhetsfilter	Strängjämförelse. Ditt program skickar en användar- eller gruppidentitet som en sträng som fyller i ett filter på en fråga, exklusive dokument som inte matchar strängen. Säkerhetsfilter är en teknik för att uppnå åtkomstkontroll på dokumentnivå. Den här metoden är inte bunden till ett API så du kan använda valfri version eller paket.
POSIX-liknande ACL/RBAC-omfång (förhandsversion)	Microsoft Entra-säkerhetshuvudkontot bakom frågetokenen jämförs mot behörighetsmetadata för dokument som returneras i sökresultaten, och dokument som inte har motsvarande behörigheter exkluderas. Behörigheter för åtkomstkontrollistor (ACL) gäller för Azure Data Lake Storage (ADLS) Gen2-kataloger och -filer. Rollbaserad åtkomstkontroll (RBAC) gäller för ADLS Gen2-innehåll och för Azure blobar. Inbyggt stöd för identitetsbaserad åtkomst på dokumentnivå är i förhandsversion, tillgängligt i REST-API:er och förhandsversion Azure SDKs paket som tillhandahåller funktionen. Om du vill ha bevis på funktionsstöd kan du läsa supportinformationen för SDK-versionen.
Microsoft Purview känslighetsetiketter (förhandsversion)	Indexeraren extraherar känslighetsetiketter som definierats i Microsoft Purview från datakällor som stöds (Azure Blob Storage, ADLS Gen2, SharePoint i Microsoft 365, OneLake). Dessa etiketter lagras som metadata och utvärderas vid frågetillfället för att framtvinga användaråtkomst baserat på Microsoft Entra token och Purview-principtilldelningar. Etiketter visas också via kunskapskällor och agentiskt hämtningssvar, vilket gör att AI-agenter och chattappar som använder en kunskapsbas kan ta emot samma etikettmedvetna filtrering. Den här metoden justerar Azure AI-sökning auktorisering med företagets Microsoft Information Protection modell.
SharePoint i Microsoft 365 ACL:er (förhandsversion)	Azure AI-sökning-indexerare extraherar behörighetsmetadata från SharePoint-innehåll som stöds och använder den för åtkomstkontroller vid frågetillfället. Information om innehåll, huvudnamn, grupprelationer, synkroniseringsbeteende och behörigheter som stöds finns i Använda en SharePoint indexerare för att mata in behörighetsmetadata.

För indexerade kunskapskällor ingestionPermissionOptions kan inte kombineras med assetStore. Därför är bildservern (förhandsversion) inte tillgänglig när inmatning av intern behörighet på dokumentnivå är aktiverad.

Välj en metod

Använd följande kriterier för att identifiera den metod som bäst passar din datakälla, identitetsmodell och efterlevnadskrav.

Scenario	Rekommenderat tillvägagångssätt	Varför
Anpassat identitetssystem, ett säkerhetsramverk som inte kommer från Microsoft eller ett index av push-modelltyp.	Säkerhetsfilter	API-agnostisk, allmänt tillgänglig och baserad på enkel strängmatchning.
Innehåll i ADLS Gen2 eller Azure Blob Storage med befintliga ACL- eller RBAC-tilldelningar.	POSIX-liknande ACL/RBAC-omfång	Inbyggd integration med Microsoft Entra; åtkomstkontroll vid frågetillfället använder behörighetsmetadata som skrivs till indexet av den dokumenterade synkroniseringsmekanismen.
Företagsinnehåll som redan styrs av Microsoft Purview informationsskyddsprinciper.	Microsoft Purview-känslighetsetiketter	Återanvänder centraliserade klassificerings- och principtilldelningar över Azure AI-sökning.
Innehåll som kommer från SharePoint i Microsoft 365 (bibliotek, listor, ASPX-webbplatssidor).	SharePoint i Microsoft 365 ACL:er	Respekterar inbyggda SharePoint behörigheter, inklusive SharePoint webbplatsgrupper.

Mönster för säkerhetstrimning med hjälp av filter

För scenarier där intern ACL/RBAC-omfångsintegrering inte är genomförbar använder du säkerhetssträngfilter för att trimma resultat baserat på undantagskriterier. Mönstret innehåller följande komponenter:

Om du vill lagra användar- eller gruppidentiteter skapar du ett strängfält i indexet.
Läs in indexet med hjälp av källdokument som innehåller associerade ACL:er.
Inkludera ett filteruttryck i din frågelogik för matchning av strängen.
Under frågestunden hämtas uppringarens identitet.
Skicka in anroparens identitet som filtersträng.
Resultaten trimmas för att exkludera matchningar som inte innehåller användar- eller gruppidentitetssträngen.

Du kan använda PUSH- eller pull-modell-API:er. Eftersom den här metoden är API-agnostisk behöver du bara bekräfta att indexet och frågan har giltiga strängar (identiteter) för filtreringssteget.

Den här metoden är användbar för system med anpassade åtkomstmodeller eller icke-Microsoft säkerhetsramverk. Mer information om den här metoden finns i Säkerhetsfilter för att trimma resultat i Azure AI-sökning.

Mönster för inbyggt stöd för POSIX-liknande ACL- och RBAC-omfångsbehörigheter (förhandsversion)

Inbyggt stöd baseras på Microsoft Entra användare och grupper som är kopplade till dokument som du vill indexeras och fråga efter.

Azure Data Lake Storage (ADLS) Gen2-containrar stöder ACL:er på containern och på filer. För ADLS Gen2 stöds RBAC-omfångsbevarande på dokumentnivå internt när du använder en ADLS Gen2-indexerare eller en Blob-kunskapskälla (stöder ADLS Gen2) och ett förhandsversions-API för att mata in innehåll. För Azure-blobar med hjälp av Azure blobindexerare eller en kunskapskälla sker bevarande av RBAC-omfång på containernivå.

För ACL-skyddat innehåll använder du gruppåtkomst över enskild användaråtkomst för enkel hantering. Mönstret innehåller följande komponenter:

Börja med dokument eller filer som har ACL-tilldelningar.
Aktivera behörighetsfilter i indexet.
Lägg till ett behörighetsfilter i ett strängfält i ett index.
Läs in indexet med källdokument som har associerade ACL:er.
Fråga indexet och lägg till x-ms-query-source-authorization i begärandehuvudet.

Klientappen får läsbehörighet till indexet via rollen Search Index Data Reader eller Search Index Data Contributor . Åtkomst vid frågetillfället bestäms av metadata för användar- eller gruppbehörighet i det indexerade innehållet. Frågor som innehåller ett behörighetsfilter skickar en användar- eller grupptoken som x-ms-query-source-authorization i begärandehuvudet. När du använder behörighetsfilter vid frågetillfället söker Azure AI-sökning efter två saker:

Först söker den efter behörigheten Search Index Data Reader som gör att klientprogrammet kan komma åt indexet.
För det andra, med tanke på den extra token på begäran, söker den efter användar- eller gruppbehörigheter för dokument som returneras i sökresultat, exklusive alla som inte matchar.

Om du vill hämta behörighetsmetadata till indexet använder du PUSH-modell-API:et och push-överför alla JSON-dokument till sökindexet, där nyttolasten innehåller ett strängfält som tillhandahåller POSIX-liknande ACL:er för varje dokument. Den viktiga skillnaden mellan den här metoden och säkerhetstrimningen är att behörighetsfiltermetadata i indexet och frågan identifieras som Microsoft Entra ID autentisering, medan lösningen för säkerhetstrimning är enkel strängjämförelse. Du kan också använda Graph SDK för att hämta identiteterna.

Du kan också använda pull-modell-API:erna (indexeraren) om datakällan är Azure Data Lake Storage (ADLS) Gen2 och koden anropar ett förhandsversions-API för indexering.

Hämta metadata för ACL-behörigheter under datainmatningsprocessen (förhandsversion)

Hur du hämtar ACL-rättigheter varierar beroende på om du överför en dokumentnyckel eller använder ADLS Gen2-indexerare.

Börja med ett förhandsversions-API som innehåller funktionen:

REST API för förhandsversion 2026-08-01
Azure SDKs för Python förhandsversionspaket. Kontrollera ändringsloggen för den senaste förhandsversionen som stöder inmatning av ACL- och RBAC-omfång.
Azure SDKs för .NET förhandsversionspaket. Kontrollera ändringsloggen för den senaste förhandsversionen som stöder inmatning av ACL- och RBAC-omfång.
Azure SDKs för Java förhandsversionspaket. Kontrollera ändringsloggen för den senaste förhandsversionen som stöder inmatning av ACL- och RBAC-omfång.

För push-modellmetoden:

Bekräfta att indexschemat har skapats med en förhandsversion eller förhandsversions-SDK och att schemat har behörighetsfilter.
Överväg att använda Microsoft Graph SDK för att hämta grupp- eller användaridentiteter.
Använd Index Documents eller motsvarande Azure SDKs API för att skicka dokument och tillhörande behörighetsmetadata till sökindexet.

För pull-modellens ADLS Gen2-indexerare eller blob (ADLS Gen2) kunskapskälla:

Kontrollera att filer i katalogen skyddas med åtkomstkontrollmodellen ADLS Gen2.
Använd Indexers – Skapa (REST API), Knowledge Sources – Create (REST API) eller motsvarande Azure SDKs API för att skapa indexeraren, index och datakällan.

Om din kompetensuppsättning delar upp dokument, till exempel med färdigheten Textdelning för integrerad vektorisering, flyttas behörighetsmetadatafälten från indexeringsfältmappningar till indexprojektioner. Se Välj var du vill fylla I ACL-fält.

Mönster för SharePoint i Microsoft 365 grundläggande inmatning av ACL-behörigheter (förhandsversion)

För indexerat SharePoint innehåll kan Azure AI-sökning lagra källbehörigheter som metadata och använda dem för att filtrera frågeresultat. Du kan komma åt den här funktionen i förhandsversionen via SharePoint i Microsoft 365 indexeraren och det senaste REST API:et eller ett motsvarande SDK-paket för förhandsversion.

Behörighetskrav, grupprelationer som stöds, behörighetssynkronisering och begränsningar finns i Använda en SharePoint indexerare för att mata in behörighetsmetadata.

Om din kompetensuppsättning delar upp dokument (till exempel med färdigheten Textdelning för integrerad vektorisering) flyttas ACL-fälten från indexeringsfältmappningar till indexprojektioner. Se Välj var du vill fylla I ACL-fält.

Mönster för Microsoft Purview känslighetsetiketter (förhandsversion)

När du aktiverar etikettinmatning extraherar Azure AI-sökning känslighetsmetadata från datakällor som stöds. Dessa datakällor omfattar Azure Blob Storage, Azure Data Lake Storage Gen2 (ADLS Gen2), SharePoint i Microsoft 365 och Microsoft OneLake. De extraherade etiketterna lagras i indexet tillsammans med dokumentinnehåll.

Vid frågetillfället kontrollerar Azure AI-sökning varje dokuments känslighetsetikett, användarens Microsoft Entra token och organisationens Purview-principer för att fastställa åtkomst. Systemet returnerar endast dokument om användarens identitets- och etikettbaserade behörigheter tillåter åtkomst enligt de konfigurerade Purview-principerna.

Det här mönstret innehåller följande komponenter:

Konfigurera index, datakälla och indexerare (i schemaläggningssyfte) med hjälp av det senaste rest-API:et för förhandsversionen eller en förhandsversions-SDK som stöder Purview-etikettinmatning.
Aktivera en systemtilldelad hanterad identitet i söktjänsten. Användartilldelade hanterade identiteter stöds inte för extrahering av Purview-etiketter – tjänstens egen identitet måste innehålla de utökade Purview-behörigheterna. Låt sedan den globala administratören eller den privilegierade rolladministratören bevilja nödvändig åtkomst så att söktjänsten kan autentisera med Microsoft Purview och extrahera etikettmetadata.
Använd känslighetsetiketter på dokument innan du indexerar så att systemet kan identifiera och bevara dem under inmatningen.
Vid frågetillfället bifogar du en giltig Microsoft Entra token via rubriken x-ms-query-source-authorization till varje frågebegäran. Azure AI-sökning utvärderar token och associerade etikettmetadata för att framtvinga etikettbaserad åtkomstkontroll.

Purview-tillämpning av känslighetsetiketter är begränsad till scenarier med en enda klientorganisation och kräver RBAC-autentisering. Under förhandsversionen stöds den endast via REST API och Azure-SDK:er. API:erna för automatisk komplettering och förslag är för närvarande inte tillgängliga för Purview-aktiverade index.

Där känslighetsetiketter visas

Innan systemet kan framtvinga etiketter vid frågetillfället eller returnera dem i hämta svar måste du först synkronisera etikettmetadata till indexet. Båda användningsvägarna som beskrivs i detta avsnitt är beroende av detta synkroniseringssteg. Du kan synkronisera etiketter antingen genom att konfigurera en Azure AI-sökning indexerare direkt mot en datakälla som stöds eller genom att aktivera motsvarande inmatningsalternativ när du skapar en kunskapskälla. I båda fallen måste din miljö uppfylla förutsättningarna för konfigurationen av synkronisering av känslighetsetikettmetadata (hanterad identitet, RBAC för söktjänsten och de nödvändiga behörigheterna för Microsoft Purview och datakällan). Mer information om hur du konfigurerar en komplett indexerare finns i Använd Azure AI-sökning-indexerare för att importera känslighetsetiketter från Microsoft Purview. För kunskapskälladriven inmatning anger du ingestionPermissionOptions att inkludera sensitivityLabel när kunskapskällan skapas.

När du har synkroniserat etiketter använder två frågesökvägar samma indexerade etikettmetadata. Välj den sökväg som matchar hur programmet anropar Azure AI-sökning:

API för direkta frågor (/docs/search): Bifoga användarens Microsoft Entra-token i x-ms-query-source-authorization. Administratörer kan också utfärda utökade läsbegäranden för granskningsbara undersökningar. Information om konfiguration och exempel finns i Query-time enforcement of Microsoft Purview sensitivity labels.
Kunskapskällor och agentisk hämtning (MCP): Ange ingestionPermissionOptions att inkludera sensitivityLabel på kunskapskällan. Hämtningsåtgärden och MCP-verktyget knowledge_base_retrieve returnerar per referens sensitivityLabelInfo - och svarsnivå metadata.responseSensitivityLabelInfo som klienter kan använda för att visa banderoller och principtillämpning. Information om konfiguration finns i Skapa kunskapskälla och Granska metadata för känslighetsetiketter i hämtningssvar.

Om kunskapskällan pekar på ett segmenterat index, till exempel ett som fylls i via integrerad vektorisering eller en anpassad färdighet för textdelning, måste kunskapsuppsättningen också projicera känslighetsetiketten för varje segmentrad. Utan den här projektionen filtreras inte referenser på segmentnivå.

Mer information finns i Använd Azure AI-sökning indexerare för att mata in Microsoft Purview känslighetsetiketter.

Framtvinga behörigheter på dokumentnivå vid frågetid (förhandsversion)

Tokenbaserad frågetillämpning är en övergripande kapacitet som omfattar POSIX-liknande ACL- och RBAC-omfång, känslighetsetiketter i Microsoft Purview och ACL-mönster för SharePoint i Microsoft 365. Genom att använda inbyggda tokenbaserade frågor verifierar Azure AI-sökning anroparens Microsoft Entra token för varje begäran och trimmar resultatuppsättningar till endast de dokument som anroparen har behörighet att läsa enligt dokumentets ACL:er, så länge dokumentets ACL-metadata synkroniseras med indexet.

När du kopplar användarens token till en frågebegäran via rubriken x-ms-query-source-authorization Azure AI-sökning:

Extraherar användar-, grupp- och scopeanspråk från tokenen.
Jämför dessa anspråk med behörighetsmetadata som lagras tillsammans med indexerade dokument (ACL-poster, RBAC-omfång, Purview-etiketttilldelningar eller SharePoint ACL).
Returnerar endast dokument vars synkroniserade behörighetsmetadata ger anroparen åtkomst.

Frågetidsframtvingande utvärderar anroparens Microsoft Entra anspråk mot behörighetsmetadata som redan lagras i indexet. Behörighetsändringar i källsystemet (Microsoft Entra gruppmedlemskap, ADLS Gen2-ACL:er, Purview-etiketttilldelningar eller SharePoint ACL:er) återspeglas bara i sökresultaten efter att metadata har synkroniserats med indexet via den källspecifika mekanismen, till exempel en efterföljande indexeringskörning, en push-API-uppdatering eller en Purview-driven uppdatering. För SharePoint hämtas ACL-ändringar på objekt med unika behörigheter stegvis för varje lyckad indexeringskörning med början i REST API:et 2026-05-01-preview, medan ändringar som ärvs från överordnade omfång (webbplats, bibliotek, lista eller mapp) kräver en explicit uppdatering. Mer information finns i Synkronisera behörigheter mellan indexerat innehåll och källinnehåll.

Anvisningar för implementering av frågor från slutpunkt till slutpunkt finns i Query-time ACL och RBAC-tillämpning i Azure AI-sökning.

Fördelar med åtkomstkontroll på dokumentnivå

Intern åtkomstkontroll på dokumentnivå i Azure AI-sökning ger konkreta fördelar jämfört med filtrering på programsidan:

Eliminerar anpassad behörighetskod: Du behöver inte implementera kapslad gruppmatchning, flernivå-ACL-bläddrande eller trimning efter frågor i ditt program. Azure AI-sökning hanterar jämförelsen och filtreringen under frågekörningen.
Justeringar med befintliga efterlevnadskontroller: Återanvända Microsoft Entra, Microsoft Purview och SharePoint behörighetsmetadata hjälper till att hålla sökresultaten i linje med källidentitetssystemet. Granska behörighetssynkroniseringsmodellen för varje källa för att förstå dess begränsningar.
Respekterar källbehörigheter efter varje ACL-synkronisering: För tokenbaserade metoder (ACL, RBAC-omfång, Purview-etiketter, SharePoint ACL:er) använder frågetidstillämpning de behörighetsmetadata som den dokumenterade källspecifika synkroniseringsmekanismen (indexerarekörning, push-API-uppdatering eller Purview-uppdatering) redan har skrivit till indexet.
Förbättrar prestanda jämfört med trimning efter fråga: Filtrering i sökpipelinen går snabbare än att läsa in större resultatuppsättningar i ditt program och trimma det, särskilt vid höga frågevolymer.
Återanvänder din befintliga identitetsinfrastruktur: Microsoft Entra- och SharePoint-identiteter förblir den auktoritativa källan för åtkomstbeslut, vilket minskar identitetsduplicering och den administrativa overheaden för att underhålla en parallell behörighetsdatabas.

Självstudier och exempel

Utforska åtkomstkontroll på dokumentnivå i Azure AI-sökning med fler artiklar och exempel.

Feedback

Var den här sidan till hjälp?

Uppdaterades senast 2026-09-17