Sobre o módulo de plataforma confiável virtual

Um módulo de plataforma confiável virtual (vTPM, na sigla em inglês) é uma representação baseada em software de um bloco de plataforma confiável física (TPM, na sigla em inglês) 2.0. Com o recurso vTPM, você pode adicionar um criptoprocessador virtual TPM 2.0 a uma máquina virtual. O Google Cloud VMware Engine oferece suporte a vTPMs.

É possível usar o provedor de chaves padrão, o Cloud Key Management Service ou um KMS externo para criar vTPMs. Recomendamos configurar o provedor de chaves como o padrão no vCenter antes de criar um vTPM.

Como adicionar vTPMs às VMs

É possível adicionar vTPMs às VMs incluindo o dispositivo virtual "Trusted Platform Module" na VM. Consulte Perguntas e respostas sobre o vTPM virtual do vSphere (vTPM, link em inglês) para mais informações.

Criptografia de vTPM e VM para VMs de carga de trabalho

As VMs de carga de trabalho usam uma semente interna armazenada no módulo de plataforma confiável virtual (vTPM) para criptografar dados de carga de trabalho. Ao adicionar um vTPM, o sistema criptografa os arquivos de origem da VM por padrão, mas não inclui os discos da máquina virtual (VMDKs). Para criptografar os VMDKs, é necessário fazer isso separadamente.

Armazenamento de dados e pré-requisitos

O sistema armazena dados de vTPM no arquivo NVRAM no diretório inicial da VM, junto com outros metadados da VM. Para usar o vTPM, é necessário atender ao seguinte requisito:

  • Configurar um provedor de chaves: é necessário configurar um provedor de chaves porque a funcionalidade vTPM exige a criptografia de VM. A criptografia de VM protege os dados de vTPM no diretório inicial da VM.

Principais considerações para a nova chave de VMs com vTPM

A nova chave de uma VM com um dispositivo vTPM atualiza apenas a chave de criptografia que protege os dados de vTPM no diretório inicial da VM. Não é possível mudar a semente em um vTPM após a instanciação.

  • Ao adicionar um dispositivo vTPM a uma VM, o dispositivo gera uma semente interna. Os aplicativos em execução no sistema operacional convidado podem usar essa semente para gerar secrets ou chaves de criptografia para proteger os dados do aplicativo.
  • Separadamente, a ativação do vTPM em uma VM exige a criptografia de arquivos de VM que usa um provedor de chaves externo. A criptografia de VMDK é opcional e desativada por padrão.
  • A chave de criptografia do provedor de chaves externo criptografa os arquivos de VM (e os VMDKs, se você ativou a criptografia). Essa chave é separada da semente armazenada no dispositivo vTPM ou das chaves que os aplicativos geram usando essa semente.
  • É necessário configurar o provedor de chaves externo como o padrão no vCenter.
  • A nova criptografia de uma VM com um dispositivo vTPM criptografa novamente os arquivos de VM (e os VMDKs, se você ativou a criptografia) usando uma nova chave de criptografia do provedor de chaves externo. Essa operação não afeta a semente ou os secrets armazenados no dispositivo vTPM.

Requisito para máquinas virtuais criptografadas

É possível gerenciar chaves de criptografia para VMs usando o provedor padrão Google-owned and managed key ou o Cloud Key Management Service.

Se você ativar a criptografia de VM (ou vTPM) para qualquer VM na sua nuvem privada e usar um KMS para gerenciar chaves de criptografia, será necessário criptografar novamente (nova chave superficial) cada VM depois de alternar a chave do KMS.

Uma nova chave superficial substitui apenas a chave de criptografia de chaves (KEK) e não muda a chave de criptografia de dados (DEK) das VMs. Normalmente, você aciona uma nova chave superficial usando a ação Criptografar novamente no vSphere Client.

Durante essa operação, o sistema envolve novamente (criptografa novamente) a DEK atual usando uma nova KEK. Esse processo é rápido porque não reescreve os dados reais no disco. Em vez disso, ele apenas atualiza o pequeno pacote de chaves que contém a DEK criptografada. Para mais informações, consulte a seguinte documentação do VMware (links em inglês):

Riscos de não criar uma nova chave de VMs criptografadas

Não criar uma nova chave de VMs criptografadas antes de excluir a versão da chave do KMS alternada (antiga) pode causar os seguintes problemas:

  • Falha nas vMotions: os hosts ESXi não podem descriptografar DEKs de VM durante a vMotion se você reiniciar os hosts de destino ou adicioná-los ao cluster após a rotação da chave do KMS, mas antes de executar a nova chave da VM.
  • Falhas de ativação: se um host for reinicializado ou limpar o cache de chaves local, ele não poderá readquirir chaves do KMS. Se você excluiu as chaves necessárias do KMS, o host não poderá descriptografar a DEK, o que impede que as VMs criptografadas sejam ativadas.

Etapas para executar uma operação de nova chave em VMs de carga de trabalho

  1. No vSphere Client, clique com o botão direito do mouse na VM.
  2. Selecione Políticas de VM > Criptografar novamente.
  3. Confirme a solicitação de nova criptografia na caixa de diálogo exibida.
  4. Aguarde a conclusão da tarefa.
  5. Verifique a nova chave migrando a VM para um host que você reinicializou ou adicionou ao cluster após a rotação de chaves do KMS.