Indipendentemente dal provider di chiavi utilizzato, con la Crittografia delle macchine virtuali di vSphere è possibile creare macchine virtuali crittografate e crittografare le macchine virtuali esistenti. Poiché tutti i file della macchina virtuale con informazioni sensibili sono crittografati, la macchina virtuale è protetta. Solo gli amministratori con privilegi di crittografia possono eseguire attività di crittografia e decrittografia.
Che tipo di archiviazione è supportata dalla Crittografia delle macchine virtuali di vSphere
La Crittografia delle macchine virtuali di vSphere funziona con qualsiasi tipo di archiviazione supportata (NFS, iSCSI, Fibre Channel, archiviazione collegata direttamente e così via), incluso VMware vSAN. Per ulteriori informazioni sull'utilizzo della crittografia in un cluster vSAN, vedere la documentazione di Amministrazione di VMware vSAN.
La Crittografia delle macchine virtuali vSphere e vSAN utilizzano le stesse librerie di crittografia, ma hanno profili diversi. La crittografia della macchina virtuale è una crittografia a livello della macchina virtuale e vSAN è una crittografia a livello di datastore.
Chiavi di crittografia e provider di chiavi di vSphere
vSphere utilizza due livelli di crittografia sotto forma di chiave di crittografia chiave (KEK) e chiave di crittografia dati (DEK). In breve, un host ESXi genera una DEK per crittografare macchine virtuali e dischi. La KEK viene fornita da un server delle chiavi e crittografa (o esegue il wrapping) della DEK. La KEK crittografa la DEK utilizzando l'algoritmo AES256 e la DEK crittografa VMDK utilizzando l'algoritmo XTS-AES-256 (dimensioni della chiave 512 bit). In base al tipo di provider di chiavi, vengono utilizzati metodi diversi per creare e gestire DEK e KEK.
- L'host ESXi genera e utilizza chiavi interne per crittografare macchine virtuali e dischi. Queste chiavi vengono utilizzate come DEK.
- vCenter Server richiede le chiavi al server di chiavi (KMS). Queste chiavi vengono utilizzate come KEK. vCenter Server archivia solo l'ID di ogni KEK, ma non la chiave stessa.
- ESXi utilizza la chiave KEK per crittografare le chiavi interne e archivia la chiave interna crittografata sul disco. ESXi non archivia la KEK sul disco. Se un host viene riavviato, vCenter Server richiede la KEK con l'ID corrispondente al server di chiavi e lo mette a disposizione di ESXi. ESXi può pertanto decrittografare le chiavi interne in base alle esigenze.
Il provider di chiavi attendibili vSphere Trust Authority funziona come segue.
- Il vCenter Server del cluster attendibile verifica se il provider di chiavi attendibile predefinito è accessibile all'host ESXi in cui deve essere creata la macchina virtuale crittografata.
- Il vCenter Server del cluster attendibile aggiunge il provider di chiavi attendibile alla macchina virtuale ConfigSpec.
- La richiesta di creazione della macchina virtuale viene inviata all'host ESXi.
- Se un token di attestazione non è già a disposizione dell'host ESXi, ne viene richiesto uno al Servizio di attestazione.
- Il Servizio del provider di chiavi convalida il token di attestazione e crea una KEK da inviare all'host ESXi. La KEK viene crittografata con la chiave primaria configurata sul provider di chiavi. Il testo della crittografia KEK e il testo normale KEK vengono restituiti all'Host attendibile.
- L'host ESXi genera una DEK o chiave di crittografia dati per crittografare i dischi della macchina virtuale.
- KEK viene utilizzato per crittografare la chiave generata dall'host ESXi e il testo cifrato dal provider di chiavi viene archiviato insieme ai dati crittografati.
- La macchina virtuale è criptata e scritta nell'archivio.
Gli host ESXi nei cluster vSphere contengono la KEK per le macchine virtuali crittografate nella memoria dell'host per abilitare le funzionalità di disponibilità come High Availability, vMotion, DRS e così via. Quando si elimina una macchina virtuale o se ne annulla la registrazione, gli host ESXi nel cluster eliminano la KEK dalla loro memoria. Gli host ESXi non possono quindi più utilizzare la KEK. Questo comportamento è lo stesso per i provider di chiavi standard e i provider di chiavi attendibili.
vSphere Native Key Provider funziona come segue.
- Quando si crea il provider di chiavi, vCenter Server genera una chiave primaria ed esegue il push agli host ESXi nel cluster. (Nessun server di chiavi esterno coinvolto.)
- Gli host ESXi generano una DEK su richiesta.
- Quando si esegue un'attività di crittografia, i dati vengono crittografati mediante DEK.
Le DEK crittografate vengono archiviate insieme ai dati crittografati.
- Quando i dati vengono decrittografati, viene utilizzata la chiave primaria per decrittografare la DEK, quindi i dati.
Quali componenti vengono crittografati dalla Crittografia delle macchine virtuali di vSphere?
- File della macchina virtuale
-
La maggior parte dei file delle macchine virtuali, in particolare i dati guest non archiviati nel file VMDK, sono crittografati. Questo set di file include, a titolo esemplificativo e non limitativo, i file NVRAM, VSWP e VMSN. La chiave del provider di chiavi sblocca un bundle crittografato nel file VMX che contiene chiavi interne e altri segreti. Il recupero della chiave funziona come segue, in funzione del provider di chiavi:
- Provider di chiavi standard: vCenter Server gestisce le chiavi provenienti dal server di chiavi e gli host Il ESXi non possono accedere direttamente al provider di chiavi. Gli host attendono che vCenter Server esegua il push delle chiavi.
- Provider di chiavi attendibili e vSphere Native Key Provider: gli host ESXi accedono direttamente ai provider di chiavi, quindi recuperano le chiavi richieste direttamente dal servizio vSphere Trust Authority o dal vSphere Native Key Provider.
- File di disco virtuale
- I dati contenuti in un file di disco virtuale crittografato (VMDK) non vengono mai scritti con testo non crittografato nell'archivio o nel disco fisico e non vengono mai trasmessi in rete con testo non crittografato. Il file descrittore VMDK è principalmente non crittografato, ma contiene un ID chiave per la KEK e la chiave interna (DEK) nel bundle crittografato.
- Dump principali
- I dump principali in un host ESXi in cui è abilitata la modalità di crittografia sono sempre crittografati. Vedere Crittografia delle macchine virtuali vSphere e dump principale. I dump principali nel sistema vCenter Server non sono crittografati. Proteggere l'accesso al sistema vCenter Server.
- File di swap della macchina virtuale
- Il file di swap della macchina virtuale viene crittografato ogni volta che si aggiunge un vTPM a una macchina virtuale. Negli ambienti con RAM insufficiente può verificarsi il paging relativo alla crittografia che può influire sulle prestazioni.
- vTPM
- Quando si configura un vTPM, i file della macchina virtuale vengono crittografati, ma i dischi no. È possibile scegliere di aggiungere la crittografia in modo esplicito per la macchina virtuale e i relativi dischi. Per ulteriori informazioni, vedere Protezione delle macchine virtuali con Trusted Platform Module virtuale.
Quali componenti non vengono crittografati dalla Crittografia delle macchine virtuali di vSphere?
Privilegi necessari per eseguire operazioni crittografiche
Solo gli utenti a cui sono assegnati i privilegi delle Operazioni crittografiche possono eseguire operazioni crittografiche. Il set di privilegi è dettagliato. Il ruolo di amministratore di sistema predefinito include tutti i privilegi delle Operazioni crittografiche. Il ruolo di amministratore senza crittografia supporta tutti i privilegi di amministratore, ad eccezione dei privilegi di Operazioni crittografiche.
Oltre a utilizzare i privilegi Crittografo.*, vSphere Native Key Provider può utilizzare il privilegio Cryptographer.ReadKeyServersInfo, specifico per Provider di chiavi nativi vSphere.
Per ulteriori informazioni, vedere Privilegi delle operazioni crittografiche.
È possibile creare ruoli personalizzati aggiuntivi, ad esempio per consentire a un gruppo di utenti di crittografare le macchine virtuali, impedendo loro tuttavia di decrittografarle.
Come eseguire operazioni crittografiche
Il vSphere Client supporta molte delle operazioni crittografiche. Per altre attività, è possibile utilizzare PowerCLI o vSphere API.
| Interfaccia | Operazioni | Informazioni |
|---|---|---|
| vSphere Client | Creare una macchina virtuale crittografata Crittografare e decrittografare le macchine virtuali Eseguire una ri-crittografia superficiale di una macchina virtuale (utilizzare una KEK diversa) |
Il presente documento |
| PowerCLI | Creare una macchina virtuale crittografata Crittografare e decrittografare le macchine virtuali Configurare vSphere Trust Authority |
Riferimento Cmdlets VMware PowerCLI |
| SDK per vSphere Web Services | Creare una macchina virtuale crittografata Crittografare e decrittografare le macchine virtuali Eseguire una ri-crittografia approfondita di una macchina virtuale (utilizzare una DEK diversa) Eseguire una ri-crittografia superficiale di una macchina virtuale (utilizzare una KEK diversa) |
Guida alla programmazione di vSphere Web Services SDK Riferimento API per Servizi Web di vSphere |
| crypto-util | Decrittografare dump principali crittografati Verificare se i file sono crittografati Eseguire altre attività di gestione direttamente nell'host ESXi |
Guida della riga di comando Crittografia delle macchine virtuali vSphere e dump principale |
Come crittografare nuovamente (ridefinire la chiave) una macchina virtuale crittografata
È possibile crittografare nuovamente (ovvero ridefinire la chiave) una macchina virtuale con nuove chiavi, ad esempio nel caso in cui una chiave scada o venga danneggiata. Sono disponibili le seguenti opzioni per la nuova crittografia.
- Una nuova crittografia superficiale che sostituisce solo la KEK (Key Encryption Key)
- Una nuova crittografia approfondita che sostituisce sia la DEK (Disk Encryption Key) sia la KEK (Key Encryption Key)
Una ri-crittografia approfondita richiede che la macchina virtuale sia spenta e non contenga snapshot. È possibile eseguire un'operazione di riesecuzione della crittografia superficiale se la macchina virtuale è accesa e se sono presenti snapshot nella macchina virtuale. Una nuova crittografia superficiale di una macchina virtuale crittografata con snapshot è consentita solo in un singolo ramo di snapshot (catena di dischi). I rami di snapshot multipli non sono supportati. Inoltre, una ri-crittografia superficiale non è supportata in un clone collegato di una macchina virtuale o di un disco. Se la nuova crittografia superficiale produce un errore prima che vengano aggiornati tutti i collegamenti nella catena con la nuova KEK, sarà comunque possibile accedere alla macchina virtuale crittografata se sono presenti le KEK nuove e quelle precedenti. Tuttavia, è meglio eseguire nuovamente l'operazione di ri-crittografia superficiale prima di eseguire qualsiasi operazione di snapshot.
È possibile eseguire la ridefinizione della chiave di una macchina virtuale utilizzando vSphere Client, la CLI o l'API. Vedere Ridefinizione della chiave di una macchina virtuale crittografata mediante vSphere Client, Ridefinizione della chiave di una macchina virtuale crittografata mediante la CLI e Guida alla programmazione di vSphere Web Services SDK.
