Gerenciar o Serviço Guardião de Host

O HGS (Serviço Guardião de Host) é a peça central da solução de malha protegida. Ele é responsável por garantir que os hosts Hyper-V na malha sejam conhecidos pelo hoster ou pela empresa, pela execução do software confiável e pelo gerenciamento das chaves usadas para iniciar VMs blindadas. Quando um locatário decide confiar em você para hospedar suas VMs blindadas, ele está depositando sua confiança em sua configuração e gerenciamento do Serviço Guardião de Host. Portanto, é muito importante seguir as práticas recomendadas ao gerenciar o Serviço Guardião de Host para garantir a segurança, a disponibilidade e a confiabilidade da malha protegida. As diretrizes nas seções a seguir abordam os problemas operacionais mais comuns enfrentados pelos administradores do HGS.

Limitação do acesso de administrador ao HGS

Devido à natureza confidencial de segurança do HGS, é importante garantir que seus administradores sejam membros altamente confiáveis da sua organização e, idealmente, separados dos administradores de seus recursos de malha. Além disso, é recomendável que você gerencie apenas o HGS de estações de trabalho seguras usando protocolos de comunicação seguros, como WinRM via HTTPS.

Separação de funções

Ao configurar o HGS, você recebe a opção de criar uma floresta isolada do Active Directory apenas para o HGS ou para ingressar o HGS em um domínio confiável e existente. Essa decisão, bem como as funções que você atribui aos administradores em sua organização, determinam o limite de confiança para o HGS. Quem tiver acesso ao HGS, seja diretamente como administrador ou indiretamente como administrador de outra coisa (por exemplo, o Active Directory) que pode influenciar o HGS, tem controle sobre sua malha protegida. Os administradores do HGS escolhem quais hosts Hyper-V estão autorizados a executar VMs blindadas e gerenciar os certificados necessários para iniciar VMs blindadas. Um invasor ou administrador mal-intencionado que tenha acesso ao HGS pode usar esse poder para autorizar hosts comprometidos a executar VMs blindadas, iniciar um ataque de negação de serviço removendo material de chave e muito mais.

Para evitar esse risco, é altamente recomendável limitar a sobreposição entre os administradores do HGS (incluindo o domínio ao qual o HGS está ingressado) e os ambientes Hyper-V. Ao garantir que nenhum administrador tenha acesso a ambos os sistemas, um invasor precisaria comprometer duas contas diferentes de dois indivíduos para concluir sua missão de alterar as políticas do HGS. Isso também significa que o domínio e os administradores corporativos dos dois ambientes do Active Directory não devem ser a mesma pessoa, nem o HGS deve usar a mesma floresta do Active Directory que seus hosts Hyper-V. Qualquer pessoa que possa conceder a si mesma acesso a mais recursos representa um risco à segurança.

Usar Administração Just Enough

O HGS vem com funções JEA (Administração Just Enough) internas para ajudá-lo a gerenciar com mais segurança. O JEA ajuda permitindo delegar tarefas de administrador a usuários não administradores, o que significa que as pessoas que gerenciam políticas do HGS não precisam realmente ser administradores de todo o computador ou domínio. O JEA funciona limitando quais comandos um usuário pode executar em uma sessão do PowerShell e usando uma conta local temporária nos bastidores (exclusivo para cada sessão de usuário) para executar os comandos que normalmente exigem elevação.

O HGS é fornecido com 2 funções JEA pré-configuradas:

• Administradores do HGS que permitem que os usuários gerenciem todas as políticas do HGS, incluindo a autorização de novos hosts para executar VMs blindadas.
• Revisores do HGS que só permitem aos usuários o direito de auditar as políticas existentes. Eles não podem fazer alterações na configuração do HGS.

Para usar o JEA, primeiro você precisa criar um novo usuário padrão e torná-lo membro do grupo de administradores do HGS ou revisores do HGS. Se você usou Install-HgsServer para configurar uma nova floresta para HGS, esses grupos serão nomeados "Administradores servicename" e "Revisores servicename", respectivamente, onde servicename é o nome da rede do cluster do HGS. Se você ingressou o HGS em um domínio existente, consulte os nomes de grupo especificados em Initialize-HgsServer.

Criar usuários padrão para as funções de administrador e revisor do HGS

$hgsServiceName = (Get-ClusterResource HgsClusterResource | Get-ClusterParameter DnsName).Value
$adminGroup = $hgsServiceName + "Administrators"
$reviewerGroup = $hgsServiceName + "Reviewers"

