Durchsetzung der Vertraulichkeitsbezeichnungen von Microsoft Purview in Azure KI-Suche während der Abfrage (Vorschau)

Zur Abfragezeit kann Azure KI-Suche die Richtlinien für Vertraulichkeitsbezeichnungen erzwingen, die in Microsoft Purview definiert sind. Diese Richtlinien umfassen die Auswertung von EXTRACT Nutzungsrechten , die jedem Dokument zugeordnet sind, und sicherstellen, dass Benutzer nur Dokumente abrufen können, auf die sie zugreifen dürfen.

Diese Funktion erweitert die Zugriffssteuerung auf Dokumentebene, um den Informationsschutz- und Complianceanforderungen Ihrer Organisation zu entsprechen, die in Microsoft Purview verwaltet werden.

Wenn die Indizierung von Purview-Sensitivitätskennzeichnungen aktiviert ist, überprüft Azure KI-Suche während der Abfragezeit die Bezeichnungsmetadaten jedes Dokuments. Es wendet Zugriffsfilter basierend auf Purview-Richtlinien an, um nur Ergebnisse zurückzugeben, auf die der anfordernde Benutzer zugreifen darf.

In diesem Artikel wird erklärt, wie die Durchsetzung von Vertraulichkeitskennzeichnungen zur Abfragezeit funktioniert und wie man sichere Suchabfragen stellt.

Voraussetzungen

• Schließen Sie alle Schritte unter Benutzen Sie Azure KI-Suche Indexer, um Microsoft Purview Vertraulichkeitskennzeichnungen einzubinden ab.

• Stellen Sie sicher, dass der Azure KI-Suche Dienst die vom System zugewiesene verwaltete Identität (keine vom Benutzer zugewiesene verwaltete Identität) aktiviert hat und dass er die Content.SuperUser und UnifiedPolicy.Tenant.Read Rollenzuweisungen enthält. Die Erzwingung zur Abfragezeit hängt von Bezeichnungsmetadaten ab, die der Indexer nur dann extrahieren kann, wenn die vom System zugewiesene Identität korrekt konfiguriert ist. Siehe Schritt 1 im Indexer-Setupartikel.

• Sowohl der Azure KI-Suche-Dienst als auch der Benutzer, der die Abfrage ausgibt, muss sich im gleichen Microsoft Entra Mandanten befinden.

• REST API Version 2025-11-01-preview oder höher oder ein entsprechendes Vorschau-SDK-Paket, um den Index abzufragen. Die Funktion für erhöhte Leseberechtigungen und die Purview-Überwachungsprotokollierung erfordern 2026-05-01-preview oder höher.

• Authentifizieren von Abfragen mithilfe von Azure rollenbasierten Zugriffssteuerung (RBAC) und nicht mit API-Schlüsseln. Wenn Purview-Vertraulichkeitsbezeichnungen aktiviert sind, ist der API-Schlüsselzugriff auf den Indexschemaabruf beschränkt.

Einschränkungen

• Gastkonten und mandantenübergreifende Abfragen werden nicht unterstützt.

• AutoVervollständigen- und Vorschlags-APIs werden für purview-fähige Indizes nicht unterstützt.

• Wenn die Bezeichnungsauswertung fehlschlägt, gibt der Dienst anstelle eines teilweisen oder ungefilterten Resultsets einen bestimmten HTTP-Fehlercode zurück. Die vollständige Liste der Fehlercodes und Ursachen finden Sie unter Problembehandlung bei Abfragefehlern.

• Das System wertet Bezeichnungen nur so aus, wie sie zum Zeitpunkt der letzten Ausführung des Indexers vorhanden sind. Aktuelle Bezeichnungsänderungen werden möglicherweise erst nach der nächsten geplanten Neuindizierung angezeigt.

So funktioniert die Erzwingung von Vertraulichkeitsbezeichnungen zur Abfragezeit

Wenn Sie einen Index abfragen, der Microsoft Purview Vertraulichkeitsbezeichnungen enthält, überprüft Azure KI-Suche die zugehörigen Purview-Richtlinien, bevor Ergebnisse zurückgegeben werden. Auf diese Weise gibt die Abfrage nur Dokumente zurück, auf die das Benutzertoken zugreifen darf.

1. Eingabe von Benutzeridentitäts- und Anwendungsrollen

Zur Abfragezeit überprüft Azure KI-Suche beide:

• Die RBAC-Rolle der aufrufenden Anwendung, die im Header Authorization bereitgestellt wird. Die mindestens erforderliche Rolle ist Search Index Data Reader. Weitere Informationen finden Sie im Azure KI-Suche RBAC-Leitfaden.
• Die Benutzeridentität über Token, die im x-ms-query-source-authorization Header bereitgestellt ist.

