Připojení z aplikace k prostředkům bez zpracování přihlašovacích údajů

Prostředky Azure se spravovanými identitami podporují vždy možnost zadat spravovanou identitu pro připojení k prostředkům Azure, které podporují ověřování Microsoft Entra. Díky podpoře spravovaných identit vývojáři nespravuje přihlašovací údaje v kódu. Spravované identity jsou doporučenou možností ověřování při práci s prostředky Azure, které je podporují. Přečtěte si přehled spravovaných identit.

Tato stránka ukazuje, jak nakonfigurovat službu App Service, aby se mohl připojit ke službě Azure Key Vault, Azure Storage a Microsoft SQL Serveru. Stejné principy je možné použít pro jakýkoli prostředek Azure, který podporuje spravované identity a který se připojí k prostředkům, které podporují ověřování Microsoft Entra.

Ukázky kódu používají klientskou knihovnu Azure Identity, což je doporučená metoda, protože automaticky zpracovává mnoho kroků za vás, včetně získání přístupového tokenu použitého v připojení.

K jakým prostředkům se můžou spravované identity připojit?

Spravovaná identita se může připojit k libovolnému prostředku, který podporuje ověřování Microsoft Entra. Obecně platí, že pro prostředek není nutná žádná zvláštní podpora, aby se k němu mohly připojit spravované identity.

Některé prostředky nepodporují ověřování Microsoft Entra nebo jejich klientská knihovna nepodporuje ověřování pomocí tokenu. Pokračujte ve čtení a podívejte se na naše pokyny, jak používat spravovanou identitu k bezpečnému přístupu k přihlašovacím údajům, aniž byste je museli ukládat do konfigurace kódu nebo aplikace.

Vytvoření spravované identity

Existují dva typy spravovaných identit: přiřazené systémem a přiřazené uživatelem. Identity přiřazené systémem jsou přímo propojené s jedním prostředkem Azure. Když se prostředek Azure odstraní, je to identita. Spravovanou identitu přiřazenou uživatelem je možné přidružit k více prostředkům Azure a její životní cyklus je nezávislý na těchto prostředcích.

Pro většinu scénářů doporučujeme používat spravovanou identitu přiřazenou uživatelem. Pokud zdrojový prostředek, který používáte, nepodporuje spravované identity přiřazené uživatelem, měli byste se podívat do dokumentace poskytovatele prostředků a zjistit, jak ho nakonfigurovat tak, aby měla spravovanou identitu přiřazenou systémem.

Důležitý

Účet použitý k vytváření spravovaných identit potřebuje k vytvoření nové spravované identity roli, například Přispěvatel spravovaných identit.

Vytvořte spravovanou identitu přiřazenou uživatelem pomocí preferované možnosti:

Po vytvoření spravované identity přiřazené uživatelem si poznamenejte clientId hodnoty, principalId které se vrátí při vytvoření spravované identity. Používáte principalId při přidávání oprávnění a clientId v kódu aplikace.

Konfigurace služby App Service pomocí spravované identity přiřazené uživatelem

Než budete moct ve svém kódu použít spravovanou identitu, musíme ji přiřadit službě App Service, která ji bude používat. Proces konfigurace služby App Service tak, aby používal spravovanou identitu přiřazenou uživatelem, vyžaduje, abyste v konfiguraci aplikace zadali identifikátor prostředku spravované identity.

Přidání oprávnění k identitě

Jakmile nakonfigurujete službu App Service tak, aby používala spravovanou identitu přiřazenou uživatelem, udělte identitě potřebná oprávnění. V tomto scénáři používáme tuto identitu k interakci se službou Azure Storage, takže k udělení oprávnění spravované identity přiřazené uživatelem k prostředku potřebujete použít systém řízení přístupu na základě role (RBAC).

Důležitý

K přidání přiřazení rolí budete potřebovat roli správce uživatelských přístupů nebo vlastníka cílového prostředku. Ujistěte se, že udělujete nejnižší požadovaná oprávnění ke spuštění aplikace.

Všechny prostředky, ke kterým chcete získat přístup, vyžadují udělení oprávnění identit. Pokud například požadujete token pro přístup ke službě Key Vault, musíte také přidat zásadu přístupu, která zahrnuje spravovanou identitu vaší aplikace nebo funkce. Jinak budou vaše volání do služby Key Vault odmítnuta, i když použijete platný token. Totéž platí pro Azure SQL Database. Další informace o tom, které prostředky podporují tokeny Microsoft Entra, najdete v tématu Služby Azure, které podporují ověřování Microsoft Entra.

