Sicherheit in Azure AI Search

Azure AI Search bietet umfassende Sicherheitskontrollen über Netzwerkzugriff, Datenzugriff und Datenschutz hinweg, um die Unternehmensanforderungen zu erfüllen. Als Lösungsarchitekt sollten Sie drei wichtige Sicherheitsdomänen verstehen:

• Netzwerkdatenverkehrsmuster und Netzwerksicherheit: Eingehender, ausgehender und interner Datenverkehr.
• Zugriffssteuerungsmechanismen: API-Schlüssel oder Microsoft Entra-ID mit Rollen.
• Datenresidenz und -schutz: Verschlüsselung während der Übertragung, bei Verwendung mit optionaler vertraulicher Datenverarbeitung und im Ruhezustand mit optionaler Doppelverschlüsselung.

Ein Suchdienst unterstützt mehrere Netzwerksicherheitstopologien, von IP-Firewalleinschränkungen bis hin zu privaten Endpunkten zur vollständigen Netzwerkisolation. Verwenden Sie optional einen Netzwerksicherheitsperimeter, um eine logische Grenze um Ihre Azure PaaS-Ressourcen zu erstellen. Für Unternehmensszenarien, die präzise Berechtigungen erfordern, können Sie Zugriffssteuerungen auf Dokumentebene implementieren. Alle Sicherheitsfeatures sind in das Complianceframework von Azure integriert und unterstützen allgemeine Unternehmensmuster wie mehrinstanzenfähige und dienstübergreifende Authentifizierung mithilfe von verwalteten Identitäten.

In diesem Artikel werden die Implementierungsoptionen für jede Sicherheitsebene erläutert, die Ihnen beim Entwerfen geeigneter Sicherheitsarchitekturen für Entwicklungs- und Produktionsumgebungen helfen.

Netzwerkverkehrsmuster

Ein Azure AI Search-Dienst kann in der öffentlichen Azure-Cloud, einer privaten Azure-Cloud oder einer souveränen Cloud (z. B. Azure Government) gehostet werden. Standardmäßig wird für alle Cloudhosts der Suchdienst in der Regel von Clientanwendungen über öffentliche Netzwerkverbindungen aufgerufen. Obwohl dieses Muster vorherrschend ist, ist es nicht das einzige Datenverkehrsmuster, um das Sie sich kümmern müssen. Die Kenntnis aller Einstiegspunkte und des ausgehenden Datenverkehrs bildet den notwendigen Hintergrund für den Schutz Ihrer Entwicklungs- und Produktionsumgebungen.

Azure AI Search hat drei grundlegende Netzwerkverkehrsmuster:

• Eingehende Anforderungen, die von einem Benutzer oder Client an den Suchdienst gerichtet werden (vorherrschendes Muster)
• Ausgehende Anforderungen vom Suchdienst an andere Dienste in Azure und sonstigen Umgebungen
• Interne Anfragen zwischen Diensten über das sichere Microsoft-Backbonenetzwerk

Eingehender Datenverkehr

Eingehende Anforderungen, die auf einen Suchdienstendpunkt abzielen, umfassen Folgendes:

• Erstellen, Lesen, Aktualisieren oder Löschen von Indizes und anderen Objekten im Suchdienst
• Laden eines Indexes mit Suchdokumenten
• Index abfragen
• Ausführen von Indexer- oder Skillset-Aufträgen

Die REST-APIs beschreiben den vollständigen Bereich eingehender Anforderungen, die von einem Suchdienst behandelt werden.

Zumindest müssen alle eingehenden Anforderungen mit einer dieser beiden Optionen authentifiziert werden:

• Schlüsselbasierte Authentifizierung (Standard). Eingehende Anforderungen müssen einen gültigen API-Schlüssel enthalten.
• Rollenbasierte Zugriffssteuerung. Die Autorisierung erfolgt über Microsoft Entra-Identitäten und Rollenzuweisungen auf Ihrem Suchdienst.

