Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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 Bestimmungen und kann dazu führen, dass Daten außerhalb der Azure-Compliancegrenze verarbeitet oder gespeichert werden und 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.
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.
Tip
Wenn Sie gekennzeichnete Inhalte über eine Wissensdatenbank (Abrufaktion oder MCP-Endpunkt) nutzen, anstatt Azure KI-Suche direkt aufzurufen, finden Sie unter Überprüfen von Metadaten mit Vertraulichkeitsbezeichnungen in Abrufantworten die entsprechenden Antwortfelder. Der in diesem Artikel dokumentierte erweiterte Lesezugriff und die Microsoft Purview-Auditprotokollierung gelten für beide Pfade.
Voraussetzungen
Schließen Sie alle Schritte unter Benutzen Sie Azure KI-Suche Indexer, um Microsoft Purview Vertraulichkeitskennzeichnungen einzubinden ab.
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 ein entsprechendes Vorschau-SDK-Paket zum Abfragen des Indexes. 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 (beispielsweise sind Purview-APIs vorübergehend nicht verfügbar), gibt der Dienst 5xx zurück und gibt kein partielles oder ungefiltertes Resultset zurück.
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
Authorizationbereitgestellt wird. Die mindestens erforderliche Rolle istSearch Index Data Reader. Weitere Informationen finden Sie im Azure KI-Suche RBAC-Leitfaden. - Die Benutzeridentität über Token, die im
x-ms-query-source-authorizationHeader bereitgestellt ist.
Beide sind erforderlich, um die bezeichnungsbasierte Sichtbarkeit zu autorisieren.
| Eingabetyp | Beschreibung | Beispielquelle |
|---|---|---|
| Anwendungsrolle | Bestimmt, ob die aufrufende App über die Berechtigung zum Ausführen von Abfragen für den Index verfügt. | Authorization: Bearer <app-token> |
| Benutzeridentität | Bestimmt, auf welche Vertraulichkeitsbezeichnungen der Endbenutzer zugreifen darf. | x-ms-query-source-authorization: <user-token> |
2. Bewertung von Vertraulichkeitsetiketten
Wenn eine Abfrageanforderung empfangen wird, wertet Azure KI-Suche Folgendes aus:
- Das Feld
sensitivityLabelin jedem indizierten Dokument (extrahiert aus Microsoft Purview während des Ingestionsprozesses). - 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.
Hinweis
Intern erstellt der Dienst dynamische Zugriffsfilter ähnlich der RBAC-Erzwingung.
Diese Filter sind nicht vom Benutzer sichtbar und können nicht in der Abfragenutzlast geändert werden.
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-authorizationBenutzeridentitä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 unter Verwendung einer unterstützten Authentifizierungsbibliothek beziehen, wie z. B. die Microsoft Authentication Library (MSAL) (MSAL).
In OBO-Szenarien muss das Token für die downstream-API angefordert werden, die die Anwendung aufruft. Wenn Sie beispielsweise Azure KI-Suche aufrufen, ist der Ressourcen-URI https://search.azure.com/.default.
Der .default-Bereich fragt alle delegierten Berechtigungen an, die für die Anwendung für die angegebene Ressource vorab genehmigt wurden.
Vertraulichkeitsbezeichnungsberechtigungen, einschließlich EXTRACT, werden nicht als OAuth-Bereiche dargestellt. Diese Berechtigungen werden zur Laufzeit vom nachgeschalteten Dienst ausgewertet, z. B. Azure KI-Suche, basierend auf der Benutzeridentität im Token und der angewendeten Vertraulichkeitsbezeichnungsrichtlinie.
Abfragebeispiel
Hier ist ein Beispiel für eine Abfrageanforderung mit Microsoft Purview-Vertraulichkeitsbezeichnungserzwingung.
Das Anwendungstoken wird als Bearertoken im Authorization Header übergeben. Das Benutzertoken wird ohne das x-ms-query-source-authorization Präfix als unformatierten Tokenwert im Bearer Header übergeben.
POST {{endpoint}}/indexes/sensitivity-docs/docs/search?api-version=2025-11-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)
Mit erhöhtem Lesezugriff kann ein autorisierter Entwickler gekennzeichnete Dokumente zurückgeben, die der aufrufende Benutzer normalerweise nicht sehen könnte, wobei für jedes Dokument, das die Anfrage zurückgibt, 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
Die aufrufende Anwendung legt den
x-ms-enable-elevated-read: trueHeader für die Suchanforderung fest.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
EXTRACTfür jede einzelne Bezeichnung.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 .
Ü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-05-01-preview
Authorization: Bearer {{contributor-token}}
x-ms-enable-elevated-read: true
Content-Type: application/json
{
"search": "*",
"select": "title,summary,sensitivityLabel",
"orderby": "title asc"
}
Überwachungsfelder, die an Microsoft Purview ausgegeben werden
Jeder Überwachungseintrag folgt der Office 365 Verwaltungsaktivitäts-API Schema und enthält die folgenden Felder.
| Kategorie | Feld | Beschreibung |
|---|---|---|
| Standardschema | CreationTime |
UTC-Zeitstempel der Leseanforderung mit erhöhten Rechten. |
| Standardschema | Operation |
Der Vorgangsname, der die Leseaktion mit erhöhten Rechten identifiziert. |
| Standardschema | OrganizationId |
Die Microsoft Entra Mandanten-ID des Suchdiensts. |
| Standardschema | RecordType |
Der Office 365-Datensatztyp für Verwaltungsaktivitäten für Azure KI-Suche. |
| Standardschema | UserType |
Der Typ des Benutzers, der die Anforderung ausgestellt hat. |
| Standardschema | UserId |
Der eindeutige Bezeichner (PUID) des anfordernden Benutzers. |
| Standardschema | UserPrincipalName |
Der Benutzerprinzipalname (UPN) des anfordernden Benutzers. |
| Standardschema | ClientIP |
Die IP-Adresse der aufrufenden Anwendung. |
| Azure KI-Suche | UserObjectId |
Die Microsoft Entra Objekt-ID des anfordernden Benutzers. |
| Azure KI-Suche | DocumentDataSourceType |
Der Quelltyp des aufgerufenen Dokuments, z. B. azureblob, sharepoint, onelake oder searchIndex. |
| Azure KI-Suche | DocumentDataSourceId |
Der quellspezifische Bezeichner des zugegriffenen Dokuments, z. B. die BLOB-URL oder SharePoint Element-ID. |
| Azure KI-Suche | SensitivityLabelName |
Der Anzeigename der Vertraulichkeitsbezeichnung, die auf das aufgerufene Dokument angewendet wurde. |
Graduelle Leistungsminderung
Wenn Azure KI-Suche während der Verarbeitung einer Abfrage nicht Microsoft Purview erreichen kann, z. B. während eines vorübergehenden Purview-Ausfalls, wird die Bezeichnungsauswertung für diese Anforderung übersprungen. 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 mit5xxfehl. 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 mit5xxfehl. Azure KI-Suche gibt keine teilweisen oder ungefilterten Ergebnisse zurück, wenn Bezeichnungsrichtlinien nicht 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.
Ü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:
Wählen Sie im Microsoft Purview-PortalSolutions>Audit aus.
Wählen Sie Audit Search aus, und filtern Sie dann nach Datumsbereich, Benutzer oder dem Azure KI-Suche Datensatztyp.
Öffnen Sie einen Eintrag, um die Standardschemafelder und die Azure KI-Suche benutzerdefinierten Felder anzuzeigen, einschließlich
SensitivityLabelName,DocumentDataSourceTypeundDocumentDataSourceId.
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.
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:
- So konfigurieren Sie die Vertraulichkeitskennzeichnungen für die Synchronisierung und die Anerkennung in Azure KI-Suche
- Testen von Szenarien zum Einbinden und Durchsetzen der Abfragezeit für Dokumente mit vertraulichen Kennzeichnungen
- So extrahieren Sie die Bezeichnung und stellen sie als Element der in Ihren RAG-Anwendungen oder Agents verwendeten Zitate zur Verfügung.