Konfigurieren von kundenseitig verwalteten Schlüsseln über verschiedene Mandanten hinweg

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

Funktionen, Möglichkeiten oder Eigenschaften, die als „Vorschau“ gekennzeichnet sind, werden nicht durch ein Service Level Agreement (SLA) abgedeckt, nicht für Produktionsworkloads empfohlen und können geändert oder eingeschränkt werden, bevor sie allgemein verfügbar sind. Die Azure KI-Suche Vorschaubedingungen gelten für alle Vorschaufunktionen, unabhängig davon, ob sie eigenständig oder Teil eines allgemein verfügbaren Features ist.

In diesem Artikel wird ein mandantenübergreifendes Szenario beschrieben, in dem ein Dienstanbieter Azure KI-Suche im eigenen Mandanten hostet und die Verschlüsselung mit kundenseitig verwaltetem Schlüssel (CMK) mithilfe einer mandantenfähigen Microsoft Entra-Anwendung aktiviert.

In dieser Konfiguration verwendet der Kunde Azure Key Vault in einem eigenen Mandanten, um seinen Verschlüsselungsschlüssel zu verwalten. Der Dienstanbieter hat keinen Zugriff auf diesen Schlüssel.

Voraussetzungen

  • Tenant A: Ein Mandant und die erforderlichen Berechtigungen zum Erstellen des Azure KI-Suche Diensts und zugeordneter Objekte (Indizes, Synonymlisten, Indexer, Datenquellen, Vectorizer, Skillsets). Die Unterstützung kundenseitig verwalteter Schlüssel (CMK) erfordert die Basic-Preisstufe oder höher.

  • Konfigurieren Sie den Suchdienst für rollenbasierten Zugriff(empfohlen für erweiterte Sicherheit, nicht erforderlich).

  • Tenant B: Ein separater Kundenmandant mit einem Azure Key Vault und den erforderlichen Berechtigungen für diesen Mandanten:

    • Key Vault Mitwirkender: Diese Rolle ist erforderlich, wenn Sie eine neue key vault erstellen müssen.
    • Permission zum Registrieren von Anwendungen in Microsoft Entra ID: Um die vom Dienstanbieter für mandantenübergreifende CMK konfigurierte Multitenant-App zu installieren, müssen Sie über die Berechtigung zum Erstellen von App-Registrierungen in Microsoft Entra ID verfügen. Dies erfordert in der Regel die Rolle "Anwendungsentwickler " oder eine höhere administrative Rolle, z. B. "Anwendungsadministrator" oder "Globaler Administrator".
    • Key Vault Crypto Officer: Diese Rolle ist erforderlich, um dem key vault einen neuen Schlüssel hinzuzufügen.
    • Kryptografiedienstverschlüsselung für Schlüsseltresore: Diese Rolle muss dem Dienstprinzipal zugewiesen werden, der für die installierte mehrinstanzenfähige Anwendung erstellt wurde, um dem Dienstprinzipal Zugriff auf den kundenseitig verwalteten Schlüssel im Schlüsseltresor zu gewähren. Sie müssen über die Berechtigung "Benutzerzugriffsadministrator " verfügen, um dies zu tun. Hier können Sie die Dienstprinzipal-GUID (auch als Objekt-ID bezeichnet) anzeigen: Enterprise applications\<installed multitenant application>\Manage\Properties\Object ID.
  • Die Azure Key Vault muss auch für rollenbasierten Zugriff konfiguriert sein.

  • Azure CLI zum Senden von Anforderungen.

Auswählen eines Authentifizierungsansatzes

Sie können eine mehrinstanzenfähige Microsoft Entra Anwendung so konfigurieren, dass kundenverwaltete Schlüssel in einem mandantenübergreifenden Szenario verwendet werden, indem Sie einen der folgenden Ansätze verwenden:

  1. Unterstützung von Verbundidentitäten (Vorschauversion, empfohlen): Konfigurieren Sie Microsoft Entra-Verbundanmeldeinformationen für Identitäten (FIC) mit einer benutzerseitig zugewiesenen verwalteten Identität (UAMI). Dieser Ansatz verwendet Tokens für verwaltete Identitäten und tauscht sie gegen Zugriffstoken aus, wodurch langlebige Geheimnisse überflüssig werden und er im Einklang mit den Prinzipien der Workload Identity Federation steht. Für diesen Ansatz ist die Vorschaueigenschaft federatedIdentityClientId erforderlich, die in der API-Version 2026-05-01-previeweingeführt wurde.

  2. Geheime Clientschlüssel: Konfigurieren eines geheimen Clientschlüssels mithilfe der accessCredentials Eigenschaft. Dieser Ansatz ist weniger sicher und erfordert zusätzlichen Verwaltungsaufwand, um das Geheimnis zu rotieren und zu schützen.