Darüber hinaus können Sie Netzwerksicherheitsfeatures hinzufügen, um den Zugriff auf den Endpunkt weiter einzuschränken. Sie können entweder eingehende Regeln in einer IP-Firewall erstellen oder private Endpunkte erstellen, die Ihren Suchdienst vollständig vom öffentlichen Internet abschirmen.

Ausgehender Datenverkehr

Ausgehende Anforderungen können von Ihnen gesichert und verwaltet werden. Ausgehende Anfragen gehen von einem Suchdienst an andere Anwendungen. Diese Anfragen werden in der Regel von Indexern für textbasierte und multimodale Indizierung, benutzerdefinierte kompetenzbasierte KI-Anreicherung und Vektorisierung zum Zeitpunkt der Abfrage vorgenommen. Ausgehende Anforderungen umfassen sowohl Lese- als auch Schreibvorgänge.

Die folgende Liste ist eine vollständige Enumeration der ausgehenden Anforderungen, für die Sie sichere Verbindungen konfigurieren können. Ein Suchdienst stellt Anfragen in seinem eigenen Namen und im Auftrag eines Indexers oder benutzerdefinierter Fähigkeiten.

Ausgehende Verbindungen können in der Regel mithilfe der Vollzugriffsverbindungszeichenfolge einer Ressource erfolgen, die einen Schlüssel oder eine Datenbankanmeldung enthält, oder eine verwaltete Identität , wenn Sie Microsoft Entra-ID und rollenbasierten Zugriff verwenden.

Um Azure-Ressourcen hinter einer Firewall zu erreichen, erstellen Sie eingehende Regeln für andere Azure-Ressourcen, die Suchdienstanforderungen zulassen.

Um Azure-Ressourcen zu erreichen, die durch Azure Private Link geschützt werden, erstellen Sie eine freigegebene private Verbindung, die ein Indexer zum Herstellen seiner Verbindung verwendet.

Ausnahme für Such- und Speicherdienste in derselben Region

Wenn sich Azure Storage und die Azure KI-Suche in derselben Region befinden, wird der Netzwerkdatenverkehr über eine private IP-Adresse und das Microsoft-Backbonenetzwerk geleitet. Da private IP-Adressen verwendet werden, können Sie für Netzwerksicherheit weder IP-Firewalls noch einen privaten Endpunkt konfigurieren.

Konfigurieren Sie Verbindungen in derselben Region mit einer der folgenden Methoden:

• Ausnahme für vertrauenswürdige Dienste
• Ressourceninstanzregeln

Interner Verkehr

Interne Anforderungen werden von Microsoft gesichert und verwaltet. Sie können diese Verbindungen weder konfigurieren noch steuern. Wenn Sie den Netzwerkzugriff sperren, ist keine Aktion Ihrerseits erforderlich, da interner Datenverkehr nicht vom Kunden konfiguriert werden kann.

Interner Datenverkehr umfasst:

• Service-to-Service-Aufrufe für Aufgaben wie Authentifizierung und Autorisierung durch Microsoft Entra ID, Ressourcenprotokollierung, die an Azure Monitor gesendet wird, und Verbindungen mit privaten Endpunkten, die Azure Private Link nutzen.
• Anforderungen für integrierte Fähigkeitenverarbeitung, wobei Anfragen aus derselben Region an eine intern gehostete Microsoft Foundry-Ressource weitergeleitet werden, die ausschließlich für die integrierte Fähigkeitenverarbeitung von Azure AI Search genutzt wird.
• Anforderungen an die verschiedenen Modelle, die die semantische Bewertung unterstützen.

Netzwerksicherheit

Netzwerksicherheit schützt Ressourcen vor nicht autorisiertem Zugriff oder Angriffen, indem Kontrollen auf den Netzwerkdatenverkehr angewendet werden. Azure AI Search unterstützt Netzwerkfunktionen, die Ihre erste Verteidigungslinie gegen unbefugten Zugriff sein können.

Eingehende Verbindungen über IP-Firewalls

