Guia de Planejamento de Malha Protegida e VM Blindada para Hosters

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

Este tópico aborda as decisões de planejamento que precisarão ser tomadas para permitir que máquinas virtuais blindadas sejam executadas em sua malha. Se você atualizar uma malha existente do Hyper-V ou criar uma nova malha, a execução de VMs blindadas consiste em dois componentes principais:

• O HGS (Serviço Guardião de Host) fornece atestado e proteção de chave para que você possa garantir que as VMs blindadas sejam executadas somente em hosts Hyper-V aprovados e íntegros. 
• Hosts Hyper-V aprovados e íntegros nos quais as VMs blindadas (e VMs regulares) podem ser executadas— eles são conhecidos como hosts protegidos.

Decisão nº 1: nível de confiança na malha

A maneira como você implementa o Serviço Guardião de Host e os hosts Hyper-V protegidos dependerão principalmente da força de confiança que você está procurando alcançar em sua malha. A força da confiança é governada pelo modo de atestado. Existem duas opções mutuamente excludentes:

1. Atestado de TPM confiável

   Se sua meta for ajudar a proteger máquinas virtuais contra administradores mal-intencionados ou uma malha comprometida, você usará o atestado confiável do TPM. Essa opção funciona bem para cenários de hospedagem multilocatário, bem como para ativos de alto valor em ambientes corporativos, como controladores de domínio ou servidores de conteúdo como SQL ou SharePoint. As políticas de HVCI (integridade de código protegida por Hipervisor) são medidas e sua validade imposta pelo HGS antes que o host seja autorizado a executar VMs blindadas.

