Zugriffssteuerung auf Dokumentebene in Azure KI-Suche

Note

Azure KI-Suche ist über das Azure Portal, REST-APIs und Azure SDKs verfügbar. Es unterstützt auch Foundry IQ, die verwaltete Wissensschicht, die Unternehmensinhalte in wiederverwendbare, berechtigungsfähige Wissensbasen für Agenten im Microsoft Foundry-Portal transformiert.

Important

Diese Features und Funktionen sind Teil der REST-API 2026-08-01-Preview. Die Vorschau 2026-08-01 wird Ihnen als Teil Ihres Azure-Abonnements lizenziert und unterliegt den Bedingungen für "Vorschauen" in den Microsoft Produktbedingungen, dem Microsoft Produkt- und Dienstdatenschutzzusatz ("DPA") und den ergänzenden Nutzungsbedingungen für Microsoft Azure Previews.

Die Version 2026-08-01-preview unterstützt Verbindungen zu anderen Microsoft-Diensten und Drittanbieterdiensten. 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-08-01 kann keine Zugriffsberechtigungen ändern, die außerhalb der Vorschau von 2026-08-01 festgelegt wurden. Wenn Sie 2026-08-01-preview mit Inhalten mit Zugriffs- oder Berechtigungsbeschränkungen verwenden, kommt es zu einer zeitlichen Verzögerung, bevor 2026-08-01-preview Änderungen an diesen Zugriffs- oder Berechtigungsbeschrä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. Diese Verantwortung umfasst die Implementierung Ihrer eigenen verantwortungsvollen KI-Gegenmaßnahmen, 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. Zugriffssteuerungslistenberechtigungen (Access Control List, ACL) 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) Azure KI-Suche Indexer extrahieren Berechtigungsmetadaten aus unterstützten SharePoint Inhalten und verwenden sie für Abfragezeitzugriffsprüfungen. Unterstützte Inhalte, Prinzipale, Gruppenbeziehungen, Synchronisierungsverhalten und Berechtigungen finden Sie unter Verwenden eines SharePoint Indexers zum Aufnehmen von Berechtigungsmetadaten.

Für indizierte Wissensquellen kann ingestionPermissionOptions nicht mit assetStore kombiniert werden. Aus diesem Grund ist die Bildbereitstellung (Vorschau) nicht verfügbar, wenn die Erfassung systemeigener Berechtigungen auf Dokumentebene aktiviert ist.

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.

Muster für die Sicherheitskürzung mithilfe von Filtern

Verwenden Sie für Szenarien, in denen die native ACL/RBAC-Integration nicht realisierbar ist, Sicherheits-String-Filter, um Ergebnisse anhand von Ausschlusskriterien einzugrenzen. 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.

Verwenden Sie für ACL-gesicherte Inhalte 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, verwenden Sie die Pushmodell-API, indem Sie 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)

Bei indizierten SharePoint Inhalten können Azure KI-Suche Quellberechtigungen als Metadaten speichern und zum Filtern von Abfrageergebnissen verwenden. Sie können als Vorschau über den SharePoint-Indexer in Microsoft 365 sowie über die neueste REST-API oder ein entsprechendes Vorschau-SDK-Paket auf diese Funktion zugreifen.

Informationen zu Berechtigungsanforderungen, unterstützten Gruppenbeziehungen, Berechtigungssynchronisierung und Einschränkungen finden Sie unter Verwenden eines SharePoint Indexers zum Aufnehmen von Berechtigungsmetadaten.

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 Sie die Aufnahme von Bezeichnungen aktivieren, extrahiert Azure KI-Suche Vertraulichkeitsmetadaten aus unterstützten Datenquellen. Zu diesen Datenquellen 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. Das System gibt Dokumente nur zurück, wenn die Identität des Benutzers und seine bezeichnungsbasierten Berechtigungen den Zugriff gemäß den konfigurierten Purview-Richtlinien zulassen.

Dieses Muster enthält die folgenden Komponenten:

  • Konfigurieren Sie Ihren Index, die Datenquelle und den Indexer (für Planungszwecke), indem Sie die neueste Vorschau-REST-API oder ein Vorschau-SDK verwenden, das die Aufnahme von Purview-Bezeichnungen unterstützt.
  • Aktivieren Sie eine vom System zugewiesene verwaltete Identität in Ihrem Suchdienst. Benutzerseitig zugewiesene verwaltete Identitäten werden für die Extraktion von Purview-Bezeichnungen nicht unterstützt; die eigene Identität des Diensts muss über die erhöhten Purview-Berechtigungen verfügen. Lassen Sie dann Ihren globalen Mandantenadministrator oder den Administrator für privilegierte Rollen den erforderlichen Zugriff gewähren, damit der Suchdienst sich bei Microsoft Purview authentifizieren und Metadaten von Bezeichnungen extrahieren kann.
  • Übernehmen Sie Vertraulichkeitsbezeichnungen vor der Indizierung für Dokumente, damit das System sie während der Aufnahme erkennen und beibehalten kann.
  • 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 das System Kennzeichnungen bei Abfragen erzwingen oder in Abrufantworten zurückgeben kann, müssen Sie zuerst die Metadaten der Kennzeichnungen in den Index synchronisieren. 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 Sie Bezeichnungen synchronisiert haben, verwenden zwei Abfragepfade dieselben indizierten Bezeichnungsmetadaten. Wählen Sie den Pfad aus, der dazu passt, wie Ihre Anwendung Azure KI-Suche aufruft:

Wenn die Wissensquelle auf einen in Chunks unterteilten Index verweist, wie etwa einen, der durch integrierte Vektorisierung oder einen benutzerdefinierten Skill zur Textaufteilung erstellt wird, muss das Skillset auch die Vertraulichkeitsbezeichnung in 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 Abfragedurchsetzung ist eine bereichsübergreifende Funktion, die für POSIX-ähnliche ACL- und RBAC-Bereiche, Microsoft-Purview-Vertraulichkeitsbezeichnungen und ACL-Muster in SharePoint in Microsoft 365 gilt. Mithilfe der systemeigenen tokenbasierten Abfrage überprüft Azure KI-Suche das Microsoft Entra-Token des Aufrufers für jede Anforderung und schneidet Resultsets nur auf die Dokumente zu, die der Aufrufer gemäß den Dokument-ACLs lesen darf, solange die Dokument-ACL-Metadaten mit dem Index synchronisiert werden.

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 Abfragezeiterzwingung die Berechtigungsmetadaten, die der dokumentierte quellspezifische Synchronisierungsmechanismus (Indexerausführung, Push-API-Update 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

Erkunden Sie die Zugriffssteuerung auf Dokumentebene in Azure KI-Suche mit weiteren Artikeln und Beispielen.

Verwandte Inhalte

  • Last updated on