Konfigurieren von vom Kunden verwalteten Schlüsseln für Azure KI-Suche verschlüsselten Daten

Durch das Aktivieren von vom Kunden verwalteten Schlüsseln (CMK) wird zusätzlich zur ruhenden Standardverschlüsselung bei Verwendung von Microsoft verwalteten Schlüsseln zusätzliche Sicherheit hinzugefügt. Wenn Sie CMK aktivieren, steuern Sie die Verschlüsselungsschlüssel, die zum Schutz Ihrer Daten verwendet werden, einschließlich der Folgenden:

• Drehen von Schlüsseln in einem vom Kunden definierten Zeitplan
• Deaktivieren oder Widerrufen von Schlüsseln zum Blockieren des Zugriffs auf verschlüsselte Inhalte (zwischengespeicherte Schlüssel können bis zu 60 Minuten lang beibehalten werden)
• Überwachen der Schlüsselverwendung durch Azure Key Vault Protokollierung

Sie können Schlüssel mithilfe einer der folgenden Methoden erstellen, speichern und verwalten:

• Azure Key Vault

• Azure Key Vault Managed HSM (Hardware-Sicherheitsmodul). Ein Azure Key Vault Managed HSM ist ein FIPS 140-2 Level 3 validiertes HSM. Um von Azure Key Vault zu HSM zu migrieren, rotieren Sie Ihre Schlüssel und wählen Sie Managed HSM für die Speicherung aus.

In diesem Artikel wird erläutert, wie Sie CMK für zusätzlichen Schutz Ihrer verschlüsselten Daten in Azure KI-Suche konfigurieren.

Voraussetzungen

• Azure KI-Suche in einem abrechenbaren Tarif (mindestens Basic in einer beliebigen Region)

• Azure Key Vault und ein Key Vault mit aktivierten Funktionen für vorläufiges Löschen und Bereinigungsschutz. Oder Azure Key Vault Managed HSM. Diese Ressource kann sich in einem beliebigen Abonnement und in einem anderen Mandanten befinden. Diese Anweisungen setzen einen einzelnen Mandanten voraus. Informationen zur mandantenübergreifenden Konfiguration finden Sie unter Konfigurieren von vom Kunden verwalteten Schlüsseln in verschiedenen Mandanten.

• Wenn Sie CMK auf Dienstebene konfigurieren möchten, verwenden Sie die Search Management-REST-API-Version 2026-03-01-preview oder neuer. Um zu prüfen, ob ein Objekt einen Schlüssel auf Dienstebene erbt, verwenden Sie die Datenebenen-API, Version 2026-05-01-Preview oder höher.

• Möglichkeit zum Einrichten von Berechtigungen für den Schlüsselzugriff und zum Zuweisen von Rollen. Zum Erstellen von Schlüsseln müssen Sie Key Vault Crypto Officer in Azure Key Vault oder Managed HSM Crypto Officer in Azure Key Vault managed HSM sein.

  Um Rollen zuzuweisen, müssen Sie entweder Besitzer, Benutzerzugriffsadministrator, Rollenbasierter Zugriffskontrolladministrator sein oder einer benutzerdefinierten Rolle mit Microsoft.Authorization/roleAssignments/write-Berechtigungen zugewiesen sein.

Konfigurieren von CMK für Azure KI-Suche-Objekte

Objekte mit verschlüsselten Daten, die mit einem vom Kunden verwalteten Schlüssel (CMK) konfiguriert werden können, umfassen Indizes, Synonymlisten, Indexer, Datenquellen, Vektorisierer und Skillsets. Verschlüsselung ist rechenintensiv zu entschlüsseln, sodass nur vertrauliche Inhalte verschlüsselt werden.

Verschlüsselung erfolgt über:

• Alle Inhalte in Indizes und Synonymlisten.

• Vertrauliche Inhalte in Indexern, Datenquellen, Skillsets und Vektorisierern. Vertrauliche Inhalte umfassen Verbindungszeichenfolgen, Beschreibungen, Identitäten, Schlüssel und Benutzereingaben. Beispielsweise können Skillsets Schlüssel für verbundene Dienste enthalten, und einige Fähigkeiten akzeptieren Benutzereingaben, z. B. benutzerdefinierte Entitäten. In beiden Fällen werden Schlüssel und Benutzereingaben verschlüsselt. Alle Verweise auf externe Ressourcen, z. B. Azure Datenquellen oder Azure OpenAI-Modelle, werden ebenfalls verschlüsselt.

