Condividi tramite

Crittografia con le chiavi gestite dai clienti in Microsoft Cloud for Sovereignty

  • Articolo

I clienti che intendono implementare Microsoft Cloud for Sovereignty potrebbero richiedere l'uso di funzionalità di crittografia dei dati per soddisfare i requisiti di sovranità dei dati. I clienti con severi requisiti di sovranità dei dati devono sviluppare piani per implementare la gestione delle chiavi nel cloud. Questo articolo fornisce le informazioni necessarie ad architetti cloud, proprietari di sistemi crittografici e altri decisori tecnici per sviluppare un piano per l'implementazione della crittografia a livello di piattaforma in Azure. La pianificazione della crittografia a livello di piattaforma implica in genere l'identificazione dei requisiti di gestione delle chiavi, scelte tecnologiche e la selezione delle scelte di progettazione e configurazione per i servizi di Azure da usare. Questo processo implica la presa di decisioni tecniche in tre ambiti:

  • Definire i requisiti di gestione delle chiavi: cosa deve fare la tua organizzazione per proteggere i dati sensibili dei clienti e il materiale crittografico sensibile?
  • Seleziona le funzionalità di crittografia dei dati per proteggere i dati dei clienti: come, dove e quando crittografare i dati dei clienti in Azure?
  • Selezionare le soluzioni di gestione delle chiavi per proteggere le chiavi dei clienti: quale archivio di chiavi devi usare per proteggere le chiavi di crittografia dei dati utilizzate per crittografare i dati dei clienti in Azure?

Definire i requisiti di gestione delle chiavi

I requisiti per la gestione delle chiavi possono includere requisiti tecnici relativi ai servizi di crittografia utilizzati e requisiti operativi relativi a prestazioni, sicurezza e sovranità. Il punto di partenza consigliato per prendere decisioni su quando e come crittografare i dati nei carichi di lavoro di Azure è il sistema di classificazione dei dati di un'organizzazione. Allineando i requisiti di crittografia alle classificazioni dei dati, anziché a sistemi o soluzioni specifici, le organizzazioni hanno una maggiore flessibilità nel selezionare il livello ottimale di crittografia durante la pianificazione della migrazione dei carichi di lavoro.

Basare i requisiti di crittografia sulla classificazione dei dati consente anche un approccio a più livelli, in cui i carichi di lavoro con criticità inferiore possono trarre vantaggio da soluzioni più semplici riservando al contempo le configurazioni più complesse per carichi di lavoro con un livello di rischio intrinseco più elevato. Un esempio di questo approccio potrebbe essere quello di consentire l'uso di chiavi gestite da Microsoft per crittografare account di archiviazione per ambienti di sviluppo richiedendo al contempo agli account di archiviazione di produzione di utilizzare chiavi di crittografia gestite dai clienti.

Dopo che un'organizzazione ha compreso chiaramente in che modo i requisiti di crittografia sono correlati alle classificazioni dei dati, può iniziare il processo di selezione delle funzionalità per i servizi di Azure che intende utilizzare. Alcune di queste funzionalità possono funzionare in modo diverso rispetto a sistemi locale simili, quindi le organizzazioni sono incoraggiate ad acquisire familiarità con il funzionamento della crittografia in Azure e ad esaminare le raccomandazioni e le procedure consigliate per la progettazione di soluzioni di crittografia. Gli articoli seguenti forniscono ulteriori prospettive su alcune delle scelte tecniche che i clienti devono effettuare e possono rappresentare un utile punto di partenza per avviare una conversazione sugli obiettivi di gestione delle chiavi cloud di un'organizzazione.

Selezionare le funzionalità di crittografia dei dati

Molti servizi di Azure abilitano la crittografia utilizzando chiavi generate, archiviate e gestite interamente da Azure, senza alcuna interazione con i clienti. Queste chiavi gestite dalla piattaforma possono aiutare le organizzazioni a implementare la crittografia con un sovraccarico operativo minimo. Tuttavia, è possibile che i clienti con severi requisiti di sovranità dei dati debbano selezionare funzionalità di crittografia specifiche della piattaforma per proteggere i dati sensibili mentre sono inattivi in un determinato servizio di Azure.

Per i dati altamente sensibili, molti servizi di Azure comunemente usati consentono ai clienti di implementare la doppia crittografia utilizzando chiavi gestite dai clienti. L'implementazione delle chiavi gestite dai clienti nei servizi di Azure può aiutare i clienti a proteggere i dati archiviati in tali servizi da accessi non autorizzati.

L'implementazione di chiavi gestite dai clienti in Azure può aumentare il costo e la complessità di un carico di lavoro, pertanto le organizzazioni sono incoraggiate a valutare la necessità di questa funzionalità per ogni carico di lavoro e livello di classificazione dei dati. L'implementazione di chiavi gestite dai clienti solo per i carichi di lavoro e i tipi di dati che ne hanno bisogno può contribuire a ridurre il sovraccarico operativo per i carichi di lavoro che non gestiscono dati sensibili.

Se sono necessarie chiavi gestite dai clienti, è necessario configurarle per ogni rispettivo servizio di Azure. Le organizzazioni possono contribuire a semplificare le attività di pianificazione della distribuzione o della migrazione stabilendo standard a livello di organizzazione e schemi progettuali ripetibili per l'implementazione di queste funzionalità. Gli articoli seguenti forniscono ulteriori informazioni sulla modalità di configurazione della crittografia dei dati inattivi in Azure:

Scopri come configurare i servizi di Azure di uso comune per crittografare i dati inattivi utilizzando chiavi gestite dai clienti:

Selezionare le soluzioni di gestione delle chiavi

Mentre funzionalità come la doppia crittografia con chiavi gestite dai clienti possono aiutare a proteggere i dati dei clienti conservati nei servizi di Azure, le soluzioni di gestione delle chiavi basate su cloud aiutano a proteggere le chiavi di crittografia e altri materiali crittografici usati per crittografare i dati sensibili. I clienti con severi requisiti di sovranità dei dati devono selezionare una soluzione di gestione delle chiavi adeguata in base alle loro esigenze di garanzia e al profilo di rischio dei loro carichi di lavoro.

I carichi di lavoro che gestiscono dati sensibili potrebbero trarre vantaggio dalla garanzia aggiuntiva fornita da soluzioni come HSM gestito di Azure, inclusi moduli di sicurezza hardware convalidati FIPS-140-2 Livello 3 che dispongono di controlli di sicurezza aggiuntivi per proteggere il materiale crittografico archiviato.

Gli articoli seguenti forniscono linee guida che i clienti possono utilizzare per selezionare un archivio di chiavi appropriato per gli scenari identificati. Fornisce inoltre informazioni su come Microsoft gestisce i servizi di crittografia utilizzati dai clienti nell'ambito della loro soluzione di crittografia.

Modelli operativi per la gestione delle chiavi

Azure Key Vault implementa il controllo degli accessi in base al ruolo in diversi modi, a seconda che si usi il livello Standard/Premium di Azure Key Vault o HSM gestito di Azure Key Vault. Queste differenze nel controllo degli accessi possono influire sul modo in cui un'organizzazione utilizza queste funzionalità. In questa sezione vengono descritte queste differenze e il modo in cui potrebbero influenzare la scelta di un'organizzazione di progettare i propri processi operativi per la gestione delle chiavi cloud.

Vincoli di conformità per la convalida FIPS-140 Livello 3

La convalida FIPS-140 livello 3 richiede l'identificazione dell'operatore basata sull'identità. Queste misure di sicurezza vengono distribuite e convalidate nell'hardware HSM sottostante che supporta i servizi Key Vault in Azure. Di conseguenza, le funzionalità RBAC in Azure Key Vault dipendono dalle funzionalità RBAC dell'hardware sottostante.

HSM gestito di Azure Key Vault sfrutta le assegnazioni RBAC locali implementate a livello di hardware e consente assegnazioni di ruolo nell'ambito del dominio di sicurezza (ad esempio, a livello di HSM) o in base alla chiave. Ciò significa che la creazione della chiave richiede autorizzazioni amministrative sull'intero dominio di sicurezza, poiché non è possibile assegnare autorizzazioni per una chiave che non esiste ancora. L'impatto di questa progettazione è che chiunque abbia bisogno di archiviare una chiave in un'istanza mHSM deve disporre di autorizzazioni complete per tutte le chiavi archiviate in quel dominio di sicurezza oppure richiedere le chiavi a un team centralizzato che dispone delle autorizzazioni necessarie per il dominio di sicurezza. Ciò rappresenta un cambiamento rispetto alle linee guida per Azure Key Vault che consigliano di creare key vault separati per ogni applicazione.

Operazioni di gestione delle chiavi in HSM gestito di Azure Key Vault

Per sviluppare processi operativi per la gestione delle chiavi, i clienti devono determinare se necessitano di HSM gestito di Azure Key Vault come parte dell'architettura della propria soluzione. Le organizzazioni che intendono utilizzare HSM gestito devono innanzitutto acquisire familiarità con i modelli di controllo degli accessi utilizzati per le operazioni di amministrazione e quelle di crittografia e comprendere come viene assegnato il controllo degli accessi in base al ruolo.

Ulteriori informazioni sul controllo degli accessi in HSM gestito:

Le organizzazioni che intendono utilizzare HSM di Azure Key Vault devono esaminare l'elenco dei ruoli RBAC integrati e delle operazioni consentite per HSM gestito e pianificare in modo specifico la gestione dei seguenti scenari operativi:

  • Creazione di una nuova chiave in HSM gestito
  • Operazioni di gestione di una chiave esistente utilizzando il piano di controllo, come aggiornamenti o rotazione delle chiavi
  • Utilizzo del piano dati di una chiave esistente mediante un'applicazione o un servizio

Attualmente, l'unico modo per assegnare le autorizzazioni per creare una nuova chiave è assegnare un ruolo come Crypto User che includa anche altre autorizzazioni come la rotazione e l'eliminazione delle chiavi. Di conseguenza, concedere a un membro del team dell'applicazione le autorizzazioni necessarie per creare le proprie chiavi in HSM gestito può probabilmente violare i principi dei privilegi minimi, poiché quell'utente disporrebbe anche di autorizzazioni amministrative per tutte le chiavi nell'HSM. Questo problema può essere risolto introducendo un team centralizzato con autorizzazioni elevate che possa facilitare le richieste di creazione di chiavi o introducendo un'automazione che possa facilitare nuove richieste di creazione di chiavi attraverso processi di gestione dei servizi IT che sfruttano l'API REST di HSM gestito.

Contenuto correlato