Note

Azure Key Vault und Azure Key Vault Managed HSM verwenden dieselben APIs und Verwaltungsschnittstellen für vom Kunden verwaltete Schlüssel. Alle unterstützten Vorgänge in Azure Key Vault werden auch in Azure Key Vault verwalteten HSM unterstützt.

Erstellen einer mehrinstanzenfähigen Microsoft Entra-Anwendung in Mandant A

Verwenden Sie die Azure CLI, um Anforderungen zu senden. Der Mandant des Dienstanbieters, der Azure KI-Suche enthält, wird als Mandant A bezeichnet.

  1. Abrufen der Mandanten-ID: az account show --query tenantId --output tsv

  2. Stellen Sie sicher, dass Sie bei Mandant A angemeldet sind: az login --tenant \<tenant-A-id\>

  3. Erstellen Sie die Anwendungsregistrierung: az ad app create --display-name cross-tenant-auth --sign-in-audience AzureADMultipleOrgs

  4. Speichern Sie die App-ID-Ausgabe aus diesem Schritt.

Verwenden der Verbundidentitätsunterstützung (Vorschau)

So verwenden Sie eine Verbundidentität zur Unterstützung eines mandantenübergreifenden CMK-Szenarios:

  1. Der Dienstanbieter konfiguriert den KI-Suchdienst in ihrem Mandanten (Mandant A). Anleitungen hierzu finden Sie unter Create a Search Service (im Azure Portal) or use the az search service create command in Azure CLI.

  2. Der Dienstanbieter erstellt eine Microsoft Entra-App-Registrierung für mehrere Mandanten. Anleitungen dazu finden Sie unter Wie Sie eine App in Microsoft Entra ID oder verwenden Sie den Befehl Azure CLI: az ad app create. Notieren Sie die Anwendungs-ID (Client-ID), sobald Sie die App-Registrierung abgeschlossen haben.

  3. Der Dienstanbieter richtet eine vom Benutzer zugewiesene verwaltete Identität ein. Anleitungen dazu finden Sie unter Manage von vom Benutzer zugewiesenen verwalteten Identitäten mithilfe von Azure Portal oder Manage von vom Benutzer zugewiesenen verwalteten Identitäten mithilfe des Azure CLI.

  4. Der Dienstanbieter konfiguriert die vom Benutzer zugewiesenen verwalteten Identitäten als Verbundidentitätsanmeldeinformationen in der App. Anleitungen dazu finden Sie unter Konfigurieren einer App, um einem externen Identitätsanbieter zu vertrauen.

  5. Sobald der Dienstanbieter die App-ID für mehrere Mandanten mitteilt, gewährt der Kunde der App des Dienstanbieters Zugriff auf den Schlüsseltresor in seinem Mandanten (Mandant B). Um die App für Mandant B zu installieren, muss ein Dienstprinzipal mit der mehrinstanzenfähigen App-ID erstellt werden. Um den Dienstprinzipal zu erstellen, erstellen Sie eine URL für die Administratoreinwilligung und erteilen Sie die mandantenweite Administratoreinwilligung, oder verwenden Sie den Befehl az ad sp in der Azure CLI.

  6. Wenn der Kunde noch nicht über einen Schlüsseltresor verfügt, lesen Sie Schnellstart: Erstellen eines Azure-Schlüsseltresors mit dem Azure-Portal oder Schnellstart: Erstellen eines Azure-Schlüsseltresors mit der Azure CLI. Für den Key Vault muss das Berechtigungsmodell auf „rollenbasierte Zugriffssteuerung in Azure (RBAC)“ festgelegt werden, wobei der mandantenfähigen Anwendung des Dienstanbieters durch Zuweisung der Rolle „Key Vault Crypto Service Encryption User“ die erforderliche Berechtigung erteilt wird. Der Kunde kann dann einen Verschlüsselungsschlüssel erstellen. Anleitungen hierzu finden Sie unter Erteilen von Berechtigungen für Anwendungen für den Zugriff auf einen Azure Key Vault mithilfe von Azure RBAC.

Sobald diese Schritte abgeschlossen sind, hat der Dienstanbieter jetzt Folgendes:

  • Eine Anwendungs-ID für eine mehrmandantenfähige Anwendung, die im Mandanten von Kund*innen installiert ist und der Zugriff auf den vom Kunden verwalteten Schlüssel gewährt wurde.

  • Eine verwaltete Identität, die als Verbundanmeldeinformation für die mehrinstanzenfähige Anwendung konfiguriert ist.

  • Den Speicherort des Schlüssels im Schlüsseltresor des Kunden.

Mit diesen drei Parametern kann der Dienstanbieter jetzt Azure KI-Suche Objekte in Tenant A erstellen, die mit dem vom Kunden verwalteten Schlüssel verschlüsselt werden können, der in Tenant B gespeichert ist. Anleitungen zum Konfigurieren von vom Kunden verwalteten Schlüsseln für neue Suchobjekte finden Sie unter Configure vom Kunden verwaltete Schlüssel für Azure KI-Suche verschlüsselten Daten.

Überprüfen der mandantenübergreifenden CMK-Konfiguration für die Verbundidentität

Nachdem Sie die mehrinstanzenfähige Microsoft Entra Anwendung konfiguriert und mit der Key Vault des Kunden verbunden haben, überprüfen Sie das Setup, indem Sie ein Testobjekt in Ihrem Suchdienst (Mandant A) erstellen. In diesem Beispiel wird ein Index erstellt, der bestätigt, dass der Suchdienst mithilfe der Verbundidentitätsauthentifizierung auf den vom Kunden verwalteten Schlüssel zugreifen kann.

  1. Weitere Informationen dazu, wie Sie einen Suchdienst und ein neues Indexobjekt mit einem kundenseitig verwalteten Schlüssel erstellen, finden Sie unter Konfigurieren von kundenseitig verwalteten Schlüsseln für verschlüsselte Daten in Azure KI-Suche.

  2. Nachdem das Indexobjekt erstellt wurde, müssen Sie Folgendes ausfüllen:

    • keyVaultUri: Die URI-Adresse des Kunden.
    • keyVaultKeyName: Der Schlüsselname des Kunden.
    • keyVaultKeyVersion: Die Schlüsselversion des Kunden.
    • userAssignedIdentity: <subscription-id> und <resource-group> aus Ihrem Mandanten und <identity-name> ist der Name der benutzerseitig zugewiesenen verwalteten Identität.
    • federatedIdentityClientId: Dieser Eigenschaftswert, <application-client-id>, ist die ID der mehrinstanzenfähigen Anwendung (Client).
    {
      "name": "cross-tenant-cmk-test",
      "fields": [
        {
          "name": "id",
          "type": "Edm.String",
          "key": true
        }
      ],
      "encryptionKey": {
        "keyVaultUri": "https://<key-vault-name>.vault.azure.net/",
        "keyVaultKeyName": "<key-name>",
        "keyVaultKeyVersion": "<key-version>",
        "identity": {
          "@odata.type": "#Microsoft.Azure.Search.DataUserAssignedIdentity",
          "userAssignedIdentity": "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name>",
          "federatedIdentityClientId": "<application-client-id>"
        }
      }
    }
    
  3. Überprüfen Sie den Index, indem Sie eine GET Anforderung senden: GET https://<search-service>.search.windows.net/indexes/cross-tenant-cmk-test?api-version=2026-08-01-preview

Wenn die Anforderung erfolgreich ist, funktioniert die mandantenübergreifende CMK-Konfiguration ordnungsgemäß.

Wenn die Indexerstellung mit einem Schlüsselzugriffsfehler fehlschlägt, überprüfen Sie Folgendes:

  • Die vom Benutzer zugewiesene verwaltete Identität ist ordnungsgemäß konfiguriert.
  • Der Verbundidentitätsnachweis ist für die App festgelegt.
  • Die Key Vault Zugriffsrichtlinie oder RBAC-Rollenzuweisungen sind korrekt.

Verwenden eines geheimen Clientschlüssels (wenn die Verbundidentität keine Option ist)

Wenn die Verbundidentität keine Option ist, können Sie der Mehrinstanzenanwendung einen geheimen Clientschlüssel hinzufügen, um ein mandantenübergreifendes CMK-Szenario zu unterstützen:

  1. Führen Sie den folgenden Befehl aus, um den geheimen Clientschlüssel zur mehrinstanzenfähigen Anwendung in Mandant A hinzuzufügen:

    az ad app credential reset --id <multitenant-app-id>

  2. Speichern Sie die Kennwortausgabe aus diesem Schritt. Die Kennwortausgabe ist eine erforderliche Eingabe zum Einrichten von CMK in Azure KI-Suche.

  3. Um anzugeben, wann der geheime Clientschlüssel abläuft, können Sie einen Enddatumsparameter für diesen Befehl angeben.

    az ad app credential reset --id <multitenant-app-id> --end-date <end-date>

    Der Enddatumsparameter akzeptiert ein Datum im ISO 8601-Format. Beispiel: az ad app credential reset --id <multitenant-app-id> --end-date 2026-12-31.

Erstellen eines Dienstprinzipals in Mandant B für die mehrinstanzenfähige Anwendung

Wir verweisen auf den Mandanten, der Azure Key Vault enthält, als Mandant B. Erstellen Sie in Mandanten B einen Dienstprinzipal für die mehrinstanzenfähige Anwendung in Mandanten A.

  1. Melden Sie sich bei Mandant B an:

    az login --tenant <tenant-B-id>

  2. Erstellen Sie den Dienstprinzipal mithilfe der Ausgabe der Mehrinstanzen-App-ID aus dem ersten Schritt:

    az ad sp create --id <multitenant-app-id>

    Dieser Dienstprinzipal ist eine Instanz der mehrinstanzenfähigen Anwendung in Mandant A. Rollen, die diesem Dienstprinzipal im Mandanten B zugewiesen sind, werden auch der Mehrinstanzenanwendung in Mandant A zugewiesen.

  3. Überprüfen Sie die Verknüpfung zwischen Mandant A und B, indem Sie die "appOwnerOrganizationId" im folgenden Befehl überprüfen:

    az ad sp show --id <multitenant-app-id>

    Mit diesem Befehl werden die Dienstprinzipaldetails in JSON angezeigt. Suchen Sie in der Ausgabe nach dem Feld "appOwnerOrganizationId", um zu bestätigen, dass es mit der ID des Mandanten A übereinstimmt.

  4. Speichern Sie die Objekt-ID des Dienstprinzipals (aus dem "id" Feld) aus diesem Schritt. Die Objekt-ID ist eine erforderliche Eingabe zum Einrichten von CMK in Azure KI-Suche.

  5. Abrufen der Ressourcen-ID für Azure Key Vault:

    az keyvault show --name <key-vault-name> --query id --output tsv

  6. Weisen Sie dem neuen Dienstprinzipal die Rolle Key Vault Crypto Service Encryption User im Schlüsseltresor im Mandanten B zu.

    az role assignment create --assignee <service-principal-object-id> --role "Key Vault Crypto Service Encryption User" --scope <key-vault-resource-id>

    Ein Beispiel für diese Aufgabe könnte wie folgt aussehen:

    az role assignment create --assignee 00001111-aaaa-2222-bbbb-3333cccc4444 --role "Key Vault Crypto Service Encryption User" --scope /subscriptions/87654321-4321-4321-4321-210987654321/resourceGroups/myKeyVaultRG/providers/Microsoft.KeyVault/vaults/myCompanyKeyVault

Überprüfen der mandantenübergreifenden CMK-Konfiguration des Clientgeheimnisses

Nachdem Sie die mehrinstanzenfähige Microsoft Entra Anwendung konfiguriert und mit der Key Vault des Kunden verbunden haben, überprüfen Sie das Setup, indem Sie ein Testobjekt in Ihrem Suchdienst (Mandant A) erstellen. In diesem Beispiel wird ein Index erstellt, um zu bestätigen, dass der Suchdienst mithilfe des geheimen Clientschlüssels auf den vom Kunden verwalteten Schlüssel zugreifen kann.

  1. Weitere Informationen dazu, wie Sie einen Suchdienst und ein neues Indexobjekt mit einem kundenseitig verwalteten Schlüssel erstellen, finden Sie unter Konfigurieren von kundenseitig verwalteten Schlüsseln für verschlüsselte Daten in Azure KI-Suche.

  2. Sie können das Azure Portal verwenden, um einen Index hinzuzufügen und diesen JSON bereitzustellen, oder einen REST-Client verwenden, um eine Create IndexAnforderung zu senden. Nachdem das Indexobjekt erstellt wurde, müssen Sie Folgendes ausfüllen:

    • keyVaultUri: Die URI-Adresse des Kunden.
    • keyVaultKeyName: Der Schlüsselname des Kunden.
    • keyVaultKeyVersion: Die Schlüsselversion des Kunden.
    • accessCredentials: Das applicationId ist etwas wie 00001111-aaaa-2222-bbbb-3333cccc4444, und das applicationSecret ist der Wert, den Sie gerade erstellt haben.
{
  "name": "cross-tenant-cmk-test",
  "fields": [
        {
            "name": "id",
            "type": "Edm.String",
            "key": true
        }
      ],
 "encryptionKey": {
        "keyVaultUri": "https://<key-vault-name>.vault.azure.net/",
        "keyVaultKeyName": "<key-name>",
        "keyVaultKeyVersion": "<key-version>",
    "accessCredentials": {
      "applicationId": "<application-client-id>",
      "applicationSecret": "<application-client-secret>"
    }
  }
}

Überprüfen Sie, ob der Index erfolgreich erstellt wurde:

GET https://<search-service>.search.windows.net/indexes/cross-tenant-cmk-test?api-version=2026-04-01

Weitere Informationen zum Drehen oder Verwalten von Schlüsseln finden Sie unter Konfigurieren von vom Kunden verwalteten Schlüsseln für die Datenverschlüsselung.