Visão geral sobre malha protegida e VMs blindadas

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

A segurança de virtualização é uma área de grande investimento no Hyper-V. Além de proteger hosts ou outras máquinas virtuais de uma máquina virtual que está executando software mal-intencionado, também é necessário proteger as máquinas virtuais de um host comprometido. Isso é um perigo fundamental para cada plataforma de virtualização hoje, seja Hyper-V, VMware ou qualquer outra. Se uma máquina virtual fica fora de uma organização (seja por más intenções ou acidentalmente), essa máquina virtual pode ser executada em qualquer outro sistema. Proteger os ativos de alto valor na sua organização, como controladores de domínio, servidores de arquivos confidenciais e sistemas de RH, é uma prioridade.

Para ajudar a proteger contra a malha de virtualização comprometida, o Hyper-V do Windows Server 2016 apresentou VMs blindadas. Uma VM blindada é uma VM de geração 2 (com suporte no Windows Server 2012 e versões posteriores) que tem um TPM virtual, é criptografada com BitLocker só pode ser executada em hosts íntegros e aprovados na malha. As VMs blindadas e as malhas protegidas permitem que os provedores de serviço de nuvem ou administradores de nuvens privadas empresariais forneçam um ambiente mais seguro para VMs locatárias.

Uma malha protegida consiste em:

• 1 HGS (Serviço Guardião de Host) (normalmente, um cluster de 3 nós).
• 1 ou mais hosts protegidos.
• Um conjunto de máquinas virtuais blindadas. O diagrama a seguir mostra como o Serviço Guardião de Host usa atestado para garantir que somente hosts válidos e conhecidos possam iniciar as VMs blindadas e a proteção de chave para liberar com segurança as chaves para as VMs blindadas.

Quando um locatário cria VMs blindadas que são executadas em uma malha protegida, os hosts Hyper-V e as VMs blindadas em si são protegidas pelo HGS. O HGS fornece dois serviços distintos: atestado e proteção de chave. O serviço de Atestado garante que somente os hosts Hyper-V confiáveis possam executar VMs blindadas enquanto o Serviço de Proteção de Chave fornece as chaves necessárias para ativá-las e para migrá-las ao vivo para outros hosts protegidos.

Para saber mais, confira este vídeo na Introdução às máquinas virtuais blindadas.

Modos de Atestado na solução de malha protegida

O HGS é compatível com modos diferentes de atestado para uma malha protegida:

• Atestado de TPM confiável (baseado no hardware)
• Atestado de chave de host (com base em pares de chaves assimétricas)

O Atestado de TPM confiável é recomendado porque oferece garantias mais fortes, conforme explicado na tabela a seguir, mas exige que os hosts do Hyper-V tenham TPM 2.0. Se você atualmente não tiver o TPM 2.0 ou qualquer TPM, poderá usar o atestado de chave de host. Se decidir mover de Atestado de TPM confiável ao adquirir novo hardware, você poderá alternar o modo de atestado do Serviço Guardião de Host com pouca ou nenhuma interrupção para sua malha.

Modo de atestado escolhido para hosts	Garantias de host
Atestado de TPM confiável: oferece as proteções mais fortes de possíveis, mas também exigem mais etapas de configuração. O firmware e o hardware do host devem incluir TPM 2.0 e UEFI 2.3.1 com Inicialização Segura habilitada.	Os hosts protegidos são aprovados de acordo com sua identidade TPM, a sequência de Inicialização Medida e as políticas de integridade de código para garantir que eles só executem o código aprovado.
Atestado de chave de host: destinado a dar suporte a hardware de host existente, onde o TPM 2.0 não está disponível. Requer menos etapas de configuração e é compatível com o hardware de servidor comum.	Os hosts protegidos são aprovados de acordo com a posse de uma chave.

Outro modo chamado Atestado confiável do administrador foi preterido do Windows Server 2019 em diante. Esse modo foi baseado na associação de host protegido em um grupo de segurança designado do AD DS (Active Directory Domain Services). O atestado de chave de host fornece identificação de host semelhante e é mais fácil de configurar.

As garantias fornecidas pelo Serviço Guardião de Host

HGS, junto com os métodos para a criação de VMs blindadas, ajudam a fornecer as seguintes garantias.