New-ADUser -Name 'hgsadmin01' -AccountPassword (Read-Host -AsSecureString -Prompt 'HGS Admin Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $adminGroup -Members 'hgsadmin01'

New-ADUser -Name 'hgsreviewer01' -AccountPassword (Read-Host -AsSecureString -Prompt 'HGS Reviewer Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $reviewerGroup -Members 'hgsreviewer01'

Políticas de auditoria com a função de revisor

Em um computador remoto que tenha conectividade de rede com o HGS, execute os comandos a seguir no PowerShell para entrar na sessão JEA com as credenciais do revisor. É importante observar que, como a conta do revisor é apenas um usuário padrão, ela não pode ser usada para comunicação remota do Windows PowerShell regular, acesso de Área de Trabalho Remota ao HGS etc.

Enter-PSSession -ComputerName <hgsnode> -Credential '<hgsdomain>\hgsreviewer01' -ConfigurationName 'microsoft.windows.hgs'

Em seguida, você pode verificar quais comandos são permitidos na sessão com Get-Command e executar quaisquer comandos permitidos para auditar a configuração. No exemplo abaixo, estamos verificando quais políticas estão habilitadas no HGS.

Get-Command

Get-HgsAttestationPolicy

Digite o comando Exit-PSSession ou seu alias exit quando terminar de trabalhar com a sessão JEA.

Adicionar uma nova política ao HGS usando a função de administrador

Para realmente alterar uma política, você precisa se conectar ao ponto de extremidade JEA com uma identidade que pertence ao grupo "hgsAdministrators". No exemplo abaixo, mostramos como você pode copiar uma nova política de integridade de código para o HGS e registrá-la usando JEA. A sintaxe pode ser diferente do que você está acostumado. Isso serve para acomodar algumas restrições no JEA, como não ter acesso ao sistema de arquivos completo.

$cipolicy = Get-Item "C:\temp\cipolicy.p7b"
$session = New-PSSession -ComputerName <hgsnode> -Credential '<hgsdomain>\hgsadmin01' -ConfigurationName 'microsoft.windows.hgs'
Copy-Item -Path $cipolicy -Destination 'User:' -ToSession $session

# Now that the file is copied, we enter the interactive session to register it with HGS
Enter-PSSession -Session $session
Add-HgsAttestationCiPolicy -Name 'New CI Policy via JEA' -Path 'User:\cipolicy.p7b'

# Confirm it was added successfully
Get-HgsAttestationPolicy -PolicyType CiPolicy

# Finally, remove the PSSession since it is no longer needed
Exit-PSSession
Remove-PSSession -Session $session

Monitoramento do HGS

Fontes de evento e encaminhamento

Os eventos do HGS aparecerão no log de eventos do Windows em duas fontes:

• HostGuardianService-Attestation
• HostGuardianService-KeyProtection

Você pode exibir esses eventos abrindo o Visualizador de Eventos e acessando Microsoft-Windows-HostGuardianService-Attestation e Microsoft-Windows-HostGuardianService-KeyProtection.

Em um ambiente grande, geralmente é preferível encaminhar eventos para um Coletor de Eventos central do Windows para facilitar a análise dos eventos. Para obter mais informações, confira a documentação sobre o Windows Event Forwarding.

Usar System Center Operations Manager

Você também pode usar o System Center 2016 – Operations Manager para monitorar o HGS e seus hosts protegidos. O pacote de gerenciamento de malha protegida tem monitores de eventos para verificar se há configurações incorretas comuns que podem causar tempo de inatividade do datacenter, incluindo hosts que não passam por atestado e servidores HGS relatando erros.

Para começar, instale e configure o SCOM 2016 e baixe o pacote de gerenciamento de malha protegida. O guia do pacote de gerenciamento incluído explica como configurar o pacote de gerenciamento e entender o escopo de seus monitores.

Backup e restauração do HGS

Planejamento de recuperação de desastre

Ao elaborar seus planos de recuperação de desastre, é importante considerar os requisitos exclusivos do Serviço Guardião de Host em sua malha protegida. Se você perder alguns ou todos os nós do HGS, poderá enfrentar problemas de disponibilidade imediatos que impedirão que os usuários iniciem suas VMs blindadas. Se você perder todo o cluster do HGS, será necessário ter backups completos da configuração do HGS disponíveis para restaurar o cluster do HGS e retomar as operações normais. Esta seção aborda as etapas necessárias para se preparar para esse cenário.

Primeiro, é importante saber o que é importante fazer backup no HGS. O HGS retém várias informações que ajudam a determinar quais hosts estão autorizados a executar VMs blindadas. Isso inclui:

1. Identificadores de segurança do Active Directory para os grupos que contêm hosts confiáveis (ao usar o atestado do Active Directory);
2. Identificadores TPM exclusivos para cada host em seu ambiente;
3. Políticas de TPM para cada configuração exclusiva do host; e
4. Políticas de integridade de código que determinam qual software tem permissão para ser executado em seus hosts.

Esses artefatos de atestado exigem coordenação com os administradores da malha de hospedagem, potencialmente dificultando a obtenção dessas informações novamente após um desastre.

Além disso, o HGS requer acesso a 2 ou mais certificados usados para criptografar e assinar as informações necessárias para iniciar uma VM blindada (o protetor de chave). Esses certificados são bem conhecidos (usados pelos proprietários de VMs blindadas para autorizar sua malha a executar suas VMs) e devem ser restaurados após um desastre para uma experiência de recuperação perfeita. Se você não restaurar o HGS com os mesmos certificados após um desastre, cada VM precisará ser atualizada para autorizar suas novas chaves a descriptografar suas informações. Por motivos de segurança, somente o proprietário da VM pode atualizar a configuração da VM para autorizar essas novas chaves, o que significa que a falha na restauração das chaves após um desastre resultará na necessidade de cada proprietário da VM tomar medidas para que suas VMs sejam executadas novamente.

Preparando para o pior cenário

Para se preparar para uma perda completa do HGS, há duas etapas que você deve seguir:

1. Fazer backup das políticas de atestado do HGS
2. Fazer backup das chaves do HGS

As diretrizes sobre como executar essas duas etapas são fornecidas na seção Backup do HGS.

Além disso, é recomendável, mas não necessário, fazer backup da lista de usuários autorizados a gerenciar o HGS em seu domínio do Active Directory ou no próprio Active Directory.

Os backups devem ser feitos regularmente para garantir que as informações estejam atualizadas e armazenadas com segurança para evitar adulterações ou roubos.

Não é recomendável fazer backup ou tentar restaurar uma imagem inteira do sistema de um nó HGS. Caso você tenha perdido todo o cluster, é recomendável configurar um novo nó do HGS e restaurar apenas o estado do HGS, não todo o sistema operacional do servidor.

Recuperação da perda de um nó

Se você perder um ou mais nós (mas não todos os nós) no cluster do HGS, poderá simplesmente adicionar nós ao cluster seguindo as diretrizes no guia de implantação. As políticas de atestado serão sincronizadas automaticamente, assim como todos os certificados que foram fornecidos ao HGS como arquivos PFX com senha. Para certificados adicionados ao HGS usando uma impressão digital (certificados não exportáveis e com suporte de hardware, normalmente), você precisará garantir que cada novo nó tenha acesso à chave privada de cada certificado.

Recuperando-se da perda de todo o cluster

Se todo o cluster do HGS ficar inativo e você não conseguir colocá-lo online novamente, será necessário restaurar o HGS de um backup. A restauração do HGS de um backup envolve primeiro a configuração de um novo cluster do HGS de acordo com as diretrizes no guia de implantação. É altamente recomendável, mas não necessário, usar o mesmo nome de cluster ao configurar o ambiente do HGS de recuperação para ajudar na resolução de nomes de hosts. O uso do mesmo nome evita a necessidade de reconfigurar hosts com novas URLs de atestado e proteção de chave. Se você restaurou objetos para o domínio do Active Directory que está apoiando o HGS, é recomendável remover os objetos que representam o cluster do HGS, computadores, conta de serviço e grupos JEA antes de inicializar o servidor do HGS.

Depois de configurar seu primeiro nó do HGS (por exemplo, ele foi instalado e inicializado), você seguirá os procedimentos em Restaurar o HGS de um backup para restaurar as políticas de atestado e as metades públicas dos certificados de proteção de chave. Você precisará restaurar as chaves privadas para seus certificados manualmente de acordo com as diretrizes do provedor de certificados (por exemplo, importar o certificado no Windows ou configurar o acesso a certificados com suporte de HSM). Depois que o primeiro nó for configurado, você poderá continuar instalando nós adicionais no cluster até atingir a capacidade e a resiliência desejadas.

Backup do HGS

O administrador do HGS deve ser responsável por fazer backup do HGS regularmente. Um backup completo conterá material de chave confidencial que deve ser protegido adequadamente. Se uma entidade não confiável tiver acesso a essas chaves, ela poderá usar esse material para configurar um ambiente HGS mal-intencionado com a finalidade de comprometer VMs blindadas.

Backup das políticas de atestado Para fazer backup das políticas de atestado do HGS, execute o comando a seguir em qualquer nó de servidor HGS em funcionamento. Você será solicitado a fornecer uma senha. Essa senha é usada para criptografar todos os certificados adicionados ao HGS usando um arquivo PFX (em vez de uma impressão digital do certificado).

Export-HgsServerState -Path C:\temp\HGSBackup.xml

Backup de certificados

O comando Export-HgsServerState fará backup de todos os certificados baseados em PFX adicionados ao HGS no momento em que o comando for executado. Se você adicionou certificados ao HGS usando uma impressão digital (típica para certificados não exportáveis e com suporte de hardware), será necessário fazer backup manual das chaves privadas para seus certificados. Para identificar quais certificados são registrados com o HGS e precisam ser copiados em backup manualmente, execute o comando do PowerShell a seguir em qualquer nó de servidor HGS em funcionamento.

Get-HgsKeyProtectionCertificate | Where-Object { $_.CertificateData.GetType().Name -eq 'CertificateReference' } | Format-Table Thumbprint, @{ Label = 'Subject'; Expression = { $_.CertificateData.Certificate.Subject } }

Para cada certificado listado, você precisará fazer backup manualmente da chave privada. Se você estiver usando um certificado baseado em software que não seja exportável, entre em contato com sua autoridade de certificação para garantir que eles tenham um backup do certificado e/ou possam reemiti-lo sob demanda. Para certificados criados e armazenados em módulos de segurança de hardware, consulte a documentação do seu dispositivo para obter diretrizes sobre o planejamento de recuperação de desastre.

Você deve armazenar os backups de certificado junto com seus backups de política de atestado em um local seguro para que ambas as partes possam ser restauradas juntas.

Configuração adicional para fazer backup

O estado do servidor do HGS com backup feito não incluirá o nome do cluster do HGS, as informações do Active Directory ou os certificados SSL usados para proteger as comunicações com as APIs do HGS. Essas configurações são importantes para consistência, mas não críticas para colocar o cluster do HGS online novamente após um desastre.

Para capturar o nome do serviço HGS, execute Get-HgsServer e anote o nome simples nas URLs de Atestado e Proteção de Chave. Por exemplo, se a URL de Atestado for "https://hgs.contoso.com/Attestation", "hgs" será o nome do serviço HGS.

O domínio do Active Directory usado pelo HGS deve ser gerenciado como qualquer outro domínio do Active Directory. Ao restaurar o HGS após um desastre, você não precisará necessariamente recriar os objetos exatos presentes no domínio atual. No entanto, isso facilitará a recuperação se você fizer backup do Active Directory e mantiver uma lista dos usuários JEA autorizados a gerenciar o sistema, bem como a associação de todos os grupos de segurança usados pelo atestado confiável do administrador para autorizar hosts protegidos.

Para identificar a impressão digital dos certificados SSL configurados para o HGS, execute o comando a seguir no PowerShell. Em seguida, você pode fazer backup desses certificados SSL de acordo com as instruções do provedor de certificados.

Get-WebBinding -Protocol https | Select-Object certificateHash

Restauração do HGS de um backup

As etapas a seguir descrevem como restaurar as configurações do HGS de um backup. As etapas são relevantes para ambas as situações em que você está tentando desfazer as alterações feitas em suas instâncias do HGS já em execução e quando você está enfrentando um cluster do HGS totalmente novo após uma perda completa do anterior.

Configurar um cluster do HGS de substituição

Antes de restaurar o HGS, você precisa ter um cluster do HGS inicializado para o qual você possa restaurar a configuração. Se você estiver simplesmente importando configurações que foram excluídas acidentalmente para um cluster existente (em execução), ignore esta etapa. Se você estiver se recuperando de uma perda completa do HGS, será necessário instalar e inicializar pelo menos um nó do HGS seguindo as diretrizes no guia de implantação.

Especificamente, você precisará:

1. Configurar o domínio do HGS ou ingressar o HGS em um domínio existente
2. Inicialize o servidor HGS usando suas chaves existentes ou um conjunto de chaves temporárias. Você pode remover as chaves temporárias depois de importar suas chaves reais dos arquivos de backup do HGS.
3. Importar configurações do HGS do backup para restaurar os grupos de hosts confiáveis, as políticas de integridade de código, as linhas de base do TPM e os identificadores do TPM

Importar configurações de um backup

Para restaurar políticas de atestado, certificados baseados em PFX e chaves públicas de certificados não PFX para o nó do HGS de um arquivo de backup, execute o comando a seguir em um nó inicializado do servidor do HGS. Você será solicitado a inserir a senha especificada ao criar o backup.

Import-HgsServerState -Path C:\Temp\HGSBackup.xml

Se você quiser importar apenas políticas de atestado confiáveis de administrador ou políticas de atestado confiáveis do TPM, especifique os sinalizadores -ImportActiveDirectoryModeState ou -ImportTpmModeState para Import-HgsServerState.

Verifique se a atualização cumulativa mais recente para Windows Server 2016 está instalada antes de executar Import-HgsServerState. Deixar de fazer isso pode resultar em um erro de importação.

Reinstalar chaves privadas para certificados

Se qualquer um dos certificados usados no HGS do qual o backup foi criado tiver sido adicionado usando impressões digitais, somente a chave pública desses certificados será incluída no arquivo de backup. Isso significa que você precisará instalar manualmente e/ou conceder acesso às chaves privadas para cada um desses certificados antes que o HGS possa atender a solicitações de hosts do Hyper-V. As ações necessárias para concluir essa etapa variam dependendo de como o certificado foi emitido originalmente. Para certificados com suporte de software emitidos por uma autoridade de certificação, você precisará entrar em contato com sua AC para obter a chave privada e instalá-la em cada nó do HGS de acordo com suas instruções. Da mesma forma, se os certificados tiverem suporte de hardware, você precisará consultar a documentação do fornecedor do módulo de segurança de hardware para instalar os drivers necessários em cada nó do HGS para se conectar ao HSM e conceder a cada computador acesso à chave privada.

Como lembrete, os certificados adicionados ao HGS usando impressões digitais exigem a replicação manual das chaves privadas para cada nó. Você precisará repetir essa etapa em cada nó adicional adicionado ao cluster do HGS restaurado.

Examinar as políticas de atestado importadas

Depois de importar suas configurações de um backup, é recomendável examinar de perto todas as políticas importadas usando Get-HgsAttestationPolicy para garantir que apenas os hosts confiáveis para executar VMs blindadas possam atestar com êxito. Se você encontrar políticas que não correspondam mais à sua postura de segurança, desabilite ou remova as mesmas.

Executar o diagnóstico para verificar o estado do sistema

Depois de concluir a configuração e a restauração do estado do nó do HGS, você deverá executar a ferramenta de diagnóstico do HGS para verificar o estado do sistema. Para fazer isso, execute o seguinte comando no nó do HGS em que você restaurou a configuração:

Get-HgsTrace -RunDiagnostics

Se o "Resultado Geral" não for "Aprovado", etapas adicionais serão necessárias para concluir a configuração do sistema. Verifique as mensagens relatadas nos subtestes com falha para obter mais informações.

Aplicação de patch no HGS

É importante manter os nós do Serviço Guardião de Host atualizados instalando a atualização cumulativa mais recente quando ela for lançada. Se você estiver configurando um novo nó do HGS, é altamente recomendável instalar todas as atualizações disponíveis antes de instalar a função do HGS ou configurá-la. Isso garantirá que qualquer funcionalidade nova ou alterada entre em vigor imediatamente.

Ao aplicar patch na malha protegida, é altamente recomendável que você atualize primeiro todos os hosts do Hyper-V antes de atualizar o HGS. Isso serve para garantir que todas as alterações nas políticas de atestado no HGS sejam feitas depois que os hosts do Hyper-V forem atualizados para fornecer as informações necessárias para eles. Se uma atualização alterar o comportamento das políticas, elas não serão habilitadas automaticamente para evitar a interrupção da malha. Essas atualizações exigem que você siga as diretrizes na seção a seguir para ativar as políticas de atestado novas ou alteradas. Recomendamos que você leia as notas sobre a versão do Windows Server e todas as atualizações cumulativas instaladas para verificar se as atualizações de política são necessárias.

Atualizações que exigem ativação de política

Se uma atualização do HGS introduzir ou alterar significativamente o comportamento de uma política de atestado, será necessária uma etapa adicional para ativar a política alterada. As alterações de política só são promulgadas após a exportação e importação do estado do HGS. Você só deve ativar as políticas novas ou alteradas depois de aplicar a atualização cumulativa a todos os hosts e a todos os nós do HGS em seu ambiente. Depois que cada computador tiver sido atualizado, execute os seguintes comandos em qualquer nó do HGS para disparar o processo de atualização:

$password = Read-Host -AsSecureString -Prompt "Enter a temporary password"
Export-HgsServerState -Path .\temporaryExport.xml -Password $password
Import-HgsServerState -Path .\temporaryExport.xml -Password $password

Se uma nova política tiver sido introduzida, ela será desabilitada por padrão. Para habilitar a nova política, primeiro localize-a na lista de políticas da Microsoft (prefixada com 'HGS_') e, em seguida, habilite-a usando os seguintes comandos:

Get-HgsAttestationPolicy

Enable-HgsAttestationPolicy -Name <Hgs_NewPolicyName>

Gerenciamento de políticas de atestado

O HGS mantém várias políticas de atestado que definem o conjunto mínimo de requisitos que um host deve atender para ser considerado "íntegro" e ter permissão para executar VMs blindadas. Algumas dessas políticas são definidas pela Microsoft, outras são adicionadas por você para definir as políticas de integridade de código permitidas, as linhas de base do TPM e os hosts em seu ambiente. A manutenção regular dessas políticas é necessária para garantir que os hosts possam continuar atestando corretamente à medida que você os atualiza e substitui, e para garantir que quaisquer hosts ou configurações não confiáveis sejam impedidos de atestar com êxito.

Para atestado de administrador confiável, há apenas uma política que determina se um host está íntegro: associação em um grupo de segurança conhecido e confiável. O atestado de TPM é mais complicado e envolve várias políticas para medir o código e a configuração de um sistema antes de determinar se ele está íntegro.

Um único HGS pode ser configurado com as políticas do Active Directory e do TPM de uma só vez, mas o serviço verificará apenas as políticas para o modo atual para o qual ele está configurado quando um host tentar atestear. Para verificar o modo do servidor HGS, execute Get-HgsServer.

Políticas padrão

Para atestado confiável do TPM, há várias políticas internas configuradas no HGS. Algumas dessas políticas estão "bloqueadas", o que significa que elas não podem ser desabilitadas por motivos de segurança. A tabela a seguir explica a finalidade de cada política padrão.

Nome da política	Finalidade
Hgs_SecureBootEnabled	Requer que a Inicialização Segura este habilitada nos hosts. Isso é necessário para medir os binários de inicialização e outras configurações bloqueadas por UEFI.
Hgs_UefiDebugDisabled	Garante que os hosts não tenham um depurador de kernel habilitado. Os depuradores do modo de usuário são bloqueados com políticas de integridade de código.
Hgs_SecureBootSettings	Política negativa para garantir que os hosts correspondam a pelo menos uma linha de base TPM (definida pelo administrador).
Hgs_CiPolicy	Política negativa para garantir que os hosts estejam usando uma das políticas de CI definidas pelo administrador.
Hgs_HypervisorEnforcedCiPolicy	Requer que a política de integridade de código seja imposta pelo hipervisor. A desabilitação dessa política enfraquece suas proteções contra ataques de política de integridade de código no modo kernel.
Hgs_FullBoot	Garante que o host não retornou da suspensão ou hibernação. Os hosts devem ser reiniciados ou desligados corretamente para passar essa política.
Hgs_VsmIdkPresent	Requer que a segurança baseada em virtualização esteja em execução no host. O IDK representa a chave necessária para criptografar as informações enviadas de volta para o espaço de memória segura do host.
Hgs_PageFileEncryptionEnabled	Requer que os arquivos de paginação sejam criptografados no host. A desabilitação dessa política poderá resultar na exposição de informações se um arquivo de paginação não criptografado for inspecionado quanto a segredos do locatário.
Hgs_BitLockerEnabled	Requer que o BitLocker seja habilitado no host do Hyper-V. Essa política é desabilitada por padrão por motivos de desempenho e não deve ser habilitada. Essa política não tem nenhuma influência sobre a criptografia das VMs blindadas em si.
Hgs_IommuEnabled	Exige que o host tenha um dispositivo IOMMU em uso para evitar ataques de acesso direto à memória. A desabilitação dessa política e uso de hosts sem um IOMMU habilitado pode expor segredos de VM de locatário a ataques de memória direta.
Hgs_NoHibernation	Requer que a hibernação seja desabilitada no host do Hyper-V. A desabilitação dessa política pode permitir que os hosts salvem memória de VM blindada em um arquivo de hibernação não criptografado.
Hgs_NoDumps	Requer que despejos de memória sejam desabilitados no host do Hyper-V. Se você desabilitar essa política, é recomendável configurar a criptografia de despejo para impedir que a memória de VM blindada seja salva em arquivos de despejo de falha não criptografados.
Hgs_DumpEncryption	Requer que os despejos de memória, se habilitados no host do Hyper-V, sejam criptografados com uma chave de criptografia confiável pelo HGS. Essa política não se aplicará se os despejos não estiverem habilitados no host. Se essa política e Hgs_NoDumps estiverem desabilitadas, a memória de VM blindada poderá ser salva em um arquivo de despejo não criptografado.
Hgs_DumpEncryptionKey	Política negativa para garantir que os hosts configurados para permitir despejos de memória estejam usando uma chave de criptografia de arquivo de despejo definida pelo administrador conhecida como HGS. Essa política não se aplica quando Hgs_DumpEncryption está desabilitado.

Autorização de novos hosts protegidos

Para autorizar um novo host a se tornar um host protegido (por exemplo, atestar com êxito), o HGS deve confiar no host e (quando configurado para usar o atestado confiável do TPM) o software em execução nele. As etapas para autorizar um novo host diferem com base no modo de atestado para o qual o HGS está configurado no momento. Para verificar o modo de atestado da malha protegida, execute Get-HgsServer em qualquer nó HGS.

Configuração de software

No novo host do Hyper-V, verifique se o Windows Server 2016 Datacenter Edition está instalado. O Windows Server 2016 Standard não pode executar VMs blindadas em uma malha protegida. O host pode ser instalado na Experiência Desktop ou Server Core.

No servidor com Experiência Desktop e Server Core, você precisa instalar as funções de servidor do Hyper-V e do Suporte do Hyper-V do Guardião de Host:

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart

Atestado de administrador confiável

Para registrar um novo host no HGS ao usar o atestado confiável do administrador, primeiro você deve adicionar o host a um grupo de segurança no domínio ao qual ele está ingressado. Normalmente, cada domínio terá um grupo de segurança para hosts protegidos. Se você já registrou esse grupo com o HGS, a única ação que você precisa tomar é reiniciar o host para atualizar sua associação de grupo.

Você pode verificar quais grupos de segurança são confiáveis pelo HGS executando o seguinte comando:

Get-HgsAttestationHostGroup

Para registrar um novo grupo de segurança com o HGS, primeiro capture o SID (identificador de segurança) do grupo no domínio do host e registre o SID com o HGS.

Add-HgsAttestationHostGroup -Name "Contoso Guarded Hosts" -Identifier "S-1-5-21-3623811015-3361044348-30300820-1013"

Instruções sobre como configurar a confiança entre o domínio do host e o HGS estão disponíveis no guia de implantação.

Atestado de TPM confiável

Quando o HGS está configurado no modo TPM, os hosts devem passar todas as políticas bloqueadas e políticas "habilitadas" prefixadas com "Hgs_", bem como pelo menos uma linha de base TPM, um identificador TPM e uma política de integridade de código. Sempre que você adicionar um novo host, será necessário registrar o novo identificador TPM com o HGS. Desde que o host esteja executando o mesmo software (e tenha a mesma política de integridade de código aplicada) e a linha de base do TPM como outro host em seu ambiente, você não precisará adicionar novas políticas de CI ou linhas de base.

Adicionando o identificador TPM para um novo host No novo host, execute o comando a seguir para capturar o identificador do TPM. Especifique um nome exclusivo para o host que o ajudará a pesquisar no HGS. Você precisará dessas informações se desativar o host ou quiser impedi-lo de executar VMs blindadas no HGS.

(Get-PlatformIdentifier -Name "Host01").InnerXml | Out-File C:\temp\host01.xml -Encoding UTF8

Copie esse arquivo para o servidor HGS e execute o comando a seguir para registrar o host com o HGS.

Add-HgsAttestationTpmHost -Name 'Host01' -Path C:\temp\host01.xml

Adicionando uma nova linha de base do TPM Se o novo host estiver executando uma nova configuração de hardware ou firmware para seu ambiente, talvez seja necessário usar uma nova linha de base do TPM. Para fazer isso, execute o seguinte comando no host.

Get-HgsAttestationBaselinePolicy -Path 'C:\temp\hardwareConfig01.tcglog'

Copie a linha de base do TPM para o servidor HGS e registre-a com o comando a seguir. É recomendável usar uma convenção de nomenclatura que ajude você a entender a configuração de hardware e firmware dessa classe de host do Hyper-V.

Add-HgsAttestationTpmPolicy -Name 'HardwareConfig01' -Path 'C:\temp\hardwareConfig01.tcglog'

Adicionando uma nova política de integridade de código Se você alterou a política de integridade de código em execução em seus hosts Hyper-V, será necessário registrar a nova política com o HGS antes que esses hosts possam atestar com êxito. Em um host de referência, que serve como uma imagem mestra para os computadores confiáveis do Hyper-V em seu ambiente, capture uma nova política de CI usando o comando New-CIPolicy. Incentivamos você a usar o nível FilePublisher e o fallback de Hash para políticas de CI de host do Hyper-V. Primeiro, você deve criar uma política de CI no modo de auditoria para garantir que tudo esteja funcionando conforme o esperado. Depois de validar uma carga de trabalho de exemplo no sistema, você pode impor a política e copiar a versão imposta para o HGS. Para obter uma lista completa das opções de configuração de política de integridade de código, consulte a documentação do Device Guard.

# Capture a new CI policy with the FilePublisher primary level and Hash fallback and enable user mode code integrity protections
New-CIPolicy -FilePath 'C:\temp\ws2016-hardware01-ci.xml' -Level FilePublisher -Fallback Hash -UserPEs

# Apply the CI policy to the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\ws2016-hardware01-ci.xml' -BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b' 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer

# Check the event log for any untrusted binaries and update the policy if necessary
# Consult the Device Guard documentation for more details

# Change the policy to be in enforced mode
Set-RuleOption -FilePath 'C:\temp\ws2016-hardare01-ci.xml' -Option 3 -Delete

# Apply the enforced CI policy on the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\ws2016-hardware01-ci.xml' -BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b' 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer

Depois de criar, testar e impor sua política, copie o arquivo binário (.p7b) para o servidor HGS e registre a política.

Add-HgsAttestationCiPolicy -Name 'WS2016-Hardware01' -Path 'C:\temp\ws2016-hardware01-ci.p7b'

Adicionando uma chave de criptografia de despejo de memória

Quando a política Hgs_NoDumps está desabilitada e a política Hgs_DumpEncryption está habilitada, os hosts protegidos têm permissão para que despejos de memória sejam habilitados, desde que esses despejos sejam criptografados. Os hosts protegidos só passarão pelo atestado se tiverem despejos de memória desabilitados ou estiverem criptografando-os com uma chave conhecida pelo HGS. Por padrão, nenhuma chave de criptografia de despejo é configurada no HGS.

Para adicionar uma chave de criptografia de despejo ao HGS, use o cmdlet Add-HgsAttestationDumpPolicy para fornecer ao HGS o hash da chave de criptografia de despejo. Se você capturar uma linha de base do TPM em um host do Hyper-V configurado com criptografia de despejo, o hash será incluído no tcglog e poderá ser fornecido ao cmdlet Add-HgsAttestationDumpPolicy.

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey01' -Path 'C:\temp\TpmBaselineWithDumpEncryptionKey.tcglog'

Como alternativa, você pode fornecer diretamente a representação de cadeia de caracteres do hash para o cmdlet.

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey02' -PublicKeyHash '<paste your hash here>'

Adicione cada chave de criptografia de despejo exclusiva ao HGS se você optar por usar chaves diferentes em sua malha protegida. Os hosts que estão criptografando despejos de memória com uma chave não conhecida pelo HGS não passarão pelo atestado.

Consulte a documentação do Hyper-V para obter mais informações sobre como configurar a criptografia de despejo em hosts.

Verificar se o sistema passou pelo atestado

Depois de registrar as informações necessárias com o HGS, você deve verificar se o host passa pelo atestado. No host do Hyper-V recém-adicionado, execute Set-HgsClientConfiguration e forneça as URLs corretas para o cluster do HGS. Essas URLs podem ser obtidas executando Get-HgsServer em qualquer nó HGS.

Set-HgsClientConfiguration -KeyProtectionServerUrl 'https://hgs.bastion.local/KeyProtection' -AttestationServerUrl 'https://hgs.bastion.local/Attestation'

Se o status resultante não indicar "IsHostGuarded : True", você precisará solucionar problemas de configuração. No host que falhou no atestado, execute o comando a seguir para obter um relatório detalhado sobre problemas que podem ajudá-lo a resolver o atestado com falha.

Get-HgsTrace -RunDiagnostics -Detailed

Examinar políticas de atestado

Para examinar o estado atual das políticas configuradas no HGS, execute os seguintes comandos em qualquer nó do HGS:

# List all trusted security groups for admin-trusted attestation
Get-HgsAttestationHostGroup

# List all policies configured for TPM-trusted attestation
Get-HgsAttestationPolicy

Se você encontrar uma política habilitada que não atenda mais às suas necessidades de segurança (por exemplo, uma política de integridade de código antiga que agora é considerada insegura), você poderá desabilitá-la substituindo o nome da política no seguinte comando:

Disable-HgsAttestationPolicy -Name 'PolicyName'

Da mesma forma, você pode usar Enable-HgsAttestationPolicy para reabilitar uma política.

Se você não precisar mais de uma política e quiser removê-la de todos os nós do HGS, execute Remove-HgsAttestationPolicy -Name 'PolicyName' para excluir permanentemente a política.

Alternando modos de atestado

Se você iniciou a malha protegida usando o atestado confiável do administrador, provavelmente desejará atualizar para o modo de atestado de TPM muito mais forte assim que tiver hosts compatíveis com o TPM 2.0 suficientes em seu ambiente. Quando estiver pronto para alternar, você poderá pré-carregar todos os artefatos de atestado (políticas de CI, linhas de base do TPM e identificadores TPM) no HGS enquanto continua executando o HGS com atestado confiável do administrador. Para fazer isso, basta seguir as instruções na seção autorizar um novo host protegido.

Depois de adicionar todas as políticas ao HGS, a próxima etapa é executar uma tentativa de atestado sintético em seus hosts para ver se eles passariam pelo atestado no modo TPM. Isso não afeta o estado operacional atual do HGS. Os comandos abaixo devem ser executados em um computador que tenha acesso a todos os hosts no ambiente e pelo menos um nó do HGS. Se o firewall ou outras políticas de segurança impedirem isso, você poderá ignorar esta etapa. Quando possível, recomendamos executar o atestado sintético para saber se a "inversão" para o modo TPM causará tempo de inatividade em suas VMs.

# Get information for each host in your environment
$hostNames = 'host01.contoso.com', 'host02.contoso.com', 'host03.contoso.com'
$credential = Get-Credential -Message 'Enter a credential with admin privileges on each host'
$targets = @()
$hostNames | ForEach-Object { $targets += New-HgsTraceTarget -Credential $credential -Role GuardedHost -HostName $_ }

$hgsCredential = Get-Credential -Message 'Enter an admin credential for HGS'
$targets += New-HgsTraceTarget -Credential $hgsCredential -Role HostGuardianService -HostName 'HGS01.bastion.local'

# Initiate the synthetic attestation attempt
Get-HgsTrace -RunDiagnostics -Target $targets -Diagnostic GuardedFabricTpmMode

Após a conclusão do diagnóstico, examine as informações geradas para determinar se algum host teria falhado no atestado no modo TPM. Execute novamente o diagnóstico até obter uma "aprovação" de cada host e, em seguida, altere o HGS para o modo TPM.

A alteração para o modo TPM leva apenas um segundo para ser concluída. Execute o comando a seguir em qualquer nó do HGS para atualizar o modo de atestado.

Set-HgsServer -TrustTpm

Se você tiver problemas e precisar voltar para o modo do Active Directory, execute Set-HgsServer -TrustActiveDirectory.

Depois de confirmar se tudo está funcionando conforme o esperado, remova todos os grupos de hosts confiáveis do Active Directory do HGS e remova a confiança entre o HGS e os domínios de malha. Se você deixar a confiança do Active Directory em vigor, correrá o risco de alguém reabilitá-la e alternar o HGS para o modo do Active Directory, o que pode permitir que o código não confiável seja executado desmarcado em seus hosts protegidos.

Gerenciamento de chaves

A solução de malha protegida usa vários pares de chaves públicas/privadas para validar a integridade de vários componentes na solução e criptografar segredos do locatário. O Serviço Guardião de Host é configurado com pelo menos dois certificados (com chaves públicas e privadas), que são usados para assinar e criptografar as chaves usadas para iniciar VMs blindadas. Essas chaves devem ser cuidadosamente gerenciadas. Se a chave privada for adquirida por um adversário, ela poderá desabilitar todas as VMs em execução em sua malha ou configurar um cluster do HGS impostor que use políticas de atestado mais fracas para ignorar as proteções que você colocou em prática. Se você perder as chaves privadas durante um desastre e não encontrá-las em um backup, será necessário configurar um novo par de chaves e ter cada VM digitada novamente para autorizar seus novos certificados.

Esta seção aborda tópicos gerais de gerenciamento de chaves para ajudá-lo a configurar suas chaves para que elas sejam funcionais e seguras.

Adicionar novas chaves

Embora o HGS precise ser inicializado com um conjunto de chaves, você pode adicionar mais de uma chave de criptografia e assinatura ao HGS. Os dois motivos mais comuns pelos quais você adicionaria novas chaves ao HGS são:

1. Para dar suporte a cenários de "Bring Your Own Key", em que os locatários copiam suas chaves privadas para o módulo de segurança de hardware e autorizam apenas suas chaves a iniciar as VMs blindadas.
2. Para substituir as chaves existentes para o HGS, primeiro adicione as novas chaves e mantenha os dois conjuntos de chaves até que cada configuração de VM seja atualizada para usar as novas chaves.

O processo para adicionar suas novas chaves difere com base no tipo de certificado que você está usando.

Opção 1: adicionar um certificado armazenado em um HSM

Nossa abordagem recomendada para proteger chaves do HGS é usar certificados criados em um HSM (módulo de segurança de hardware). Os HSMs garantem que o uso de suas chaves esteja vinculado ao acesso físico a um dispositivo sensível à segurança em seu datacenter. Cada HSM é diferente e tem um processo exclusivo para criar certificados e registrá-los no HGS. As etapas a seguir destinam-se a fornecer diretrizes aproximadas para usar certificados com suporte do HSM. Consulte a documentação do fornecedor de HSM para obter as etapas e os recursos exatos.

1. Instale o software de HSM em cada nó do HGS no cluster. Dependendo da existência de uma rede ou dispositivo de HSM local, talvez seja necessário configurar o HSM para conceder ao computador acesso ao repositório de chaves.

2. Criar dois certificados no HSM com chaves RSA de 2048 bits para criptografia e assinatura

   1. Criar um certificado de criptografia com a propriedade de uso da chave de Criptografia de dados no HSM
   2. Criar um certificado de autenticação com a propriedade de uso da chave de Assinatura Digital no HSM

3. Instale os certificados no repositório de certificados local de cada nó do HGS de acordo com as diretrizes do fornecedor de HSM.

4. Se o HSM usar permissões granulares para conceder permissão a aplicativos ou usuários específicos para usar a chave privada, você precisará conceder à sua conta de serviço gerenciada do grupo do HGS acesso ao certificado. Você pode encontrar o nome da conta gMSA do HGS executando (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName

5. Adicione os certificados de assinatura e criptografia ao HGS substituindo as impressões digitais pelas dos certificados nos seguintes comandos:

   Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"
   Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA"
   

Opção 2: adicionando certificados de software não exportáveis

Se você tiver um certificado com suporte de software emitido pela autoridade de certificação pública ou da sua empresa que tenha uma chave privada não exportável, será necessário adicionar seu certificado ao HGS usando sua impressão digital.

1. Instale o certificado em seu computador de acordo com as instruções da autoridade de certificação.

2. Conceda à conta de serviço gerenciada do grupo do HGS acesso de leitura à chave privada do certificado. Você pode encontrar o nome da conta gMSA do HGS executando (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName

3. Registre o certificado com o HGS usando o seguinte comando e substituindo na impressão digital do certificado (altere Criptografia para Autenticação para autenticação de certificados):

   Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"
   

Opção 3: adicionar certificados armazenados em arquivos PFX

Se você tiver um certificado com suporte de software com uma chave privada exportável que pode ser armazenada no formato de arquivo PFX e protegida com uma senha, o HGS poderá gerenciar automaticamente seus certificados para você. Os certificados adicionados com arquivos PFX são replicados automaticamente para cada nó do cluster do HGS e o HGS protege o acesso às chaves privadas. Para adicionar um novo certificado usando um arquivo PFX, execute os seguintes comandos em qualquer nó do HGS (altere Criptografia para Autenticação para autenticação de certificados):

$certPassword = Read-Host -AsSecureString -Prompt "Provide the PFX file password"
Add-HgsKeyProtectionCertificate -CertificateType Encryption -CertificatePath "C:\temp\encryptionCert.pfx" -CertificatePassword $certPassword

Identificação e alteração dos certificados primários Embora o HGS possa dar suporte a vários certificados de assinatura e criptografia, ele usa um par como seus certificados "primários". Esses são os certificados que serão usados se alguém baixar os metadados do guardião para esse cluster do HGS. Para verificar quais certificados estão marcados atualmente como seus certificados primários, execute o seguinte comando:

Get-HgsKeyProtectionCertificate -IsPrimary $true

Para definir uma nova criptografia primária ou certificado de autenticação, localize a impressão digital do certificado desejado e marque-o como primário usando os seguintes comandos:

Get-HgsKeyProtectionCertificate
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899" -IsPrimary
Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA" -IsPrimary

Renovação ou substituição de chaves

Quando você criar os certificados usados pelo HGS, eles receberão uma data de validade de acordo com a política da autoridade de certificação e suas informações de solicitação. Normalmente, em cenários em que a validade do certificado é importante, como a proteção de comunicações HTTP, os certificados devem ser renovados antes de expirarem para evitar uma interrupção de serviço ou uma mensagem de erro preocupante. O HGS não usa certificados nesse sentido. O HGS está simplesmente usando certificados como uma maneira conveniente de criar e armazenar um par de chaves assimétricas. Uma criptografia expirada ou certificado de autenticação no HGS não indica uma fraqueza ou perda de proteção para VMs blindadas. Além disso, as verificações de revogação de certificado não são executadas pelo HGS. Se um certificado do HGS ou certificado da autoridade emissora for revogado, ele não afetará o uso do certificado pelo HGS.

Você só precisa se preocupar com um certificado do HGS se você tiver motivos para acreditar que sua chave privada foi roubada. Nesse caso, a integridade de suas VMs blindadas está em risco porque a posse da metade privada do par de chaves de criptografia e assinatura do HGS é suficiente para remover as proteções de blindagem em uma VM ou receber um servidor do HGS falso que tenha políticas de atestado mais fracas.

Se você se encontrar nessa situação ou se os padrões de conformidade exigirem a atualização das chaves de certificado regularmente, as etapas a seguir descrevem o processo para alterar as chaves em um servidor do HGS. Observe que as diretrizes a seguir representam uma tarefa significativa que resultará em uma interrupção do serviço para cada VM atendida pelo cluster do HGS. O planejamento adequado para alterar as chaves do HGS é necessário para minimizar a interrupção do serviço e garantir a segurança das VMs de locatário.

Em um nó do HGS, execute as etapas a seguir para registrar um novo par de certificados de criptografia e autenticação. Confira a seção sobre como adicionar novas chaves para obter informações detalhadas sobre as várias maneiras de adicionar novas chaves ao HGS.

1. Crie um novo par de certificados de criptografia e autenticação para o servidor do HGS. O ideal é que eles sejam criados em um módulo de segurança de hardware.

2. Registrar a nova criptografia e autenticar certificados com Add-HgsKeyProtectionCertificate

   Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>
   Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>
   

3. Se você usou impressões digitais, precisará acessar cada nó no cluster para instalar a chave privada e conceder ao gMSA do HGS acesso à chave.

4. Tornar os novos certificados os certificados padrão no HGS

   Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsPrimary
   Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsPrimary
   

Neste ponto, os dados de blindagem criados com metadados obtidos do nó do HGS usarão os novos certificados, mas as VMs existentes continuarão funcionando porque os certificados mais antigos ainda estão lá.

Para garantir que todas as VMs existentes funcionem com as novas chaves, você precisará atualizar o protetor de chave em cada VM.

Essa é uma ação que exige que o proprietário da VM (pessoa ou entidade em posse do guardião "proprietário") esteja envolvido. Para cada VM blindada, execute as seguintes etapas:

1. Desligue a VM. A VM não pode ser ativada novamente até que as etapas restantes sejam concluídas ou você precisará iniciar o processo novamente.

2. Salve o protetor de chave atual em um arquivo: Get-VMKeyProtector -VMName 'VM001' | Out-File '.\VM001.kp'

3. Transferir o KP para o proprietário da VM

4. Faça com que o proprietário baixe as informações do guardião atualizadas do HGS e importe-as em seu sistema local

5. Leia o KP atual na memória, conceda ao novo guardião acesso ao KP e salve-o em um novo arquivo executando os seguintes comandos:

   $kpraw = Get-Content -Path .\VM001.kp
   $kp = ConvertTo-HgsKeyProtector -Bytes $kpraw
   $newGuardian = Get-HgsGuardian -Name 'UpdatedHgsGuardian'
   $updatedKP = Grant-HgsKeyProtectorAccess -KeyProtector $kp -Guardian $newGuardian
   $updatedKP.RawData | Out-File .\updatedVM001.kp
   

6. Copie o KP atualizado de volta para a malha de hospedagem.

7. Aplique o KP à VM original:

   $updatedKP = Get-Content -Path .\updatedVM001.kp
   Set-VMKeyProtector -VMName VM001 -KeyProtector $updatedKP
   

8. Por fim, inicie a VM e verifique se ela foi executada com êxito.

   Observação

   Se o proprietário da VM definir um protetor de chave incorreto na VM e não autorizar a malha a executar a VM, não será possível iniciar a VM blindada. Para retornar ao último protetor de chave válido conhecido, execute Set-VMKeyProtector -RestoreLastKnownGoodKeyProtector

   Depois que todas as VMs tiverem sido atualizadas para autorizar as novas chaves guardiãs, você poderá desabilitar e remover as chaves antigas.

9. Obter as impressões digitais dos certificados antigos de Get-HgsKeyProtectionCertificate -IsPrimary $false

10. Desabilite cada certificado executando os seguintes comandos:

    Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsEnabled $false
    Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsEnabled $false
    

11. Depois de garantir que as VMs ainda possam começar com os certificados desabilitados, remova os certificados do HGS executando os seguintes comandos:

    Remove-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>`
    Remove-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>`
    

Replicação de chave entre nós

Cada nó no cluster do HGS deve ser configurado com a mesma criptografia, autenticação e (quando configurados) certificados SSL. Isso é necessário para garantir que os hosts do Hyper-V que acessam qualquer nó no cluster possam ter suas solicitações atendidas com êxito.

Se você inicializou o servidor HGS com certificados baseados em PFX, o HGS replicará automaticamente a chave pública e privada desses certificados em todos os nós do cluster. Você só precisa adicionar as chaves em um nó.

Se você inicializou o servidor HGS com referências de certificado ou impressões digitais, o HGS replicará apenas a chave pública no certificado para cada nó. Além disso, o HGS não pode conceder a si mesmo acesso à chave privada em qualquer nó neste cenário. Portanto, é sua responsabilidade:

1. Instalar a chave privada em cada nó do HGS
2. Conceda à conta de serviço gerenciado do grupo HGS (gMSA) acesso à chave privada em cada nó Essas tarefas adicionam uma carga operacional extra, no entanto, elas são necessárias para chaves e certificados com suporte de HSM com chaves privadas não exportáveis.

Os Certificados SSL nunca são replicados em nenhum formulário. É sua responsabilidade inicializar cada servidor HGS com o mesmo certificado SSL e atualizar cada servidor sempre que você optar por renovar ou substituir o certificado SSL. Ao substituir o certificado SSL, é recomendável usar o cmdlet Set-HgsServer.

Cancelar a configuração do HGS

Se você precisar desativar ou reconfigurar significativamente um servidor HGS, use os cmdlets Clear-HgsServer ou Uninstall-HgsServer.

Limpeza da configuração do HGS

Para remover um nó do cluster HGS, use o cmdlet Clear-HgsServer. Esse cmdlet fará as seguintes alterações no servidor em que ele é executado:

• Cancela o registro dos serviços de atestado e proteção de chave
• Remove o ponto de extremidade de gerenciamento JEA "microsoft.windows.hgs"
• Remove o computador local do cluster de failover do HGS

Se o servidor for o último nó do HGS no cluster, o cluster e seu recurso de Nome de Rede Distribuída correspondente também serão destruídos.

# Removes the local computer from the HGS cluster
Clear-HgsServer

Após a conclusão da operação de limpeza, o servidor HGS pode ser inicializado novamente com Initialize-HgsServer. Se você usou Install-HgsServer para configurar um domínio do Active Directory Domain Services, esse domínio permanecerá configurado e operacional após a operação de limpeza.

Desinstalação do HGS

Se você quiser remover um nó do cluster dp HGS e rebaixar o Controlador de Domínio do Active Directory em execução, use o cmdlet Uninstall-HgsServer. Esse cmdlet fará as seguintes alterações no servidor em que ele é executado:

• Cancela o registro dos serviços de atestado e proteção de chave
• Remove o ponto de extremidade de gerenciamento JEA "microsoft.windows.hgs"
• Remove o computador local do cluster de failover do HGS
• Rebaixa o Controlador de Domínio do Active Directory, se configurado

Se o servidor for o último nó do HGS no cluster, o domínio, o cluster de failover e o recurso de Nome de Rede Distribuída do cluster também serão destruídos.

# Removes the local computer from the HGS cluster and demotes the ADDC (restart required)
$newLocalAdminPassword = Read-Host -AsSecureString -Prompt "Enter a new password for the local administrator account"
Uninstall-HgsServer -LocalAdministratorPassword $newLocalAdminPassword -Restart

Depois que a operação de desinstalação for concluída e o computador tiver sido reiniciado, você poderá reinstalar o ADDC e o HGS usando Install-HgsServer ou ingressar o computador em um domínio e inicializar o servidor HGS nesse domínio com Initialize-HgsServer.

Se você não pretende mais usar o computador como um nó do HGS, é possível remover a função do Windows.

Uninstall-WindowsFeature HostGuardianServiceRole