Toegangsbeheer op documentniveau in Azure AI Zoeken

Note

Azure AI Zoeken is beschikbaar via de Azure-portal, REST API's en Azure-SDK's. Het vormt ook een basis voor Foundry IQ, de beheerde kennislaag die bedrijfsinhoud transformeert in herbruikbare, machtigingsbewuste knowledge bases voor agents in de Microsoft Foundry-portal.

Important

Functies, mogelijkheden of eigenschappen die zijn gemarkeerd (preview) vallen niet onder een service level agreement, worden niet aanbevolen voor productieworkloads en kunnen worden gewijzigd of beperkt voordat ze algemeen beschikbaar worden. De Azure AI Zoeken preview-voorwaarden zijn van toepassing op alle preview-functionaliteit, ongeacht of deze zelfstandig is of deel uitmaakt van een algemeen beschikbare functie.

Azure AI Zoeken ondersteunt toegangsbeheer op documentniveau, waardoor organisaties nauwkeurige machtigingen kunnen afdwingen op documentniveau, van gegevensopname via queryuitvoering. Deze mogelijkheid is essentieel voor het bouwen van beveiligde AI-agentische systemen voor het gronden van gegevens, het ophalen van augmented generation-toepassingen (RAG) en bedrijfszoekoplossingen waarvoor autorisatiecontroles op documentniveau zijn vereist.

Benaderingen voor toegangsbeheer op documentniveau

Azure AI Zoeken biedt vier primaire benaderingen voor het afdwingen van machtigingen op documentniveau, die elk geschikt zijn voor verschillende gegevensbronnen en identiteitsmodellen.

Aanpak Beschrijving
Beveiligingsfilters Tekenreeksvergelijking. Uw toepassing geeft een gebruikers- of groepsidentiteit door als een tekenreeks, waardoor een filter aan een query wordt toegevoegd, waardoor documenten die niet overeenkomen met de tekenreeks worden uitgesloten.

Beveiligingsfilters zijn een techniek voor het bereiken van toegangsbeheer op documentniveau. Deze benadering is niet gebonden aan een API, zodat u elke versie of elk pakket kunt gebruiken.
POSIX-achtige ACL-/RBAC-toepassingsgebieden (voorbeeldweergave) De Microsoft Entra-beveiligingsidentiteit die aan het querytoken ten grondslag ligt, wordt vergeleken met de metagegevens over machtigingen van documenten die in de zoekresultaten worden geretourneerd, waarbij documenten waarvoor de machtigingen niet overeenkomen, worden uitgesloten. ACL-machtigingen (Access Control List) zijn van toepassing op Azure Data Lake Storage (ADLS) Gen2-mappen en -bestanden. RBAC-bereiken (op rollen gebaseerd toegangsbeheer) zijn van toepassing op ADLS Gen2-inhoud en op Azure blobs.

Ingebouwde ondersteuning voor identiteitstoegang op documentniveau is in preview, beschikbaar in REST API's en preview-Azure SDK pakketten die de functie bieden. Voor bewijs van functieondersteuning raadpleegt u de details van de SDK-versieondersteuning.
Microsoft Purview gevoeligheidslabels (preview) De indexeerfunctie extraheert vertrouwelijkheidslabels die zijn gedefinieerd in Microsoft Purview uit ondersteunde gegevensbronnen (Azure Blob Storage, ADLS Gen2, SharePoint in Microsoft 365, OneLake). Deze labels worden opgeslagen als metagegevens en geëvalueerd tijdens de query om gebruikerstoegang af te dwingen op basis van Microsoft Entra tokens en Purview-beleidstoewijzingen. Labels worden ook beschikbaar gemaakt via kennisbronnen en de agentische retrievalrespons, zodat AI-agents en chat-apps die een kennisbank gebruiken, dezelfde labelbewuste filtering krijgen. Met deze benadering wordt Azure AI Zoeken autorisatie afgestemd op het Microsoft Information Protection model van uw onderneming.
SharePoint in Microsoft 365 ACLs (voorvertoning) Azure AI Zoeken-indexers extraheren machtigingsmetagegevens uit ondersteunde SharePoint-inhoud en gebruiken deze voor toegangscontroles tijdens query’s. Zie Een SharePoint indexeerfunctie gebruiken om metagegevens van machtigingen op te nemen voor ondersteunde inhoud, principals, groepsrelaties, synchronisatiegedrag en machtigingen.

