La comprensione dei flussi di processo di vSphere Trust Authority è essenziale per apprendere come configurare e amministrare l'infrastruttura attendibile.
Come si configura vSphere Trust Authority
vSphere Trust Authority non è attivata per impostazione predefinita. È necessario configurare manualmente vSphere Trust Authority nell'ambiente. Vedere Configurazione di vSphere Trust Authority.
Quando si configura vSphere Trust Authority, è necessario specificare le versioni del software ESXi che il Servizio di attestazione accetta e quali TPM (Trusted Platform Module) sono attendibili.
TPM e attestazione in vSphere Trust Authority
Questa guida utilizza le seguenti definizioni in materia di TPMs e attestazione.
| Termine | Definizione |
|---|---|
| Chiave di verifica dell'autenticità (EK) | Un TPM è prodotto con una coppia di chiavi pubblica/privata RSA integrata nell'hardware, denominata chiave di verifica dell'autenticità (EK). EK è univoco per un TPM specifico. |
| Chiave pubblica EK | La parte pubblica della coppia di chiavi EK. |
| Chiave privata EK | La parte privata della coppia di chiavi EK. |
| Certificato EK | La chiave pubblica EK soggetta a wrapping con una firma. Il certificato EK viene creato dal produttore di TPM che utilizza la chiave privata dell'Autorità di certificazione per firmare la chiave pubblica EK. Non tutte le TPM contengono un certificato EK. In questo caso, la chiave pubblica EK non è firmata. |
| Attestazione TPM | La capacità del Servizio di attestazione di verificare il software in esecuzione in un host remoto. L'attestazione TPM viene eseguita tramite le misure crittografiche effettuate da TPM durante l'avvio dell'host remoto, e viene inoltrata al Servizio di attestazione su richiesta. Il Servizio di attestazione stabilisce l'attendibilità nel TPM tramite la chiave pubblica EK o il certificato EK. |
Configurazione dell'attendibilità TPM sugli Host attendibili
Un Host attendibile ESXi deve contenere un TPM. Un TPM è prodotto con una coppia di chiavi pubblica/privata integrata nell'hardware, denominata chiave di verifica dell'autenticità (EK). Anche se TPM 2.0 consente molte coppie di chiavi/certificati, la più comune è una coppia di chiavi RSA-2048. Quando una chiave pubblica EK TPM viene firmata da una CA, il risultato è il certificato EK. Il produttore TPM in genere genera almeno un EK, firma la chiave pubblica con un'Autorità di certificazione e incorpora il certificato firmato nella memoria non volatile del TPM.
È possibile configurare il Servizio di attestazione in modo che consideri attendibili i TPM come indicato di seguito:
- Considerare attendibili tutti i certificati CA con cui il produttore ha firmato il TPM (la chiave pubblica EK). L'impostazione predefinita per il Servizio di attestazione prevede che consideri attendibili i certificati CA. In questo approccio, lo stesso certificato CA copre molti host ESXi e riduce quindi le spese generali amministrative.
- Considerare attendibile il certificato CA TPM dell'host ESXi e la chiave pubblica EK. Quest'ultima può essere il certificato EK o la chiave pubblica EK. Sebbene questo approccio fornisca maggiore sicurezza, richiede la configurazione delle informazioni su ciascun Host attendibile.
- Alcuni TPM non contengono un certificato EK. In questo caso, si considera attendibile la chiave pubblica EK.
Decidere di considerare attendibili tutti i certificati CA TPM è comodo dal punto di vista operativo. I nuovi certificati vengono configurati solo quando si aggiunge una nuova classe di hardware al data center. Attraverso la considerazione dei singoli certificati EK come attendibili, è possibile limitare l'accesso a host ESXi specifici.
È inoltre possibile decidere di non considerare attendibili i certificati CA TPM. Sebbene non sia una situazione comune, è possibile utilizzare questa configurazione quando un profilo EK non è firmato da una CA. Attualmente questa funzionalità non è pienamente implementata.
In che modo vSphere Trust Authority attesta i TPM
Per avviare il processo di attestazione, l'Host attendibile ESXi nel cluster attendibile invia la chiave pubblica EK preconfigurata e il certificato EK al Servizio di attestazione nel cluster Trust Authority. Quando il Servizio di attestazione riceve la richiesta, cerca l'EK nella sua configurazione, che può essere la chiave pubblica EK, il certificato EK o entrambi, in base alla configurazione. Se nessun caso è valido, il servizio di attestazione rifiuta la richiesta di attestazione.
L'EK non viene utilizzato direttamente per la firma, per cui viene negoziata una chiave di attestazione (AK o AIK). Il protocollo di negoziazione garantisce che un AK appena creato sia associato all'EK verificato in precedenza, impedendo una situazione man-in-the-middle o una rappresentazione. Dopo la negoziazione, un AK viene riutilizzato nelle richieste di attestazione future, anziché generarne uno nuovo ogni volta.
L'Host attendibile ESXi legge i valori di Preventivo e PCR da TPM. Il Preventivo viene firmato dall'AK. L'Host attendibile ESXi legge anche il Registro eventi TCG, che include tutti gli eventi che hanno determinato lo stato corrente di PCR. Le informazioni TPM vengono inviate al Servizio di attestazione per la convalida. Il Servizio di attestazione verifica i valori di PCR utilizzando il registro eventi.
Come funzionano i provider di chiavi con i server delle chiavi
Il Servizio del provider di chiavi utilizza il concetto di provider di chiavi attendibile per nascondere le specifiche del server chiavi dal resto del software del data center. Ogni provider di chiavi attendibile ha una singola chiave di crittografia primaria configurata e fa riferimento a uno o più server di chiavi. La chiave di crittografia primaria è presente nei server delle chiavi. Come parte della configurazione di vSphere Trust Authority, è necessario eseguire il provisioning della chiave primaria come attività separata e attivarla. Nel servizio del provider di chiavi possono essere configurati diversi provider di chiavi attendibili. Ogni provider di chiavi attendibile utilizza una chiave primaria diversa, ma può fare riferimento allo stesso server chiavi di supporto.
Quando viene aggiunto un nuovo provider di chiavi attendibile, l'amministratore di Trust Authority deve specificare il server di chiavi e un identificatore della chiave esistente in tale server.
Nella figura seguente viene illustrata la relazione tra il Servizio del provider di chiavi e i server chiavi.
Dopo aver configurato un provider di chiavi attendibile per un cluster attendibile, il Servizio del provider di chiavi può accettare richieste di esecuzione di operazioni crittografiche rispetto a tale provider di chiavi attendibile. Ad esempio, in questa figura, sono configurati tre provider di chiavi attendibili, due per KMS-1 e uno per KMS-2. L'Host attendibile richiede un'operazione di crittografia rispetto a key-provider-2. L'Host attendibile richiede la generazione e la restituzione di una chiave di crittografia e la utilizza per eseguire operazioni di crittografia.
Il Servizio del provider di chiavi utilizza la chiave primaria a cui fa riferimento key-provider-2 per crittografare i dati in testo normale specificati e restituire il testo cifrato corrispondente. In seguito, l'Host attendibile può fornire lo stesso testo di crittografia a un'operazione di decrittografia e recuperare il testo normale originale.
vSphere Trust Authority autenticazione e autorizzazione
vSphere Trust Authority le operazioni amministrative richiedono che l'utente sia membro del gruppo TrustedAdmins. La presenza solo di privilegi di amministratore di Trust Authority non è sufficiente per eseguire tutte le operazioni amministrative che interessano gli host ESXi. Per ulteriori informazioni, vedere Prerequisiti e privilegi necessari per vSphere Trust Authority.
Aggiunta di un host attendibile a un cluster attendibile
I passaggi per aggiungere inizialmente host ESXil Cluster attendibile sono descritti in Configurazione di vSphere Trust Authority.
In seguito, se si desidera aggiungere host ESXi al Cluster attendibile, il workflow è diverso. Vedere Aggiunta e rimozione di host vSphere Trust Authority.
Quando si aggiungono inizialmente host ESXi al cluster attendibile, è necessario raccogliere le seguenti informazioni:
- Certificato TPM per ogni tipo di hardware nel cluster
- Immagine di ESXi per ogni versione di ESXi nel cluster
- Informazioni entità vCenter Server
Se in un secondo momento si aggiungono host ESXi a un Cluster attendibile, potrebbe essere necessario raccogliere alcune informazioni aggiuntive. Ciò significa che, se i nuovi host ESXi differiscono nell'hardware o nella versione ESXi dagli host originali, è necessario raccogliere le nuove informazioni sugli host ESXi e importarle nel cluster Trust Authority. È necessario raccogliere le informazioni entità vCenter Server una sola volta per ogni sistema vCenter Server.