Ein Suchdienst wird mit einem öffentlichen Endpunkt bereitgestellt, der den Zugriff über eine öffentliche IP-Adresse ermöglicht. Um einzuschränken, welcher Datenverkehr über den öffentlichen Endpunkt fließt, erstellen Sie eine Firewallregel für eingehenden Datenverkehr, die Anforderungen von einer bestimmten IP-Adresse oder einem IP-Adressbereich zulässt. Alle Clientverbindungen müssen über eine zulässige IP-Adresse erfolgen, sonst wird die Verbindung verweigert.

Sie können das Azure-Portal zum Konfigurieren des Firewallzugriffs verwenden.

Alternativ können Sie die Verwaltungs-REST-APIs verwenden. Ab API-Version 2020-03-13 können Sie mit dem IpRule-Parameter den Zugriff auf Ihren Dienst einschränken, indem Sie die IP-Adressen, die Zugriff auf Ihren Dienst erhalten sollen, einzeln oder als Bereich angeben.

Eingehende Verbindung mit einem privaten Endpunkt (Netzwerkisolation, kein Internetdatenverkehr)

Für strengere Sicherheit können Sie einen privaten Endpunkt für Azure AI Search einrichten, der es einem Client in einem virtuellen Netzwerk ermöglicht, über einen Private Link sicher auf Daten in einem Suchindex zuzugreifen.

Der private Endpunkt verwendet eine IP-Adresse aus dem Adressraum des virtuellen Netzwerks für Verbindungen mit Ihrem Suchdienst. Der Netzwerkdatenverkehr zwischen dem Client und dem Suchdienst wird über das virtuelle Netzwerk und eine private Verbindung im Microsoft-Backbonenetzwerk geleitet, sodass keine Offenlegung im öffentlichen Internet erfolgt. Ein virtuelles Netzwerk ermöglicht eine sichere Kommunikation zwischen Ressourcen in Ihrem lokalen Netzwerk und im Internet.

Diese Lösung ist zwar die sicherste, aber die Inanspruchnahme weiterer Dienste ist mit zusätzlichen Kosten verbunden, so dass Sie sich über die Vorteile im Klaren sein sollten, bevor Sie sich darauf einlassen. Weitere Informationen zu den Kosten finden Sie in der Preisübersicht. Weitere Informationen zur Zusammenarbeit dieser Komponenten finden Sie in diesem Video. Die Option des privaten Endpunkts wird ab 5:48 m im Video behandelt. Anweisungen zum Einrichten des Endpunkts finden Sie unter Erstellen eines privaten Endpunkts für Azure AI Search.

Netzwerksicherheitsperimeter

Ein Netzwerksicherheitsperimeter ist eine logische Netzwerkgrenze um Ihre PaaS-Ressourcen (Platform-as-a-Service), die außerhalb eines virtuellen Netzwerks bereitgestellt werden. Sie richtet einen Umkreis für die Steuerung des öffentlichen Netzwerkzugriffs auf Ressourcen wie Azure KI-Suche, Azure Storage und Azure OpenAI ein. Sie können Ausnahmen über explizite Zugriffsregeln für eingehenden und ausgehenden Datenverkehr gewähren. Dieser Ansatz trägt dazu bei, Datenexfiltration zu verhindern und gleichzeitig die erforderliche Konnektivität für Ihre Anwendungen aufrechtzuerhalten.

Eingehende Clientverbindungen und Dienst-zu-Dienst-Verbindungen treten innerhalb der Grenze auf, wodurch Ihre Abwehr vor unbefugtem Zugriff vereinfacht und gestärkt wird. Es ist üblich, dass Azure KI-Suche-Lösungen mehrere Azure-Ressourcen verwenden. Die folgenden Ressourcen können alle mit einem vorhandenen Netzwerksicherheitsperimeter verbunden werden:

• Azure AI Search
• Azure OpenAI
• Azure Storage
• Azure Monitor.

Eine vollständige Liste der berechtigten Dienste finden Sie unter Ongeboardete Private Link-Ressourcen.

Authentication

Sobald eine Anfrage für den Suchdienst zugelassen ist, muss sie noch eine Authentifizierung und Autorisierung durchlaufen, die bestimmt, ob die Anfrage zulässig ist. Azure AI Search unterstützt zwei Ansätze:

• Bei der Microsoft-Entra-Authentifizierung wird der Anrufer (und nicht die Anfrage) als die authentifizierte Identität festgelegt. Eine Azure-Rollenzuweisung bestimmt die Autorisierung.

• Die schlüsselbasierte Authentifizierung erfolgt für die Anforderung (nicht die aufrufende App oder den Benutzer) durch einen API-Schlüssel, wobei der Schlüssel aus einer Zeichenfolge aus nach dem Zufallsprinzip generierten Ziffern und Buchstaben besteht, die beweisen, dass die Anforderung von einer vertrauenswürdigen Quelle stammt. Schlüssel sind für jede Anforderung erforderlich. Die Übermittlung eines gültigen Schlüssels gilt als Beleg dafür, dass die Anforderung von einer vertrauenswürdigen Entität stammt.

  Die Abhängigkeit von der auf API-Schlüsseln basierenden Authentifizierung bedeutet, dass Sie über einen Plan für die regelmäßige erneute Generierung des Administratorschlüssels gemäß den bewährten Azure-Sicherheitsmethoden verfügen sollten. Pro Suchdienst können maximal zwei Administratorschlüssel vorhanden sein. Weitere Informationen zum Sichern und Verwalten von API-Schlüsseln finden Sie unter Erstellen und Verwalten von API-Schlüsseln.

Die schlüsselbasierte Authentifizierung ist die Standardeinstellung für Datenebenenvorgänge (Erstellen und Verwenden von Objekten im Suchdienst). Sie können beide Authentifizierungsmethoden verwenden oder eine Methode, die Sie für Ihren Suchdienst nicht Verfügbar machen möchten, deaktivieren.

Authorization

Azure AI Search bietet Autorisierungsmodelle für die Verwaltung von Diensten und Inhalten.

Privilegierter Zugriff

Bei einem neuen Suchdienst werden vorhandene Rollenzuweisungen auf Abonnementebene vom Suchdienst geerbt, und nur Besitzer und Benutzerzugriffsadministratoren können Zugriff gewähren.

Vorgänge der Steuerungsebene (Dienst- oder Ressourcenerstellung und -verwaltung) sind ausschließlich über Rollenzuweisungen autorisiert, ohne schlüsselbasierte Authentifizierung für die Dienstverwaltung zu verwenden.

Zu den Steuerungsebenenvorgängen gehören das Erstellen, Konfigurieren oder Löschen des Diensts und das Verwalten von Sicherheit. Daher bestimmen Azure-Rollenzuweisungen, wer diese Aufgaben ausführen kann, unabhängig davon, ob dazu das Portal, PowerShell oder die Verwaltungs-REST-APIs verwendet werden.

Für die Verwaltung von Suchdiensten gibt es drei grundlegende Rollen (Besitzer, Mitwirkender, Leser).

Zugriff auf Inhalte autorisieren

Datenebenenvorgänge beziehen sich auf die Objekte, die in einem Suchdienst erstellt und verwendet werden.

• Für die rollenbasierte Autorisierung verwenden Sie Azure-Rollenzuweisungen, um Lese- und Schreibzugriff auf Vorgänge einzurichten.

• Bei der schlüsselbasierten Autorisierung bestimmen ein API-Schlüssel und ein qualifizierter Endpunkt den Zugang. Ein Endpunkt kann der Dienst selbst, die Indexsammlung, ein bestimmter Index, eine Dokumentsammlung oder ein bestimmtes Dokument sein. Wenn der Endpunkt, der Vorgang (z. B. eine Erstellungsanforderung) und der Schlüsseltyp (Administrator oder Abfrage) miteinander verkettet sind, autorisieren sie den Zugriff auf Inhalte und Vorgänge.

Beschränkung des Zugriffs auf Indizes

Mit Azure-Rollen können Sie Berechtigungen für einzelne Indizes festlegen, solange dies programmatisch geschieht.