Tipo de garantia para VMs	Garantias de VMs blindadas, do Serviço de Proteção de Chave e de métodos de criação para VMs blindadas
Discos criptografados por BitLocker (discos do sistema operacional e discos de dados)	VMs blindadas usam o BitLocker para proteger seus discos. As chaves de BitLocker necessárias para inicializar a VM e descriptografar os discos são protegidas pelo TPM virtual da VM blindada, usando tecnologias comprovadas do setor como a inicialização medida protegida. Embora as VMs blindadas apenas criptografem e protejam automaticamente o disco do sistema operacional, você também poderá criptografar unidades de dados anexadas à VM blindada.
Implantação de novas VMs blindadas de discos/imagens de modelo "confiável"	Ao implantar novas VMs blindadas, os locatários são capazes de especificar em quais discos modelo confiam. Os discos modelos blindados têm assinaturas que são calculadas em um ponto no tempo quando seu conteúdo é considerado confiável. As assinaturas do disco são armazenadas em um catálogo de assinatura, que locatários fornecem com segurança à malha ao criar VMs blindadas. Durante o provisionamento das VMs blindadas, a assinatura do disco é computada novamente e comparada com as assinaturas confiáveis no catálogo. Se as assinaturas forem correspondentes, a máquina virtual blindada estará implantada. Se as assinaturas não corresponderem, o disco de modelo blindado será considerado não confiável e haverá falha na implantação.
Proteção de senhas e outros segredos quando uma máquina virtual blindada é criada	Ao criar VMs, é necessário garantir que os segredos de VM, como as assinaturas de disco confiáveis, certificados RDP e a senha da conta de administrador local da VM, não sejam divulgados à malha. Esses segredos são armazenados em um arquivo criptografado chamado de arquivo de dados de blindagem (um arquivo .PDK), que é protegido por chaves de locatário e carregado para a malha pelo locatário. Quando uma máquina virtual blindada é criada, o locatário seleciona os dados de blindagem para usar que fornece com segurança esses segredos somente para os componentes confiáveis na malha protegida.
Controle de locatário de onde a VM pode ser iniciada	Os dados de blindagem também contêm uma lista das malhas protegidas nas quais uma VM blindada específica tem permissão para executar. Isso é útil, por exemplo, em casos em que uma máquina virtual blindada geralmente reside em uma nuvem privada local, mas talvez precise ser migrada para outra nuvem (pública ou privada) para fins de recuperação de desastres. A malha ou nuvem de destino deve suportar VMs blindadas e a VM blindada deve permitir que a malha a execute.

O que são dados de blindagem e por que isso é necessário?

Um arquivo de dados de blindagem (também chamado de um arquivo de dados de provisionamento ou arquivo PDK) é um arquivo criptografado que um locatário ou proprietário de VM cria para proteger as informações de configuração de VM importantes, como a senha do administrador, RDP e outros certificados relacionados à identidade, credenciais de associação de domínio e assim por diante. Um administrador de malha usa o arquivo de dados de blindagem ao criar uma máquina virtual blindada, mas não consegue exibir ou usar as informações contidas no arquivo.

Entre outros, os arquivos de dados de blindagem contêm segredos como:

• Credenciais do administrador
• Um arquivo de resposta (unattend.xml)
• Uma política de segurança que determina se as VMs criadas usando esses dados de blindagem são configuradas como blindadas ou com suporte para criptografia
  • Lembre-se de que VMs configuradas como blindadas são protegidas contra administradores de malha, enquanto que as VMs com suporte de criptografia não são
• Um certificado RDP para proteger a comunicação da área de trabalho remota com a máquina virtual
• Um catálogo de assinatura de volume que contém uma lista de assinaturas de disco modelo confiável e assinada a partir da qual uma nova VM tem permissão para ser criada
• Um protetor de chave (ou KP) que define em quais malhas protegidas uma máquina virtual blindada está autorizada a executar

O arquivo de dados de blindagem (arquivo PDK) fornece garantias de que a VM será criada da maneira que locatário desejava. Por exemplo, quando o locatário coloca um arquivo de resposta (unattend.xml) no arquivo de dados de blindagem e o entrega para o provedor de hospedagem, o provedor de hospedagem não pode exibir ou fazer alterações nesse arquivo de resposta. Da mesma forma, o provedor de hospedagem não pode substituir um VHDX diferente ao criar a VM blindada, porque o arquivo de dados de blindagem contém as assinaturas dos discos confiáveis a partir das quais as VMs blindadas podem ser criadas.

A figura a seguir mostra o arquivo de dados de blindagem e os elementos de configuração relacionados.

Quais são os tipos de máquinas virtuais que podem ser executados por uma malha protegida?

Malhas protegidas são capazes de executar VMs de três maneiras:

