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. Verschaffen Sie sich einen Überblick ü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ückgesendet 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 von verwalteten 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.

Wir empfehlen die Verwendung der Azure Identity-Bibliothek für Ihre bevorzugte Programmiersprache. Die Bibliothek bezieht Zugriffstoken für Sie, sodass Sie sich ganz einfach mit Zielressourcen verbinden können.

Weitere Informationen zu den Azure Identity-Bibliotheken finden Sie unter:

Verwenden der Azure Identity-Bibliothek in Ihrer Entwicklungsumgebung

Die Azure Identity-Bibliotheken stellen jeweils einen DefaultAzureCredential Typ bereit. DefaultAzureCredential versucht automatisch, sich über mehrere Mechanismen zu authentifizieren, darunter Umgebungsvariablen oder interaktive Anmeldung. Der Anmeldeinformationstyp kann in Ihrer 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 zur 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();	

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.

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