Delen via


Verbinding maken vanuit uw toepassing met resources zonder referenties te verwerken

Azure-resources met beheerde identiteiten ondersteunen altijd een optie om een beheerde identiteit op te geven om verbinding te maken met Azure-resources die ondersteuning bieden voor Microsoft Entra-verificatie. Door de ondersteuning voor beheerde identiteiten hoeven ontwikkelaars geen referenties in code te beheren. Beheerde identiteiten zijn de aanbevolen verificatieoptie bij het werken met Azure-resources die deze ondersteunen. Bekijk een overzicht van beheerde identiteiten.

Op deze pagina ziet u hoe u een App Service zo configureert dat deze verbinding kan maken met Azure Key Vault, Azure Storage en Microsoft SQL Server. Dezelfde principes kunnen worden gebruikt voor elke Azure-resource die beheerde identiteiten ondersteunt en die verbinding maken met resources die ondersteuning bieden voor Microsoft Entra-verificatie.

De codevoorbeelden maken gebruik van de Azure Identity-clientbibliotheek. Dit is de aanbevolen methode, omdat deze automatisch veel van de stappen voor u verwerkt, waaronder het verkrijgen van een toegangstoken dat in de verbinding wordt gebruikt.

Met welke resources kunnen beheerde identiteiten verbinding maken?

Een beheerde identiteit kan verbinding maken met elke resource die ondersteuning biedt voor Microsoft Entra-verificatie. Over het algemeen is er geen speciale ondersteuning vereist voor de resource om beheerde identiteiten verbinding te laten maken.

Sommige resources bieden geen ondersteuning voor Microsoft Entra-verificatie of de clientbibliotheek biedt geen ondersteuning voor verificatie met een token. Lees verder om onze richtlijnen te bekijken over het gebruik van een beheerde identiteit om veilig toegang te krijgen tot de referenties zonder ze op te slaan in uw code of toepassingsconfiguratie.

Een beheerde identiteit maken

Er zijn twee typen beheerde identiteiten: door het systeem toegewezen en door de gebruiker toegewezen. Door het systeem toegewezen identiteiten worden rechtstreeks gekoppeld aan één Azure-resource. Als de Azure-resource wordt verwijderd, wordt ook de identiteit verwijderd. Een door de gebruiker toegewezen beheerde identiteit kan worden gekoppeld aan meerdere Azure-resources en de levenscyclus ervan is onafhankelijk van deze resources.

Voor de meeste scenario's wordt u aangeraden een door de gebruiker toegewezen beheerde identiteit te gebruiken. Als de bronresource die u gebruikt geen ondersteuning biedt voor door de gebruiker toegewezen beheerde identiteiten, raadpleegt u de documentatie van die resourceprovider om te leren hoe u deze configureert voor een door het systeem toegewezen beheerde identiteit.

Belangrijk

Het account dat wordt gebruikt voor het maken van beheerde identiteiten, heeft een rol nodig, zoals 'Inzender voor beheerde identiteiten' om een nieuwe door de gebruiker toegewezen beheerde identiteit te maken.

Maak een door de gebruiker toegewezen beheerde identiteit met behulp van uw voorkeursoptie:

Nadat u een door de gebruiker toegewezen beheerde identiteit hebt gemaakt, noteert u de clientId waarden die principalId worden geretourneerd wanneer de beheerde identiteit wordt gemaakt. U gebruikt principalId tijdens het toevoegen van machtigingen en clientId in de code van uw toepassing.

App Service configureren met een door de gebruiker toegewezen beheerde identiteit

Voordat u de beheerde identiteit in uw code kunt gebruiken, moeten we deze toewijzen aan de App Service die deze gebruikt. Voor het configureren van een App Service voor het gebruik van een door de gebruiker toegewezen beheerde identiteit moet u de resource-id van de beheerde identiteit opgeven in de configuratie van uw app.

Machtigingen toevoegen aan de identiteit

Zodra u uw App Service hebt geconfigureerd voor het gebruik van een door de gebruiker toegewezen beheerde identiteit, verleent u de benodigde machtigingen aan de identiteit. In dit scenario gebruiken we deze identiteit om te communiceren met Azure Storage. Daarom moet u het RBAC-systeem (Op rollen gebaseerd toegangsbeheer) van Azure gebruiken om de door de gebruiker toegewezen beheerde identiteit machtigingen te verlenen aan de resource.

Belangrijk

U hebt een rol nodig, zoals Beheerder van gebruikerstoegang of Eigenaar voor de doelresource om roltoewijzingen toe te voegen. Zorg ervoor dat u de minimale bevoegdheid verleent die nodig is om de toepassing uit te voeren.

Voor alle resources die u wilt openen, moet u de identiteitsmachtigingen verlenen. Als u bijvoorbeeld een token aanvraagt voor toegang tot Key Vault, moet u ook een toegangsbeleid toevoegen dat de beheerde identiteit van uw app of functie bevat. Anders worden uw aanroepen naar Key Vault geweigerd, zelfs als u een geldig token gebruikt. Hetzelfde geldt voor Azure SQL Database. Zie Azure-services die ondersteuning bieden voor Microsoft Entra-verificatie voor meer informatie over welke resources Ondersteuning bieden voor Microsoft Entra-tokens.

Beheerde identiteiten gebruiken in uw code

Nadat u de bovenstaande stappen hebt voltooid, heeft uw App Service een beheerde identiteit met machtigingen voor een Azure-resource. U kunt de beheerde identiteit gebruiken om een toegangstoken te verkrijgen dat uw code kan gebruiken om te communiceren met Azure-resources, in plaats van referenties op te slaan in uw code.