1. Uma VM normal que não oferece proteções além de versões anteriores do Hyper-V
2. Uma VM com suporte para criptografia cujas proteções podem ser configuradas por um administrador de malha
3. Uma VM blindada cujas proteções estão todas ligadas e não podem ser desabilitadas por um administrador de malha

VMs com suporte para criptografia destinam-se ao uso onde os administradores da malha são totalmente confiáveis. Por exemplo, uma empresa pode implantar uma malha protegida para garantir que os discos de VM estejam criptografados em repouso para fins de conformidade. Os administradores da malha podem continuar a usar os recursos de gerenciamento convenientes, por exemplo, conexões de console de VM, PowerShell Direct e outras ferramentas de gerenciamento e solução de problemas diários.

As VMs blindadas destinam-se ao uso em malhas onde os dados e o estado da máquina virtual devem ser protegidas dos administradores de malha e de softwares não confiáveis que possam estar em execução nos hosts do Hyper-V. Por exemplo, VMs blindadas nunca permitirão uma conexão de console da máquina virtual, enquanto que um administrador de malha pode ativar ou desativar essa proteção para VMs de criptografia compatíveis.

A tabela a seguir resume as diferenças entre VMs blindadas e compatíveis com criptografia.

Funcionalidade	Suporte à criptografia de geração 2	Blindado de geração 2
Inicialização Segura	Sim, obrigatória mas configurável	Sim, obrigatória e imposta
Vtpm	Sim, obrigatória mas configurável	Sim, obrigatória e imposta
Criptografar o estado da VM e o tráfego da migração ao vivo	Sim, obrigatória mas configurável	Sim, obrigatória e imposta
Componentes de integração	Configurável pelo administrador da malha	Alguns componentes de integração bloqueados (por exemplo, troca de dados, PowerShell Direct)
Conexão de máquina virtual (Console), dispositivos HID (por exemplo, teclado, mouse)	Ativado, não pode ser desabilitado	Habilitado nos hosts que começam com o Windows Server versão 1803; desabilitado em hosts anteriores
Portas seriais/COM	Com suporte	Desabilitado (não pode ser habilitado)
Anexar um depurador (ao processo de VM)1	Com suporte	Desabilitado (não pode ser habilitado)

¹ No entanto, os depuradores tradicionais que anexam diretamente a um processo, como WinDbg.exe, são bloqueados para VMs blindadas porque o VMWP.exe (processo de trabalho da VM) é um PPL (leve do processo protegido). Técnicas de depuração alternativas, como as usadas pelo LiveKd.exe, não são bloqueadas. Ao contrário das VMs blindadas, o processo de trabalho para VMs com suporte de criptografia não é executado como PPL, de modo que depuradores tradicionais, como WinDbg.exe, continuarão funcionando normalmente.

As VMs blindadas e as VMs com suporte à criptografia continuam a oferecer suporte a recursos de gerenciamento de malha comuns, como migração ao vivo, réplica do Hyper-V, pontos de verificação de máquina virtual e assim por diante.

O Serviço Guardião de Host em ação: como uma máquina virtual blindada é ligada

1. VM01 está ligado. Para que um host protegido possa ligar uma VM blindada, ele deverá primeiro ser atestado afirmativamente de que está íntegro. Para provar que está íntegro, ele deverá apresentar um certificado de integridade para o KPS (Serviço de Proteção de Chave). O certificado de integridade é obtido através do processo de atestado.

2. Hosts exigem atestado. O host protegido exige atestado. O modo de atestado é determinado pelo Serviço Guardião de Host:

   • Atestado de TPM confiável: o host do Hyper-V envia informações que incluem:

     • Informações de identificação do TPM (sua chave de endosso)

     • Informações sobre os processos que foram iniciados durante a sequência de inicialização mais recente (o log do TCG)

     • Informações sobre a política de CI (Integridade de Código) que foi aplicada no host.

       O atestado acontece quando o host é iniciado e a cada 8 horas. Se por algum motivo um host não tiver um certificado de atestado quando uma VM tentar iniciar, isso também vai disparar o atestado.

   • Atestado de chave de host: o host do Hyper-V envia a metade pública do par de chaves. O HGS valida se a chave de host está registrada.

   • Atestado de admin confiável: o host do Hyper-V envia um tíquete Kerberos, que identifica os grupos de segurança em que o host está. O HGS valida que o host pertence a um grupo de segurança que foi configurado anteriormente pelo administrador de HGS confiável.