Beide sind erforderlich, um die bezeichnungsbasierte Sichtbarkeit zu autorisieren.

2. Bewertung von Vertraulichkeitsetiketten

Wenn eine Abfrageanforderung empfangen wird, wertet Azure KI-Suche Folgendes aus:

1. Das Feld sensitivityLabel in jedem indizierten Dokument (extrahiert aus Microsoft Purview während des Ingestionsprozesses).
2. Die effektiven Purview-Berechtigungen des Benutzers, wie durch Microsoft Entra ID und Purview-Labelrichtlinie definiert.

Wenn der Benutzer nicht für die Vertraulichkeitsbezeichnung eines Dokuments mit EXTRACT Berechtigungen autorisiert ist, wird dieses Dokument von den Abfrageergebnissen ausgeschlossen.

3. Sichere Ergebnisfilterung

Azure KI-Suche wendet den Sicherheitsfilter nach allen benutzerdefinierten Filtern und Bewertungsschritten an.
Ein Dokument ist nur dann im endgültigen Resultset enthalten, wenn:

• Die aufrufende Anwendung verfügt über eine gültige Rollenzuweisung (über RBAC) und
• Das dargestellte x-ms-query-source-authorization Benutzeridentitätstoken ist gültig und erlaubt, Inhalte mit der Vertraulichkeitsbezeichnung des Dokuments anzuzeigen.

Wenn eine der Bedingungen fehlschlägt, wird das Dokument aus den Ergebnissen weggelassen.

Ein Benutzerzugriffstoken abrufen

Um Azure KI-Suche mithilfe des Benutzerkontexts abzufragen, müssen Sie ein Zugriffstoken abrufen, das den angemeldeten Benutzer darstellt. Der verwendete Ansatz hängt davon ab, ob Sie lokal mit Ihrem eigenen Token testen, ob Sie Zugriff auf das Quelldokument haben oder den Anwendungsfluss implementieren, der das Endbenutzertoken übergibt.

Für Testszenarien

Für lokale Tests können Sie ein Benutzerzugriffstoken mithilfe von Azure CLI abrufen:

$token = az account get-access-token `
  --resource https://search.azure.com `
  --query accessToken `
  --output tsv

Dieser Ansatz verwendet Ihre aktuelle Azure CLI-Anmeldesitzung, sodass Sie den Kontext über Dokumente verwenden können, denen Sie EXTRACT-Berechtigungen über Vertraulichkeitskennzeichnungen zugewiesen haben. Diese Methode ist nur für Entwicklungs- und Validierungsszenarien vorgesehen.

Tokenerwerb für OBO-Szenarien

Anwendungen, die den On-Behalf-of (OBO) Flow implementieren, müssen Token über Microsoft Entra ID mithilfe einer unterstützten Authentifizierungsbibliothek beziehen, wie z. B. die Microsoft Authentication Library (MSAL) (MSAL).

Fordern Sie in OBO-Szenarien das Token für die downstream-API an, die die Anwendung aufruft. Wenn Sie beispielsweise Azure KI-Suche aufrufen, ist der Ressourcen-URI https://search.azure.com/.default.

Der .default Bereich fordert alle delegierten Berechtigungen an, die die Anwendung für die angegebene Ressource vorkonsentiert hat.

Vertraulichkeitsbezeichnungsberechtigungen, einschließlich EXTRACT, werden nicht als OAuth-Bereiche dargestellt. Der nachgeschaltete Dienst, z. B. Azure KI-Suche, wertet diese Berechtigungen zur Laufzeit basierend auf der Benutzeridentität im Token und der angewendeten Vertraulichkeitsbezeichnungsrichtlinie aus.

Abfragebeispiel

Hier ist ein Beispiel für eine Abfrageanforderung, die Microsoft Purview Erzwingung von Vertraulichkeitsbezeichnungen verwendet.

Übergeben Sie das Anwendungs-Token als Bearer-Token im Authorization-Header. Übergeben Sie das Benutzertoken als unformatierten Tokenwert im x-ms-query-source-authorization Header, ohne das Bearer Präfix.

POST  {{endpoint}}/indexes/sensitivity-docs/docs/search?api-version=2026-08-01-preview
Authorization: Bearer {{app-query-token}}
x-ms-query-source-authorization: {{user-query-token}}
Content-Type: application/json

{
    "search": "*",
    "select": "title,summary,sensitivityLabel",
    "orderby": "title asc"
}

Erhöhte Leseberechtigungen für administrative Untersuchungen (Vorschau)

Erhöhter Lesezugriff ermöglicht es einem autorisierten Entwickler, gekennzeichnete Dokumente zurückzugeben, auf die der aufrufende Benutzer normalerweise keinen Zugriff hat, wobei für jedes von der Anfrage zurückgegebene Dokument ein Microsoft-Purview-Überwachungsprotokolleintrag erstellt wird. Verwenden Sie sie für Complianceüberprüfungen, eDiscovery, Vorfallreaktionen und andere administrative Untersuchungen, bei denen ein auditierbarer Zugriffsdatensatz erforderlich ist.

Lesezugriff mit erhöhten Rechten ist für Purview-fähige Indizes in REST-API Version 2026-05-01-preview und höher verfügbar.

So funktionieren die erhöhten Leseberechtigungen

1. Die aufrufende Anwendung legt den x-ms-enable-elevated-read: true Header für die Suchanforderung fest.

2. Azure KI-Suche überspringt die bezeichnungsbasierte Zugriffsüberprüfung pro Dokument und gibt übereinstimmende Dokumente zurück, unabhängig von den Berechtigungen des anfordernden Benutzers EXTRACT für jede einzelne Bezeichnung.

3. Für jedes Dokument in der Antwort gibt Azure KI-Suche einen Eintrag im überwachungsprotokoll Microsoft Purview im Namen des anfordernden Mandanten aus. Eine einzelne Suchanforderung, die N-Dokumente zurückgibt, erzeugt N-Überwachungseinträge .

4. Überwachungseinträge werden asynchron in Purview hochgeladen, nachdem die Suchantwort zurückgegeben wurde.

Erforderliche Rollenzuweisung

Der aufrufende Entwicklerbenutzer muss für den Suchdienst oder den Indexbereich über die Rolle Mitwirkender an Suchindexdaten verfügen. Der Suchindexdatenleser reicht nicht aus. Der Zugriff mit erhöhten Leseberechtigungen schlägt mit 403 Forbidden fehl, wenn die Rolle nicht zugewiesen ist. Weitere Informationen zu Azure KI-Suche Rollen finden Sie unter Connect to Azure KI-Suche using roles.

Wenn der x-ms-enable-elevated-read-Header auf true gesetzt ist, darf der x-ms-query-source-authorization-Header nicht verwendet werden.

Beispiel für erhöhte Leseberechtigungen

POST  {{endpoint}}/indexes/sensitivity-docs/docs/search?api-version=2026-08-01-preview
Authorization: Bearer {{contributor-token}}
x-ms-enable-elevated-read: true
Content-Type: application/json

{
    "search": "*",
    "select": "title,summary,sensitivityLabel",
    "orderby": "title asc"
}

An Microsoft Purview übermittelte Auditfelder

Jeder Überwachungseintrag folgt der Office 365 Verwaltungsaktivitäts-API Schema und enthält die folgenden Felder.

Graduelle Leistungsminderung

Wenn Azure KI-Suche während der Verarbeitung einer Abfrage, z. B. während eines vorübergehenden Purview-Ausfalls, nicht Microsoft Purview erreichen kann, überspringt er die Bezeichnungsauswertung für diese Anforderung. Das Verhalten hängt davon ab, ob die Anforderung ein Benutzeridentitätstoken enthält:

• Leseanforderungen mit erweiterten Rechten (x-ms-enable-elevated-read: true): Die Anforderung schlägt mit 5xx fehl. Azure KI-Suche gibt keine beschrifteten Dokumente zurück, ohne zuerst Überwachungsprotokolle ausgeben zu können.

• Durch Bezeichnungen erzwungene Standardanforderungen (mit x-ms-query-source-authorization): Die Anfrage schlägt mit 5xx fehl. Azure KI-Suche gibt keine teilweisen oder ungefilterten Ergebnisse zurück, wenn keine Bezeichnungsrichtlinien ausgewertet werden können.

• Aufrufe ohne x-ms-query-source-authorization, die von einer Anwendung mit mindestens der Rolle Suchindex-Datenleser ausgeführt werden: Die Anfrage wird erfolgreich ausgeführt und gibt nur Dokumente zurück, denen keine Vertraulichkeitsbezeichnung zugewiesen ist. Beschriftete Dokumente werden aus der Antwort weggelassen.

Dieser herabgestufte Pfad ist nur für nicht benutzerorientierte Workflows vorgesehen, die explizit nicht bezeichnete Ergebnisse akzeptieren. Verlassen Sie sich nicht darauf, um Endbenutzer-Suchfunktionen zu nutzen.

Eine vollständige Liste der Fehlercodes, die während der Auswertung der Vertraulichkeitsbezeichnungen von Abfragen zurückgegeben werden, finden Sie unter Problembehandlung bei Abfragefehlern.

Überwachungsprotokolle zu Lesezugriffen mit erhöhten Rechten in Microsoft Purview ermitteln

Azure KI-Suche lädt Überwachungseinträge in das Überwachungsprotokoll von Microsoft Purview des aufrufenden Mandanten hoch. So untersuchen Sie eine erhöhte Leseaktivität:

1. Wählen Sie im Microsoft Purview-PortalSolutions>Audit aus.

2. Wählen Sie Audit Search aus, und filtern Sie dann nach Datumsbereich, Benutzer oder dem Azure KI-Suche Datensatztyp.

3. Öffnen Sie einen Eintrag, um die Standardschemafelder und die Azure KI-Suche benutzerdefinierten Felder anzuzeigen, einschließlich SensitivityLabelName, DocumentDataSourceType und DocumentDataSourceId.

Eine schrittweise Anleitung zum Ausführen von Überwachungssuchen, Aufbewahrungsverhalten und erforderlichen Purview-Rollen finden Sie unter Suche des Überwachungsprotokolls im Microsoft Purview-Portal.

Behandlung von Sensitivitätslabels bei Azure KI-Suche

Wenn Azure KI-Suche Dokumentinhalte mit Vertraulichkeitsbezeichnungen aus Quellen wie SharePoint, Azure Blob und anderen indiziert, werden sowohl der Inhalt als auch die Bezeichnungsmetadaten gespeichert. Die Suchabfrage gibt indizierte Inhalte zusammen mit der GUID zurück, die die auf das Dokument angewendete Vertraulichkeitsbezeichnung identifiziert. Dies geschieht nur, wenn der Benutzer über den über die Definition der Vertraulichkeitsbezeichnung zugewiesenen Datenzugriff EXTRACT für dieses Dokument verfügt. Diese GUID identifiziert die Bezeichnung eindeutig, enthält aber keine lesbaren Eigenschaften wie den Bezeichnungsnamen oder die zugehörigen Berechtigungen.

Beachten Sie, dass die GUID allein für Szenarien, die die Benutzeroberfläche enthalten, nicht ausreicht, da Vertraulichkeitsbezeichnungen häufig andere Richtliniensteuerelemente enthalten, die von Microsoft Purview Information Protection erzwungen werden, z. B.: Druckberechtigungen oder Screenshot- und Bildschirmaufnahmeeinschränkungen. Azure KI-Suche zeigt diese Funktionen nicht an.

Um Bezeichnungsnamen anzuzeigen und/oder benutzeroberflächenspezifische Einschränkungen zu erzwingen, muss Ihre Anwendung den Microsoft Purview Information Protection Endpunkt aufrufen, um vollständige Bezeichnungsmetadaten und zugehörige Berechtigungen abzurufen.

Sie können die von Azure KI-Suche zurückgegebene GUID verwenden, um die Bezeichnungseigenschaften aufzulösen und die APIs Purview-Bezeichnungen aufzurufen, um den Bezeichnungsnamen, die Beschreibung und die Richtlinieneinstellungen abzurufen.

Fehler bei Abfragen beheben

Wenn die Auswertung von Vertraulichkeitsbezeichnungen in Abfragezeit fehlschlägt, gibt Azure KI-Suche einen bestimmten HTTP-Fehlercode zurück, der die Ursache identifiziert. Der Dienst gibt niemals ein partielles oder ungefiltertes Resultset zurück. Wenn Bezeichnungsrichtlinien nicht ausgewertet werden können, schlägt die Abfrage fehl, statt nicht bezeichnete oder nicht autorisierte Inhalte offenzulegen.

400 Fehlerhafte Anfrage

Ein 400-Fehler zeigt ein Problem mit der Indexkonfiguration oder den Anforderungsheadern an. Beheben Sie die Konfiguration, bevor Sie den Vorgang wiederholen.

401 Nicht autorisiert

Ein 401-Fehler gibt ein Problem mit dem Autorisierungstoken oder den Purview-Berechtigungen der Anwendung an.

502 Ungültiges Gateway

Ein 502-Fehler weist auf einen Verbindungsfehler zwischen Azure KI-Suche und Microsoft Purview hin. Diese Fehler sind in der Regel vorübergehend.

504 Gateway-Timeout

Ein 504-Fehler weist darauf hin, dass Microsoft Purview nicht innerhalb des zulässigen Zeitraums geantwortet hat.

End-to-End-Testeinrichtung

Um Ihnen bei der Validierung Ihrer Vertraulichkeitskennzeichnung in Azure KI-Suche zu helfen, finden Sie hier eine Referenz für eine End-to-End-Einrichtung.

Dieses Repository veranschaulicht, wie:

• Konfigurieren Sie die Vertraulichkeitskennzeichnungen für die Synchronisierung und die Anerkennung in Azure KI-Suche
• Testen Sie Szenarien zum Einbinden und Durchsetzen der Abfragezeit für Dokumente mit vertraulichen Kennzeichnungen
• Extrahieren Sie den Namen des Labels und stellen Sie ihn als Teil der Quellenangaben bereit, die in Ihren RAG-Anwendungen oder Agenten verwendet werden.