Das Hinzufügen eines vom Kunden verwalteten Schlüssels zu einem Objekt muss erfolgen, wenn das Objekt neu erstellt wird. Es ist wichtig, folgendes zu beachten:

• Sie können CMK nicht rückwirkend zu einem vorhandenen Objekt hinzufügen. Wenn Sie einem vorhandenen Objekt einen vom Kunden verwalteten Schlüssel hinzufügen möchten, müssen Sie dieses Objekt mit aktivierter Verschlüsselung löschen und neu erstellen.

• Sobald CMK konfiguriert ist, erfolgt die Verschlüsselung jedes Mal, wenn der Dienst Daten schreibt, einschließlich ruhender Daten (langfristiger Speicher) oder temporäre zwischengespeicherte Daten (kurzfristiger Speicher). Bei Objekten wie Datenquellen, Indexern und Skillsets wird die Objektdefinition verschlüsselt. Bei Indizes werden die indizierten Dokumente selbst (nicht nur das Indexschema) verschlüsselt.

• Obwohl Sie einem vorhandenen Objekt keine Verschlüsselung hinzufügen können, können Sie alle Teile der Verschlüsselungsdefinition eines Objekts ändern, einschließlich des Wechsels zu einem anderen Schlüsseltresor oder HSM-Speicher, solange sich die Ressource im selben Mandanten befindet.

• Die Verschlüsselung mit einem CMK ist unumkehrbar. Sie können Schlüssel drehen und die CMK-Konfiguration ändern, die Indexverschlüsselung dauert jedoch für die Lebensdauer des Indexes. Nach der Verschlüsselung mit CMK kann nur auf einen Index zugegriffen werden, wenn der Suchdienst Zugriff auf den Schlüssel hat. Wenn Sie den Zugriff auf den Schlüssel widerrufen, indem Sie die Rollenzuweisung löschen oder ändern, kann der Index nicht verwendet werden, und der Dienst kann erst skaliert werden, wenn der Index gelöscht oder der Zugriff auf den Schlüssel wiederhergestellt wird. Wenn Sie Schlüssel löschen oder drehen, wird der neueste Schlüssel für bis zu 60 Minuten zwischengespeichert.

• Wenn Sie CMK für Ihren Suchdienst benötigen, legen Sie eine Erzwingungsrichtlinie fest.

• CMK-Erzwingung mithilfe von Azure Policy und die CMK-Konfiguration auf Dienstebene (die sich noch in der Vorschau befindet) sind unabhängige Einstellungen. Sie können je nach Ihren Anforderungen entweder oder beides verwenden. Die CMK-Konfiguration auf Dienstebene wendet einen Standardschlüssel auf neue Objekte an, während Azure Policy Erzwingung sicherstellt, dass alle Objekte Ihren Verschlüsselungsanforderungen entsprechen. Wenn Sie eine CMK-Erzwingungsrichtlinie ohne einen Schlüssel auf Dienstebene aktivieren, müssen alle CMK-fähigen Objekte zum Erstellungszeitpunkt ihren eigenen Verschlüsselungsschlüssel angeben. Objekterstellungsanforderungen, die die CMK-Konfiguration weglassen, schlagen fehl.

CMK auf Dienstebene für neue Objekte standardmäßig aktivieren (Vorschau)

Ab der Version 2026-03-01-Preview können Sie einen vom Kunden verwalteten Schlüssel auf Dienstebene im Azure KI-Suche Dienst selbst konfigurieren. Mit diesem Feature können Sie den Schlüssel einmal konfigurieren und auf alle neu erstellten Objekte standardmäßig anwenden. Dieser Schutz schützt vertrauliche Daten in Ihrem Suchdienst mit einem von Ihnen gesteuerten Schlüssel, ohne dass Sie bei jeder Erstellung eines Objekts wichtige Informationen angeben müssen. In der API-Version 2026-05-01-preview der Datenebene und höher können Sie anhand der isServiceLevelKey Eigenschaft encryptionKey ermitteln, ob ein Objekt den Schlüssel auf Dienstebene erbt oder einen expliziten Schlüssel auf Objektebene verwendet.

Das Aktivieren von CMK auf Dienstebene bedeutet:

• Alle new Objekte, die auf Ihrem Azure KI-Suche-Dienst erstellt wurden, verwenden standardmäßig automatisch den vom Kunden verwalteten Dienstschlüssel, sodass Sie bei jedem Erstellen eines Objekts keine Expliziten Verschlüsselungsschlüsseldetails mehr angeben müssen.

• Dieses Feature ist optional, und Sie können CMK weiterhin pro Objekt konfigurieren. Sie können den Schlüssel auf Dienstebene auch für einzelne Objekte außer Kraft setzen und den Schlüssel auf Dienstebene unabhängig voneinander drehen, sodass Sie bei Bedarf unterschiedliche Schlüssel für unterschiedliche Objekte verwenden können.

Sie können diesen Standardschlüssel überschreiben, indem Sie einen neuen Schlüssel für das objekt angeben, das Sie erstellen. Der Schlüssel auf Objektebene, den Sie angeben, setzt den Standardschlüssel auf Dienstebene für dieses Objekt außer Kraft.

Wählen Sie zwischen CMK auf Dienstebene und Objektebene

Verwenden Sie CMK auf Dienstebene standardmäßig, um einen einzelnen Schlüssel für alle Objekte anzuwenden. Sie konfigurieren den Schlüssel einmal, und neue Objekte erben diesen Schutz automatisch.

Verwenden Sie CMK auf Objektebene für Workloads, die einen unabhängigen Schlüssellebenszyklus erfordern. Vorhandene CMK-Konfigurationen auf Objektebene funktionieren weiterhin ohne Änderungen. CMK auf Dienstebene vereinfacht die Schlüsselverwaltung, ersetzt jedoch keine CMK auf Objektebene.

Ein häufiges Unternehmensmuster besteht darin, für die meisten Objekte (Indizes, Indexer, Datenquellen, Skillsets, Vektorisierer und Synonymzuordnungen) einen Schlüssel auf Dienstebene zu konfigurieren. Workloads mit strengeren Complianceanforderungen können einen objektbezogenen Schlüssel konfigurieren, um Zugriff, Schlüsselrotation und Widerruf unabhängig zu verwalten.

Schritt 1: Erstellen eines Verschlüsselungsschlüssels

Verwenden Sie entweder Azure Key Vault oder Azure Key Vault verwaltetes HSM, um einen Schlüssel zu erstellen. Azure KI-Suche Verschlüsselung unterstützt RSA-Schlüssel der Größen 2048, 3072 und 4096. Weitere Informationen zu unterstützten Schlüsseltypen finden Sie unter "Informationen zu Schlüsseln".

Es wird empfohlen , diese Tipps zu überprüfen, bevor Sie beginnen.

Erforderliche Vorgänge sind "Wrap", " Unwrap", "Encrypt" und "Decrypt".

Schritt 2: Erstellen eines Sicherheitsprinzipals

Erstellen Sie einen Sicherheitsprinzipal, den Ihr Suchdienst für den Zugriff auf den Verschlüsselungsschlüssel verwendet. Sie können eine verwaltete Identität und Rollenzuweisung verwenden, oder Sie können eine Anwendung registrieren und der Suchdienst die Anwendungs-ID für Anforderungen bereitstellen lassen.

Verwenden Sie eine verwaltete Identität und Rollen. Sie können entweder eine vom System verwaltete Identität oder eine vom Benutzer verwaltete Identität verwenden. Mit einer verwalteten Identität kann sich Ihr Suchdienst über Microsoft Entra ID authentifizieren, ohne Anmeldeinformationen (ApplicationID oder ApplicationSecret) im Code zu speichern. Der Lebenszyklus dieser Art von verwalteter Identität ist an den Lebenszyklus Ihres Suchdiensts gebunden, der nur eine vom System zugewiesene verwaltete Identität aufweisen kann. Weitere Informationen zur Funktionsweise von verwalteten Identitäten finden Sie unter What are managed identities for Azure resources.

Schritt 3: Erteilen von Berechtigungen

Wenn Sie Ihren Suchdienst für die Verwendung einer verwalteten Identität konfiguriert haben, weisen Sie Rollen zu, die ihm Zugriff auf den Verschlüsselungsschlüssel gewähren.

Die rollenbasierte Zugriffssteuerung wird gegenüber dem Zugriffsrecht-Modell empfohlen. Für weitere Informationen oder Migrationsschritte beginnen Sie mit Azure rollenbasierten Zugriffssteuerung (Azure RBAC) und Zugriffsrichtlinien (Legacy).

