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.
Sie können Microsoft Entra ID-Sicherheitsprinzipale und Rollenzuweisungen für ausgehende Verbindungen von Azure KI-Suche mit anderen Azure-Ressourcen verwenden, die Daten, angewendete KI oder Vektorisierung während der Indizierung oder für Abfragen bereitstellen.
Um Rollen für eine ausgehende Verbindung zu verwenden, konfigurieren Sie zuerst Ihren Suchdienst so, dass eine systemseitig zugewiesene oder benutzerseitig zugewiesene verwaltete Identität als Sicherheitsprinzipal für Ihren Suchdienst in einem Microsoft Entra-Mandanten verwendet wird. Sobald Sie über eine verwaltete Identität verfügen, können Sie Rollen für autorisierten Zugriff zuweisen. Verwaltete Identitäten und Rollenzuweisungen machen die Übergabe von Geheimnissen und Anmeldeinformationen in einer Verbindungszeichenfolge oder Code überflüssig.
Voraussetzungen
Ein Suchdienst auf der Basic-Dienstebene oder höher in einer beliebigen Region.
Eine Azure-Ressource, die eingehende Anforderungen von einem Microsoft Entra-Sicherheitsprinzipal mit einer gültigen Rollenzuweisung akzeptiert.
Um eine verwaltete Identität zu erstellen, müssen Sie die Rolle „Besitzer“ oder „Benutzerzugriffsadmin“ haben. Zum Zuweisen von Rollen müssen Sie Besitzer, Benutzerzugriffsadmin, Admin für rollenbasierte Zugriffssteuerung oder ein Mitglied einer benutzerdefinierten Rolle mit Berechtigungen vom Typ „Microsoft.Authorization/roleAssignments/write“ sein.
Unterstützte Szenarien
Sie können verwaltete Identitäten für diese Szenarien verwenden.
| Szenario | System | Benutzerseitig zugewiesen |
|---|---|---|
| Herstellen einer Verbindung mit Indexerdatenquellen1 | Ja | Ja 2 |
| Herstellen einer Verbindung mit Einbettungs- und Chatvervollständigungsmodellen in Azure OpenAI, Azure AI Foundry und Azure Functions über Skills/Vektorisierer 3 | Ja | Ja |
| Herstellen einer Verbindung mit Azure Key Vault für kundenseitig verwaltete Schlüssel | Ja | Ja |
| Herstellen einer Verbindung mit Debugsitzungen (in Azure Storage gehostet)1 | Ja | Nein |
| Herstellen einer Verbindung mit einem Anreicherungscache (in Azure Storage gehostet)1,4 | Ja | Ja 2 |
| Herstellen einer Verbindung mit einem Wissensspeicher (in Azure Storage gehostet)1 | Ja | Ja 2 |
1 Für die Konnektivität zwischen Suche und Speicher legt die Netzwerksicherheit Einschränkungen fest, welche Art von verwalteter Identität Sie verwenden können. Nur eine systemseitig verwaltete Identität kann für eine Verbindung mit Azure Storage in derselben Region verwendet werden, und diese Verbindung muss über die Ausnahme für vertrauenswürdige Dienste oder die Ressourceninstanzregel hergestellt werden. Ausführliche Informationen finden Sie unter Zugriff auf ein netzwerkgeschütztes Speicherkonto.
2 Benutzerseitig zugewiesene verwaltete Identitäten können in Datenquellenverbindungszeichenfolgen verwendet werden. Allerdings unterstützen nur die neueren Vorschau-REST-APIs und Vorschaupakete eine benutzerseitig zugewiesene verwaltete Identität in einer Verbindungszeichenfolge. Stellen Sie sicher, dass Sie zu einer Vorschau-API wechseln, wenn Sie SearchIndexerDataUserAssignedIdentity als identity in einer Datenquellenverbindung festlegen.
3 Verbindungen mit Azure OpenAI, Azure KI Foundry und Azure Functions über Skills/Vektorisierer umfassen Folgendes: Benutzerdefinierte Skills, Benutzerdefinierte Vektorisierer, Azure OpenAI-Einbettungsskills, Azure OpenAI-Vektorisierer, AML-Skill und Azure KI Foundry-Modellkatalogvektorisierer.
4 Der Dienst für KI-Suche kann derzeit keine Verbindung mit Tabellen in einem Speicherkonto herstellen, für das der Zugriff per gemeinsam verwendetem Schlüssel deaktiviert ist.
Erstellen einer vom System verwalteten Identität
Eine systemseitig zugewiesene verwaltete Identität ist ein Microsoft Entra ID-Sicherheitsprinzipal, der automatisch erstellt und mit einer Azure-Ressource verknüpft wird, z. B. einem Dienst für Azure KI-Suche.
Sie können für jeden Suchdienst nur eine systemseitig zugewiesene verwaltete Identität verwenden. Sie ist eindeutig für Ihren Suchdienst und für seine Lebensdauer an den Dienst gebunden.
Wenn Sie eine systemseitig zugewiesene verwaltete Identität aktivieren, wird in Microsoft Entra ID ein Sicherheitsprinzipal für den Suchdienst erstellt, der für die Authentifizierung bei anderen Azure-Ressourcen verwendet wird. Sie können diese Identität dann in Rollenzuweisungen für autorisierten Zugriff auf Daten und Vorgänge verwenden.
Melden Sie sich beim Azure-Portal an, und finden Sie Ihren Suchdienst.
Wählen Sie im linken Bereich Einstellungen>Identität aus.
Wählen Sie auf der Registerkarte Systemseitig zugewiesen unter Status die Option Ein aus.
Wählen Sie Speichern aus.
Nachdem Sie die Einstellungen gespeichert haben, wird die Seite aktualisiert und zeigt einen Objektbezeichner an, der Ihrem Suchdienst zugewiesen ist.
Erstellen einer benutzerseitig zugewiesenen verwalteten Identität
Eine vom Benutzer zugewiesene verwaltete Identität ist eine Azure-Ressource, die auf Abonnements, Ressourcengruppen oder Ressourcentypen ausgerichtet werden kann.
Sie können mehrere vom Benutzer zugewiesene verwaltete Identitäten erstellen, für mehr Granularität bei der Zuweisung von Rollen. Sie könnten beispielsweise separate Identitäten für verschiedene Anwendungen und Szenarien verwenden. Als unabhängig erstellte und verwaltete Ressource ist sie nicht an den Dienst selbst gebunden.
Die Schritte zum Einrichten einer benutzerseitig zugewiesenen verwalteten Identität sind wie folgt:
Erstellen Sie in Ihrem Azure-Abonnement eine benutzerseitig zugewiesene verwaltete Identität.
Ordnen Sie in Ihrem Suchdienst die benutzerseitig zugewiesene verwaltete Identität Ihrem Suchdienst zu.
Erstellen Sie in anderen Azure-Diensten, mit denen Sie eine Verbindung herstellen möchten, eine Rollenzuweisung für die Identität.
Das Zuordnen einer benutzerseitig zugewiesenen verwalteten Identität zu einem Dienst für Azure KI-Suche wird im Azure-Portal, in Search-Verwaltungs-REST-APIs und in SDK-Paketen unterstützt, die das Feature bereitstellen.
Melden Sie sich beim Azure-Portal an.
Wählen Sie oben links auf dem Dashboard die Option Ressource erstellen aus.
Verwenden Sie das Suchfeld, um die vom Benutzer zugewiesene verwaltete Identität zu finden, und wählen Sie dann "Erstellen" aus.
Wählen Sie das Abonnement, die Ressourcengruppe und die Region an. Geben Sie der Identität einen beschreibenden Namen.
Wählen Sie Erstellen aus, und warten Sie, bis die Bereitstellung der Ressource abgeschlossen ist.
Es dauert mehrere Minuten, bis Sie die Identität verwenden können.
Wählen Sie auf Ihrer Suchdienstseite Einstellungen>Identität aus.
Wählen Sie auf der Registerkarte Benutzerseitig zugewiesen die Option Hinzufügen aus.
Wählen Sie das Abonnement und die vom Benutzer zugewiesene verwaltete Identität aus, die Sie zuvor erstellt haben.
Zuweisen einer Rolle
Sobald Sie über eine verwaltete Identität verfügen, weisen Sie Rollen zu, die Suchdienstberechtigungen für die Azure-Ressource bestimmen.
Leseberechtigungen sind für Indexerdatenverbindungen und für den Zugriff auf einen vom Kunden verwalteten Schlüssel in Azure Key Vault erforderlich.
Schreibberechtigungen sind für KI-Anreicherungsfeatures erforderlich, die Azure Storage zum Hosten von Debugsitzungsdaten, Zwischenspeichern von Anreicherungen und für die langfristige Inhaltsspeicherung in einem Wissensspeicher verwenden.
Der Workflow der Rollenzuweisung wird in den folgenden Schritten veranschaulicht. Dieses Beispiel gilt für Azure OpenAI. Weitere Azure-Ressourcen finden Sie unter Verbinden mit Azure Storage, Verbinden mit Azure Cosmos DB oder Verbinden mit Azure SQL.
Melden Sie sich mit Ihrem Azure-Konto beim Azure-Portal an und wechseln Sie zu Ihrer Azure OpenAI-Ressource.
Wählen Sie im linken Menü Zugriffssteuerung aus.
Wählen Sie Hinzufügen und dann Rollenzuweisung hinzufügen aus.
Wählen Sie unter Auftragsfunktionsrolle die Option Cognitive Services OpenAI-Benutzer und dann Weiter aus.
Wählen Sie unter Mitglieder die Option Verwaltete Identität und dann Mitglieder aus.
Filtern Sie nach Abonnement und Ressourcentyp (Suchdienste), und wählen Sie dann die verwaltete Identität Ihres Suchdiensts aus.
Wählen Sie "Überprüfen+ Zuweisen" aus.
Beispiele für Verbindungszeichenfolgen
Erinnern Sie sich an die Beschreibung der Szenarien, dass Sie verwaltete Identitäten in Verbindungszeichenfolgen mit anderen Azure-Ressourcen verwenden können. Dieser Abschnitt enthält Beispiele. Sie können allgemein verfügbare REST-API-Versionen und Azure SDK-Pakete für Verbindungen mit einer systemseitig zugewiesenen verwalteten Identität verwenden.
Tipp
Sie können die meisten dieser Objekte im Azure-Portal erstellen. Geben Sie dafür eine system- oder benutzerseitig zugewiesene verwaltete Identität an, und zeigen Sie dann die JSON-Definition an, um die Verbindungszeichenfolge abzurufen.
Hier sehen Sie einige Beispiele für Verbindungszeichenfolgen für verschiedene Szenarien.
Blob-Datenquelle (systemseitig verwaltete Identität):
Eine Indexerdatenquelle enthält eine credentials-Eigenschaft, die bestimmt, wie die Verbindung mit der Datenquelle hergestellt wird. Das folgende Beispiel zeigt eine Verbindungszeichenfolge, die die eindeutige Ressourcen-ID eines Speicherkontos angibt.
Eine systemseitig verwaltete Identität wird angegeben, wenn eine Verbindungszeichenfolge die eindeutige Ressourcen-ID eines Microsoft Entra ID-fähigen Diensts oder einer Microsoft Entra ID-fähigen Anwendung ist. Eine benutzerseitig zugewiesene verwaltete Identität wird mithilfe einer identity-Eigenschaft angegeben.
"credentials": {
"connectionString": "ResourceId=/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Storage/storageAccounts/{storage-account-name};"
}
Blob-Datenquelle (benutzerseitig verwaltete Identität):
Benutzerseitig zugewiesene verwaltete Identitäten können auch in Verbindungszeichenfolgen für Indexerdatenquellen verwendet werden. Allerdings unterstützen nur die neueren Vorschau-REST-APIs und Vorschaupakete eine benutzerseitig zugewiesene verwaltete Identität in Datenquellen-Verbindungszeichenfolge. Stellen Sie sicher, dass Sie zu einer Vorschauversion wechseln, wenn Sie SearchIndexerDataUserAssignedIdentity als Identität in einer Datenquellenverbindung festlegen.
Eine Benutzeridentität des Suchdiensts wird in der Eigenschaft identity angegeben.
"credentials": {
"connectionString": "ResourceId=/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Storage/storageAccounts/{storage-account-name};"
},
. . .
"identity": {
"@odata.type": "#Microsoft.Azure.Search.DataUserAssignedIdentity",
"userAssignedIdentity": "/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{user-assigned-managed-identity-name}"
}
Eine Wissensspeicherdefinition beinhaltet eine Verbindungszeichenfolge zum Azure Storage. Die Verbindungszeichenfolge ist die eindeutige Ressourcen-ID Ihres Speicherkontos. Beachten Sie, dass die Zeichenfolge keine Container oder Tabellen im Pfad enthält. Diese werden in der eingebetteten Projektionsdefinition definiert, nicht in der Verbindungszeichenfolge.
"knowledgeStore": {
"storageConnectionString": "ResourceId=/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Storage/storageAccounts/storage-account-name};"
}
Ein Indexer erstellt, verwendet und speichert den Container, der für die zwischengespeicherten Anreicherungen verwendet wird. Es ist nicht erforderlich, den Container in die Cacheverbindungszeichenfolge einzufügen. Sie finden die Objekt-ID im Azure-Portal auf der Seite Identität Ihres Suchdiensts.
"cache": {
"enableReprocessing": true,
"storageConnectionString": "ResourceId=/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Storage/storageAccounts/{storage-account-name};"
}
Eine Debugsitzung wird im Azure-Portal ausgeführt und nimmt eine Verbindungszeichenfolge an, wenn Sie die Sitzung starten. Sie können eine Zeichenkette ähnlich dem folgenden Beispiel einfügen.
"ResourceId=/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Storage/storageAccounts/{storage-account-name}/{container-name};",
Ein benutzerdefinierter Skill ist auf den Endpunkt einer Azure-Funktion oder -App ausgerichtet, die benutzerdefinierten Code hostet.
uriist der Endpunkt der Funktion oder App.authResourceIdweist den Suchdienst an, mithilfe einer verwalteten Identität eine Verbindung herzustellen, wobei die Anwendungs-ID der Zielfunktion oder -App im Attribut übergeben wird.
{
"@odata.type": "#Microsoft.Skills.Custom.WebApiSkill",
"description": "A custom skill that can identify positions of different phrases in the source text",
"uri": "https://contoso.count-things.com",
"authResourceId": "<Azure-AD-registered-application-ID>",
"batchSize": 4,
"context": "/document",
"inputs": [ ... ],
"outputs": [ ...]
}
Verbindungsbeispiele für Modelle
Für Verbindungen, die mithilfe von verwalteten Identitäten hergestellt werden, zeigt dieser Abschnitt Beispiele für Verbindungsinformationen, die von einem Suchdienst zum Herstellen einer Verbindung mit einem Modell in einer anderen Ressource verwendet werden. Eine Verbindung über eine systemseitig verwaltete Identität ist transparent. Die Identität und die Rollen sind vorhanden, und die Verbindung ist erfolgreich, wenn sie ordnungsgemäß konfiguriert sind. Im Gegensatz dazu erfordert eine benutzerseitig verwaltete Identität zusätzliche Verbindungseigenschaften.
Azure OpenAI-Einbettungsskill und Azure OpenAI-Vektorisierung:
Ein Azure OpenAI-Einbettungsskill und -Vektorisierung in der KI-Suche zielen auf den Endpunkt einer Azure OpenAI-Instanz, die ein Einbettungsmodell hostet. Der Endpunkt wird in der Azure OpenAI-Einbettungsskilldefinition und/oder in der Azure OpenAI-Vektorisierungsdefinition angegeben.
Die vom System verwaltete Identität wird automatisch verwendet, wenn "apikey" und "authIdentity" leer sind, wie im folgenden Beispiel gezeigt. Die Eigenschaft "authIdentity" wird nur für die benutzerseitig zugewiesene verwaltete Identität verwendet.
Beispiel zu einer systemseitig verwalteten Identität:
{
"@odata.type": "#Microsoft.Skills.Text.AzureOpenAIEmbeddingSkill",
"description": "Connects a deployed embedding model.",
"resourceUri": "https://url.openai.azure.com/",
"deploymentId": "text-embedding-ada-002",
"modelName": "text-embedding-ada-002",
"inputs": [
{
"name": "text",
"source": "/document/content"
}
],
"outputs": [
{
"name": "embedding"
}
]
}
Dies ist ein Vektorisierungsbeispiel, das für eine systemseitig zugewiesene verwaltete Identität konfiguriert ist. Ein Vektorisierer wird in einem Suchindex spezifiziert.
"vectorizers": [
{
"name": "my_azure_open_ai_vectorizer",
"kind": "azureOpenAI",
"azureOpenAIParameters": {
"resourceUri": "https://url.openai.azure.com",
"deploymentId": "text-embedding-ada-002",
"modelName": "text-embedding-ada-002"
}
}
]
Beispiel zu einer benutzerseitig zugewiesenen verwalteten Identität:
Eine benutzerseitig zugewiesene verwaltete Identität wird verwendet, wenn "apiKey" leer ist und ein gültiger Wert für "authIdentity" bereitgestellt wird.
{
"@odata.type": "#Microsoft.Skills.Text.AzureOpenAIEmbeddingSkill",
"description": "Connects a deployed embedding model.",
"resourceUri": "https://url.openai.azure.com/",
"deploymentId": "text-embedding-ada-002",
"modelName": "text-embedding-ada-002",
"inputs": [
{
"name": "text",
"source": "/document/content"
}
],
"outputs": [
{
"name": "embedding"
}
],
"authIdentity": {
"@odata.type": "#Microsoft.Azure.Search.DataUserAssignedIdentity",
"userAssignedIdentity": "/subscriptions/<subscription_id>/resourcegroups/<resource_group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<user-assigned-managed-identity-name>"
}
}
Dies ist ein Vektorisierungsbeispiel, das für eine benutzerseitig zugewiesene verwaltete Identität konfiguriert ist. Ein Vektorisierer wird in einem Suchindex spezifiziert.
"vectorizers": [
{
"name": "my_azure_open_ai_vectorizer",
"kind": "azureOpenAI",
"azureOpenAIParameters": {
"resourceUri": "https://url.openai.azure.com",
"deploymentId": "text-embedding-ada-002",
"modelName": "text-embedding-ada-002"
"authIdentity": {
"@odata.type": "#Microsoft.Azure.Search.DataUserAssignedIdentity",
"userAssignedIdentity": "/subscriptions/<subscription_id>/resourcegroups/<resource_group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<user-assigned-managed-identity-name>"
}
}
}
]
Überprüfen des Firewallzugriffs
Wenn sich Ihre Azure-Ressource hinter einer Firewall befindet, achten Sie darauf, dass eine Eingangsregel vorhanden ist, die Anforderungen von Ihrem Suchdienst und vom Azure-Portal zulässt.
Verwenden Sie für Verbindungen in derselben Region mit Azure Blob Storage oder Azure Data Lake Storage Gen2 eine systemseitig zugewiesene verwaltete Identität und die Ausnahme für vertrauenswürdige Dienste. Optional können Sie eine Ressourceninstanzregel konfigurieren, um Anforderungen zuzulassen.
Konfigurieren Sie für alle anderen Ressourcen und Verbindungen eine IP-Firewallregel, die Anforderungen von Azure KI-Suche zulässt. Weitere Informationen dazu finden Sie unter Indexerzugriff auf mit Azure-Netzwerksicherheitsfeatures geschützten Inhalt.