3. O atestado tem êxito (ou falha). O modo de atestado determina quais verificações são necessárias para atestar com êxito que o host está íntegro. Com o atestado de TPM confiável, a identidade de TPM, as medidas de inicialização e a política de integridade de código do host são válidas. Com o atestado de chave de host, somente o registro da chave de host é válido.

4. Certificado de atestado enviado ao host. Supondo que o atestado tenha sido bem-sucedido, um certificado de integridade é enviado para o host e o host é considerado "protegido" (autorizado a executar VMs blindadas). O host usa o certificado de integridade para autorizar o Serviço de Proteção de Chave para liberar com segurança as chaves necessárias para trabalhar com VMs blindadas

5. O host solicita chave de máquina virtual. O host protegido não tem as chaves necessárias para ligar uma VM blindada (VM01 neste caso). Para obter as chaves necessárias, o host protegido deve fornecer o seguinte para o KPS:

   • O certificado de integridade atual
   • Um segredo criptografado (um Protetor de Chave ou KP) que contém as chaves necessárias para ligar a VM01. O segredo é criptografado usando outras chaves que somente o KPS conhece.

6. Versão da chave. O KPS examina o certificado de integridade para determinar sua validade. O certificado não deve ter expirado e o KPS deve confiar no serviço de atestado que o emitiu.

7. A chave é retornada ao host. Se o certificado de integridade é válido, o KPS tenta descriptografar o segredo e retornar com segurança as chaves necessárias para ligar a VM. As chaves são criptografadas para a SBV do host protegido.

8. O host liga a VM01.

Glossário de malha protegida e VMs blindadas

Termo	Definição
Serviço Guardião de Host (HGS)	Uma função do Windows Server que é instalada em um cluster protegido de servidores de bare-metal que é capaz de medir a integridade de um host do Hyper-V e liberar chaves para hosts do Hyper-V íntegros ao ligar ou migrar ao vivo VMs blindadas. Esses dois recursos são fundamentais para uma solução de máquina virtual blindada e são chamados de Serviço de atestado e Serviço de Proteção de Chave respectivamente.
host protegido	Um host do Hyper-V no qual as VMs blindadas podem ser executadas. Um host só pode ser considerado protegido quando tiver sido considerado íntegro pelo serviço de Atestado do HGS. As VMs blindadas não podem ser ligadas ou migradas ao vivo para um host do Hyper-V que ainda não foi atestado ou que apresentou falhas no atestado.
malha protegida	Esse é o termo coletivo usado para descrever uma malha de hosts do Hyper-V e o Serviço Guardião de Host que tem a capacidade de gerenciar e executar VMs blindadas.
máquinas virtuais blindadas (VM)	Uma máquina virtual que pode ser executada somente em hosts protegidos e está protegida contra a inspeção, violação e roubo de administradores de malha mal-intencionados e malware de host.
administrador de malha	Um administrador de nuvem pública ou privada que pode gerenciar máquinas virtuais. No contexto de uma malha protegida, um administrador de malha não tem acesso a VMs blindadas ou às políticas que determinam em quais hosts as VMs blindadas podem ser executadas.
administrador de HGS	Um administrador confiável na nuvem pública ou privada que tem autoridade para gerenciar as políticas e o material criptográfico para hosts protegidos, ou seja, os hosts nos quais uma máquina virtual blindada pode ser executada.
arquivo de dados de provisionamento ou arquivo de dados de blindagem (arquivo PDK)	Um arquivo criptografado que um locatário ou usuário cria para guardar informações importantes de configuração de VM e proteger essas informações contra o acesso por outros usuários. Por exemplo, um arquivo de dados de blindagem pode conter a senha que será atribuída à conta de administrador local quando a VM é criada.
Segurança com Base em virtualização (VBS)	Um ambiente de processamento e armazenamento baseado no Hyper-V que é protegido dos administradores. O Modo Seguro Virtual fornece ao sistema a capacidade de armazenar as chaves do sistema operacional que não são visíveis para um administrador do sistema operacional.
TPM virtual	Uma versão virtualizada de um Trusted Platform Module (TPM). A partir do Hyper-V no Windows Server 2016, você pode fornecer um dispositivo virtual TPM 2.0 para que as máquinas virtuais possam ser criptografadas, assim como um TPM físico permite que um computador físico seja criptografado.

Referências adicionais

• Malha protegida e VMs blindadas
• Blog: Blog de segurança de nuvem privada e datacenter
• Vídeo: Introdução a máquinas virtuais blindadas
• Vídeo: Estudar as VMs blindadas com o Hyper-V do Windows Server 2016