1. Gehen Sie zu Ihrem Schlüsseltresor im Azure-Portal.

2. Wählen Sie Access Control (IAM) und dann "Rollenzuweisung hinzufügen" aus.

3. Wählen Sie eine Rolle aus:

   • Wählen Sie auf Azure Key Vault Key Vault Crypto Service Encryption User aus.
   • Auf dem verwalteten HSM wählen Sie Managed HSM Crypto Service Encryption User aus.

4. Wählen Sie verwaltete Identitäten aus, wählen Sie Mitglieder und dann die verwaltete Identität Ihres Suchdiensts aus. Wenn Sie lokal testen, sollten Sie sich diese Rolle ebenfalls zuweisen.

5. Wählen Sie "Überprüfen" und "Zuweisen" aus.

Warten Sie einige Minuten, bis die Rollenzuweisung betriebsbereit ist.

Key Vault Firewall- und virtueller Netzwerkzugriff für CMK

Azure KI-Suche muss auf Ihren Azure Key Vault zugreifen können, um auf den Verschlüsselungsschlüssel zuzugreifen.

Wenn Ihr Schlüsseltresor eine Firewall oder virtuelle Netzwerkeinschränkungen verwendet, konfigurieren Sie eine der folgenden Optionen:

• Zugriff von ausgewählten Netzwerken zulassen, die Ihren Suchdienst enthalten.
• Aktivieren Sie Erlauben der Umgehung dieser Firewall für vertrauenswürdige Microsoft-Dienste.

Wenn die Umgehung vertrauenswürdiger Dienste aktiviert ist, kann Azure KI-Suche mithilfe der verwalteten Identität auf den Schlüssel als vertrauenswürdiger Dienst zugreifen, auch wenn der Zugriff auf öffentliche Netzwerke eingeschränkt ist.

Wenn die Firewall den Zugriff blockiert und die Umgehung vertrauenswürdiger Dienste nicht aktiviert ist, können Azure KI-Suche den Schlüssel nicht abrufen, und CMK-abhängige Vorgänge schlagen fehl.

Schritt 4: Hinzufügen von Verschlüsselungsschlüsselinformationen zu Azure KI-Suche Objekten

Wenn Sie ein verschlüsseltes Objekt erstellen, geben Sie den Schlüsseltresor-URI, den Schlüsselnamen und die Schlüsselversion ein. Wenn Sie eine Microsoft Entra ID Anwendung für die Authentifizierung verwenden, geben Sie auch die Anwendungs-ID und den geheimen Schlüssel ein.

Um einem Suchobjekt einen vom Kunden verwalteten Schlüssel hinzuzufügen, kann es sich um einen Index, einen Indexer, eine Datenquelle, ein Skillset, einen Vektorizer oder eine Synonymzuordnung handeln, sie können den Schlüssel auf Dienstebene oder auf Objektebene konfigurieren.

Dienstebene: Durch das Einrichten eines vom Kunden verwalteten Schlüssels auf Dienstebene wird dieser Schlüssel standardmäßig auf alle neu erstellten Suchobjekte angewendet. Sie gilt nicht für bereits vorhandene Suchobjekte.

Objektebene: Sie können auch einen neuen, eindeutigen Schlüssel auf Objektebene definieren, wenn Sie ein neues Suchobjekt erstellen. Diese Schlüsseldefinition auf Objektebene setzt den Standardschlüssel auf Dienstebene außer Kraft.

Um CMK für ein Objekt zu konfigurieren, verwenden Sie das Azure Portal, Search Service REST-APIs oder einen Azure SDK.

Konfigurieren von CMK auf Dienstebene (Vorschau)

Um die CMK-Konfiguration auf Dienstebene zu aktivieren, verwenden Sie die Rest-API für die Suchverwaltung oder ein Azure SDK Paket, das aktualisiert wird, um die Search Management REST API Version 2026-03-01-preview oder höher zu unterstützen. Das Azure-Portal unterstützt dieses Feature noch nicht. Wenn Sie CMK auf Dienstebene aktivieren, fügen Sie vorhandenen Objekten keine Verschlüsselung hinzu, aber Sie wenden denselben Schlüssel standardmäßig auf alle neu erstellten Objekte im Dienst an, es sei denn, Sie geben einen anderen Schlüssel auf Objektebene an, um den Standardwert auf Dienstebene außer Kraft zu setzen.

