Zugriffssteuerung auf Dokumentebene in Azure KI-Suche

Important

Diese Features und Funktionen sind Teil der REST-API 2026-05-01-Preview. Die 2026-05-01-preview wird Ihnen als Teil Ihres Azure-Abonnements zur Verfügung gestellt und unterliegt den für „Previews“ geltenden Bestimmungen in den Microsoft-Produktbestimmungen, dem Nachtrag zum Datenschutz für Microsoft-Produkte und -Dienste („DPA“) und den Ergänzenden Nutzungsbedingungen für Microsoft Azure-Vorschauen.

Die Vorschauversion 2026-05-01 unterstützt Verbindungen mit anderen Microsoft-Diensten und Diensten von Drittanbietern. Die Nutzung dieser Dienste unterliegt den jeweiligen Bedingungen und kann dazu führen, dass Daten außerhalb der Azure-Compliancegrenze verarbeitet oder gespeichert werden sowie dass Daten in die Azure-Compliancegrenze fließen.

Die Vorschau 2026-05-01 kann keine Zugriffsberechtigungen ändern, die außerhalb der Vorschau von 2026-05-01 festgelegt wurden. Wenn Sie 2026-05-01-preview mit Inhalten mit Zugriffs- oder Berechtigungseinschränkungen verwenden, tritt eine zeitliche Verzögerung auf, bevor 2026-05-01-preview Änderungen an diesen Zugriffs- oder Berechtigungseinschränkungen erkennt.

Es liegt in Ihrer Verantwortung, zu verwalten, ob Ihre Daten außerhalb der Compliance- und geografischen Grenzen Ihrer Organisation und alle damit verbundenen Auswirkungen fließen und dass entsprechende Berechtigungen, Grenzen und Genehmigungen bereitgestellt werden.

Sie sind dafür verantwortlich, Anwendungen, die Sie im Kontext Ihrer spezifischen Anwendungsfälle erstellen, sorgfältig zu überprüfen und zu testen und alle geeigneten Entscheidungen und Anpassungen zu treffen. Dazu gehört die Implementierung ihrer eigenen verantwortungsvollen KI-Entschärfungen, wie Metaprompts, Inhaltsfilter oder andere Sicherheitssysteme, und sicherzustellen, dass Ihre Anwendungen angemessene Qualität, Zuverlässigkeit, Sicherheit und Vertrauenswürdigkeitsstandards erfüllen. Weitere Informationen finden Sie im Azure KI-Suche Transparenzhinweis.

Azure KI-Suche unterstützt die Zugriffssteuerung auf Dokumentebene, sodass Organisationen differenzierte Berechtigungen auf Dokumentebene von der Datenaufnahme über die Abfrageausführung erzwingen können. Diese Funktionalitäten sind unverzichtbar für den Aufbau sicherer KI-Agenten-Systeme, die Daten erden, Retrieval-augmented Generation (RAG)-Anwendungen und Suchlösungen für Unternehmen, die Autorisierungsprüfungen auf Dokumentenebene erfordern.

Ansätze für die Zugriffssteuerung auf Dokumentebene

Azure KI-Suche bietet vier primäre Ansätze zum Erzwingen von Berechtigungen auf Dokumentebene, die jeweils für unterschiedliche Datenquellen und Identitätsmodelle geeignet sind.

Ansatz Beschreibung
Sicherheitsfilter Zeichenfolgenvergleich. Ihre Anwendung übergibt eine Benutzer- oder Gruppenidentität als Zeichenfolge, die einen Filter für eine Abfrage auffüllt, wobei alle Dokumente ausgeschlossen werden, die nicht mit der Zeichenfolge übereinstimmen.

Sicherheitsfilter sind eine Technik zum Erreichen der Zugriffssteuerung auf Dokumentebene. Dieser Ansatz ist nicht an eine API gebunden, sodass Sie eine beliebige Version oder ein beliebiges Paket verwenden können.
POSIX-ähnliche ACL/ RBAC-Bereiche (Vorschau) Der Microsoft Entra-Sicherheitsprinzipal, der dem Abfragetoken zugeordnet ist, wird mit den Berechtigungsmetadaten der Dokumente verglichen, die in den Suchergebnissen angezeigt werden. Dokumente, die nicht den Berechtigungen entsprechen, werden ausgeschlossen. Zugriffssteuerungslisten (Access Control Lists, ACL)-Berechtigungen gelten für Azure Data Lake Storage (ADLS) Gen2-Verzeichnisse und -Dateien. Rollenbasierte Zugriffssteuerungsbereiche (RBAC) gelten für ADLS Gen2-Inhalte und Azure Blobs.