2. Atestado de chave de host

   Se seus requisitos forem orientados principalmente pela conformidade que exige que as máquinas virtuais sejam criptografadas tanto em repouso quanto em funcionamento, você usará o atestado de chave do host. Essa opção funciona bem para datacenters de uso geral nas quais você se sente confortável com os administradores de host e malha do Hyper-V tendo acesso aos sistemas operacionais convidados de máquinas virtuais para manutenção e operações diárias.

   Nesse modo, o administrador de malha é o único responsável por garantir a integridade dos hosts Hyper-V. Como o HGS não desempenha nenhum papel na decisão do que é ou não permitido executar, malwares e depuradores funcionarão conforme projetado.

   No entanto, os depuradores que tentam anexar diretamente a um processo, como WinDbg.exe, são bloqueados para VMs blindadas porque o processo de trabalho da VM (VMWP.exe) é uma PPL (sinal de 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.

   Um modo de atestado semelhante chamado atestado de Administração confiável (baseado no Active Directory) foi preterido a partir do Windows Server 2019.

O nível de confiança escolhido determinará os requisitos de hardware para seus hosts Hyper-V, bem como as políticas que você aplicar na malha. Se necessário, você pode implantar sua malha protegida usando o atestado confiável de administrador e hardware existente e convertê-la em atestado confiável do TPM quando o hardware tiver sido atualizado e você precisar reforçar a segurança da malha.

Decisão nº 2: malha Hyper-V existente versus uma nova malha separada do Hyper-V

Se você tiver uma malha existente (Hyper-V ou outra), é muito provável que você possa usá-la para executar VMs blindadas junto com VMs regulares. Alguns clientes optam por integrar VMs blindadas em suas ferramentas e malhas existentes, enquanto outros separam a malha por motivos comerciais.

Planejamento do administrador do HGS para o Serviço Guardião de Host

Implante o HGS (Serviço Guardião de Host) em um ambiente altamente seguro, seja em um servidor físico dedicado, em uma VM blindada, em uma VM em um host Hyper-V isolado (separado da malha que está protegendo) ou em um ambiente logicamente separado usando uma assinatura diferente do Azure.

Área	Detalhes
Requisitos de instalação	Um servidor (cluster de três nós recomendado para alta disponibilidade) Para fallback, pelo menos dois servidores HGS são necessários Os servidores podem ser virtuais ou físicos (servidor físico com TPM 2.0 recomendado; o TPM 1.2 também tem suporte) Instalação do Server Core do Windows Server 2016 ou posterior Linha de visão da rede para a malha, que permite a configuração de fallback ou HTTP Certificado HTTPS recomendado para validação de acesso
Dimensionamento	Cada nó do servidor HGS (8 núcleos/4 GB) pode lidar com 1.000 hosts Hyper-V.
Gerenciamento	Designe pessoas específicas que gerenciarão o HGS. Elas devem ser separadas dos administradores de malha. Para comparação, os clusters HGS podem ser comparados a ACs (Autoridades de Certificação) em termos de isolamento administrativo, implantação física e nível geral de confidencialidade da segurança.
Active Directory do Serviço Guardião de Host	Por padrão, o HGS instala seu próprio Active Directory interno para gerenciamento. Essa é uma floresta autocontida e autogerenciada e é a configuração recomendada para ajudar a isolar o HGS da malha. Se você já tiver uma floresta do Active Directory altamente privilegiada que use para isolamento, poderá usá-la em vez da floresta padrão do HGS. É importante que o HGS não esteja ingressado em um domínio na mesma floresta que os hosts Hyper-V ou suas ferramentas de gerenciamento de malha. Isso pode permitir que um administrador de malha obtenha controle sobre o HGS.
Recuperação de desastre	Há três opções: Instale um cluster HGS separado em cada datacenter e autorize VMs blindadas a serem executadas nos datacenters primário e de backup. Isso evita a necessidade de alongar o cluster em uma WAN e permite isolar máquinas virtuais de modo que elas sejam executadas somente em seu local designado. Instale o HGS em um cluster estendido entre dois (ou mais) datacenters. Isso fornecerá resiliência se a WAN ficar inativa, mas força os limites do clustering de failover. Você não pode isolar cargas de trabalho em um local; uma VM autorizada a executar em um local pode executar em qualquer outro. Registre seu host Hyper-V com outro HGS como failover. Você também deve fazer backup de cada HGS exportando a configuração para que você sempre possa fazer a recuperação localmente. Para obter mais informações, consulte Export-HgsServerState e Import-HgsServerState.
Chaves do Serviço Guardião de Host	Um Serviço Guardião de Host usa dois pares de chaves assimétricas — uma chave de criptografia e uma chave de assinatura — cada um representado por um certificado SSL. Há duas opções para gerar essas chaves: Autoridade de certificação interna – você pode gerar essas chaves usando sua infraestrutura de PKI interna. Isso é adequado para um ambiente de datacenter. Autoridades de certificação publicamente confiáveis – use um conjunto de chaves obtidas de uma autoridade de certificação publicamente confiável. Essa é a opção que os hosters devem usar. Observe que, embora seja possível usar certificados autoassinados, eles não são recomendados para cenários de implantação que não sejam laboratórios de prova de conceito. Além de ter chaves HGS, um hoster pode usar "traga sua própria chave", em que os locatários podem fornecer suas próprias chaves para que alguns (ou todos) os locatários possam ter sua própria chave HGS específica. Essa opção é adequada para hosters que podem fornecer um processo fora de banda para os locatários carregarem suas chaves.
Armazenamento de chaves do Serviço Guardião de Host	Para obter a segurança mais forte possível, recomendamos que as chaves do HGS sejam criadas e armazenadas exclusivamente em um HSM (módulo de segurança de hardware). Se você não estiver usando HSMs, é altamente recomendável aplicar o BitLocker nos servidores HGS.

Planejamento de administração de malha para hosts protegidos

Área	Detalhes
Hardware	Atestado de chave de host: você pode usar qualquer hardware existente como host protegido. Há algumas exceções (para garantir que o host possa usar novos mecanismos de segurança a partir do Windows Server 2016. Consulte Hardware compatível com a proteção de integridade de código baseada em virtualização no Windows Server 2016. Atestado confiável do TPM: você pode usar qualquer hardware que tenha a Qualificação Adicional de Garantia de Hardware, desde que esteja configurada adequadamente (consulte Configurações de servidor compatíveis com VMs blindadas e Proteção baseada em virtualização da integridade de código para a configuração específica). Isso inclui o TPM 2.0 e o UEFI versão 2.3.1c e superior.
Sistema operacional	É recomendável usar a opção Server Core para o sistema operacional do host Hyper-V.
Implicações de desempenho	Com base nos testes de desempenho, antecipamos uma diferença de densidade de aproximadamente 5% entre a execução de VMs blindadas e VMs não blindadas. Isso significa que, se um determinado host Hyper-V pode executar 20 VMs não blindadas, esperamos que ele possa executar 19 VMs blindadas. Verifique o dimensionamento com suas cargas de trabalho típicas. Por exemplo, pode haver algumas exceções com cargas de trabalho intensivas de E/S orientadas a gravação que afetarão ainda mais a diferença de densidade.
Considerações das filiais	A partir do Windows Server, versão 1709, é possível especificar uma URL de fallback para um servidor do HGS virtualizado executado localmente como uma VM blindada na filial. A URL de fallback pode ser usada quando a filial perder a conectividade com os servidores do HGS no datacenter. Em versões anteriores do Windows Server, um host Hyper-V em execução em uma filial precisa de conectividade com o Serviço Guardião de Host para ativar ou migrar dinamicamente VMs blindadas. Para obter mais informações, consulte Considerações sobre filiais.