Použití spravovaných identit v kódu

Po dokončení výše uvedených kroků má služba App Service spravovanou identitu s oprávněními k prostředku Azure. Spravovanou identitu můžete použít k získání přístupového tokenu, který váš kód může použít k interakci s prostředky Azure místo ukládání přihlašovacích údajů do kódu.

Doporučujeme použít knihovnu Identit Azure pro preferovaný programovací jazyk. Knihovna za vás získává přístupové tokeny, což usnadňuje připojení k cílovým prostředkům.

Přečtěte si další informace o následujících knihovnách identit Azure:

Použití knihovny Azure Identity ve vývojovém prostředí

Knihovny identit Azure poskytují typ DefaultAzureCredential . DefaultAzureCredential automaticky se pokusí ověřit prostřednictvím více mechanismů, včetně proměnných prostředí nebo interaktivního přihlašování. Typ přihlašovacích údajů můžete použít ve vývojovém prostředí pomocí vlastních přihlašovacích údajů. Dá se také použít v produkčním prostředí Azure pomocí spravované identity. Při nasazování aplikace se nevyžadují žádné změny kódu.

Pokud používáte spravované identity přiřazené uživatelem, měli byste také explicitně zadat spravovanou identitu přiřazenou uživatelem, kterou chcete ověřit předáním ID klienta identity jako parametru. ID klienta můžete načíst tak, že přejdete na identitu na webu Azure Portal.

Přístup k objektu blob ve službě 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();                
}

Přístup k tajnému kódu uloženému ve službě Azure Key Vault

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;

Přístup ke službě Azure SQL Database

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();	

Připojení k prostředkům, které nepodporují ověřování na základě ID Nebo tokenu Microsoftu v knihovnách

Některé prostředky Azure zatím nepodporují ověřování Microsoft Entra nebo jejich klientské knihovny nepodporují ověřování pomocí tokenu. Tyto prostředky jsou obvykle opensourcové technologie, které v připojovací řetězec očekávají uživatelské jméno a heslo nebo přístupový klíč.

Abyste se vyhnuli ukládání přihlašovacích údajů v kódu nebo konfiguraci vaší aplikace, můžete přihlašovací údaje uložit jako tajný kód ve službě Azure Key Vault. Pomocí výše uvedeného příkladu můžete načíst tajný klíč z Azure KeyVault pomocí spravované identity a předat přihlašovací údaje do svého připojovací řetězec. Tento přístup znamená, že v kódu nebo prostředí není potřeba zpracovávat žádné přihlašovací údaje.

Pokyny, pokud zpracováváte tokeny přímo

V některých scénářích můžete chtít získat tokeny pro spravované identity ručně místo použití integrované metody pro připojení k cílovému prostředku. Mezi tyto scénáře patří žádná klientská knihovna pro programovací jazyk, který používáte, nebo cílový prostředek, ke kterému se připojujete, nebo připojení k prostředkům, které nejsou spuštěné v Azure. Při ručním získávání tokenů poskytujeme následující pokyny:

Uložení tokenů do mezipaměti, které jste získali

Pro zvýšení výkonu a spolehlivosti doporučujeme, aby vaše aplikace ukládaly tokeny do mezipaměti v místní paměti nebo zašifrovaly, pokud je chcete uložit na disk. Vzhledem k tomu, že tokeny spravované identity jsou platné 24 hodin, není možné pravidelně vyžadovat nové tokeny, protože jeden token uložený v mezipaměti se vrátí z vydávajícího koncového bodu tokenu. Pokud překročíte limity požadavků, budete omezeni rychlostí a zobrazí se chyba HTTP 429.

Když token získáte, můžete nastavit, aby platnost mezipaměti tokenů vypršela 5 minut před expires_on (nebo ekvivalentní vlastností), která se vrátí při vygenerování tokenu.

Kontrola tokenu

Vaše aplikace by neměla spoléhat na obsah tokenu. Obsah tokenu je určený jenom pro cílovou skupinu (cílový prostředek), ke které se přistupuje, nikoli pro klienta, který token požaduje. Obsah tokenu se může v budoucnu změnit nebo zašifrovat.

Nezpřístupňujte ani nepřesouvejte tokeny

Tokeny by se měly považovat za přihlašovací údaje. Nezpřístupňujte je uživatelům ani jiným službám; Například řešení protokolování/monitorování. Neměli by být přesunuti ze zdrojového prostředku, který je používá, jinak než k ověření u cílového prostředku.

Další kroky