Voor geïndexeerde kennisbronnen ingestionPermissionOptions kan niet worden gecombineerd met assetStore. Daarom is het leveren van afbeeldingen (preview) niet beschikbaar wanneer systeemeigen machtigingsopname op documentniveau is ingeschakeld.

Een benadering kiezen

Gebruik de volgende criteria om de aanpak te identificeren die het beste past bij uw gegevensbron, identiteitsmodel en nalevingsvereisten.

Scenario Aanbevolen aanpak Waarom
Aangepast identiteitssysteem, niet-Microsoft beveiligingsframework of een push-modelindex. Beveiligingsfilters API-agnostisch, algemeen beschikbaar en gebaseerd op eenvoudige tekenreeksvergelijking.
Inhoud in ADLS Gen2 of Azure Blob Storage met bestaande ACL- of RBAC-toewijzingen. POSIX-achtige ACL-/RBAC-bereiken Systeemeigen Microsoft Entra-integratie; afdwinging van querytijd maakt gebruik van machtigingsmetagegevens die zijn geschreven naar de index door het gedocumenteerde synchronisatiemechanisme.
Bedrijfsinhoud die al valt onder Microsoft Purview-beleidsregels voor informatiebeveiliging. Microsoft Purview gevoeligheidslabels Gebruikt gecentraliseerde classificatie- en beleidstoewijzingen in Azure AI Zoeken.
Inhoud die afkomstig is van SharePoint in Microsoft 365 (bibliotheken, lijsten, ASPX-sitepagina's). SharePoint in Microsoft 365 ACLs Respecteert de standaardmachtigingen van SharePoint, waaronder SharePoint-sitelidgroepen.

Patroon voor beveiligingsbeperkingen met behulp van filters

Voor scenario's waarin integratie van systeemeigen ACL-/RBAC-bereiken niet haalbaar is, gebruikt u filters voor beveiligingsreeksen om resultaten te knippen op basis van uitsluitingscriteria. Het patroon bevat de volgende onderdelen:

  • Als u gebruikers- of groepsidentiteiten wilt opslaan, maakt u een tekenreeksveld in de index.
  • Laad de index met brondocumenten die gekoppelde ACL's bevatten.
  • Neem een filterexpressie op in de querylogica om te zoeken naar overeenkomsten in de tekenreeks.
  • Haal tijdens de query de identiteit van de aanroeper op.
  • Geef de identiteit van de beller door als filtertekenreeks.
  • Resultaten worden ingekort om overeenkomsten uit te sluiten die de tekenreeks voor de gebruikers- of groepsidentiteit niet bevatten.

U kunt push- of pull-model-API's gebruiken. Omdat deze methode API-agnostisch is, hoeft u alleen te bevestigen dat de index en query geldige tekenreeksen (identiteiten) hebben voor de filtratiestap.

Deze benadering is handig voor systemen met aangepaste toegangsmodellen of niet-Microsoft beveiligingsframeworks. Zie Beveiligingsfilters voor het bijsnijden van resultaten in Azure AI Zoeken voor meer informatie over deze aanpak.

Patroon voor systeemeigen ondersteuning voor POSIX-achtige ACL- en RBAC-bereikmachtigingen (preview)

Systeemeigen ondersteuning is gebaseerd op Microsoft Entra gebruikers en groepen die zijn gekoppeld aan documenten die u wilt indexeren en opvragen.

Azure Data Lake Storage (ADLS) Gen2-containers ondersteunen ACL's in de container en op bestanden. Voor ADLS Gen2 wordt RBAC-bereikbehoud op documentniveau systeemeigen ondersteund wanneer u een ADLS Gen2-indexeerfunctie of een Blob-kennisbron (ondersteunt ADLS Gen2) en een preview-API gebruikt om inhoud op te nemen. Voor Azure-blobs met behulp van de Azure blob-indexeerfunctie of kennisbron, blijft het RBAC-bereik behouden op containerniveau.

Voor inhoud met ACL-beveiliging gebruikt u groepstoegang via afzonderlijke gebruikerstoegang om het beheer te vereenvoudigen. Het patroon bevat de volgende onderdelen:

Uw client-app ontvangt leesmachtigingen voor de index via de rol Search Index Data Reader of Inzender voor zoekindexgegevens . Toegang op querytijd wordt bepaald door metagegevens van gebruikers- of groepsmachtigingen in de geïndexeerde inhoud. Query's met een machtigingsfilter geven een gebruikers- of groepstoken door zoals x-ms-query-source-authorization in de aanvraagheader. Wanneer u machtigingsfilters op het moment van query's gebruikt, controleert Azure AI Zoeken op twee dingen:

  • Eerst wordt gecontroleerd op de machtiging Search Index Data Reader waarmee uw clienttoepassing toegang heeft tot de index.

  • Ten tweede wordt, met het extra token in de aanvraag, gecontroleerd op gebruikers- of groepsmachtigingen voor documenten die in de zoekresultaten worden weergegeven, waarbij alle worden uitgesloten die niet voldoen.

Als u machtigingenmetagegevens in de index wilt ophalen, gebruikt u de PUSH-model-API en pusht u JSON-documenten naar de zoekindex, waarbij de nettolading een tekenreeksveld bevat met POSIX-achtige ACL's voor elk document. Het belangrijkste verschil tussen deze aanpak en beveiligingsafknippen is dat de metagegevens van het machtigingsfilter in de index en query worden herkend als Microsoft Entra ID-authenticatie, terwijl de tijdelijke oplossing voor beveiligingsafknippen een eenvoudige stringvergelijking is. U kunt ook de Graph SDK gebruiken om de identiteiten op te halen.

U kunt ook de PULL-model-API's (indexeerfunctie) gebruiken als de gegevensbron is Azure Data Lake Storage (ADLS) Gen2 en uw code een preview-API aanroept voor indexering.

Metagegevens van ACL-machtigingen ophalen tijdens het gegevensopnameproces (preview)

Hoe u ACL-machtigingen ophaalt, is afhankelijk van of u een nettolading van documenten pusht of de ADLS Gen2-indexeerfunctie gebruikt.

Begin met een preview-API die de functie biedt:

Voor de benadering van het pushmodel:

  1. Controleer of uw indexschema is gemaakt met een preview- of voorlopige SDK en of het schema machtigingenfilters heeft.
  2. Overweeg het gebruik van de Microsoft Graph SDK om groeps- of gebruikersidentiteiten op te halen.
  3. Gebruik de Index Documents of equivalente Azure SDK-API om documenten en de bijbehorende machtigingsmetagegevens naar de zoekindex te pushen.

Voor de pull-model ADLS Gen2-indexeerbenadering of Blob (ADLS Gen2) kennisbron:

  1. Controleer of bestanden in de map zijn beveiligd met behulp van het ADLS Gen2-toegangsbeheermodel.
  2. Gebruik Indexers - Create (REST API), Knowledge Sources - Create (REST API) of een equivalente Azure SDK-API om de indexeerfunctie, index en gegevensbron te maken.

Als uw vaardighedenset documenten segmenteert, zoals met de vaardigheid Tekst splitsen voor geïntegreerde vectorisatie, worden de machtigingsmetagegevensvelden verplaatst van indexeerveldtoewijzingen naar indexprojecties. Zie Kies waar u ACL-velden wilt invullen.

Patroon voor het opnemen van basis ACL-machtigingen in SharePoint in Microsoft 365 (preview)

Voor geïndexeerde SharePoint inhoud kan Azure AI Zoeken bronmachtigingen opslaan als metagegevens en deze gebruiken om queryresultaten te filteren. U hebt toegang tot deze mogelijkheid in preview via de SharePoint in Microsoft 365 indexeerfunctie en de nieuwste REST API of een equivalent preview SDK-pakket.

Zie Een SharePoint indexeerfunctie gebruiken om metagegevens van machtigingen op te nemen voor informatie over machtigingsvereisten, ondersteunde groepsrelaties, machtigingssynchronisatie en beperkingen.

Als uw vaardighedenset documenten segmenteert (bijvoorbeeld met de vaardigheid Tekst splitsen voor geïntegreerde vectorisatie), worden de ACL-velden verplaatst van indexeerveldtoewijzingen naar indexprojecties. Zie Kies waar u ACL-velden wilt invullen.

Patroon voor Microsoft Purview gevoeligheidslabels (preview)

Wanneer u labelopname inschakelt, extraheert Azure AI Zoeken vertrouwelijkheidsmetagegevens uit ondersteunde gegevensbronnen. Deze gegevensbronnen omvatten Azure Blob Storage, Azure Data Lake Storage Gen2 (ADLS Gen2), SharePoint in Microsoft 365 en Microsoft OneLake. De geëxtraheerde labels worden naast documentinhoud opgeslagen in de index.

Tijdens de query controleert Azure AI Zoeken het vertrouwelijkheidslabel van elk document, het Microsoft Entra token van de gebruiker en het Purview-beleid van de organisatie om de toegang te bepalen. Het systeem retourneert alleen documenten als de identiteits- en labelmachtigingen van de gebruiker toegang toestaan onder het geconfigureerde Purview-beleid.

Dit patroon bevat de volgende onderdelen:

  • Configureer uw index, gegevensbron en indexeerfunctie (voor planningsdoeleinden) met behulp van de nieuwste PREVIEW REST API of een preview-SDK die ondersteuning biedt voor purview-labelopname.
  • Schakel een door het systeem toegewezen beheerde identiteit in voor uw zoekservice. Door de gebruiker toegewezen beheerde identiteiten worden niet ondersteund voor Purview-labelextractie. De eigen identiteit van de service moet de verhoogde Purview-machtigingen bevatten. Laat vervolgens de globale beheerder van uw tenant of bevoorrechte rolbeheerder de vereiste toegang verlenen om de zoekservice te laten verifiëren met Microsoft Purview en labelmetagegevens te extraheren.
  • Pas vertrouwelijkheidslabels toe op documenten voordat u indexeert, zodat het systeem deze tijdens de opname kan herkennen en behouden.
  • Voeg tijdens de query een geldig Microsoft Entra token toe via de header x-ms-query-source-authorization aan elke queryaanvraag. Azure AI Zoeken evalueert het token en de bijbehorende labelmetagegevens om toegangsbeheer op basis van labels af te dwingen.

Het afdwingen van purview-vertrouwelijkheidslabels is beperkt tot scenario's met één tenant en vereist RBAC-verificatie. Tijdens de preview wordt deze alleen ondersteund via de REST API en Azure-SDK's. Api's voor automatisch aanvullen en voorstellen zijn momenteel niet beschikbaar voor indexen met Purview.

Waar vertrouwelijkheidslabels worden weergegeven

Voordat het systeem labels tijdens het uitvoeren van query’s kan afdwingen of deze kan retourneren in ophaalreacties, moet u eerst de labelmetagegevens naar de index synchroniseren. Beide verbruikspaden die in deze sectie worden beschreven, zijn afhankelijk van deze synchronisatiestap. U kunt labels synchroniseren door een Azure AI Zoeken indexeerfunctie rechtstreeks te configureren op basis van een ondersteunde gegevensbron of door de equivalente opnameoptie in te schakelen wanneer u een kennisbron maakt. In beide gevallen moet uw omgeving voldoen aan de vereisten voor de configuratie van synchronisatie van metagegevens van gevoeligheidslabels (beheerde identiteit, RBAC op de zoekservice en de vereiste Microsoft Purview- en gegevensbronmachtigingen). Voor end-to-end-configuratie van indexers raadpleegt u Azure AI Zoeken-indexers gebruiken om Microsoft Purview-gevoeligheidslabels op te nemen. Voor opname op basis van kennisbronnen stelt u ingestionPermissionOptions zo in dat sensitivityLabel wordt opgenomen tijdens het maken van de kennisbron.

Nadat u labels hebt gesynchroniseerd, gebruiken twee querypaden dezelfde geïndexeerde labelmetagegevens. Kies het pad dat overeenkomt met de wijze waarop uw toepassing Azure AI Zoeken aanroept:

Als de kennisbron verwijst naar een gesegmenteerde index, zoals een index die is gevuld via geïntegreerde vectorisatie of een aangepaste vaardigheid voor tekstsplitsing, moet de vaardighedenset ook het vertrouwelijkheidslabel projecteren op elke segmentrij. Zonder deze projectie worden verwijzingen op segmentniveau niet gefilterd.

Zie Gebruik Azure AI Zoeken indexeerfuncties voor het opnemen van Microsoft Purview vertrouwelijkheidslabels voor meer informatie.

Machtigingen op documentniveau afdwingen tijdens query's (preview)

Het afdwingen van tokengebaseerde query's is een overkoepelende functionaliteit die van toepassing is op de POSIX-achtige ACL- en RBAC-toepassingsgebieden, Microsoft Purview-gevoeligheidslabels en SharePoint-ACL-patronen in Microsoft 365. Door systeemeigen query’s op basis van tokens te gebruiken, valideert Azure AI Zoeken bij elk verzoek het Microsoft Entra-token van de aanroeper en beperkt het de resultatensets tot alleen de documenten die de aanroeper volgens de document-ACL’s mag lezen, zolang de document-ACL-metagegevens met de index zijn gesynchroniseerd.

Wanneer u het token van de gebruiker koppelt aan een queryaanvraag via de header x-ms-query-source-authorization, Azure AI Zoeken:

  1. Extraheert de gebruikers-, groeps- en bereikclaims uit het token.
  2. Vergelijkt deze claims met de metagegevens van machtigingen die zijn opgeslagen naast geïndexeerde documenten (ACL-vermeldingen, RBAC-bereiken, Purview-labeltoewijzingen of SharePoint ACL's).
  3. Retourneert alleen documenten waarvan de metagegevens met gesynchroniseerde machtigingen de aanroeper toegang verlenen.

Afdwinging van querytijd evalueert de Microsoft Entra claims van de aanroeper op basis van de machtigingsmetagegevens die al in de index zijn opgeslagen. Machtigingswijzigingen in het bronsysteem (Microsoft Entra groepslidmaatschap, ADLS Gen2 ACL's, Purview-labeltoewijzingen of SharePoint ACL's) worden alleen weergegeven in zoekresultaten nadat de metagegevens via het bronspecifieke mechanisme worden gesynchroniseerd met de index, bijvoorbeeld een volgende indexeerfunctieuitvoering, een push-API-update of een purview-gestuurde vernieuwing. Voor SharePoint worden ACL-wijzigingen voor items met unieke machtigingen vanaf de REST API-versie 2026-05-01-preview incrementeel meegenomen bij elke geslaagde indexeeruitvoering, terwijl wijzigingen die van bovenliggende scopes (site, bibliotheek, lijst of map) worden overgenomen een expliciete vernieuwing vereisen. Zie Machtigingen synchroniseren tussen geïndexeerde en broninhoud voor meer informatie.

Zie Afdwinging van ACL en RBAC tijdens query's in Azure AI Zoeken voor stappen voor het implementeren van query's van begin tot eind.

Voordelen van toegangsbeheer op documentniveau

Systeemeigen toegangsbeheer op documentniveau in Azure AI Zoeken biedt concrete voordelen ten opzichte van filteren aan de toepassingszijde:

  • Elimineert maatwerkcode voor machtigingen: U hoeft in uw toepassing geen resolutie van geneste groepen, meerlaagse ACL-doorloop of filtering na de query te implementeren. Azure AI Zoeken verwerkt de vergelijking en het filteren tijdens het uitvoeren van query's.
  • Sluit aan op bestaande nalevingscontroles: Het hergebruiken van Microsoft Entra, Microsoft Purview en SharePoint-metagegevens over machtigingen helpt ervoor te zorgen dat zoekresultaten afgestemd blijven op het bronsysteem voor identiteitsbeheer. Bekijk het machtigingssynchronisatiemodel voor elke bron om inzicht te hebben in de beperkingen.
  • Bronmachtigingen worden na elke ACL-synchronisatie nageleefd: Voor tokengebaseerde benaderingen (ACL, RBAC-bereiken, Purview-labels, SharePoint-ACL's) maakt handhaving tijdens query's gebruik van de machtigingsmetadata die het gedocumenteerde, bronspecifieke synchronisatiemechanisme (een indexeruitvoering, een push-API-update of een Purview-vernieuwing) al naar de index heeft geschreven.
  • Verbetert de prestaties ten opzichte van het bijsnijden van query's: Filteren in de zoekpijplijn is sneller dan het laden van grotere resultatensets in uw toepassing en daar bijsnijden, met name bij grote queryvolumes.
  • Hergebruikt uw bestaande identiteitsinfrastructuur: De identiteiten van Microsoft Entra en SharePoint blijven de gezaghebbende bron voor toegangsbeslissingen, waardoor dubbele identiteiten en de operationele overhead van het onderhouden van een parallelle machtigingenopslag worden verminderd.

Zelfstudies en voorbeelden

Verken toegangsbeheer op documentniveau in Azure AI Zoeken met meer artikelen en voorbeelden.

Verwante inhoud

  • Laatst bijgewerkt om