Integrierte Unterstützung für identitätsbasierten Zugriff auf Dokumentenebene befindet sich in der Vorschau, verfügbar in REST-APIs und Azure SDK Vorschaupaketen, die die Funktion bereitstellen. Informationen zur Unterstützung von Features finden Sie in den SDK-Versionssupportdetails.
Microsoft Purview Sensitivitätslabels (Vorschau) Indexer extrahiert Vertraulichkeitsbezeichnungen, die in Microsoft Purview aus unterstützten Datenquellen definiert sind (Azure Blob Storage, ADLS Gen2, SharePoint in Microsoft 365, OneLake). Diese Bezeichnungen werden als Metadaten gespeichert und zur Abfragezeit ausgewertet, um den Benutzerzugriff basierend auf Microsoft Entra-Token und Purview-Richtlinienzuweisungen zu erzwingen. Bezeichnungen werden auch über Wissensquellen und die Antwort zur agentischen Abfrage bereitgestellt, sodass KI-Agenten und Chat-Apps, die eine Wissensdatenbank nutzen, dieselbe kennzeichnungsbasierte Filterung erhalten. Dieser Ansatz richtet Azure KI-Suche Autorisierung an das Microsoft Information Protection Modell Ihres Unternehmens aus.
SharePoint in Microsoft 365 ACLs (Vorschau) Bei der Konfiguration extrahieren Azure KI-Suche Indexer SharePoint Dokument-, Listenelement- und ASPX-Websiteseitenberechtigungen direkt aus Microsoft 365 ACLs. Ab der REST-API-Version 2026-05-01-preview werden ACL-Änderungen für Elemente mit eindeutigen Berechtigungen bei jedem erfolgreichen Indexerlauf ebenfalls inkrementell erfasst. Zugriffsprüfungen verwenden Benutzer- und Gruppenmitgliedschaften in Microsoft Entra; auch SharePoint-Websitegruppen werden im Rahmen derselben Vorschau unterstützt, vorbehaltlich zusätzlicher Konfiguration. Erfordert Microsoft Graph Sites.FullControl.All (zum Lesen von SharePoint-Inhalten und ACLs) bei der App-Registrierung; User.Read.All ist zusätzlich erforderlich, wenn Sie Listenelemente oder ASPX-Website-Seiten indizieren (um die von der SharePoint-REST-API zurückgegebenen E-Mail-Adressen in Microsoft Entra-Objekt-IDs aufzulösen). Die vollständige Berechtigungsmatrix pro Szenario, einschließlich Mindestberechtigungskombinationen, finden Sie unter Berechtigungen nach ACL-Szenario.

Auswählen eines Ansatzes

Verwenden Sie die folgenden Kriterien, um den Ansatz zu identifizieren, der ihren Anforderungen an Datenquelle, Identitätsmodell und Compliance am besten entspricht.

Szenario Empfohlener Ansatz Warum?
Benutzerdefiniertes Identitätssystem, nicht von Microsoft stammendes Sicherheitsframework oder ein beliebiger Push-Model-Index. Sicherheitsfilter API-agnostisch, allgemein verfügbar und basierend auf einfachem Zeichenfolgenabgleich.
Inhalt in ADLS Gen2 oder Azure Blob Storage mit vorhandenen ACL- oder RBAC-Zuordnungen. POSIX-ähnliche ACL / RBAC-Bereiche Native Microsoft Entra-Integration; die Durchsetzung zur Abfragezeit verwendet Berechtigungsmetadaten, die mithilfe des dokumentierten Synchronisierungsmechanismus in den Index geschrieben werden.
Unternehmensinhalte unterliegen bereits Microsoft Purview Informationsschutzrichtlinien. Microsoft Purview Vertraulichkeitsetiketten Verwendet zentralisierte Klassifizierungen und Richtlinienzuweisungen in Azure KI-Suche wieder.
Inhalte, die aus SharePoint in Microsoft 365 (Bibliotheken, Listen, ASPX-Websiteseiten) stammen. ACLs für SharePoint in Microsoft 365 Berücksichtigt native SharePoint-Berechtigungen, einschließlich SharePoint-Websitengruppen.

