Concetti di base di Azure Key Vault

Azure Key Vault è un servizio cloud che consente di archiviare i segreti e di accedervi in modo sicuro. Un segreto è qualsiasi elemento per cui si vuole controllare rigorosamente l'accesso, ad esempio chiavi API, password, certificati o chiavi crittografiche. Il servizio Key Vault supporta due tipi di contenitori: insiemi di credenziali e pool di moduli di protezione hardware gestiti. Gli insiemi di credenziali offrono il supporto per l'archiviazione di chiavi, segreti e certificati supportati da software e HSM. I pool di HSM gestiti forniscono supporto solo per le chiavi protette da moduli di protezione hardware. Per informazioni dettagliate, vedere Panoramica dell'API REST di Azure Key Vault.

Altri termini importanti sono riportati di seguito:

  • Tenant: un tenant è l'organizzazione che possiede e gestisce una specifica istanza dei servizi cloud Microsoft. Viene spesso usato per fare riferimento al set di servizi di Azure e Microsoft 365 per l’organizzazione.

  • Proprietario dell'insieme di credenziali: può creare un insieme di credenziali delle chiavi e ottenere accesso e controllo completo. Il proprietario dell'insieme di credenziali può anche configurare il controllo per registrare chi accede a segreti e chiavi. Gli amministratori possono controllare il ciclo di vita delle chiavi. Possono passare a una nuova versione della chiave, eseguirne il backup e svolgere attività correlate.

  • Consumer dell'insieme di credenziali: può eseguire azioni sugli asset all'interno dell'insieme di credenziali delle chiavi quando il proprietario dell'insieme di credenziali concede l'accesso consumer. Le azioni disponibili dipendono dalle autorizzazioni concesse.

  • HSM gestito Amministrazione istrators: gli utenti a cui viene assegnato il ruolo Amministrazione istrator hanno il controllo completo su un pool di moduli di protezione hardware gestiti. Possono creare più assegnazioni di ruolo per delegare l'accesso controllato ad altri utenti.

  • HSM Crypto Officer/Utente gestito: ruoli predefiniti in genere assegnati a utenti o entità servizio che eseguiranno operazioni di crittografia usando chiavi nel modulo di protezione hardware gestito. L'utente della crittografia può creare nuove chiavi, ma non può eliminarle.

  • Utente di crittografia del servizio di crittografia del modulo di protezione hardware gestito: ruolo predefinito assegnato in genere a un'identità del servizio gestita degli account del servizio (ad esempio, account Archiviazione) per la crittografia dei dati inattivi con la chiave gestita dal cliente.

  • Risorsa: una risorsa è un elemento gestibile disponibile tramite Azure. Esempi comuni sono la macchina virtuale, l'account di archiviazione, l'app Web, il database e la rete virtuale. Ne esistono molti altri.

  • Gruppo di risorse: un gruppo di risorse è un contenitore con risorse correlate per una soluzione di Azure. Il gruppo di risorse può includere tutte le risorse per la soluzione o solo le risorse che si desidera gestire come gruppo. L'utente decide come allocare le risorse ai gruppi di risorse nel modo più appropriato per l'organizzazione.

  • Entità di sicurezza: un'entità di sicurezza di Azure è un'identità di sicurezza usata da app, servizi e strumenti di automazione creati dall'utente per accedere a risorse di Azure specifiche. Può essere considerata come una "identità utente" (nome utente e password o certificato) con un ruolo specifico e autorizzazioni attentamente controllate. Un'entità di sicurezza deve solo eseguire operazioni specifiche, a differenza di un'identità utente generale. Se le viene concesso solo il livello minimo di autorizzazioni necessarie per eseguire le attività di gestione, migliora la sicurezza. Un'entità di sicurezza usata con un'applicazione o un servizio è detta entità servizio.

  • Microsoft Entra ID: Microsoft Entra ID è il servizio Active Directory per un tenant. Ogni directory dispone di uno o più domini. A una directory possono essere associate molte sottoscrizioni, ma un solo tenant.

  • ID tenant di Azure: un ID tenant è un modo univoco per identificare un'istanza di Microsoft Entra all'interno di una sottoscrizione di Azure.

  • Identità gestite: Azure Key Vault consente di archiviare in modo sicuro le credenziali e altri segreti, ma il codice deve eseguire l'autenticazione in Key Vault per recuperarle. L'uso di un'identità gestita semplifica la soluzione di questo problema, fornendo ai servizi Azure un'identità gestita automaticamente in Microsoft Entra ID. È possibile usare questa identità per l’autenticazione di Key Vault o a qualsiasi servizio che supporti l'autenticazione di Microsoft Entra, senza dover inserire alcuna credenziale nel codice. Per altre informazioni, vedere l'immagine seguente e la panoramica delle identità gestite per le risorse di Azure.

Authentication

Per eseguire qualsiasi operazione con Key Vault, è prima necessario eseguire l'autenticazione. È possibile eseguire l'autenticazione a Key Vault in tre modi diversi:

  • Identità gestite per le risorse di Azure: quando si distribuisce un'app in una macchina virtuale in Azure, è possibile assegnare un'identità alla macchina virtuale che ha accesso a Key Vault. È anche possibile assegnare identità ad altre risorse di Azure. Il vantaggio di questo approccio è che l'app o il servizio non gestisce la rotazione del primo segreto. È Azure a eseguire automaticamente la rotazione dell'identità. Questo approccio è la procedura consigliata.
  • Entità servizio e certificato: è possibile usare un'entità servizio e un certificato associato che ha accesso a Key Vault. Questo approccio non è consigliabile perché è il proprietario o lo sviluppatore dell'applicazione a dover ruotare il certificato.
  • Entità servizio e segreto: anche se è possibile usare un'entità servizio e un segreto per eseguire l'autenticazione a Key Vault, questo approccio non è consigliabile. La rotazione automatica del segreto bootstrap usato per l'autenticazione a Key Vault è un'operazione complessa.

