Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
L'autenticazione con Key Vault funziona in combinazione con Microsoft Entra ID, responsabile dell'autenticazione dell'identità di qualsiasi principale di sicurezza.
Un'entità di sicurezza è un oggetto che rappresenta un utente, un gruppo, un servizio o un'applicazione che richiede l'accesso alle risorse Azure. Azure assegna un ID oggetto univoco a ogni entità di sicurezza.
Un'entità di sicurezza user identifica un utente con un profilo in Microsoft Entra ID.
Un'entità di sicurezza group identifica un set di utenti creati in Microsoft Entra ID. Tutti i ruoli o le autorizzazioni assegnati al gruppo vengono concessi a tutti gli utenti all'interno del gruppo.
Un'entità servizio è un tipo di entità di sicurezza che identifica un'applicazione o un servizio, ad esempio una parte di codice anziché un utente o un gruppo. L'ID oggetto di un'entità servizio funge da nome utente; il segreto client dell'entità servizio funge da password.
Per le applicazioni esistono due modi per ottenere un'entità servizio:
Consigliato: abilitare un'identità gestita assegnata dal sistema per l'applicazione.
Con l'identità gestita, Azure gestisce internamente l'entità servizio dell'applicazione e autentica automaticamente l'applicazione con altri servizi Azure. L'identità gestita è disponibile per le applicazioni distribuite in un'ampia gamma di servizi.
Per altre informazioni, vedere Panoramica delle identità gestite. Consulta anche Azure Servizi che supportano l'identità gestita, che collega ad articoli che descrivono come abilitare l'identità gestita per servizi specifici (ad esempio Servizio App, Funzioni di Azure, Macchine virtuali e così via).
Se non è possibile usare l'identità gestita, si deve invece registrare l'applicazione con il tenant Microsoft Entra, come descritto in Quickstart: Registrare un'applicazione con la piattaforma di identità di Azure. La registrazione crea anche un secondo oggetto applicazione che identifica l'app in tutti i tenant.
Scenari di autenticazione di Key Vault
Alla creazione in una sottoscrizione di Azure, un insieme di credenziali delle chiavi viene automaticamente associato al tenant di Microsoft Azure della sottoscrizione. Tutti i chiamanti in entrambi i piani devono essere registrati in questo tenant ed eseguire l'autenticazione per accedere all'insieme di credenziali delle chiavi. Le applicazioni possono accedere Key Vault in tre modi:
Solo dell'applicazione: l'applicazione rappresenta un'entità servizio o un'identità gestita. Questa identità è lo scenario più comune per le applicazioni che devono accedere periodicamente a certificati, chiavi o segreti dell'insieme di credenziali delle chiavi. Per il funzionamento di questo scenario quando si usano i criteri di accesso (legacy), il
objectIddell'applicazione deve essere specificato nei criteri di accesso e ilapplicationIdnon deve essere specificato o deve esserenull. Quando si usa il Controllo degli accessi in base al ruolo di Azure, assegnare i ruoli appropriati all'identità gestita o all'entità servizio dell'applicazione.Solo dell'utente: l'utente accede all'insieme di credenziali delle chiavi da qualsiasi applicazione registrata nel tenant. Alcuni esempi di questo tipo di accesso includono Azure PowerShell e il portale di Azure. Per il funzionamento di questo scenario quando si usano i criteri di accesso (legacy), il
objectIddell'utente deve essere specificato nei criteri di accesso e ilapplicationIdnon deve essere specificato o deve esserenull. Quando si usa Azure RBAC, assegnare i ruoli appropriati agli utenti.Applicazione-più-utente (talvolta definito identità composta): l'utente deve accedere all'insieme di credenziali delle chiavi da un'applicazione specifica e l'applicazione deve usare il flusso OBO (On-Behalf-of Authentication, autenticazione per conto di) per rappresentare l'utente. Affinché questo scenario funzioni con i criteri di accesso (legacy), entrambi
applicationIdeobjectIddevono essere specificati nei criteri di accesso.applicationIdIdentifica l'applicazione richiesta e identificaobjectIdl'utente. Attualmente, questa opzione non è disponibile per il data plane RBAC di Azure.
In tutti i tipi di accesso, l'applicazione esegue l'autenticazione con Microsoft Entra ID. L'applicazione usa qualsiasi metodo di autenticazione supportato in base al tipo di applicazione. L'applicazione acquisisce un token per una risorsa del piano per la concessione dell'accesso. La risorsa è un endpoint nel piano dati o di gestione, in base all'ambiente Azure. L'applicazione usa il token e invia una richiesta API REST a Key Vault. Per altre informazioni, vedere l'intero flusso di autenticazione.
Il modello di un singolo meccanismo per l'autenticazione in entrambi i piani offre diversi vantaggi:
- Le organizzazioni possono controllare l'accesso a tutti gli insiemi di credenziali delle chiavi in modo centralizzato.
- Se un utente lascia l'organizzazione, perde immediatamente l'accesso a tutti gli insiemi di credenziali delle chiavi all'interno dell'organizzazione.
- Le organizzazioni possono personalizzare l'autenticazione usando le opzioni in Microsoft Entra ID, ad esempio per abilitare l'autenticazione a più fattori per una maggiore sicurezza.
Configurare il firewall Key Vault
Per impostazione predefinita, Key Vault consente l'accesso alle risorse tramite indirizzi IP pubblici. Per maggiore sicurezza, è anche possibile limitare l'accesso a specifici intervalli IP, endpoint di servizio, reti virtuali o endpoint privati.
Per ulteriori informazioni, consultare Accedere a Azure Key Vault dietro un firewall.
Flusso dell'operazione di richiesta Key Vault con l'autenticazione
L'autenticazione di Key Vault avviene come parte di ogni richiesta a Key Vault. Una volta recuperato, il token può essere riutilizzato per le chiamate successive. Esempio di flusso di autenticazione:
Un token richiede l'autenticazione con Microsoft Entra ID, ad esempio:
- Una risorsa Azure, ad esempio una macchina virtuale o un'applicazione del servizio app con un'identità gestita, contatta l'endpoint REST per ottenere un token di accesso.
- Un utente accede al portale di Azure usando un nome utente e una password.
Se l'autenticazione con Microsoft Entra ID ha esito positivo, all'entità di sicurezza viene concesso un token OAuth.
Chiamata all'API REST Key Vault tramite l'endpoint (URI) dell'Key Vault.
Key Vault Firewall controlla i criteri seguenti. Se viene soddisfatto un criterio, la chiamata è consentita. In caso contrario, la chiamata viene bloccata e viene restituita una risposta di operazione non consentita.
- Il firewall è disabilitato e l'endpoint pubblico di Key Vault è raggiungibile dalla rete Internet pubblica.
- Il chiamante è un Key Vault Trusted Service, il che gli permette di ignorare il firewall.
- Il chiamante è elencato nel firewall in base a indirizzo IP, rete virtuale o endpoint di servizio.
- Il chiamante può raggiungere Key Vault tramite una connessione di collegamento privata configurata.
Se il firewall consente la chiamata, Key Vault chiama Microsoft Entra ID per convalidare il token di accesso dell'entità di sicurezza.
Key Vault controlla se l'entità di sicurezza dispone dell'autorizzazione necessaria per l'operazione richiesta. In caso contrario, Key Vault restituisce una risposta non consentita.
Key Vault esegue l'operazione richiesta e restituisce il risultato.
Il diagramma seguente illustra il processo per un'applicazione che chiama l'API "Get Secret" di Key Vault.
Annotazioni
Key Vault client SDK per segreti, certificati e chiavi effettuano una chiamata aggiuntiva a Key Vault senza token di accesso, che comporta una risposta 401 per recuperare le informazioni del tenant. Per altre informazioni , vedere Autenticazione, richieste e risposte
Autenticazione per Key Vault nel codice dell'applicazione
Key Vault SDK usa la libreria client Azure Identity, che consente l'autenticazione senza interruzioni per Key Vault attraverso gli ambienti con lo stesso codice.
librerie client Azure Identity
| .NET | Python | Java | JavaScript |
|---|---|---|---|
| Azure Identity SDK .NET | Azure Identity SDK Python | Azure Identity SDK Java | Azure Identity SDK JavaScript |
Per altre informazioni sulle procedure consigliate ed esempi di sviluppatori, vedere Authenticate to Key Vault in code
Passaggi successivi
guida per sviluppatori Key Vault
risoluzione dei problemi dei criteri di accesso Key Vault
Che cos'è il controllo degli accessi basato su ruoli di Azure (Azure RBAC)?