Einen direkten Vergleich der Features (unterstützte Prinzipale, Elementtypen, Synchronisierungsverhalten und API-Oberfläche) finden Sie in den weiter unten in diesem Artikel verlinkten Musterabschnitten sowie unter Indizieren von SharePoint in Microsoft 365 mit Berechtigungen auf Dokumentebene (Vorschau).

Muster für die Sicherheitskürzung mithilfe von Filtern

Für Szenarien, in denen die Integration nativer ACL/RBAC-Bereiche nicht praktikabel ist, werden Zeichenfolgenfilter empfohlen, um die Ergebnisse auf der Grundlage von Ausschlusskriterien zu beschneiden. Das Muster enthält die folgenden Komponenten:

  • Um Benutzer- oder Gruppenidentitäten zu speichern, erstellen Sie ein Zeichenfolgenfeld im Index.
  • Laden Sie den Index mithilfe von Quelldokumenten, die zugeordnete ACLs enthalten.
  • Fügen Sie Ihrer Abfragelogik einen Filterausdruck hinzu, um die Zeichenfolge abzugleichen.
  • Zur Abfragezeit die Identität des Anrufers abrufen.
  • Übergeben Sie die Identität des Aufrufers als Filterzeichenfolge.
  • Die Ergebnisse werden gekürzt, um Übereinstimmungen auszuschließen, die die Benutzer- oder Gruppenidentitätszeichenfolge nicht enthalten.

Sie können Push- oder Pullmodell-APIs verwenden. Da dieser Ansatz API-agnostisch ist, müssen Sie nur bestätigen, dass der Index und die Abfrage gültige Zeichenfolgen (Identitäten) für den Filtrationsschritt haben.

Dieser Ansatz ist nützlich für Systeme mit benutzerdefinierten Zugriffsmodellen oder nicht Microsoft Sicherheitsframeworks. Weitere Informationen zu dieser Vorgehensweise finden Sie unter Sicherheitsfilter zum Kürzen von Ergebnissen in Azure KI-Suche.

Muster für systemeigene Unterstützung für POSIX-ähnliche ACL- und RBAC-Bereichsberechtigungen (Vorschau)

Die native Unterstützung basiert auf Microsoft Entra Benutzern und Gruppen, die mit Dokumenten verbunden sind, die Sie indizieren und abfragen möchten.

Azure Data Lake Storage (ADLS) Gen2-Container unterstützen ACLs für den Container und dateien. Für ADLS Gen2 wird die Erhaltung des RBAC-Bereichs auf Dokumentebene nativ unterstützt, wenn Sie einen ADLS Gen2-Indexer oder eine BLOB-Wissensquelle (unterstützt ADLS Gen2) und eine Vorschau-API zum Aufnehmen von Inhalten verwenden. Für Azure-Blobs mit dem Azure Blob Indexer oder einer Wissensquelle befindet sich der RBAC-Bereichserhalt auf Containerebene.

Für ACL-gesicherte Inhalte empfehlen wir den Gruppenzugriff über den einzelnen Benutzerzugriff, um die Verwaltung zu erleichtern. Das Muster enthält die folgenden Komponenten:

Ihre Client-App erhält Leseberechtigungen für den Index über die Rolle Search Index Data Reader oder Search Index Data Contributor. Der Zugriff zur Abfragezeit wird durch Benutzer- oder Gruppenberechtigungsmetadaten im indizierten Inhalt bestimmt. Abfragen, die einen Berechtigungsfilter enthalten, übergeben ein Benutzer- oder Gruppentoken wie x-ms-query-source-authorization im Anforderungsheader. Wenn Sie Berechtigungsfilter zur Abfragezeit verwenden, sucht Azure KI-Suche nach zwei Dingen:

  • Zuerst wird die Berechtigung „Suchindex-Datenleser“ überprüft, die es Ihrer Client-Anwendung ermöglicht, auf den Index zuzugreifen.

  • Zweitens, mit dem zusätzlichen Token in der Anfrage überprüft es die Benutzer- oder Gruppenberechtigungen für Dokumente, die in Suchergebnissen zurückgegeben werden, und schließt alle aus, die nicht übereinstimmen.