PATCH https://management.azure.com/subscriptions/{{subscription-id}}/resourceGroups/{{resource-group}}/providers/Microsoft.Search/searchServices/{{search-service}}?api-version=2026-03-01-preview
Authorization: Bearer {{token}}
Content-Type: application/json

{
  "encryptionWithCmk": {
    "serviceLevelEncryptionKey": {
      "keyVaultUri": "<YOUR-KEY-VAULT-URI>",
      "keyVaultKeyName": "<YOUR-ENCRYPTION-KEY-NAME>",
      "keyVaultKeyVersion": "<YOUR-ENCRYPTION-KEY-VERSION>"
    }
  }
}

{
  "encryptionWithCmk": {
    "serviceLevelEncryptionKey": {
      "keyVaultUri": "<YOUR-KEY-VAULT-URI>",
      "keyVaultKeyName": "<YOUR-ENCRYPTION-KEY-NAME>",
      "keyVaultKeyVersion": "<YOUR-ENCRYPTION-KEY-VERSION>",
      "identity": {
        "@odata.type": "#Microsoft.Azure.Search.DataUserAssignedIdentity",
        "userAssignedIdentity": "/subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<your-managed-identity-name>"
      }
    }
  }
}

{
  "encryptionWithCmk": {
    "serviceLevelEncryptionKey": {
          "keyVaultUri": "<YOUR-KEY-VAULT-URI>",
          "keyVaultKeyName": "<YOUR-ENCRYPTION-KEY-NAME>",
          "keyVaultKeyVersion": "<YOUR-ENCRYPTION-KEY-VERSION>",
          "accessCredentials": {
                  "applicationId": "<YOUR-APPLICATION-ID>",
                  "applicationSecret": "<YOUR-APPLICATION-SECRET>"
      }       
    }
  }
}

Überprüfen, ob ein Suchobjekt CMK auf Dienstebene erbt

Um zu überprüfen, ob ein Suchobjekt einen vom Kunden verwalteten Schlüssel verwendet, der auf Dienstebene als Standard oder als eindeutiger vom Kunden verwalteter Schlüssel auf Objektebene konfiguriert ist, überprüfen Sie den geerbten Verschlüsselungsstatus mithilfe der isServiceLevelKey Eigenschaft.

GET https://{{search-service}}.search.windows.net/indexes/{{index-name}}?api-version=2026-08-01-preview
api-key: {{admin-api-key}}

{
  "name": "hotels-cmk",
  "fields": [
    {
      "name": "id",
      "type": "Edm.String",
      "key": true,
      "searchable": false,
      "retrievable": true
    }
  ],
  "encryptionKey": {
    "keyVaultUri": "<YOUR-KEY-VAULT-URI>",
    "keyVaultKeyName": "<YOUR-ENCRYPTION-KEY-NAME>",
    "keyVaultKeyVersion": "<YOUR-ENCRYPTION-KEY-VERSION>",
    "isServiceLevelKey": true
  }
}

PUT https://{{search-service}}.search.windows.net/indexes/{{index-name}}?api-version=2026-08-01-preview
api-key: {{admin-api-key}}
Content-Type: application/json

{
  "name": "regulated-index",
  "fields": [
    {
      "name": "id",
      "type": "Edm.String",
      "key": true,
      "searchable": false,
      "retrievable": true
    }
  ],
  "encryptionKey": {
    "keyVaultUri": "<YOUR-KEY-VAULT-URI>",
    "keyVaultKeyName": "<YOUR-ENCRYPTION-KEY-NAME>",
    "keyVaultKeyVersion": "<YOUR-ENCRYPTION-KEY-VERSION>",
    "isServiceLevelKey": false
  }
}

PUT https://{{search-service}}.search.windows.net/indexes/{{index-name}}?api-version=2026-08-01-preview
api-key: {{admin-api-key}}
Content-Type: application/json

{
  "name": "regulated-index",
  "fields": [
    {
      "name": "id",
      "type": "Edm.String",
      "key": true,
      "searchable": false,
      "retrievable": true
    }
  ],
  "encryptionKey": {
    "isServiceLevelKey": true,
    "keyVaultUri": "<SERVICE-LEVEL-KEY-VAULT-URI>",
    "keyVaultKeyName": "<SERVICE-LEVEL-KEY-NAME>",
    "keyVaultKeyVersion": "<SERVICE-LEVEL-KEY-VERSION>"
  }
}

Schritt 5: Testen der Verschlüsselung