Mit Hilfe von Schlüsseln kann jeder, der einen Administratorschlüssel für Ihren Dienst besitzt, jeden Index im selben Dienst lesen, ändern oder löschen. Zum Schutz vor der versehentlichen oder böswilligen Löschung von Indizes können Sie Ihre interne Quellcodeverwaltung für Coderessourcen verwenden und unerwünschte Lösch- oder Änderungsvorgänge für Indizes so rückgängig machen. Azure AI Search verfügt über ein Failover innerhalb des Clusters, um die Verfügbarkeit zu gewährleisten, speichert oder führt jedoch nicht Ihren eigenen Code aus, der zum Erstellen oder Laden von Indizes verwendet wird.

Bei mandantenfähigen Lösungen, die Sicherheitsgrenzen auf Indexebene erfordern, ist es üblich, die Indexisolierung auf der mittleren Ebene im Anwendungscode zu behandeln. Weitere Informationen über den mandantenfähigen Anwendungsfall finden Sie unter Designmuster für mandantenfähige SaaS-Anwendungen und Azure KI-Suche.

Beschränkung des Zugangs zu Dokumenten

Benutzerberechtigungen auf Dokumentebene, auch als Sicherheit auf Zeilenebene bezeichnet, sind als Vorschaufeature verfügbar und hängen von der Datenquelle ab. Wenn Inhalte aus Azure Data Lake Storage (ADLS) Gen2 oder Azure Blobs stammen, werden Benutzerberechtigungsmetadaten, die aus Azure Storage stammen, in indexergenerierten Indizes beibehalten und zur Abfragezeit erzwungen, sodass nur autorisierte Inhalte in Suchergebnisse einbezogen werden.

Bei anderen Datenquellen können Sie eine Dokumentnutzlast übertragen, die Metadaten für Benutzer- oder Gruppenberechtigungen enthält, und diese Berechtigungen werden in indizierten Inhalten aufbewahrt und auch zur Abfragezeit erzwungen. Diese Funktion ist auch als Vorschau verfügbar.

Wenn Sie keine Vorschau-Funktionen verwenden können, und Sie Zugriff auf Inhalte in Suchergebnissen benötigen, gibt es eine Technik zum Anwenden von Filtern, die Dokumente basierend auf der Benutzeridentität einschließen oder ausschließen. Dieser Workaround fügt ein String-Feld in die Datenquelle ein, das eine Gruppen- oder Benutzeridentität darstellt, die Sie in Ihrem Index filterbar machen können. Weitere Informationen zu diesem Muster finden Sie unter Einschränkung aus Sicherheitsgründen auf der Grundlage von Identitätsfiltern. Weitere Informationen zum Dokumentzugriff finden Sie unter Zugriffssteuerung auf Dokumentebene.

Datenresidenz

Wenn Sie einen Suchdienst einrichten, wählen Sie eine Region aus, in der die Kundendaten gespeichert und verarbeitet werden. Jede Region ist innerhalb einer Geografie (geografischer Raum) vorhanden, die oft mehrere Regionen umfasst (z. B. ist die Schweiz ein geografischer Raum mit Schweiz, Norden und Schweiz, Westen). Die Azure KI-Suche repliziert Ihre Daten möglicherweise in eine andere Region innerhalb desselben geografischen Raums für Dauerhaftigkeit und hohe Verfügbarkeit. Der Dienst speichert oder bearbeitet keine Kundendaten außerhalb des von Ihnen angegebenen geografischen Raums, es sei denn, Sie konfigurieren eine Funktion, die von einer anderen Azure-Ressource abhängig ist, und diese Ressource wird in einer anderen Region bereitgestellt.

Azure Storage ist derzeit die einzige externe Ressource, in die ein Suchdienst schreibt. Das Speicherkonto ist ein von Ihnen bereitgestelltes Konto, das sich in einer beliebigen Region befinden kann. Ein Suchdienst schreibt in Azure Storage, wenn Sie eines der folgenden Features verwenden:

• Cache für Anreicherung
• Debugsitzung
• Wissensspeicher

Weitere Informationen zur Datenresidenz finden Sie unter Datenresidenz in Azure.

Ausnahmen von der Verpflichtung zur Datenresidenz