Um Berechtigungsmetadaten in den Index zu übertragen, können Sie die Pushmodell-API verwenden und alle JSON-Dokumente an den Suchindex übertragen, wobei die Nutzlast ein Zeichenfolgenfeld enthält, das POSIX-ähnliche ACLs für jedes Dokument bereitstellt. Der wichtige Unterschied zwischen diesem Ansatz und der Sicherheitskürzung besteht darin, dass die Berechtigungsfiltermetadaten im Index und in der Abfrage als Microsoft Entra ID Authentifizierung erkannt werden, während die Problemumgehung zur Sicherheitskürzung ein einfacher Zeichenfolgenvergleich ist. Außerdem können Sie das Graph SDK verwenden, um die Identitäten abzurufen.

Sie können auch die Pullmodell-APIs (Indexer) verwenden, wenn die Datenquelle Azure Data Lake Storage (ADLS) Gen2 und ihr Code eine Vorschau-API für die Indizierung aufruft.

Abrufen von ACL-Berechtigungsmetadaten während des Datenaufnahmeprozesses (Vorschau)

Wie Sie ACL-Berechtigungen abrufen, hängt davon ab, ob Sie eine Dokumentnutzlast übertragen oder den ADLS Gen2-Indexer verwenden.

Beginnen Sie mit einer Vorschau-API, die das Feature bereitstellt:

Für den Pushmodellansatz:

  1. Vergewissern Sie sich, dass Ihr Indexschema mit einem Vorschau- oder Vorabversions-SDK erstellt wird und dass das Schema Berechtigungsfilter enthält.
  2. Erwägen Sie die Verwendung des Microsoft Graph SDK zum Abrufen von Gruppen- oder Benutzeridentitäten.
  3. Verwenden Sie die Index Documents oder gleichwertige Azure SDK-API, um Dokumente und die zugehörigen Berechtigungsmetadaten in den Suchindex zu übertragen.

Für das Pull-Modell ADLS Gen2 Indexer-Ansatz oder die ADLS Gen2-Wissensquelle:

  1. Stellen Sie sicher, dass Dateien im Verzeichnis mithilfe des ADLS Gen2-Zugriffssteuerungsmodells gesichert sind.
  2. Verwenden Sie Indexers – Create (REST-API), Knowledge Sources - Create (REST-API) oder eine entsprechende Azure SDK-API zum Erstellen des Indexers, Indexes und der Datenquelle.

Wenn Ihr Skillset Dokumente in Segmente aufteilt, z. B. mit dem Skill „Textaufteilung“ für die integrierte Vektorisierung, werden die Berechtigungsmetadatenfelder aus den Indexerfeldzuordnungen in die Indexprojektionen verschoben. Siehe Auswählen, wo ACL-Felder aufgefüllt werden sollen.

Muster für die Erfassung grundlegender ACL-Berechtigungen für SharePoint in Microsoft 365 (Vorschau)

Für Inhalte in SharePoint in Microsoft 365 kann Azure KI-Suche Dokumentenberechtigungen auf Grundlage von SharePoint-ACLs anwenden. Bei dieser Integration können nur Benutzer oder Gruppen, die Zugriff auf das Quellelement in SharePoint haben, diese aus den Suchergebnissen abrufen. Die Übereinstimmung wird wirksam, nachdem die ACL-Metadaten bei den nächsten erfolgreichen Ausführungen des geplanten Indexers, die auf die Quellenänderung folgen, in den Index geschrieben wurden. Die ACL-Erfassung gilt für Dokumente in Bibliotheken, Elementen in SharePoint Listen und ASPX-Websiteseiten.

Die SharePoint-ACL-Unterstützung ist als Vorschauversion über den SharePoint-Indexer mithilfe der 2026-05-01-preview REST API oder eines unterstützten SDK verfügbar.