Um zu überprüfen, ob die Verschlüsselung funktioniert, widerrufen Sie den Verschlüsselungsschlüssel, fragen Sie den Index ab (er sollte nicht verwendbar sein), und setzen Sie dann den Verschlüsselungsschlüssel wieder ein.

Verwenden Sie das Azure-Portal für diese Aufgabe. Stellen Sie sicher, dass Sie über eine Rollenzuweisung verfügen, die Lesezugriff auf den Schlüssel gewährt.

1. Wählen Sie auf der Seite Azure Key Vault Objects>Keys aus.

2. Wählen Sie den von Ihnen erstellten Schlüssel und dann "Löschen" aus.

3. Wählen Sie auf der Seite Azure KI-Suche Search management>Indexes aus.

4. Wählen Sie Ihren Index aus, und verwenden Sie den Such-Explorer, um eine Abfrage auszuführen. Sie sollten eine Fehlermeldung erhalten.

5. Kehren Sie zur Seite Azure Key Vault Objects>Keys zurück.

6. Wählen Sie "Gelöschte Schlüssel verwalten" aus.

7. Wählen Sie Ihren Schlüssel und dann " Wiederherstellen" aus.

8. Kehren Sie zum Index in Azure KI-Suche zurück, und führen Sie die Abfrage erneut aus. Suchergebnisse sollten angezeigt werden. Wenn keine sofortigen Ergebnisse angezeigt werden, warten Sie eine Minute, und versuchen Sie es erneut.

Einrichtung einer Richtlinie zur Durchsetzung der CMK-Compliance

Azure Richtlinien tragen dazu bei, organisatorische Standards zu erzwingen und die Compliance im großen Maßstab zu bewerten. Azure KI-Suche verfügt über zwei optionale integrierte Richtlinien im Zusammenhang mit CMK. Diese Richtlinien gelten für neue und vorhandene Suchdienste.

Zuweisen einer Richtlinie

1. Navigieren Sie im Azure-Portal zu einer integrierten Richtlinie, und wählen Sie dann Assign aus.

   • AuditIfExists

   • Verweigern

   Hier ist ein Beispiel für die richtlinie AuditIfExists im Azure-Portal:

   

2. Legen Sie den Richtlinienbereich fest, indem Sie die Abonnement- und Ressourcengruppe auswählen. Schließen Sie alle Suchdienste aus, für die die Richtlinie nicht gelten soll.

3. Übernehmen oder ändern Sie die Standardwerte. Wählen Sie "Überprüfen" und "Erstellen" und dann " Erstellen" aus.

Aktivierung der Durchsetzung von CMK-Richtlinien

Wenn Sie einer Ressourcengruppe in Ihrem Abonnement eine Richtlinie zuweisen, wird sie sofort wirksam. Prüfungsrichtlinien markieren nicht konforme Ressourcen, aber Verweigerungsrichtlinien verhindern die Erstellung und Aktualisierung nicht konformer Suchdienste. In diesem Abschnitt wird erläutert, wie Sie einen kompatiblen Suchdienst erstellen oder einen Dienst aktualisieren, um ihn kompatibel zu machen. Um Objekte in die Compliance zu bringen, beginnen Sie in Schritt 1 dieses Artikels.

Erstellen eines kompatiblen Suchdiensts

Erstellen Sie sie für neue Suchdienste mit SearchEncryptionWithCmk festgelegt auf Enabled.

Weder das Azure Portal noch die Befehlszeilentools (die Azure CLI und Azure PowerShell) stellen diese Eigenschaft nativ bereit. Sie können jedoch Management REST API verwenden, um einen Suchdienst mit einer CMK-Richtliniendefinition bereitzustellen.

### Create a search service (provide an existing resource group)
@resource-group = my-rg
@search-service-name = my-search
PUT https://management.azure.com/subscriptions/{{subscriptionId}}/resourceGroups/{{resource-group}}/providers/Microsoft.Search/searchServices/{{search-service-name}}?api-version=2025-05-01 HTTP/1.1
     Content-type: application/json
     Authorization: Bearer {{token}}

    {
        "location": "North Central US",
        "sku": {
            "name": "basic"
        },
        "properties": {
            "replicaCount": 1,
            "partitionCount": 1,
            "hostingMode": "default",
            "encryptionWithCmk": {
                "enforcement": "Enabled"
        }
      }
    }

Aktualisieren eines vorhandenen Suchdiensts