Objektnamen werden in den Telemetrieprotokollen angezeigt, die von Microsoft verwendet werden, um Support für den Dienst bereitzustellen. Objektnamen werden außerhalb der ausgewählten Region oder des ausgewählten Standorts gespeichert und verarbeitet. Zu den Objektnamen gehören die Namen von Indizes und Indexfeldern, Aliasen, Indexern, Datenquellen, Skillsets, Synonymzuordnungen, Ressourcen, Containern und Schlüsseltresorspeichern. Kunden sollten keine sensiblen Daten in solchen Namensfeldern platzieren oder Anwendungen erstellen, mit denen sensible Daten in diesen Feldern gespeichert werden.

Telemetrieprotokolle werden anderthalb Jahre lang aufbewahrt. Während dieses Zeitraums kann Microsoft unter den folgenden Bedingungen auf Objektnamen zugreifen und auf diese verweisen:

• Diagnose eines Problems, Verbesserung einer Funktion oder Behebung eines Fehlers. In diesem Szenario erfolgt der Datenzugriff ausschließlich intern, ohne Zugriff durch Dritte.

• Während des Supports können diese Informationen genutzt werden, um Probleme schnell zu lösen und das Produktteam bei Bedarf einzuschalten

Datenschutz

Auf Speicherebene ist die Datenverschlüsselung für alle vom Dienst verwalteten Inhalte, die auf Datenträgern gespeichert werden, integriert: Indizes, Synonymzuordnungen und die Definitionen von Indexern, Datenquellen und Skillsets. Dienstseitig verwaltete Verschlüsselung gilt sowohl für die langfristige Datenspeicherung als auch für die temporäre Datenspeicherung.

Optional können Sie kundenseitig verwaltete Schlüssel (Customer-Managed Keys, CMK) zur ergänzenden Verschlüsselung indizierter Inhalte hinzufügen, um eine Mehrfachverschlüsselung ruhender Daten zu erzielen. Bei Diensten, die nach dem 1. August 2020 erstellt wurden, erstreckt sich die CMK-Verschlüsselung auf kurzfristige Daten auf temporären Datenträgern.

Daten während der Übertragung

Für Suchdienstverbindungen im öffentlichen Internet lauscht die Azure KI-Suche am HTTPS-Port 443.

Die Azure KI-Suche unterstützt TLS 1.2 und 1.3 für die Client-zu-Dienst-Kanalverschlüsselung:

• TLS 1.3 ist die Standardeinstellung für neuere Clientbetriebssysteme und -versionen von .NET.
• TLS 1.2 ist die Standardeinstellung für ältere Systeme, Sie können TLS 1.3 jedoch explizit für eine Clientanforderung festlegen.

Frühere Versionen von TLS (1.0 oder 1.1) werden nicht unterstützt.

Weitere Informationen finden Sie unter TLS-Unterstützung in .NET Framework.

Verwendete Daten

Standardmäßig stellt Azure AI Search Ihren Suchdienst in der standardmäßigen Azure-Infrastruktur bereit. Diese Infrastruktur verschlüsselt ruhende und während der Übertragung befindliche Daten, schützt jedoch keine Daten, während sie aktiv im Arbeitsspeicher verarbeitet werden.

Optionalerweise können Sie das Azure-Portal oder die Dienste – Erstellen oder Aktualisieren (REST-API) verwenden, um vertrauliches Computing während der Diensterstellung zu konfigurieren. Vertrauliche Computer schützen Daten, die verwendet werden, vor unbefugtem Zugriff, einschließlich von Microsoft, durch Hardwarenachweis und Verschlüsselung. Weitere Informationen finden Sie unter "Vertrauliche Computeranwendungsfälle".

In der folgenden Tabelle werden beide Computetypen verglichen.

¹ Wenn Sie diesen Computetyp aktivieren, können Indexer nur in der privaten Ausführungsumgebung ausgeführt werden, was bedeutet, dass sie aus den Suchclustern ausgeführt werden, die auf vertraulichen Computern gehostet werden.

Ruhende Daten