Das Muster enthält die folgenden Komponenten:

  • Verwenden Sie den SharePoint-Indexer in Microsoft 365 mit Anwendungsberechtigungen, um SharePoint-Webseiteninhalte zu lesen, und volle Berechtigungen, um ACLs zu lesen. Befolgen Sie die Schritte zur Konfiguration der ACL für den SharePoint-Indexer bezüglich der Aktivierung und Begrenzungen.

  • Während der anfänglichen Indizierung werden SharePoint ACL-Einträge (Benutzer und Gruppen) als Berechtigungsmetadaten im Suchindex gespeichert.

  • Ab der 2026-05-01-preview-REST-API erfolgt die SharePoint-ACL-Synchronisierung nach folgendem Modell:

    • Änderungen an Elementen mit eindeutigen Berechtigungen werden bei jeder erfolgreichen Indizierungsausführung erkannt und aktualisiert.
    • Änderungen, die von übergeordneten Geltungsbereichen (Site, Bibliothek, Liste oder Ordner) geerbt werden, erfordern eine ausdrückliche Aktualisierung, z. B. mit /resyncoptions: ["permissions"] oder /resetdocs. Weitere Informationen finden Sie unter Synchronisieren von Berechtigungen zwischen indizierten und Quellinhalten.

  • Zur Abfragezeit überprüft Azure KI-Suche den Microsoft Entra-Prinzipal im Abfragetoken mit den im Index gespeicherten SharePoint-ACL-Metadaten. Es schließt alle Elemente aus, auf die der Aufrufer nicht zugreifen darf.

Während der Vorschau werden die folgenden Prinzipaltypen in SharePoint ACLs unterstützt:

  • Microsoft Entra Benutzerkonten
  • Microsoft Entra Sicherheitsgruppen
  • Microsoft 365-Gruppen
  • E-Mail-aktivierte Sicherheitsgruppen
  • SharePoint-Websitengruppen (Vorschau, ab der REST-API 2026-05-01-preview). Erfordert eine zusätzliche Indexkonfiguration. Weitere Informationen finden Sie unter Konfigurieren SharePoint Gruppenunterstützung.

SharePoint-Richtlinien zur Informationsverwaltung, die den Benutzerzugriff steuern, werden zur Abfragezeit nicht ausgewertet, erfasst oder berücksichtigt.

Informationen zu Konfigurationsdetails und vollständigen Einschränkungen finden Sie unter Wie indizieren Sie SharePoint in Microsoft 365 Berechtigungen auf Dokumentebene (Vorschau). Eine schrittweise Anleitung zur End-to-End-Konfiguration einschließlich der Unterstützung für SharePoint-Websitegruppen finden Sie unter Unterstützung für SharePoint-Gruppen konfigurieren.

Wenn Ihr Skillset Dokumente gliedert (z. B. mit der Fähigkeit "Textteilung" für die integrierte Vektorisierung), werden die ACL-Felder von Indexerfeldzuordnungen zu Indexprojektionen verschoben. Siehe Auswählen, wo ACL-Felder aufgefüllt werden sollen.

Muster für die Empfindlichkeitsbezeichnungen von Microsoft Purview (in der Vorschau)

Wenn die Labelverarbeitung aktiviert ist, extrahiert Azure KI-Suche Vertraulichkeitsmetadaten aus unterstützten Datenquellen. Dazu gehören: Azure Blob Storage, Azure Data Lake Storage Gen2 (ADLS Gen2), SharePoint in Microsoft 365 und Microsoft OneLake. Die extrahierten Bezeichnungen werden zusammen mit Dokumentinhalten im Index gespeichert.

Zur Abfragezeit überprüft Azure KI-Suche die Vertraulichkeitsbezeichnung jedes Dokuments, das Microsoft Entra-Token des Benutzers und die Purview-Richtlinien der Organisation, um den Zugriff zu bestimmen. Dokumente werden nur zurückgegeben, wenn die Identitäts- und kennzeichnungsbasierten Berechtigungen des Benutzers den Zugriff gemäß den konfigurierten Purview-Richtlinien zulassen.