Für vorhandene Suchdienste, die jetzt nicht kompatibel sind, patchen Sie sie mit Services – Update-API oder dem Befehl Azure CLI az-Ressourcenupdate. Durch das Patchen der Dienste wird die Möglichkeit zum Aktualisieren von Suchdiensteigenschaften wiederhergestellt.

PATCH https://management.azure.com/subscriptions/<your-subscription-Id>/resourceGroups/<your-resource-group-name>/providers/Microsoft.Search/searchServices/<your-search-service-name>?api-version=2025-05-01

{
  "properties": {
      "encryptionWithCmk": {
          "enforcement": "Enabled"
      }
  }
}

az resource update --name SEARCH-SERVICE-PLACEHOLDER --resource-group RESOURCE-GROUP-PLACEHOLDER --resource-type searchServices --namespace Microsoft.Search --set properties.encryptionWithCmk.enforcement=Enabled

"encryptionWithCmk": {
      "encryptionComplianceStatus": "NonCompliant",
      "enforcement": "Enabled"
    }
...

Drehen oder Aktualisieren von Verschlüsselungsschlüsseln

Verwenden Sie die folgenden Anweisungen, um Schlüssel zu drehen oder von Azure Key Vault zum Hardware Security Module (HSM) zu migrieren.

Verwenden Sie die Autorotationsfunktionen von Azure Key Vault für die Schlüsseldrehung. Wenn Sie autorotation verwenden, lassen Sie die Schlüsselversion in Objektdefinitionen aus. Der neueste Schlüssel wird anstelle einer bestimmten Version verwendet.

Wenn Sie einen Schlüssel oder dessen Version ändern, aktualisieren Sie jedes Objekt, das den Schlüssel verwendet, um die neuen Werte zu verwenden, bevor Sie die alten Werte löschen. Andernfalls kann das Objekt nicht mehr verwendet werden, da es nicht entschlüsselt werden kann.

Wenn Sie CMK auf Dienstebene konfiguriert haben, gilt die Rotation des Schlüssels auf Dienstebene für neu erstellte Objekte. Objekte, die bereits den vorherigen Schlüssel auf Dienstebene geerbt haben, übernehmen automatisch den neuen Schlüssel, sodass Sie sie nicht aktualisieren müssen. Wenn Sie jedoch Objekte hatten, die mit einem Schlüssel auf Objektebene konfiguriert wurden, den Sie auch drehen möchten, müssen Sie diese Objekte aktualisieren, um den neuen Schlüssel zu verwenden.

Schlüssel werden 60 Minuten zwischengespeichert. Denken Sie daran, wenn Sie Tasten testen und drehen.

1. Bestimmen Sie den Schlüssel, der von einer Index- oder Synonymzuordnung verwendet wird.

2. Erstellen Sie einen neuen Schlüssel im Schlüsseltresor, lassen Sie jedoch den ursprünglichen Schlüssel verfügbar. In diesem Schritt können Sie von Key Vault zu HSM wechseln.

3. Aktualisieren Sie die Eigenschaften des Verschlüsselungsschlüssels für einen Index oder eine Synonymzuordnung, um die neuen Werte anzuwenden. Nur Objekte, die ursprünglich mit dieser Eigenschaft erstellt wurden, können aktualisiert werden, um einen anderen Wert zu verwenden.

4. Deaktivieren oder löschen Sie den vorherigen Schlüssel im Schlüsseltresor. Überwachen Sie den Schlüsselzugriff, um zu überprüfen, ob der neue Schlüssel verwendet wird.

Aus Leistungsgründen speichert der Suchdienst den Schlüssel für bis zu mehrere Stunden zwischen. Wenn Sie den Schlüssel deaktivieren oder löschen, ohne einen neuen Schlüssel bereitzustellen, funktionieren Abfragen auf temporärer Basis, bis der Cache abläuft. Sobald der Suchdienst inhalte jedoch nicht mehr entschlüsseln kann, erhalten Sie diese Meldung: "Access forbidden. The query key used might have been revoked - please retry."

Tipps für Key Vault

• Wenn Sie noch nicht mit Azure Key Vault arbeiten, lesen Sie diese Schnellstartanleitung, um grundlegende Aufgaben zu erfahren: Set und Abrufen eines geheimen Schlüssels aus Azure Key Vault mithilfe von PowerShell.

