Concetti di base di Azure Key Vault
Azure Key Vault è un servizio cloud per archiviare i segreti e 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. Key Vault servizio supporta due tipi di contenitori: insiemi di credenziali e pool di moduli di sicurezza hardware gestiti(HSM). 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 dettagliate, vedere Panoramica dell'API REST di Azure Key Vault.
Ecco altri termini importanti:
Tenant: un tenant è l'organizzazione che possiede e gestisce una specifica istanza dei servizi cloud Microsoft. È più spesso usato per fare riferimento al set di servizi di Azure e Microsoft 365 per un'organizzazione.
Proprietario dell'insieme di credenziali: il proprietario può creare un insieme di credenziali delle chiavi e ottenerne un accesso e controllo completi. 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: quando il proprietario dell'insieme di credenziali gli concede l'accesso, il consumer può eseguire azioni sulle risorse nell'insieme di credenziali delle chiavi. Le azioni disponibili dipendono dalle autorizzazioni concesse.
Amministratori di HSM gestiti: gli utenti assegnati al ruolo Amministratore hanno il controllo completo su un pool di HSM gestito. Possono creare più assegnazioni di ruolo per delegare l'accesso controllato ad altri utenti.
Managed HSM Crypto Officer/User: ruoli predefiniti che vengono in genere assegnati agli utenti o alle entità servizio che eseguiranno operazioni di crittografia usando chiavi in Managed HSM. Crypto User può creare nuove chiavi, ma non è possibile eliminare le chiavi.
Utente di crittografia del servizio di crittografia del servizio HSM gestito: ruolo predefinito in genere assegnato a un'identità del servizio gestita degli account di servizio (ad esempio, account di 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 macchine virtuali, account di archiviazione, app Web, database e 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 della soluzione o solo le risorse da gestire come gruppo. L'utente decide come allocare le risorse ai gruppi di risorse nel modo più appropriato per l'organizzazione.
Entità 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. Consideralo come "identità utente" (nome utente e password o certificato) con un ruolo specifico e autorizzazioni strettamente controllate. Un'entità di sicurezza deve eseguire solo operazioni specifiche, a differenza di un'identità utente generale. Migliora la sicurezza se si concede solo il livello minimo di autorizzazione necessario per eseguire le attività di gestione. Un'entità di sicurezza usata con un'applicazione o un servizio viene chiamata entità servizio.
Azure Active Directory (Azure AD): Azure AD è 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 Azure AD all'interno di una sottoscrizione di Azure.
Identità gestite: Azure Key Vault offre un modo per archiviare in modo sicuro le credenziali e altri segreti, ma il codice deve eseguire l'autenticazione per Key Vault per recuperarli. L'uso di un'identità gestita consente di risolvere il problema in maniera più semplice, assegnando ai servizi di Azure un'identità gestita automaticamente in Azure AD. È possibile usare questa identità per l'autenticazione in Key Vault o in qualsiasi servizio che supporti l'autenticazione di Azure AD, senza dover inserire le credenziali 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 ruota automaticamente l'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 Transport Layer Security (TLS) per proteggere i dati quando si viaggia tra l'insieme di credenziali delle chiavi di Azure 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 chiavi per la firma e la crittografia. Ma voglio 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 mie 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 responsabilità potenziale per le chiavi e i segreti del tenant dei clienti. Voglio che i clienti possano possedere e gestire le proprie chiavi in modo che possa concentrarsi su ciò che faccio meglio, che fornisce 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 a FIPS 140-2 Level 2 o FIPS 140-2 Level 3 HSMs 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. Anche se si usano più servizi e risorse di Azure, è necessario gestire le chiavi da una singola posizione in Azure. |
√ Scegliere insiemi di credenziali per i moduli di protezione hardware convalidati FIPS 140-2 Livello 2. √ Scegliere pool HSM gestiti per FIPS 140-2 Livello 3 convalidati. √ 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 vantaggi per sviluppatori e amministratori di 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 delle attività operative come queste:
- 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
Questo amministratore fornisce quindi agli sviluppatori URI da chiamare dalle applicazioni. Questo amministratore fornisce anche le informazioni di registrazione dell'utilizzo chiave all'amministratore della sicurezza.
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
- Informazioni sulle funzionalità di sicurezza di Azure Key Vault.
- Informazioni su come proteggere i pool di moduli di protezione hardware gestiti
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.