Guia de Planejamento de Malha Protegida e VM Blindada para Hosters
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:
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.
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 |
|
| 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:
|
| 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:
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 |
|
| 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. |