Compreender os fluxos de processo do vSphere Trust Authority é essencial para aprender a configurar e gerenciar sua Infraestrutura Confiável.
Como configurar o vSphere Trust Authority
vSphere Trust Authority não é ativado por padrão. Você deve configurar manualmente o vSphere Trust Authority em seu ambiente. Consulte Configurando vSphere Trust Authority.
Ao configurar o vSphere Trust Authority, você deve especificar quais versões do software do ESXi o Serviço de Atestado aceita e também quais Módulos de Plataforma Confiáveis (TPMs) são confiáveis.
TPM e Atestado em vSphere Trust Authority
Este guia usa as seguintes definições ao discutir TPMs e atestado.
| Prazo | Definição |
|---|---|
| Chave de endosso (EK) | Um TPM é fabricado com um par de chaves pública/privada RSA integrado ao hardware, chamado de chave de endosso (EK). O EK é exclusivo para um determinado TPM. |
| Chave pública EK | A parte pública do par de chaves EK. |
| Chave privada EK | A parte privada do par de chaves EK. |
| Certificado EK | A chave pública EK encapsulada com uma assinatura. O certificado EK é criado pelo fabricante do TPM que usa a chave privada da Autoridade de Certificação para assinar a chave pública EK. Nem todos os TPMs contêm um certificado EK. Nesse caso, a chave pública EK não está assinada. |
| Atestado de TPM | A capacidade do Serviço de Atestado de verificar o software que está sendo executado em um host remoto. O atestado do TPM é realizado por meio de medições criptográficas feitas pelo TPM enquanto o host remoto é iniciado e é retransmitido para o Serviço de Atestado mediante solicitação. O Serviço de Atestado estabelece confiança no TPM por meio da chave pública EK ou do certificado EK. |
Configurando a confiança do TPM nos hosts confiáveis
Um Host Confiável ESXi deve conter um TPM. Um TPM é fabricado com um par de chaves pública/privada integrado ao hardware, chamado de chave de endosso (EK). Embora o TPM 2.0 permita muitos pares de chave/certificado, o mais comum é um par de chaves RSA-2048. Quando uma chave pública do TPM EK é assinada por uma CA, o resultado é o certificado EK. O fabricante do TPM normalmente pré-gera pelo menos um EK, assina a chave pública com uma Autoridade de Certificação e incorpora o certificado assinado na memória não volátil do TPM.
Você pode configurar o Serviço de Atestado para confiar em TPMs da seguinte maneira:
- Confie em todos os certificados de CA com os quais o fabricante assinou o TPM (a chave pública EK). A configuração padrão do Serviço de Atestado é confiar em certificados de autoridade de certificação. Nessa abordagem, o mesmo certificado de CA abrange muitos hosts ESXi e, portanto, reduz a sobrecarga administrativa.
- Confie no certificado de CA TPM do host ESXi e na chave pública EK. O último pode ser o certificado EK ou a chave pública EK. Embora essa abordagem forneça mais segurança, ela exige que você configure as informações sobre cada Host Confiável.
- Alguns TPMs não contêm um certificado EK. Nesse caso, você confia na chave pública EK.
A decisão de confiar em todos os certificados de CA do TPM é operacionalmente conveniente. Você configura novos certificados somente quando adiciona uma nova classe de hardware ao seu centro de dados. Ao confiar em certificados EK individuais, você pode limitar o acesso a hosts ESXi específicos.
Você também pode decidir não confiar em certificados de CA do TPM. Embora seja uma situação incomum, você pode usar essa configuração quando um EK não é assinado por uma CA. Atualmente, essa funcionalidade não está totalmente implementada.
Como o vSphere Trust Authority atesta TPMs
Para iniciar o processo de atestado, o Host Confiável ESXi no Cluster Confiável envia a chave pública EK pré-configurada e o certificado EK para o Serviço de Atestado no Cluster do Trust Authority. Quando o Serviço de Atestado recebe a solicitação, ele procura a EK em sua configuração, que pode ser a chave pública EK ou o certificado EK, ou ambos, dependendo da configuração. Se nenhum caso for válido, o Serviço de Atestado rejeitará a solicitação de atestado.
A EK não é usada diretamente para assinatura, portanto, uma Chave de Atestado (AK ou AIK) é negociada. O protocolo de negociação garante que uma AK recém-criada seja vinculada à EK verificada anteriormente, evitando uma situação de intermediário ou um imitador. Depois que uma AK é negociada, ela é reutilizada em futuras solicitações de atestado, em vez de gerar uma nova a cada vez.
O Host Confiável ESXi lê os valores de cotação e PCR do TPM. A cotação é assinada pelo AK. O Host Confiável ESXi também lê o Log de Eventos do TCG, que inclui todos os eventos que resultaram no estado atual da PCR. Essas informações de TPM são enviadas ao Serviço de Atestado para validação. O Serviço de Atestado verifica os valores de PCR usando o log de eventos.
Como os provedores de chaves funcionam com servidores de chaves
O Serviço de Provedor de Chaves usa o conceito de um provedor de chaves confiável para ocultar as especificidades do servidor de chaves do restante do software do centro de dados. Cada provedor de chave confiável tem uma única chave de criptografia primária configurada e faz referência a um ou mais servidores de chaves. A chave de criptografia primária está presente nos servidores de chaves. Como parte da configuração de vSphere Trust Authority, você deve provisionar a chave primária como uma atividade separada e ativá-la. O Serviço de Provedor de Chaves pode ter vários provedores de chaves confiáveis configurados. Cada provedor de chave confiável usa uma chave primária diferente, mas pode fazer referência ao mesmo servidor de chaves de backup.
Quando um novo provedor de chaves confiável é adicionado, o administrador do Trust Authority deve especificar o servidor de chaves e um identificador de chaves existente nesse servidor de chaves.
A figura a seguir mostra a relação entre o Serviço de Provedor de Chaves e os servidores de chaves.
Depois que você configurar um provedor de chaves confiável para um Cluster Confiável, o Serviço de Provedor de Chaves poderá aceitar solicitações para executar operações criptográficas nesse provedor de chaves confiável. Por exemplo, nesta figura, três provedores de chaves confiáveis estão configurados, dois para KMS-1 e um para KMS-2. O Host Confiável solicita uma operação de criptografia no provedor de chaves-2. O Host Confiável solicita que uma chave de criptografia seja gerada e retornada e usa essa chave de criptografia para realizar operações de criptografia.
O Serviço de Provedor de Chaves usa a chave primária referenciada por key-provider-2 para criptografar os dados de texto sem formatação especificados e retornar o texto criptografado correspondente. Posteriormente, o host confiável pode fornecer o mesmo texto criptografado para uma operação de descriptografia e recuperar o texto sem formatação original.
vSphere Trust Authority Autenticação e autorização
As operações administrativas vSphere Trust Authority requerem um usuário que seja membro do grupo TrustedAdmins. Ter apenas privilégios de administrador do Trust Authority não é suficiente para executar todas as operações administrativas que envolvem os hosts ESXi. Para obter mais informações, consulte Pré-requisitos e privilégios necessários para vSphere Trust Authority.
Adição de um host confiável a um cluster confiável
As etapas para adicionar hosts ESXi inicialmente ao cluster confiável estão descritas em Configurando vSphere Trust Authority.
Posteriormente, se você quiser adicionar hosts ESXi ao cluster confiável, o fluxo de trabalho será diferente. Consulte Adicionando e removendo hosts vSphere Trust Authority.
Ao adicionar inicialmente hosts ESXi ao cluster confiável, você deve coletar as seguintes informações:
- Certificado TPM para cada tipo de hardware no cluster
- imagem ESXi para cada versão de ESXi no cluster
- vCenter Server informações principais
Se mais tarde você adicionar hosts ESXi a um cluster confiável, poderá ser necessário coletar algumas informações adicionais. Ou seja, se os novos hosts ESXi diferirem em hardware ou versão ESXi dos hosts originais, você deverá coletar as informações do novo host ESXi e importá-las para o Cluster do Trust Authority. Você só deve coletar as informações do principal vCenter Server uma vez por sistema vCenter Server.