Crittografia dei dati in transito

Azure Key Vault applica il protocollo TLS (Transport Layer Security ) per proteggere i dati quando si spostano tra Azure Key Vault e i client. I client negoziano una connessione TLS con Azure Key Vault. Il protocollo TLS offre autenticazione avanzata, riservatezza dei messaggi e integrità (abilitando il rilevamento di manomissioni, intercettazioni e falsificazioni di messaggi), interoperabilità, flessibilità degli algoritmi e facilità di distribuzione e di utilizzo.

Perfect Forward Secrecy (PFS) protegge le connessioni tra i sistemi client dei clienti e i servizi cloud di Microsoft con chiavi univoche. Le connessioni usano anche lunghezze di chiavi di crittografia basate a 2.048 bit basate su RSA. Questa combinazione rende difficile ad altri utenti intercettare e accedere ai dati in transito.

Ruoli dell'insieme di credenziali delle chiavi

La seguente tabella permette di capire meglio come l'insieme di credenziali chiave aiuti a soddisfare le esigenze degli sviluppatori e degli amministratori della sicurezza.

Ruolo Presentazione del problema Soluzione offerta dall'insieme di credenziali chiave di Azure
Sviluppatore di un'applicazione Azure "Si vuole scrivere un'applicazione per Azure che usa le chiavi per la firma e la crittografia. Ma si vuole che queste chiavi siano esterne dall'applicazione in modo che la soluzione sia adatta per un'applicazione distribuita geograficamente.

Voglio che queste chiavi e questi segreti siano protetti, senza dover scrivere manualmente il codice, Voglio anche che queste chiavi e segreti siano facili da usare dalle applicazioni, con prestazioni ottimali".
√ Le chiavi vengono archiviate in un insieme di credenziali e richiamate dall'URI quando è necessario.

√ Le chiavi vengono protette da Azure con algoritmi standard del settore, lunghezze delle chiavi e moduli di protezione hardware.

√ Le chiavi vengono elaborate in moduli di protezione hardware che risiedono negli stessi data center di Azure in cui si trovano le applicazioni. In questo modo si ottiene una migliore affidabilità e una latenza ridotta rispetto a chiavi che si trovano in una posizione diversa, ad esempio in locale.
Sviluppatore di software come un servizio (SaaS) "Non voglio la responsabilità o la potenziale responsabilità per le chiavi e i segreti tenant dei miei clienti.

Voglio che i clienti possiedono e gestiscono le proprie chiavi in modo da potersi concentrare su ciò che faccio meglio, fornendo le funzionalità principali del software."
√ I clienti possono importare le loro chiavi in Azure e gestirle. Quando un'applicazione SaaS deve eseguire operazioni di crittografia usando le chiavi dei clienti, Key Vault esegue queste operazioni per conto dell'applicazione. L'applicazione non visualizza le chiavi dei clienti.
Responsabile della sicurezza "Voglio sapere che le nostre applicazioni sono conformi ai moduli di protezione hardware FIPS 140 Livello 3 per la gestione sicura delle chiavi.

Voglio assicurarmi che la mia organizzazione abbia il controllo del ciclo di vita delle chiavi e possa monitorare l'utilizzo delle chiavi.

E anche se si usano più servizi e risorse di Azure, si vogliono gestire le chiavi da un'unica posizione in Azure."
√ Scegliere insiemi di credenziali o moduli di protezione hardware gestiti per moduli di protezione hardware convalidati FIPS 140.
√ Scegliere pool di moduli di protezione hardware gestiti per moduli di protezione hardware convalidati FIPS 140-2 livello 3.

√ L'insieme di credenziali delle chiavi è progettato in modo che Microsoft non possa vedere o estrarre le chiavi.
√ L'utilizzo delle chiavi viene registrato quasi in tempo reale.

√ L'insieme di credenziali offre un'unica interfaccia, indipendentemente dal numero di insiemi di credenziali disponibili in Azure, dalle aree supportate e dalle applicazioni che li usano.

Chiunque abbia una sottoscrizione di Azure può creare e usare insiemi di credenziali delle chiavi. Anche se Key Vault offre vantaggi agli sviluppatori e agli amministratori della sicurezza, può essere implementato e gestito dall'amministratore di un'organizzazione che gestisce altri servizi di Azure. Ad esempio, questo amministratore può accedere con una sottoscrizione di Azure, creare un insieme di credenziali per l'organizzazione in cui archiviare le chiavi e quindi essere responsabile di attività operative, come le seguenti:

  • Creare o importare una chiave o un segreto
  • Revocare o eliminare una chiave o un segreto
  • Autorizzare gli utenti o le applicazioni per l'accesso all'insieme di credenziali delle chiavi, per consentire la gestione o l'uso delle chiavi e dei segreti corrispondenti
  • Configurare l'utilizzo delle chiavi (ad esempio, la firma o la crittografia)
  • Monitorare l'utilizzo delle chiavi

L’amministratore fornisce quindi agli sviluppatori gli URI da chiamare dalle applicazioni. L'amministratore fornisce anche le informazioni di registrazione relative all'uso delle chiavi all'amministratore della sicurezza.

Overview of how Azure Key Vault works

Gli sviluppatori possono gestire le chiavi anche direttamente, usando le API. Per altre informazioni, vedere la Guida per gli sviluppatori dell'insieme di credenziali delle chiavi di Azure.

Passaggi successivi

L'insieme di credenziali delle chiavi di Azure è disponibile nella maggior parte delle aree. Per altre informazioni, vedere la pagina Insieme di credenziali delle chiavi - Prezzi.