Das Muster enthält die folgenden Komponenten:

  • Konfigurieren Sie Den Index, die Datenquelle und den Indexer (für Planungszwecke) mithilfe der REST-API 2026-05-01-Preview oder eines entsprechenden SDK, das die Aufnahme von Purview-Bezeichnungen unterstützt.
  • Aktivieren Sie eine vom System zugewiesene verwaltete Identität für Ihren Suchdienst. Bitten Sie dann den globalen Mandantenadministrator oder den Administrator mit privilegierter Rolle, den erforderlichen Zugriff zu gewähren, damit der Suchdienst sicher auf Microsoft Purview zugreifen und Metadaten von Bezeichnungen extrahieren kann.
  • Wenden Sie vor der Indizierung Vertraulichkeitsbezeichnungen auf Dokumente an, damit diese während der Erfassung erkannt und beibehalten werden können.
  • Fügen Sie zur Abfragezeit ein gültiges Microsoft Entra-Token über den Header x-ms-query-source-authorization an jede Abfrageanforderung an. Azure KI-Suche wertet das Token und die zugehörigen Bezeichnungsmetadaten aus, um die bezeichnungsbasierte Zugriffssteuerung zu erzwingen.

Die Durchsetzung von Purview-Vertraulichkeitsbezeichnungen ist auf Szenarien mit nur einem Mandanten beschränkt und erfordert eine RBAC-Authentifizierung. Während der Vorschau wird sie nur über die REST-API und Azure SDKs unterstützt. AutoVervollständigen- und Vorschlags-APIs sind derzeit nicht für Purview-fähige Indizes verfügbar.

Wo Vertraulichkeitsbezeichnungen angezeigt werden

Bevor Kennzeichnungen bei Abfragen durchgesetzt oder in Abrufantworten zurückgegeben werden können, müssen die Metadaten der Kennzeichnungen zunächst mit dem Index synchronisiert werden. Beide in diesem Abschnitt beschriebenen Verbrauchspfade hängen von diesem Synchronisierungsschritt ab. Sie können Bezeichnungen synchronisieren, indem Sie einen Azure KI-Suche Indexer direkt für eine unterstützte Datenquelle konfigurieren oder die entsprechende Aufnahmeoption aktivieren, wenn Sie eine Wissensquelle erstellen. In beiden Fällen muss Ihre Umgebung die Konfigurationsvoraussetzungen für die Synchronisierung von Metadaten von Vertraulichkeitsbezeichnungen erfüllen (verwaltete Identität, RBAC für den Suchdienst und die erforderlichen Microsoft Purview- und Datenquellenberechtigungen). Informationen zur End-to-End-Einrichtung von Indexern finden Sie unter Azure KI-Suche-Indexer zur Erfassung von Microsoft Purview-Vertraulichkeitsbezeichnungen verwenden. Für eine durch Wissensquellen gesteuerte Erfassung legen Sie ingestionPermissionOptions so fest, dass sensitivityLabel bei der Erstellung der Wissensquelle einbezogen wird.

Nachdem die Labels synchronisiert wurden, werden dieselben indexierten Label-Metadaten über zwei Abfragepfade genutzt. Wählen Sie den Pfad aus, der dazu passt, wie Ihre Anwendung Azure KI-Suche aufruft:

Wenn die Wissensquelle auf einen in Blöcke unterteilten Index verweist, der beispielsweise durch integrierte Vektorisierung oder einen benutzerdefinierten Text-Split-Skill befüllt wird, muss das Skillset außerdem die Vertraulichkeitsbezeichnung auf jede Chunk-Zeile projizieren. Ohne diese Projektion werden Verweise auf Blockebene nicht gefiltert.

Weitere Informationen finden Sie unter Azure KI-Suche-Indexer zur Aufnahme von Microsoft Purview-Vertraulichkeitsbezeichnungen verwenden.

Durchsetzung von Berechtigungen auf Dokumentenebene während der Abfrage

Die tokenbasierte Abfrageerzwingung ist eine durchschneidende Funktion, die für POSIX-ähnliche ACL/RBAC-Bereiche, Microsoft Purview Vertraulichkeitsbezeichnungen und SharePoint in Microsoft 365 ACLs-Mustern gilt. Mit nativer tokenbasierter Abfrage überprüft Azure KI-Suche bei jeder Anfrage das Microsoft Entra-Token des Aufrufers und beschränkt die Ergebnismengen auf die Dokumente, die der Aufrufer gemäß den Dokument-ACLs lesen darf, sofern die Dokument-ACL-Metadaten mit dem Index synchronisiert wurden.