In der folgenden Tabelle werden für Daten, die vom Suchdienst intern verarbeitet werden, die Datenverschlüsselungsmodelle beschrieben. Einige Features, wie z. B. der Wissensspeicher, inkrementelle Anreicherung und indexerbasierte Indizierung, lesen von oder schreiben in Datenstrukturen in anderen Azure Services. Dienste, die eine Abhängigkeit von Azure Storage aufweisen, können die Verschlüsselungsfeatures dieser Technologie verwenden.

Wenn Sie CMK-Verschlüsselung einführen, verschlüsseln Sie Inhalte zweimal. Für die im vorherigen Abschnitt aufgeführten Objekte und Felder wird der Inhalt zuerst mit Ihrem CMK und dann als Zweites mit dem von Microsoft verwalteten Schlüssel verschlüsselt. Inhalte werden doppelt verschlüsselt auf Datenträgern für die langfristige Speicherung sowie auf temporären Datenträgern, die für die kurzfristige Speicherung verwendet werden.

Dienstseitig verwaltete Schlüssel

Dienstseitig verwaltete Verschlüsselung ist ein Microsoft-interner Vorgang, der die 256-Bit-AES-Verschlüsselung verwendet. Sie wird automatisch auf die gesamte Indizierung angewendet, einschließlich auf inkrementelle Updates für nicht vollständig verschlüsselte Indizes (vor Januar 2018 erstellt).

Dienstseitig verwaltete Verschlüsselung gilt für alle Inhalte bei langfristiger und kurzfristiger Speicherung.

Kundenseitig verwaltete Schlüssel (CMK)

Kunden verwenden CMK aus zwei Gründen: zusätzlichen Schutz und die Möglichkeit, Schlüssel zu widerrufen und den Zugriff auf Inhalte zu verhindern.

Vom Kunden verwaltete Schlüssel erfordern einen anderen abrechnungsfähigen Dienst, Azure Key Vault, der sich in einer anderen Region befinden kann, aber unter demselben Azure-Mandanten wie Azure AI Search.

Die CMK-Unterstützung wurde in zwei Phasen eingeführt. Wenn Sie Ihren Suchdienst während der ersten Phase erstellt haben, war CMK-Verschlüsselung auf die langfristige Speicherung und bestimmte Regionen beschränkt. In der zweiten Phase erstellte Dienste können die CMK-Verschlüsselung in jeder Region verwenden. Im Rahmen der zweiten Einführungswelle werden Inhalte sowohl bei langfristiger als auch bei kurzfristiger Speicherung CMK-verschlüsselt.

• Der erste Rollout war am 1. August 2020 und umfasste die folgenden fünf Regionen. Suchdienste, die in den folgenden Regionen erstellt wurden, unterstützten CMK für Datenfestplatten, jedoch nicht für temporäre Festplatten.

  • Westliches USA 2
  • East US
  • Süd-Mittel-USA
  • US-Regierung Virginia
  • US-Regierung Arizona

• Beim zweiten Rollout am 13. Mai 2021 wurde die Verschlüsselung für temporäre Datenträger und die erweiterte CMK-Verschlüsselung für alle unterstützten Regionen hinzugefügt.

  Wenn Sie CMK aus einem Dienst verwenden, der während des ersten Rollouts erstellt wurde und sie auch CMK-Verschlüsselung für temporäre Datenträger wünschen, müssen Sie einen neuen Suchdienst in der Region Ihrer Wahl erstellen und Ihre Inhalte erneut bereitstellen. Um das Erstellungsdatum Ihres Dienstes zu ermitteln, siehe Überprüfen Sie das Erstellungs- oder Upgradedatum des Dienstes.

Durch Aktivieren der CMK-Verschlüsselung wird die Indexgröße erhöht und die Abfrageleistung beeinträchtigt. Basierend auf den bisherigen Beobachtungen können Sie mit einem Anstieg der Abfragezeiten um 30–60 Prozent rechnen, wobei die tatsächliche Leistung je nach Indexdefinition und Art der Abfragen variiert. Aufgrund dieser negativen Auswirkungen auf die Leistung wird empfohlen, diese Funktion nur für Indizes zu aktivieren, für die sie wirklich erforderlich ist. Weitere Informationen finden Sie unter Konfigurieren von vom Kunden verwalteten Verschlüsselungsschlüsseln in Azure AI Search.