We raden u aan de clientbibliotheken te gebruiken die we bieden voor de programmeertaal van uw voorkeur. Deze bibliotheken verkrijgen toegangstokens voor u, zodat u eenvoudig kunt verifiëren met Microsoft Entra-id. Zie Clientbibliotheken voor verificatie van beheerde identiteitenvoor meer informatie.

Een Azure Identity-bibliotheek gebruiken voor toegang tot Azure-resources

De Azure Identity-bibliotheken bieden elk een DefaultAzureCredential type. DefaultAzureCredential probeert de gebruiker automatisch te verifiëren via verschillende stromen, waaronder omgevingsvariabelen of een interactieve aanmelding. Het referentietype kan worden gebruikt in een ontwikkelomgeving met uw eigen referenties. Het kan ook worden gebruikt in uw Azure-productieomgeving met gebruikmaking van een beheerde identiteit. Er zijn geen codewijzigingen vereist wanneer u uw toepassing implementeert.

Als u door de gebruiker toegewezen beheerde identiteiten gebruikt, moet u ook expliciet de door de gebruiker toegewezen beheerde identiteit opgeven waarmee u zich wilt verifiëren door de client-id van de identiteit door te geven als parameter. U kunt de client-id ophalen door te bladeren naar de identiteit in Azure Portal.

Toegang tot een 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();                
}

Toegang tot een geheim dat is opgeslagen in 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;

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

Toegang krijgen tot Azure-resources met behulp van de Microsoft Authentication Library (MSAL)

Naast de Azure Identity-bibliotheken kunt u ook MSAL gebruiken om toegang te krijgen tot Azure-resources met behulp van beheerde identiteiten. De volgende codefragmenten laten zien hoe u MSAL gebruikt voor toegang tot Azure-resources in verschillende programmeertalen.

Voor door het systeem toegewezen beheerde identiteiten hoeft de ontwikkelaar geen aanvullende informatie door te geven. MSAL leidt automatisch de relevante metagegevens af over de toegewezen identiteit. Voor door de gebruiker toegewezen beheerde identiteiten moet de ontwikkelaar de client-id, de volledige resource-id of de object-id van de beheerde identiteit doorgeven.

Vervolgens kunt u een token verkrijgen om toegang te krijgen tot een resource. Voordat ze beheerde identiteiten gebruiken, moeten ontwikkelaars ze inschakelen voor de resources die ze willen gebruiken.

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

Verbinding maken met resources die geen ondersteuning bieden voor Microsoft Entra ID of verificatie op basis van tokens in bibliotheken

Sommige Azure-resources bieden nog geen ondersteuning voor Microsoft Entra-verificatie of hun clientbibliotheken bieden geen ondersteuning voor verificatie met een token. Deze resources zijn doorgaans opensource-technologieën waarvoor een gebruikersnaam en wachtwoord of een toegangssleutel in een verbindingsreeks wordt verwacht.

Als u wilt voorkomen dat referenties moeten worden opgeslagen in uw code of de configuratie van uw toepassing, kunt u de referenties opslaan als een geheim in Azure Key Vault. Met behulp van het bovenstaande voorbeeld kunt u het geheim ophalen uit Azure Key Vault door gebruik te maken van een beheerde identiteit en de referenties doorgeven aan uw verbindingsreeks. Deze methode betekent dat er geen referenties rechtstreeks in uw code of omgeving hoeven worden verwerkt. Zie Beheerde identiteiten gebruiken voor toegang tot Azure Key Vault-certificatenvoor een gedetailleerd voorbeeld. Zie Azure Key Vault-verificatievoor meer informatie over Azure Key Vault-verificatie.

Richtlijnen wanneer u rechtstreeks tokens verwerkt

In sommige scenario's kunt u tokens voor beheerde identiteiten handmatig verkrijgen in plaats van een ingebouwde methode te gebruiken om verbinding te maken met de doelresource. Deze scenario's omvatten geen clientbibliotheek voor de programmeertaal die u gebruikt of de doelresource waarmee u verbinding maakt, of verbinding maken met resources die niet worden uitgevoerd in Azure. Bij het handmatig verkrijgen van tokens bieden we de volgende richtlijnen:

De verkregen tokens in cache plaatsen

Voor prestaties en betrouwbaarheid wordt aanbevolen tokens in het lokale geheugen op te slaan, of versleuteld als u ze op schijf wilt opslaan. Aangezien tokens voor beheerde identiteiten 24 uur geldig zijn, is het niet handig om regelmatig nieuwe tokens aan te vragen, omdat er een uit de cache wordt geretourneerd door het eindpunt dat tokens uitgeeft. Als u de aanvraaglimieten overschrijdt, wordt de snelheid beperkt en wordt er een HTTP 429-fout weergegeven.

Wanneer u een token verkrijgt, kunt u instellen dat de tokencache verloopt 5 minuten voor de expires_on (of equivalente eigenschap) die wordt geretourneerd wanneer het token wordt gegenereerd.

Tokeninspectie

Uw toepassing mag niet afhankelijk zijn van de inhoud van een token. De inhoud van het token is alleen bedoeld voor de doelgroep (doelresource) waartoe toegang wordt verkregen, niet de client die het token aanvraagt. De tokeninhoud kan in de toekomst worden gewijzigd of versleuteld.

Geen tokens beschikbaar maken of verplaatsen

Tokens moeten worden behandeld als referenties. Maak ze niet beschikbaar voor gebruikers of andere services, zoals oplossingen voor logboekregistratie/bewaking. Ze mogen niet worden verplaatst van de bronresource die ze gebruikt, behalve voor verificatie met de doelresource.

Volgende stappen