Wenn Sie das Token des Benutzers über den header x-ms-query-source-authorization an eine Abfrageanforderung anfügen, Azure KI-Suche:

  1. Extrahiert die Benutzer-, Gruppen- und Bereichsansprüche aus dem Token.
  2. Vergleicht diese Ansprüche mit den Berechtigungsmetadaten, die zusammen mit indizierten Dokumenten gespeichert sind (ACL-Einträge, RBAC-Bereiche, Purview-Bezeichnungszuweisungen oder SharePoint ACLs).
  3. Gibt nur Dokumente zurück, deren synchronisierte Berechtigungsmetadaten den Aufruferzugriff gewähren.

Die Durchsetzung zur Abfragezeit bewertet die Microsoft Entra-Ansprüche des Aufrufers anhand der Berechtigungsmetadaten, die bereits im Index gespeichert sind. Berechtigungsänderungen im Quellsystem (Microsoft Entra Gruppenmitgliedschaft, ADLS Gen2 ACLs, Purview-Bezeichnungszuweisungen oder SharePoint ACLs) werden nur in Suchergebnissen widergespiegelt, nachdem Metadaten über den quellspezifischen Mechanismus mit dem Index synchronisiert wurden, z. B. eine nachfolgende Indizierung, ein Push-API-Update oder eine purview-gesteuerte Aktualisierung. Für SharePoint werden ACL-Änderungen an Elementen mit eindeutigen Berechtigungen ab der REST-API-Version 2026-05-01-preview bei jeder erfolgreichen Ausführung des Indexers inkrementell erfasst, während Änderungen, die von übergeordneten Bereichen (Website, Bibliothek, Liste oder Ordner) geerbt werden, eine explizite Aktualisierung erfordern. Weitere Informationen finden Sie unter Synchronisieren von Berechtigungen zwischen indizierten und Quellinhalten.

Schritte zur Implementierung von End-to-End-Abfragen finden Sie unter Query-time ACL und RBAC-Erzwingung in Azure KI-Suche.

Vorteile der Zugriffssteuerung auf Dokumentebene

Systemeigene Zugriffssteuerung auf Dokumentebene in Azure KI-Suche bietet konkrete Vorteile gegenüber der anwendungsseitigen Filterung:

  • Entfernt benutzerdefinierten Berechtigungscode: Sie müssen keine geschachtelte Gruppenauflösung, mehrstufige ACL-Traversal- oder Nachabfragekürzung in Ihrer Anwendung implementieren. Azure KI-Suche behandelt den Vergleich und die Filterung während der Abfrageausführung.
  • Entspricht den vorhandenen Compliancekontrollen: Die Wiederverwendung von Berechtigungsmetadaten aus Microsoft Entra, Microsoft Purview und SharePoint trägt dazu bei, Suchergebnisse mit dem Identitätssystem der Quelle in Einklang zu halten. Überprüfen Sie das Berechtigungssynchronisierungsmodell für jede Quelle, um ihre Einschränkungen zu verstehen.
  • Berücksichtigt Quellberechtigungen nach jeder ACL-Synchronisierung: Bei tokenbasierten Ansätzen (ACL, RBAC-Bereiche, Purview-Bezeichnungen, SharePoint-ACLs) verwendet die Durchsetzung zur Abfragezeit die Berechtigungsmetadaten, die der dokumentierte quellenspezifische Synchronisierungsmechanismus (Indexerausführung, Push-API-Aktualisierung oder Purview-Aktualisierung) bereits in den Index geschrieben hat.
  • Verbessert die Leistung gegenüber dem Kürzen nach der Abfrage: Das Filtern innerhalb der Suchpipeline ist schneller als das Laden größerer Resultsets in Ihre Anwendung und das Kürzen dort, insbesondere bei hohen Abfragevolumes.
  • Reuses Ihre vorhandene Identitätsinfrastruktur: Microsoft Entra und SharePoint Identitäten bleiben die Quelle der Wahrheit für Zugriffsentscheidungen, wodurch die Identitätsduplizierung und der betriebstechnische Aufwand beim Verwalten eines parallelen Berechtigungsspeichers reduziert werden.

Lernprogramme und Beispiele

Werfen Sie einen genaueren Blick auf die Zugriffssteuerung auf Dokumentebene in Azure KI-Suche mit weiteren Artikeln und Beispielen.

Verwandte Inhalte

  • Last updated on