Protokollierung und Überwachung

Azure AI Search protokolliert keine Benutzeridentitäten, sodass Sie keine Informationen über einen bestimmten Benutzer in den Protokollen finden können. Der Dienst protokolliert jedoch CRUD-Vorgänge (Create-Read-Update-Delete, Erstellen-Lesen-Aktualisieren-Löschen), die Sie möglicherweise mit anderen Protokollen korrelieren können, um die Wirkung bestimmter Aktionen zu verstehen.

Mithilfe von Warnmeldungen und der Protokollierungsinfrastruktur in Azure können Sie Spitzen im Abfragevolumen oder andere Aktionen, die von den erwarteten Workloads abweichen, ermitteln. Weitere Informationen zum Einrichten von Protokollen finden Sie unter Sammeln und Analysieren von Protokolldaten sowie Überwachen von Abfrageanforderungen.

Compliance und Governance

Azure AI Search nimmt an regelmäßigen Audits teil und wurde nach vielen globalen, regionalen und branchenspezifischen Standards sowohl für die Public Cloud als auch für Azure Government zertifiziert. Um die vollständige Liste zu erhalten, laden Sie das Whitepaper Microsoft Azure-Complianceangebote von der offiziellen Seite mit Überwachungsberichten herunter.

Es wird empfohlen, die Zertifizierungen und Dokumentationen der Azure AI Search-Compliance regelmäßig zu überprüfen, um die Übereinstimmung mit Ihren gesetzlichen Anforderungen sicherzustellen.

Verwenden von Azure Policy

Aus Konformitätsgründen können Sie Azure Policy verwenden, um die bewährten Methoden für höchste Sicherheit der Microsoft Cloud Security Benchmark zu implementieren. Die Microsoft Cloud Security Benchmark ist eine Sammlung von Sicherheitsempfehlungen, die in Sicherheitskontrollen programmiert sind. Diese sind den wichtigsten Maßnahmen zugeordnet, die Sie zur Verringerung von Bedrohungen für Dienste und Daten ergreifen sollten. Derzeit gibt es 12 Sicherheitskontrollen, darunter Netzwerksicherheit, Protokollierung und Überwachung und Schutz von Daten.

Azure Policy ist eine in Azure integrierte Funktion, mit der Sie die Konformität für mehrere Standards, einschließlich denen der Microsoft Cloud Security Benchmark, verwalten können. Für bekannte Benchmarks bietet Azure Policy integrierte Definitionen, die sowohl Kriterien als auch eine umsetzbare Reaktion bei Nichteinhaltung bereitstellen.

Für Azure AI Search gibt es derzeit eine integrierte Definition. Es ist für die Ressourcenprotokollierung. Sie können eine Richtlinie zuweisen, die Suchdienste identifiziert, bei denen eine Ressourcenprotokollierung fehlt, und diese dann aktivieren. Weitere Informationen finden Sie unter Kontrollen zur Einhaltung gesetzlicher Bestimmungen in Azure Policy für Azure AI Search.

Verwenden von Tags

Wenden Sie Metadatentags auf die Kategorisierung von Suchdiensten basierend auf den Anforderungen an die Datenempfindlichkeit und Compliance an. Dies erleichtert ordnungsgemäße Governance- und Sicherheitskontrollen. Weitere Informationen finden Sie unter Verwenden von Tags zum Organisieren Ihrer Azure-Ressourcen und allgemeiner Anleitungen – Organisieren von Azure-Ressourcen mithilfe von Tags.

Verwandte Inhalte

• Grundlegende Azure-Sicherheitsinformationen
• Sicherheit von Azure
• Microsoft Defender für Cloud

Außerdem empfehlen wir das folgende Video zu Sicherheitsfeatures. Es ist mehrere Jahre alt und deckt keine neueren Features ab, aber es deckt diese Features ab: CMK, IP-Firewalls und private Verknüpfungen. Wenn Sie diese Features verwenden, finden Sie dieses Video möglicherweise hilfreich.