Condividi tramite

Connessione dall'applicazione alle risorse senza gestire le credenziali

  • Articolo

Le risorse di Azure con supporto delle identità gestite offrono sempre un'opzione per specificare un'identità gestita per connettersi alle risorse di Azure che supportano l'autenticazione di Microsoft Entra. Il supporto delle identità gestite rende superfluo agli sviluppatori la gestione delle credenziali nel codice. Le identità gestite sono l'opzione di autenticazione consigliata quando si lavora con le risorse di Azure che le supportano. Leggere una panoramica delle identità gestite.

Questa pagina illustra come configurare un servizio app in modo che possa connettersi ad Azure Key Vault, Archiviazione di Azure e Microsoft SQL Server. Gli stessi principi possono essere usati per qualsiasi risorsa di Azure che supporta le identità gestite e che si connetterà alle risorse che supportano l'autenticazione di Microsoft Entra.

Gli esempi di codice usano la libreria client di Azure Identity, che è il metodo consigliato perché gestisce automaticamente molti dei passaggi necessari, inclusa l'acquisizione di un token di accesso usato nella connessione.

A quali risorse possono connettersi le identità gestite?

Un'identità gestita può connettersi a qualsiasi risorsa che supporti l'autenticazione di Microsoft Entra. In generale, non è necessario alcun supporto speciale per la risorsa per consentire alle identità gestite di connettersi.

Alcune risorse non supportano l'autenticazione di Microsoft Entra o la libreria client non supporta l'autenticazione con un token. Continuare a leggere per vedere le indicazioni su come usare un'identità gestita per accedere in modo sicuro alle credenziali senza dover archiviarle nel codice o nella configurazione dell'applicazione.

Creare un'identità gestita

Esistono due tipi di identità gestita: assegnata dal sistema e assegnata dall'utente. Le identità assegnate dal sistema sono collegate direttamente a una singola risorsa di Azure. Se la risorsa viene eliminata, verrà eliminata anche l'identità gestita. Un'identità gestita assegnata dall'utente può essere associata a più risorse di Azure e il relativo ciclo di vita è indipendente da tali risorse.

Per molti scenari è consigliabile usare un'identità gestita assegnata dall'utente. Se la risorsa di origine in uso non supporta le identità gestite assegnate dall'utente, è necessario fare riferimento alla documentazione del provider di risorse per informazioni su come configurarla per avere un'identità gestita assegnata dal sistema.

Importante

L'account usato per creare identità gestite richiede un ruolo come "Collaboratore identità gestita" per creare una nuova identità gestita assegnata dall'utente.

Creare un'identità gestita assegnata dall'utente usando l’opzione preferita:

Dopo aver creato un'identità gestita assegnata dall'utente, prendere nota dei clientId valori e principalId restituiti quando viene creata l'identità gestita. Si usano principalId durante l'aggiunta di autorizzazioni e clientId nel codice dell'applicazione.

Configurare Servizio app con un'identità gestita assegnata dall'utente

Prima di poter usare l'identità gestita nel codice, è necessario assegnarla al servizio app che lo userà. Il processo di configurazione di un servizio app per l'uso di un'identità gestita assegnata dall'utente richiede di specificare l'identificatore di risorsa dell'identità gestita nella configurazione dell'app.

Assegnare autorizzazioni all'identità

Dopo aver configurato il servizio app per usare un'identità gestita assegnata dall'utente, concedere le autorizzazioni necessarie all'identità. In questo scenario si usa questa identità per interagire con Archiviazione di Azure, quindi è necessario usare il sistema RBAC (Role Based Controllo di accesso) di Azure per concedere all'identità gestita assegnata dall'utente le autorizzazioni per la risorsa.

Importante

Per aggiungere assegnazioni di ruolo, è necessario un ruolo come "Amministratore accesso utenti" o "Proprietario" per la risorsa di destinazione. Assicurarsi di concedere il privilegio minimo necessario per l'esecuzione dell'applicazione.

Per le risorse a cui si vuole accedere è necessario concedere le autorizzazioni di identità. Ad esempio, se si richiede un token di accesso a Key Vault, è necessario aggiungere anche un criterio di accesso che include l'identità dell'app o della funzione. In caso contrario, le chiamate a Key Vault verranno rifiutate, anche se si usa un token valido. Lo stesso vale per il Database SQL di Azure. Per altre informazioni sulle risorse che supportano i token di Microsoft Entra, vedere Servizi di Azure che supportano l'autenticazione di Microsoft Entra.

Uso delle identità gestite nel codice

Dopo aver completato i passaggi descritti in precedenza, l'servizio app ha un'identità gestita con autorizzazioni per una risorsa di Azure. È possibile usare l'identità gestita per ottenere un token di accesso che il codice può usare per interagire con le risorse di Azure, anziché archiviare le credenziali nel codice.

È consigliabile usare la libreria di identità di Azure per il linguaggio di programmazione preferito. La libreria acquisisce i token di accesso per l'utente, semplificando la connessione alle risorse di destinazione.

Altre informazioni sulle librerie di identità di Azure sono disponibili di seguito:

Uso della libreria di identità di Azure nell'ambiente di sviluppo

Ognuna delle librerie di identità di Azure fornisce un DefaultAzureCredential tipo. DefaultAzureCredential tenta automaticamente di eseguire l'autenticazione tramite diversi meccanismi, tra cui variabili di ambiente o accesso interattivo. Il tipo credential può essere usato nell'ambiente di sviluppo usando le proprie credenziali. Può essere usato anche nell'ambiente di produzione di Azure usando un'identità gestita. Non sono necessarie modifiche al codice quando si distribuisce l'applicazione.

Se si usano identità gestite assegnate dall'utente, è anche necessario specificare in modo esplicito l'identità gestita assegnata dall'utente con cui si vuole eseguire l'autenticazione passando l'ID client dell'identità come parametro. È possibile recuperare l'ID client passando all'identità nel portale di Azure.

Accesso a un Blob in Archiviazione di Azure

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

Accedere ai segreti archiviati 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;

Accesso a Database SQL di Azure

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

Connessione a risorse che non supportano l'autenticazione basata su token o ID Di Microsoft Entra nelle librerie

Alcune risorse di Azure non supportano ancora l'autenticazione di Microsoft Entra o le librerie client non supportano l'autenticazione con un token. In genere queste risorse sono tecnologie open source che prevedono un nome utente e una password o una chiave di accesso in un stringa di connessione.

Per evitare di archiviare le credenziali nel codice o nella configurazione dell'applicazione, è possibile archiviare le credenziali come segreto in Azure Key Vault. Usando l'esempio riportato sopra, è possibile recuperare il segreto da Azure KeyVault usando un'identità gestita e passare le credenziali all'stringa di connessione. Questo approccio significa che non è necessario gestire le credenziali direttamente nel codice o nell'ambiente.

Linee guida per la gestione diretta dei token

In alcuni scenari, è possibile acquisire manualmente i token per le identità gestite anziché usare un metodo predefinito per connettersi alla risorsa di destinazione. Questi scenari includono nessuna libreria client per il linguaggio di programmazione usato o la risorsa di destinazione a cui ci si connette o la connessione alle risorse che non sono in esecuzione in Azure. Quando si acquisiscono i token manualmente, vengono fornite le linee guida seguenti:

Memorizzare nella cache i token acquisiti

Per prestazioni e affidabilità, è consigliabile che l'applicazione memorizza nella cache i token nella memoria locale o crittografati se si desidera salvarli su disco. Poiché i token di identità gestita sono validi per 24 ore, non c'è alcun vantaggio nella richiesta di nuovi token regolarmente, perché ne verrà restituito uno memorizzato nella cache dall'endpoint emittente del token. Se si superano i limiti delle richieste, si otterrà un limite di frequenza e si riceverà un errore HTTP 429.

Quando si acquisisce un token, è possibile impostare la cache dei token per scadere 5 minuti prima della expires_on proprietà (o equivalente) che verrà restituita quando viene generato il token.

Ispezione dei token

L'applicazione non deve basarsi sul contenuto di un token. Il contenuto del token è destinato solo al gruppo di destinatari (risorsa di destinazione) a cui si accede, non al client che richiede il token. Il contenuto del token può cambiare o essere crittografato in futuro.

Non esporre o spostare token

I token devono essere considerati come credenziali. Non esporli agli utenti o ad altri servizi; ad esempio, soluzioni di registrazione/monitoraggio. Non devono essere spostati dalla risorsa di origine che li usa, ad eccezione dell'autenticazione nella risorsa di destinazione.

Passaggi successivi