• Verwenden Sie so viele Schlüsseltresore, wie Sie benötigen. Verwaltete Schlüssel können sich in verschiedenen Schlüsseltresoren befinden. Ein Suchdienst kann über mehrere verschlüsselte Objekte verfügen, die jeweils mit einem anderen vom Kunden verwalteten Verschlüsselungsschlüssel verschlüsselt sind, der in verschiedenen Schlüsseltresorn gespeichert ist.

• Verwenden Sie denselben Azure Mandant, damit Sie Ihren verwalteten Schlüssel über Rollenzuweisungen abrufen und eine Verbindung über ein System oder eine vom Benutzer verwaltete Identität herstellen können. Weitere Informationen zum Erstellen eines Mandanten finden Sie unter Einrichten eines neuen Mandanten.

• Wenn Ihre Azure Key Vault mit einer Firewall gesichert ist, müssen Sie Allow trusted Microsoft-Dienste aktivieren, um diese Firewall zu umgehen damit Azure KI-Suche auf den Schlüssel zugreifen kann.

• Aktivieren Sie den Löschschutz und das vorläufige Löschen für einen Schlüsseltresor. Aufgrund der Art der Verschlüsselung mit vom Kunden verwalteten Schlüsseln kann niemand Ihre Daten abrufen, wenn Ihr Azure Key Vault Schlüssel gelöscht wird. Um Datenverluste zu verhindern, die durch versehentliche Löschungen von Schlüsseln im Key Vault verursacht werden, muss der Soft-Delete- und Löschschutz im Key Vault aktiviert sein. Das vorläufige Löschen ist standardmäßig aktiviert, sodass Sie nur dann Probleme haben, wenn Sie es absichtlich deaktivieren. Der Löschschutz ist standardmäßig nicht aktiviert, ist jedoch für die Verschlüsselung mit einem CMK in Azure KI-Suche erforderlich.

• Aktivieren Sie die Protokollierung im Schlüsseltresor, damit Sie die Schlüsselverwendung überwachen können.

• Aktivieren Sie die automatische Rotation von Schlüsseln oder befolgen Sie strenge Verfahren während der Routinerotation von Schlüsseltresorschlüsseln, Anwendungsgeheimnissen und Registrierungen. Aktualisieren Sie immer alle verschlüsselten Inhalte , um neue Geheimschlüssel und Schlüssel zu verwenden, bevor Sie die alten löschen. Wenn Sie diesen Schritt verpassen, können Ihre Inhalte nicht entschlüsselt werden.

Arbeiten mit verschlüsselten Inhalten

Bei Verwendung von CMK können Sie aufgrund der zusätzlichen Verschlüsselungs-/Entschlüsselungsarbeit Latenz für Indizierung und Abfragen feststellen. Azure KI-Suche protokolliert keine Verschlüsselungsaktivität, Aber Sie können den Schlüsselzugriff über die Schlüsseltresorprotokollierung überwachen.

Es wird empfohlen, die Protokollierung als Teil der Key Vault-Konfiguration zu aktivieren .

1. Erstellen Sie einen Log Analytics-Arbeitsbereich.

2. Fügen Sie eine Diagnoseeinstellung im Schlüsseltresor hinzu, die den Arbeitsbereich für die Datenaufbewahrung verwendet.

3. Wählen Sie "Audit " oder "allLogs" für die Kategorie aus, geben Sie der Diagnoseeinstellung einen Namen, und speichern Sie sie.

FAQs

Kann ich ein Suchobjekt zwischen einem vom Kunden verwalteten Schlüssel ändern, der auf Dienstebene definiert ist, und einem vom Kunden verwalteten Schlüssel, der auf Objektebene definiert ist?

• Yes. Wenn Sie den CMK auf Dienstebene konfigurieren, verwendet jedes neue Suchobjekt diesen Schlüssel standardmäßig. Wenn Sie einen anderen Schlüssel in der Definition auf Objektebene konfigurieren, hat der Schlüssel auf Objektebene Vorrang vor dem Schlüssel auf Dienstebene. Wenn Sie die Schlüsseldefinition auf Objektebene entfernen, wird das Suchobjekt standardmäßig wieder auf den vom Kunden verwalteten Schlüssel zurückgeführt, der auf Dienstebene definiert ist.

Nächste Schritte

Wenn Sie mit Azure Sicherheitsarchitektur nicht vertraut sind, lesen Sie die Azure Sicherheitsdokumentation und insbesondere diesen Artikel: