Freigeben über


Herstellen einer Verbindung Ihrer Anwendung mit Ressourcen ohne Verarbeitung von Anmeldeinformationen

Azure-Ressourcen mit Unterstützung verwalteter Identitäten bieten immer eine Option zur Angabe einer verwalteten Identität zum Herstellen einer Verbindung mit Azure-Ressourcen, die die Microsoft Entra-Authentifizierung unterstützen. Die Unterstützung verwalteter Identitäten macht es für Entwickler unnötig, Anmeldeinformationen im Code zu verwalten. Verwaltete Identitäten sind die empfohlene Authentifizierungsoption beim Arbeiten mit Azure-Ressourcen, die sie unterstützen. Lesen Sie eine Übersicht über verwaltete Identitäten.

Auf dieser Seite wird gezeigt, wie Sie eine App Service-Instanz so konfigurieren, dass sie sich mit Azure Key Vault, Azure Storage und Microsoft SQL Server verbinden kann. Die gleichen Prinzipien gelten für jede Azure-Ressource, die verwaltete Identitäten unterstützt und die sich mit Ressourcen verbindet, die die Microsoft Entra-Authentifizierung unterstützen.

In den Codebeispielen wird die Azure Identity-Clientbibliothek verwendet, die empfohlen wird, da sie viele der Schritte automatisch für Sie erledigt. So z. B. auch des Beziehens eines Tokens für den Zugriff, das für die Verbindung verwendet wird.

Mit welchen Ressourcen können sich verwaltete Identitäten verbinden?

Eine verwaltete Identität kann eine Verbindung mit jeder Ressource herstellen, die Microsoft Entra-Authentifizierung unterstützt. Im Allgemeinen ist keine besondere Unterstützung für die Ressource erforderlich, damit verwaltete Identitäten sich mit ihr verbinden können.

Einige Ressourcen unterstützen die Microsoft Entra-Authentifizierung nicht, oder ihre Clientbibliothek unterstützt die Authentifizierung mit einem Token nicht. Lesen Sie weiter, um zu erfahren, wie Sie mit einer verwalteten Identität einen sicheren Zugriff auf die Anmeldeinformationen erhalten, ohne sie in Ihrem Code oder Ihrer Anwendungskonfiguration speichern zu müssen.

Erstellen einer verwalteten Identität

Es gibt zwei Arten von verwalteten Identitäten: systemseitig zugewiesene und benutzerseitig zugewiesene Identitäten. Systemseitig zugewiesene Identitäten werden direkt mit einer einzelnen Azure-Ressource verknüpft. Wenn die Azure-Ressource gelöscht wird, gilt dies auch für die Identität. Eine benutzerseitig zugewiesene verwaltete Identität kann mehreren Azure-Ressourcen zugeordnet werden, wobei ihr Lebenszyklus unabhängig von diesen Ressourcen ist.

Es wird empfohlen, eine benutzerseitig zugewiesene verwaltete Identität für die meisten Szenarien zu verwenden. Wenn die von Ihnen verwendete Quellressource keine benutzerseitig zugewiesenen verwalteten Identitäten unterstützt, konsultieren Sie die Dokumentation zu diesem Ressourcenanbieter, um zu erfahren, wie Sie sie für eine systemseitig zugewiesene verwaltete Identität konfigurieren können.

Wichtig

Das Konto, das zum Erstellen von verwalteten Identitäten verwendet wird, benötigt eine Rolle wie „Mitwirkender für verwaltete Identität“, um eine neue benutzerseitig zugewiesene verwaltete Identität zu erstellen.

Erstellen Sie eine benutzerseitig zugewiesene verwaltete Identität mit der von Ihnen bevorzugten Option:

Nachdem Sie eine benutzerzugeordnete verwaltete Identität erstellt haben, notieren Sie sich die clientId- und die principalId-Werte, die bei der Erstellung der verwalteten Identität zurückgegeben werden. Sie verwenden principalId, wenn Sie Berechtigungen hinzufügen, und clientId im Code Ihrer Anwendung.

Konfigurieren eines App Service mit einer benutzerseitig zugewiesenen verwalteten Identität

Bevor Sie die verwaltete Identität in Ihrem Code verwenden können, müssen wir sie dem App Service zuweisen, der sie verwendet. Das Konfigurieren eines App Service für die Verwendung einer benutzerseitig zugewiesenen verwalteten Identität erfordert, dass Sie den Ressourcen-Bezeichner der verwalteten Identität in Ihrer App-Konfiguration angeben.

Hinzufügen von Berechtigungen zur Identität

Nachdem Sie Ihren App Service für die Verwendung einer benutzerseitig zugewiesenen verwalteten Identität konfiguriert haben, erteilen Sie die erforderlichen Berechtigungen für die Identität. In diesem Szenario verwenden wir diese Identität, um mit Azure Storage zu interagieren. Daher müssen Sie das Azure Role Based Access Control (RBAC)-System verwenden, um der benutzerseitig zugewiesenen verwalteten Identität Berechtigungen für die Ressource zu erteilen.

Wichtig

Sie benötigen eine Rolle wie „Benutzerzugriffsadministrator“ oder „Besitzer“ für die Zielressource, um Rollenzuweisungen hinzufügen zu können. Stellen Sie sicher, dass Sie die geringsten Rechte gewähren, die für die Ausführung der Anwendung erforderlich sind.

Für alle Ressourcen, auf die Sie zugreifen möchten, müssen Sie die Identitätsberechtigungen erteilen. Wenn Sie beispielsweise ein Token für den Zugriff auf Key Vault anfordern, müssen Sie auch eine Zugriffsrichtlinie hinzufügen, die die verwaltete Identität Ihrer App oder Funktion enthält. Andernfalls werden Ihre Aufrufe von Key Vault abgelehnt, auch wenn Sie ein gültiges Token verwenden. Dasselbe gilt für Azure SQL-Datenbank. Informationen zu den Ressourcen, die Microsoft Entra-Tokens unterstützen, finden Sie unter Azure-Dienste, die die Microsoft Entra-Authentifizierung unterstützen.

Verwenden verwalteter Identitäten in Ihrem Code

Nachdem Sie die oben beschriebenen Schritte ausgeführt haben, verfügt Ihr App Service über eine verwaltete Identität mit Berechtigungen für eine Azure-Ressource. Sie können die verwaltete Identität verwenden, um ein Zugriffstoken zu erhalten, das Ihr Code zur Interaktion mit Azure-Ressourcen verwenden kann, anstatt Anmeldeinformationen in Ihrem Code zu speichern.

Es wird empfohlen, die Clientbibliotheken zu verwenden, die wir für Ihre bevorzugte Programmiersprache bereitstellen. Diese Bibliotheken erwerben Zugriffstoken für Sie, wodurch die Authentifizierung mit der Microsoft Entra-ID vereinfacht wird. Weitere Informationen finden Sie unter Clientbibliotheken für die Authentifizierung verwalteter Identitäten.

Verwenden einer Azure Identity-Bibliothek für den Zugriff auf Azure-Ressourcen

Die Azure Identity-Bibliotheken stellen jeweils einen DefaultAzureCredential-Typ bereit. DefaultAzureCredential versucht, den Benutzer automatisch über verschiedene Flüsse zu authentifizieren, einschließlich Umgebungsvariablen oder einer interaktiven Anmeldung. Der Anmeldeinformationstyp kann in einer Entwicklungsumgebung mit Ihren eigenen Anmeldeinformationen verwendet werden. Er kann auch in Ihrer Azure-Produktionsumgebung mithilfe einer verwalteten Identität verwendet werden. Zur Bereitstellung Ihrer Anwendung sind keine Codeänderungen erforderlich.

Wenn Sie benutzerseitig zugewiesene verwaltete Identitäten verwenden, sollten Sie auch die benutzerseitig zugewiesene verwaltete Identität, mit der Sie sich authentifizieren möchten, explizit angeben, indem Sie die Client-ID der Identität als Parameter übergeben. Sie können die Client-ID abrufen, indem Sie im Azure-Portal zu der Identität navigieren.

Zugreifen auf ein Blob in Azure Storage

using Azure.Identity;
using Azure.Storage.Blobs;

// code omitted for brevity

// Specify the Client ID if using user-assigned managed identities
var clientID = Environment.GetEnvironmentVariable("Managed_Identity_Client_ID");
var credentialOptions = new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = clientID
};
var credential = new DefaultAzureCredential(credentialOptions);                        

var blobServiceClient1 = new BlobServiceClient(new Uri("<URI of Storage account>"), credential);
BlobContainerClient containerClient1 = blobServiceClient1.GetBlobContainerClient("<name of blob>");
BlobClient blobClient1 = containerClient1.GetBlobClient("<name of file>");

if (blobClient1.Exists())
{
    var downloadedBlob = blobClient1.Download();
    string blobContents = downloadedBlob.Value.Content.ToString();                
}

Zugreifen auf ein in Azure Key Vault gespeichertes Geheimnis

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;
using Azure.Core;

// code omitted for brevity

// Specify the Client ID if using user-assigned managed identities
var clientID = Environment.GetEnvironmentVariable("Managed_Identity_Client_ID");
var credentialOptions = new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = clientID
};
var credential = new DefaultAzureCredential(credentialOptions);        

var client = new SecretClient(
    new Uri("https://<your-unique-key-vault-name>.vault.azure.net/"),
    credential);
    
KeyVaultSecret secret = client.GetSecret("<my secret>");
string secretValue = secret.Value;

Zugreifen auf Azure SQL-Datenbank

using Azure.Identity;
using Microsoft.Data.SqlClient;

// code omitted for brevity

// Specify the Client ID if using user-assigned managed identities
var clientID = Environment.GetEnvironmentVariable("Managed_Identity_Client_ID");
var credentialOptions = new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = clientID
};

AccessToken accessToken = await new DefaultAzureCredential(credentialOptions).GetTokenAsync(
    new TokenRequestContext(new string[] { "https://database.windows.net//.default" }));                        

using var connection = new SqlConnection("Server=<DB Server>; Database=<DB Name>;")
{
    AccessToken = accessToken.Token
};
var cmd = new SqlCommand("select top 1 ColumnName from TableName", connection);
await connection.OpenAsync();
SqlDataReader dr = cmd.ExecuteReader();
while(dr.Read())
{
    Console.WriteLine(dr.GetValue(0).ToString());
}
dr.Close();	

Verwenden der Microsoft Authentication Library (MSAL) für den Zugriff auf Azure-Ressourcen

Abgesehen von den Azure Identity-Bibliotheken können Sie msAL auch verwenden, um mithilfe von verwalteten Identitäten auf Azure-Ressourcen zuzugreifen. Die folgenden Codeausschnitte veranschaulichen die Verwendung von MSAL für den Zugriff auf Azure-Ressourcen in verschiedenen Programmiersprachen.

Für vom System zugewiesene verwaltete Identitäten muss der Entwickler keine zusätzlichen Informationen übergeben. MSAL leitet automatisch die relevanten Metadaten zur zugewiesenen Identität ab. Für vom Benutzer zugewiesene verwaltete Identitäten muss der Entwickler entweder die Client-ID, den vollständigen Ressourcenbezeichner oder die Objekt-ID der verwalteten Identität übergeben.

Anschließend können Sie ein Token für den Zugriff auf eine Ressource abrufen. Vor der Verwendung verwalteter Identitäten müssen Entwickler sie für die Ressourcen aktivieren, die sie verwenden möchten.

using Microsoft.Identity.Client;
using System;

string resource = "https://vault.azure.net";

// Applies to system-assigned managed identities only
IManagedIdentityApplication mi = ManagedIdentityApplicationBuilder.Create(ManagedIdentityId.SystemAssigned)
    .Build();

// Applies to user-assigned managed identities only
string userAssignedManagedIdentityClientId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx";
IManagedIdentityApplication mi = ManagedIdentityApplicationBuilder.Create(ManagedIdentityId.WithUserAssignedClientId(userAssignedManagedIdentityClientId))
    .Build();

// Acquire token
AuthenticationResult result = await mi.AcquireTokenForManagedIdentity(resource)
    .ExecuteAsync()
    .ConfigureAwait(false);

if (!string.IsNullOrEmpty(result.AccessToken))
{
    Console.WriteLine(result.AccessToken);
}

Herstellen einer Verbindung mit Ressourcen, die die Microsoft Entra ID- oder tokenbasierte Authentifizierung in Bibliotheken nicht unterstützen

Einige Azure-Ressourcen unterstützen die Microsoft Entra-Authentifizierung entweder noch nicht, oder ihre Clientbibliotheken unterstützen nicht die Authentifizierung mit einem Token. In der Regel handelt es sich bei diesen Ressourcen um Open-Source-Technologien, die einen Benutzernamen und ein Kennwort bzw. einen Zugriffsschlüssel in einer Verbindungszeichenfolge erwarten.

Um das Speichern von Anmeldeinformationen in Ihrem Code oder Ihrer Anwendungskonfiguration zu vermeiden, können Sie die Anmeldeinformationen als Geheimnis in Azure Key Vault speichern. Anhand des oben gezeigten Beispiels können Sie das Geheimnis mit einer verwalteten Identität aus Azure KeyVault abrufen und die Anmeldeinformationen an Ihre Verbindungszeichenfolge übergeben. Dieser Ansatz bedeutet, dass keine Anmeldeinformationen direkt in Ihrem Code oder Ihrer Umgebung verarbeitet werden müssen. Ein detailliertes Beispiel finden Sie unter Verwenden von verwalteten Identitäten für den Zugriff auf Azure Key Vault-Zertifikate. Weitere Informationen zur Azure Key Vault-Authentifizierung finden Sie unter Azure Key Vault-Authentifizierung.

Leitlinien, wenn Sie Token direkt verarbeiten

In einigen Szenarien möchten Sie möglicherweise Token für verwaltete Identitäten manuell beziehen, anstatt eine integrierte Methode zu verwenden, um eine Verbindung mit der Zielressource herzustellen. Diese Szenarien sehen keine Clientbibliothek für die von Ihnen verwendete Programmiersprache oder die Zielressource vor, mit der Sie sich verbinden, oder Sie verbinden sich mit Ressourcen, die nicht in Azure ausgeführt werden. Befolgen Sie beim manuellen Beziehen von Token die folgenden Leitlinien:

Zwischenspeichern der bezogenen Token

Aus Gründen der Leistung und Zuverlässigkeit empfehlen wir, dass Ihre Anwendung Token im lokalen Arbeitsspeicher zwischengespeichert oder verschlüsselt, wenn Sie sie auf einem Datenträger speichern möchten. Da Token für verwaltete Identitäten 24 Stunden gültig sind, ist es nicht sinnvoll, regelmäßig neue Token anzufordern, da der das Token ausstellende Endpunkt ein zwischengespeichertes Token zurückgibt. Wenn Sie die Grenzwerte für Anforderungen überschreiten, erfolgen eine Ratenbeschränkung und die Rückgabe des HTTP-Fehlers 429.

Wenn Sie ein Token beziehen, können Sie Ihren Tokencache so festlegen, dass er 5 Minuten vor der expires_on-Eigenschaft (oder einer gleichwertigen Eigenschaft) abläuft, die zurückgegeben wird, wenn das Token generiert wird.

Tokenüberprüfung

Ihre Anwendung sollte sich nicht auf den Inhalt eines Tokens verlassen. Der Inhalt des Tokens ist nur für die Zielgruppe (Zielressource) bestimmt, auf die zugegriffen wird, nicht für den Client, der das Token anfordert. Der Tokeninhalt kann in Zukunft geändert oder verschlüsselt werden.

Token nicht verfügbar machen oder verschieben

Token sollten wie Anmeldeinformationen behandelt werden. Machen Sie sie nicht für Benutzer oder andere Dienste verfügbar, z. B. für Protokollierungs- oder Überwachungslösungen. Sie sollten nicht aus der Quellressource, die sie verwendet, verschoben werden, außer zur Authentifizierung bei der Zielressource.

Nächste Schritte