Sobre a criptografia vSAN

A criptografia de dados em repouso do vSAN requer um sistema de gerenciamento de chaves (KMS). Por padrão, o gerenciamento de chaves para criptografia de dados vSAN no Google Cloud VMware Engine usa Cloud Key Management Service para novas nuvens privadas sem custo adicional.

Você pode implantar um KMS externo para a criptografia de dados vSAN em repouso dos seguintes fornecedores compatíveis. Nesta página, explicamos o comportamento da criptografia vSAN e resumimos como usar um KMS externo para criptografar dados de máquina virtual em repouso no VMware Engine.

Se você usar uma solução de KMS de terceiros, será necessário fornecer as licenças necessárias.

Criptografia de dados vSAN

Por padrão, o VMware Engine ativa a criptografia vSAN para dados no cluster principal e em clusters adicionados depois à nuvem privada. A criptografia de dados em vSAN em repouso usa uma chave de criptografia de dados (DEK) armazenada no disco físico local do cluster após a criptografia. Os hosts ESXi geram automaticamente a DEK, que é uma chave de criptografia AES-256 bits compatível com FIPS 140-2 nível 1. Uma chave de criptografia de chaves (KEK, na sigla em inglês) fornecida pelo Google-owned and managed key provedor criptografa a DEK.

O Google recomenda não desativar a criptografia vSAN de dados em repouso, já que isso pode violar os termos específicos do serviço para o Google Cloud VMware Engine. Quando você desativa a criptografia vSAN de dados em repouso em um cluster, a lógica de monitoramento do VMware Engine gera um alerta. Para ajudar a evitar que você viole os termos de serviço, esse alerta aciona uma ação orientada ao Cloud Customer Care para reativar a criptografia vSAN no cluster afetado.

Da mesma forma, se você configurar um KMS externo, o Google recomenda não excluir a configuração do provedor de chaves do Cloud Key Management Service no servidor vCenter.

Provedor de chaves padrão

O VMware Engine configura o servidor vCenter em novas nuvens privadas para se conectar a um Google-owned and managed key provedor. O VMware Engine cria uma instância do provedor de chaves por região, e o provedor de chaves usa o Cloud KMS para criptografar a KEK. O VMware Engine gerencia totalmente o provedor de chaves e o configura para ser altamente disponível em todas as regiões.

O Google-owned and managed key provedor complementa o provedor de chaves integrado no servidor vCenter (no vSphere 7.0 atualização 2 e versões mais recentes) e é a abordagem recomendada para ambientes de produção. O provedor de chaves integrado é executado como um processo no servidor vCenter, que é executado em um cluster do vSphere no VMware Engine. O VMware recomenda o uso do provedor de chaves integrado para criptografar o cluster que hospeda o servidor vCenter. Em vez disso, use um provedor de chaves padrão gerenciado pelo Google ou um KMS externo.

Rotação de chaves

Ao usar o provedor de chaves padrão, você é responsável pela rotação da KEK. Para alternar a KEK no vSphere, consulte a documentação do VMware Gerar novas chaves de criptografia de dados em reposto.

Veja outras maneiras de fazer a rotação de uma chave no vSphere nos seguintes recursos do VMware:

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 (re-chave superficial) cada VM depois de alternar a chave do KMS.

Uma re-chave superficial substitui apenas a chave de criptografia de chaves (KEK) e não altera a chave de criptografia de dados (DEK) das VMs. Normalmente, você aciona uma re-chave superficial usando a ação Recriptografar no cliente vSphere.

Durante essa operação, o sistema recriptografa a DEK atual usando uma nova KEK. Esse processo é rápido porque não reescreve 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:

Riscos de não recriptografar VMs

Não recriptografar VMs antes de excluir a versão da chave 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 KMS, mas antes de executar a re-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 re-chave em VMs de carga de trabalho

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

Fornecedores compatíveis

Para alternar o seu KMS ativo, selecione uma solução de KMS de terceiros que esteja em conformidade com o KMS 1.1 e seja certificada pelo VMware para vSAN. Os seguintes fornecedores validaram as soluções KMS com o VMware Engine e publicaram guias de implantação e declarações de suporte:

Veja instruções de configuração nos seguintes documentos:

Usar um fornecedor com suporte

Cada implantação de um KMS externo requer as mesmas etapas básicas:

  • Crie um Google Cloud projeto ou use um atual.
  • Crie uma nova nuvem particular virtual (VPC) ou escolha uma rede VPC existente.
  • Conecte a rede VPC selecionada à rede do VMware Engine.

Em seguida, implante o KMS em uma instância de VM do Compute Engine:

  1. Configure as permissões necessárias do IAM para implantar instâncias de VM do Compute Engine.
  2. Implante o KMS no Compute Engine.
  3. Estabeleça confiança entre o vCenter e o KMS.
  4. Ative a criptografia de dados vSAN.

As seções a seguir descrevem brevemente esse processo de uso de um dos fornecedores compatíveis.

Configurar permissões do IAM

É preciso ter permissões suficientes para implantar instâncias de VM do Compute Engine em um determinado Google Cloud projeto e rede VPC, para conectar a VPC ao VMware Engine e para configurar regras de firewall para a VPC.

Proprietários de projetos e principais do IAM com o papel de administrador de rede podem criar intervalos de IP alocados e gerenciar conexões particulares. Para mais informações sobre papéis, consulte Papéis do IAM do Compute Engine.

Implantar o sistema de gerenciamento de chaves no Compute Engine

Algumas soluções do KMS estão disponíveis em um formato de dispositivo no Google Cloud Marketplace. É possível implantar esses dispositivos ao importar a OVA diretamente na sua rede VPC ou Google Cloud projeto.

Para um KMS baseado em software, implante uma instância de VM do Compute Engine usando a configuração (contagem de vCPU, vMem e discos) recomendada pelo fornecedor do KMS. Instale o software KMS no sistema operacional convidado. Crie a instância de VM do Compute Engine em uma rede VPC conectada à rede do VMware Engine.

Estabelecer confiança entre o vCenter e o KMS

Depois de implantar o KMS no Compute Engine, configure o vCenter do VMware Engine para recuperar chaves de criptografia do KMS.

Para recuperar chaves de criptografia, estabeleça confiança entre o vCenter e o KMS fazendo o seguinte:

  1. Gere um certificado no vCenter.
  2. Assine o certificado usando um token ou uma chave gerada pelo KMS.
  3. Faça upload do certificado assinado para o vCenter.
  4. Verifique o status de conectividade na página de configuração do servidor vCenter.

Ativar criptografia de dados vSAN

No vCenter, o usuário CloudOwner padrão tem privilégios suficientes para ativar e gerenciar a criptografia de dados vSAN.

Para mudar de um KMS externo para o provedor Google-owned and managed key padrão, siga as etapas para alterar o provedor de chaves fornecido na documentação do VMware Como configurar e gerenciar um provedor de chaves padrão.

A seguir