Table of contents
TOC
Recolher sumário
Expandir sumário

Gerenciando o serviço guardião de Host

Ryan Puffer|Última Atualização: 14/04/2017
|
1 Colaborador

Aplica-se a: Windows Server 2016

O serviço de guardião de Host (HGS) é a parte central da solução fabric protegido. É responsável por garantir que os hosts Hyper-V na malha são conhecidos como hoster ou enterprise e executando o software confiáveis e para gerenciar as chaves usadas para iniciar VMs protegidas. Quando um locatário decide confie em você para hospedar seus VMs protegidos, eles são colocação de 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 de responsável de Host para garantir a segurança, disponibilidade e confiabilidade da estrutura protegida. As diretrizes nas seções a seguir aborda os problemas mais comuns de operacionais voltado para os administradores dos HGS.

Limitar o acesso de administrador para HGS

Devido à natureza relacionada à segurança do HGS, é importante garantir que os administradores são altamente confiáveis membros de sua organização e, idealmente, separam dos administradores de seus recursos de malha. Além disso, é recomendável que você só gerenciar HGS em estações de trabalho seguras usando os protocolos de comunicação seguro, como o WinRM por HTTPS.

Separação de funções

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

Para evitar esse risco, é altamente recomendável limitar a sobreposição entre os administradores de seu HGS (incluindo o domínio ao qual ingressou HGS) e ambientes do Hyper-V. Garantindo que sem um administrador tem acesso a ambos os sistemas, seria necessário um invasor comprometer 2 contas diferentes de 2 pessoas para concluir a missão para alterar as políticas HGS. Isso também significa que os administradores de domínio e o enterprise para os dois ambientes do Active Directory não devem ser a mesma pessoa, nem deve HGS usar floresta do Active Directory mesmo que hospeda o Hyper-V. Qualquer pessoa pode conceder a mesmos acesso aos recursos mais representa um risco de segurança.

Usando apenas o suficiente de administração

HGS vem com apenas suficiente administração funções (JEA) integradas para ajudá-lo a gerenciá-lo com mais segurança. JEA ajuda, permitindo que você a delegar tarefas de administração para os usuários não administradores, ou seja, as pessoas que gerenciar políticas HGS, na verdade, não precisam ser administradores do domínio ou toda a máquina. JEA funciona limitar quais comandos que um usuário pode executar em uma sessão do PowerShell e usando uma conta local temporária nos bastidores (exclusivos para cada sessão do usuário) para executar os comandos que normalmente exigem elevação.

HGS acompanha 2 funções JEA pré-configurados:

  • Os administradores HGS que permite aos usuários gerenciar todas as políticas HGS, incluindo autorizar novos hosts para executar VMs protegido.
  • Examinadores HGS apenas que permite aos usuários o direito de existente de políticas de auditoria. Eles não podem fazer alterações na configuração HGS.

Para usar JEA, você precisa primeiro criar um novo usuário padrão e torná-los um membro do grupo de revisores HGS ou HGS administradores. Se você usou Install-HgsServerpara configurar uma nova floresta para HGS, esses grupos serão nomeados "servicenameadministradores" e "servicenamerevisores", respectivamente, onde servicename é o nome da rede do cluster HGS. Se você associou HGS a um domínio existente, você deve consultar os nomes de grupo que você especificou noInitialize-HgsServer.

Criar os usuários padrão para as funções de administrador e revisor 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 Revisor

Em um computador remoto que tenha conectividade de rede para HGS, execute os seguintes comandos do PowerShell para inserir a sessão JEA com as credenciais do revisor. É importante observar que, como a conta do revisor é apenas um usuário padrão, ele não pode ser usado para normal Windows PowerShell remoto, acesso à área de trabalho remota para 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-Commande executar quaisquer comandos permitidos para a configuração de auditoria. Na seguir o exemplo, estamos verificando quais políticas são habilitadas em HGS.

Get-Command

Get-HgsAttestationPolicy

Digite o comando Exit-PSSessionou seu alias, exit, quando você terminar de trabalhar com a sessão JEA.

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

Para alterar uma política, você precisa se conectar ao ponto de extremidade JEA com uma identidade que pertence ao grupo 'hgsAdministrators'. Na seguir o exemplo, vamos mostrar como você pode copiar uma nova política de integridade de código para HGS e registrá-la usando JEA. A sintaxe pode ser diferente do que você está acostumado a. Isso é para acomodar dentre as restrições na 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 HGS

Encaminhamento e fontes de evento

Eventos de HGS aparecerá no log de eventos do Windows em 2 fontes:

  • Atestado HostGuardianService
  • HostGuardianService KeyProtection

Você pode exibir esses eventos abrindo o Visualizador de eventos e navegar para Atestado Microsoft-Windows-HostGuardianService e Microsoft-Windows-HostGuardianService-KeyProtection.

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

Usando o System Center Operations Manager

Você também pode usar o System Center 2016 - Operations Manager para monitorar HGS e os hosts protegidos. O pacote de gerenciamento de malha guardados tem monitores de eventos para verificar se há incorretas que podem levar ao tempo de inatividade de datacenter, incluindo hosts não passando Atestado e servidores HGS relatório de erros.

Para começar, instalar e configurar SCOM 2016 e baixar o pacote de gerenciamento de malha guardados. O guia incluído management pack explica como configurar o pacote de gerenciamento e entender o escopo de seus monitores.

Fazendo backup e restaurando HGS

Planejamento de recuperação de desastres

Quando a criação de seus planos de recuperação de desastres, é importante considerar os requisitos específicos do serviço de guardião de Host na sua malha protegida. Você perder alguns ou todos os nós HGS, você pode enfrentar problemas de disponibilidade imediata que impedirá que os usuários a partir do backup de suas VMs protegidos. Em um cenário em que você perder todo o cluster HGS, você precisará ter backups completos da configuração HGS em mãos para restaurar o cluster HGS e continuar as operações normais. Esta seção abrange as etapas necessárias para preparar para esse cenário.

Primeiro, é importante entender que tal HGS é importante fazer backup. HGS retém várias partes de informações que ajudá-lo a determinam quais hosts estão autorizados a executar VMs protegidas. Isso inclui:

  1. Os identificadores de segurança Active Directory para os grupos que contêm trusted hosts (ao usar o Atestado do Active Directory);
  2. Identificadores exclusivos do TPM para cada host em seu ambiente.
  3. Políticas TPM para cada configuração exclusiva de host; e
  4. Políticas de integridade de código que determinam qual software tem permissão para executar nos hosts.

Esses artefatos de Atestado exigem coordenação com os administradores da estrutura hospedagem obter, possivelmente tornando difícil obter essas informações novamente após um desastre.

Além disso, HGS requer acesso ao 2 ou mais certificados usados para criptografar e assinar as informações necessárias para começar a uma VM protegida (o protetor de chave). Esses certificados são bem conhecidos (usado pelos proprietários de VMs protegidos para autorizar sua malha para executar suas VMs) e devem ser restaurados após um desastre para uma experiência de recuperação contínua. Você não deve restaurar HGS com os certificados mesmo após um desastre, cada VM precisa ser atualizado para autorizar seu novas chaves para 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, falha significado para restaurar suas chaves depois que um desastre resultará em cada proprietário VM precisar executar uma ação para obter suas VMs executar novamente.

Preparando para o pior

Para preparar para uma perda completa de HGS, há 2 etapas que você deve seguir:

  1. Faça backup as políticas de Atestado HGS
  2. Fazer backup das chaves HGS

Orientação sobre como executar essas duas etapas é fornecida no backup HGS seção.

Ele é recomendado Além disso, mas não necessário, que você faça backup da lista de usuários autorizados a gerenciar HGS no domínio do Active Directory ou Active Directory em si.

Backups cuidados regularmente para garantir que as informações estão atualizadas e armazenados com segurança para evitar adulterações ou roubo.

É não recomendado para fazer backup ou tentar restaurar uma imagem de todo o sistema de um nó HGS. No caso de você ter perdido todo o cluster, a prática recomendada é configurar um novo nó HGS e restaurar apenas o estado HGS, não o servidor todo sistema operacional.

Recuperar a perda de um nó

Se você perder um ou mais nós (mas não todos os nós) no cluster HGS, você pode simplesmente adicionar nós ao cluster seguindo as orientações no guia de implantação. As políticas de Atestado sincronizará automaticamente, assim como quaisquer certificados que foram fornecidos para HGS como arquivos PFX acompanhado de senhas. Para obter certificados adicionados ao HGS usando uma impressão digital (não exportable e hardware feito certificados, comumente), você precisa garantir que cada novo nó tem acesso à chave privada de cada certificado.

Recuperar a perda do cluster inteiro

Se todo o cluster HGS desce e você não pode levá-lo de volta online, você precisará restaurar HGS de um backup. Restaurando HGS a partir de um backup envolve configurar um novo cluster HGS pelo orientações no guia de implantação. Ele é altamente recomendável, mas não precisa, use o mesmo nome de cluster ao configurar o ambiente de recuperação do HGS para auxiliar na resolução de nomes de hosts. Usando o mesmo nome evita a necessidade de reconfiguração hosts com Atestado novos e as URLs de proteção de chave. Se você restaurou objetos no domínio do Active Directory fazendo HGS, é recomendável que você remova os objetos que representam o cluster HGS, a computadores, a conta de serviço e a grupos JEA antes de inicializar o servidor HGS.

Depois que você configurou seu primeiro nó HGS (por exemplo, ele foi instalado e inicializado), você seguirá os procedimentos em HGS restauração de um backup para restaurar as políticas de Atestado e públicas metades os certificados de proteção de chave. Você precisará restaurar as chaves privadas para os certificados manualmente, de acordo com as orientações de seu provedor de certificado (por exemplo, importe o certificado no Windows, ou configurar o acesso aos certificados de apoio HSM). Depois que o primeiro nó estiver configurado, você pode continuar a instale nós adicionais ao cluster até atingir a capacidade e a resiliência que desejar.

Fazer backup de HGS

O administrador HGS deve ser responsável pelo backup HGS regularmente. Um backup completo conterá o material da chave confidencial que deve ser protegido de forma adequada. Uma entidade não confiável deve obter acesso a essas chaves, ele poderia utilizar o material para configurar um ambiente HGS mal-intencionado para fins de comprometer protegido VMs.

Fazer backup de políticas de Atestado para retornar as políticas de Atestado HGS, execute o seguinte comando no nó do servidor HGS qualquer trabalho. Você precisará fornecer uma senha. Essa senha é usada para criptografar todos os seus certificados adicionados ao HGS usando um arquivo PFX (em vez de uma impressão digital do certificado).

Export-HgsServerState -Path C:\temp\HGSBackup.xml
Observação

Se você estiver usando o Atestado confiável de administrador, você deve backup separadamente a associação dos grupos de segurança usadas pelo HGS para autorizar hosts protegidos. HGS fará backup somente o SID dos grupos de segurança, não a associação dentro deles. No caso esses grupos são perdidos durante um desastre, será necessário recriar os grupos e adicione cada host guarda-los novamente.

Fazer backup de certificados

O Export-HgsServerStatecomando fará o backup qualquer PFX certificados baseados adicionados ao HGS no momento o comando é executado. Se você adicionou certificados para HGS usando uma impressão de digital (típico para certificados não exportable e backup de hardware), você precisará fazer um backup manualmente as chaves privadas para seus certificados. Para identificar os certificados que são registrados com HGS e precisam ser feito manualmente, execute o seguinte comando do PowerShell no nó do servidor HGS qualquer trabalho.

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

Para cada um dos certificados listados, você precisará fazer um backup manualmente a chave privada. Se você estiver usando certificados baseados em software que não pode ser exportada, entre em contato com a autoridade de certificação para garantir que ele tem um backup do seu certificado e/ou podem relançar sob demanda. Para obter certificados criados e armazenados em módulos de segurança de hardware, você deverá consultar a documentação para o seu dispositivo para obter orientação sobre planejamento de recuperação de desastres.

Você deve armazenar os backups de certificado junto com seus backups de política de Atestado em um local seguro para que as duas partes podem ser restauradas juntos.

Configuração adicional para fazer backup

O backup HGS o estado do servidor não incluirá o nome do cluster HGS, nenhuma informação do Active Directory, ou quaisquer certificados SSL usada para proteger a comunicação com as APIs HGS. Essas configurações são importantes para manter a consistência, mas não essencial para o cluster HGS on-line novamente após um desastre.

Para capturar o nome do serviço HGS, execute Get-HgsServere anote o nome simples no Atestado e URLs de proteção de chave. Por exemplo, se a URL de Atestado é "http://hgs.contoso.com/Attestation", "hgs" é 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 HGS após um desastre, você não necessariamente precisará recriar os objetos exatos que estão presentes no domínio atual. No entanto, ele facilitará recuperação se você fizer backup do Active Directory e manter uma lista dos usuários JEA autorizado para gerenciar o sistema, bem como os membros de qualquer grupos de segurança usadas pelo administrador confiável Atestado para autorizar hosts protegidos.

Para identificar a impressão digital dos certificados SSL configurado para HGS, execute o seguinte comando do PowerShell. Em seguida, você pode fazer backup esses certificados SSL acordo com as instruções do seu provedor certificado.

Get-WebBinding -Protocol https | Select-Object certificateHash

Restaurando HGS a partir de um backup

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

Configurar um cluster HGS de substituição

Antes de restaurar HGS, você precisa ter um cluster HGS inicializado para as quais você pode restaurar a configuração. Se você simplesmente estiver importando configurações que foram excluídas acidentalmente a um cluster (em execução) existente, você pode pular esta etapa. Se você estiver recuperando de perda completa de HGS, você precisará instalar e inicializar pelo menos um seguinte de nó HGS o orientações no guia de implantação.

Especificamente, você precisará:

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

O novo cluster HGS não precisa usar o mesmo certificados, nome do serviço ou domínio como a instância HGS do qual o arquivo de backup foi exportado.

Importar as configurações de um backup

Para restaurar o atestado de políticas, certificados baseados em PFX e as chaves públicas de certificados PFX não para o nó HGS de um arquivo de backup, execute o seguinte comando em um nó de servidor HGS inicializado. Você precisará inserir a senha que você especificou ao criar o backup.

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

Se você deseja importar políticas de Atestado confiável de administrador ou políticas de Atestado do TPM confiável, você pode fazer isso, especificando a -ImportActiveDirectoryModeStateou -ImportTpmModeStatesinaliza para importar HgsServerState.

Certifique-se a atualização cumulativa mais recente para Windows Server 2016 é instalado antes de executarImport-HgsServerState. Deixar de fazer isso pode resultar em um erro de importação.

Observação

Se você restaurar as políticas em um nó HGS existente que já tem uma ou mais dessas políticas instalado, o comando import mostrará um erro para cada política duplicada. Isso é um comportamento esperado e pode ser ignorado na maioria dos casos.

Reinstalar chaves privadas para certificados

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

Como um lembrete, adicionados à HGS usando impressões digitais de certificados exigem replicação manual das chaves privadas para cada nó. Você precisará repetir esta etapa em cada nó adicional que você adicionar ao cluster HGS restaurado.

Reveja as políticas de Atestado importado

Depois que você tiver importado as configurações de um backup, é recomendável todos examine cuidadosamente as políticas importadas usando Get-HgsAttestationPolicypara garantir que apenas os hosts confiável para executar VMs protegidas será capazes de atestar com êxito. Se você encontrar todas as políticas que não correspondem a postura de segurança, você pode desabilitar ou removê-las.

Executar diagnósticos para verificar o estado do sistema

Depois que terminar de configurar e restaurar o estado do nó HGS, você deve executar a ferramenta de diagnóstico HGS para verificar o estado do sistema. Para fazer isso, execute o seguinte comando no nó HGS onde você restaurou a configuração:

Get-HgsTrace -RunDiagnostics

Se o "resultado geral" não "aprovado", são necessárias etapas adicionais para finalizar a configuração do sistema. Verifique as mensagens relatadas no subtests falhou para obter mais informações.

Aplicação de patch HGS

É importante manter os nós do serviço guardião de Host atualizados instalando a atualização cumulativa mais recente quando ele sai. Se você estiver configurando um novo nó HGS, é altamente recomendável que você instale as atualizações disponíveis antes de instalar a função HGS ou configurá-lo. Isso garantirá qualquer novo ou alterada funcionalidade entrarão em vigor imediatamente.

Quando a aplicação de patch sua malha protegida, é altamente recomendável que você atualize primeiro todos os hosts Hyper-V antes de atualizar HGS. Isso é para garantir que sejam feitas alterações nas políticas de Atestado HGS depois os hosts Hyper-V foram atualizados para fornecer as informações necessárias para eles. Se for uma atualização para mudar o comportamento de políticas, eles serão não automaticamente habilitados para evitar a interromper sua malha. Essas atualizações exigem que você siga as orientações na seção a seguir para ativar as políticas de Atestado novas ou alteradas. Encorajamos você a ler as notas de versão para Windows Server e quaisquer atualizações cumulativas que instalar para verificar se as atualizações de política forem necessárias.

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

Se uma atualização para HGS apresenta ou altera o comportamento de uma política de Atestado significativamente, uma etapa adicional é necessária para ativá-la alterado. Alterações na política de só são aplicadas depois de exportar e importar o estado HGS. Você só deve ativar as políticas novas ou alteradas depois que você aplicou a atualização cumulativa para todos os hosts e todos os nós HGS em seu ambiente. Depois que todos os computadores foi atualizado, execute os seguintes comandos em qualquer nó 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 foi introduzida, ele será desabilitado por padrão. Para habilitar a nova política, primeiro localize-o na lista de políticas do Microsoft (o prefixo 'HGS_') e, em seguida, habilitá-lo usando os seguintes comandos:

Get-HgsAttestationPolicy

Enable-HgsAttestationPolicy -Name <Hgs_NewPolicyName>

Gerenciamento de políticas de Atestado

HGS mantém diversas políticas de Atestado que definem o conjunto mínimo de requisitos de que um host deve atender para ser considerada "saudável" e permissão para executar VMs protegidas. Algumas dessas políticas são definidas pela Microsoft, outros são adicionados por você para definir as políticas de integridade de código permitidos, linhas de base do TPM e hosts em seu ambiente. Manutenção regular dessas políticas é necessária para garantir a hosts podem continuar Atestado corretamente como atualizar e substituí-los, e para garantir que quaisquer configurações ou hosts não confiáveis são impedidas de Atestado com êxito.

Atestado confiável de administrador, há apenas uma política que determina se um host é adequado: participação em um grupo de segurança conhecida e confiável. Atestado do 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 ao mesmo tempo, mas o serviço verificará apenas as políticas para o modo atual que está configurado para quando um host tenta Atestado. Para verificar o modo do seu servidor HGS, executeGet-HgsServer.

Políticas padrão

Atestado do TPM confiável, há diversas políticas internas configuradas em HGS. Algumas dessas políticas são "bloqueadas" — que significa que eles não podem ser desativados por motivos de segurança. A tabela a seguir explica a finalidade de cada política padrão.

Nome da políticaFinalidade
Hgs_SecureBootEnabledRequer hosts com inicialização segura habilitada. Isso é necessário para medir os binários de inicialização e outras configurações bloqueado UEFI.
Hgs_UefiDebugDisabledGarante hosts não têm um depurador de kernel habilitado. Modo de usuário depuradores são bloqueados com políticas de integridade de código.
Hgs_SecureBootSettingsPolítica negativa para garantir que os hosts coincidir com pelo menos uma base TPM (definido pelo administrador).
Hgs_CiPolicyPolítica negativa para garantir que os hosts estão usando uma das diretivas de CI definido pelo administrador.
Hgs_HypervisorEnforcedCiPolicyRequer a política de integridade de código para ser imposta pelo hipervisor. Desabilitar essa política enfraquece a proteção contra ataques de política de integridade de código de modo kernel.
Hgs_FullBootGarante que o host não retomada após uma suspensão ou hibernação. Hosts devem ser reiniciados ou desligados para passar essa política corretamente.
Hgs_VsmIdkPresentExigir segurança de virtualização com base em execução no host. O IDK representa a chave necessária encriptar informações enviadas de volta ao espaço de memória segura do host.
Hgs_PageFileEncryptionEnabledExige que os arquivos de paginação para ser criptografados no host. Desabilitar essa política pode resultar em exposição de informações se um arquivo de paginação não criptografado é inspecionado para segredos de locatário.
Hgs_BitLockerEnabledRequer o BitLocker esteja habilitada no host do Hyper-V. Esta configuração de política está desabilitada por padrão por motivos de desempenho e não é recomendada para ser habilitado. Esta configuração de política não possui a criptografia de VMs protegidas propriamente ditos.
Hgs_IommuEnabledExige que o host tenha um dispositivo IOMMU em uso para evitar ataques de acesso direto de memória. Desabilitar esta configuração de política e usando hosts sem uma IOMMU habilitada podem expor segredos do locatário VM para direcionar os ataques de memória.
Hgs_NoHibernationRequer hibernação para ser desabilitada no host do Hyper-V. Desabilitar essa política pode permitir que os hosts economizar memória VM protegida para um arquivo de hibernação não criptografada.
Hgs_NoDumpsRequer despejos de memória para ser desabilitada no host do Hyper-V. Se você desabilitar esta configuração de política, é recomendável que você configure a criptografia de despejo de memória para impedir que protegidos de memória VM está sendo salvas nos arquivos de despejo de memória de falhas não criptografada.
Hgs_DumpEncryptionRequer despejos de memória, se habilitada no host do Hyper-V, ser criptografados com uma chave de criptografia confiável pelo HGS. Esta configuração de política não se aplica à despejos não estão habilitados no host. Se esta configuração de política e Hgs_NoDumps são ambos desabilitados, protegidos de memória VM poderia ser salvos em um arquivo de despejo de memória não criptografada.
Hgs_DumpEncryptionKeyPolítica negativa para garantir que hospeda configurado para permitir que a memória despejos são usando uma chave de criptografia de arquivo de despejo de memória definida pelo administrador conhecida por HGS. Esta configuração de política não se aplica quando Hgs_DumpEncryption está desabilitada.

Autorizar novo protegidos hosts

Para autorizar um novo host para se tornar um host protegido (por exemplo, atestar com êxito), HGS devem confiar host e (quando configurado para usar o TPM confiável Atestado) o software em execução. As etapas para autorizar um novo host variam de acordo com o modo de Atestado para o qual HGS é configurado no momento. Para verificar o modo de Atestado sua malha protegida, execute Get-HgsServerem qualquer nó HGS.

Configuração de software

No novo host do Hyper-V, certifique-se de que o Windows Server 2016 Datacenter edition está instalado. Windows Server 2016 padrão não pode executar VMs protegidas em uma malha protegida. O host pode ser instalado com qualquer uma das opções de instalação (servidor com a experiência desktop, Server Core e Nano servidor).

No servidor com a experiência desktop e Server Core, você precisa instalar as funções de servidor Hyper-V e Host responsável Hyper-V suporte:

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

Para o servidor Nano, você deve preparar a imagem com a calcular, Microsoft-NanoServer-SecureStartup-Package e Microsoft-NanoServer-ShieldedVM-Package pacotes.

Atestado Admin confiável

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

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

Get-HgsAttestationHostGroup

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

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

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

Atestado do TPM confiável

Quando HGS é configurado no modo do TPM, hosts devem passar todas as diretivas bloqueadas e políticas "enabled" prefixadas com "Hgs_", bem como pelo menos uma linha de base do TPM, o identificador do TPM e política de integridade de código. Cada vez que você adicionar um novo host, você precisará registrar o novo identificador TPM com HGS. Desde que o host estiver executando o mesmo software (e aplicou a mesma política de integridade de código) e de linha de base TPM como outro host em seu ambiente, você não precisará adicionar novas políticas de CI ou linhas de base.

Adicionando o identificador do TPM para um novo host no novo host, execute o seguinte comando para capturar o identificador do TPM. Certifique-se de especificar um nome exclusivo para o host que ajudarão você a procurar em HGS. Você precisará dessas informações se você encerrar o host ou se quiser impedir a execução VMs protegidas em HGS.

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

Copie esse arquivo para o servidor HGS, em seguida, execute o seguinte comando para registrar o host HGS.

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

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

Get-HgsAttestationBaselinePolicy -Path 'C:\temp\hardwareConfig01.tcglog'
Observação

Se você receber um erro afirmando que o host falhou na validação e não será atestar com êxito, não se preocupe. Isso é uma verificação de pré-requisito para garantir que seu host pode ser executado protegido VMs e provavelmente significa que você ainda não aplicadas uma política de integridade de código ou outro exigida. Leia a mensagem de erro, faça as alterações sugeridas pelo-lo e tente novamente. Como alternativa, você pode ignorar a validação no momento, adicionando o -SkipValidationsinalizador ao comando.

Copie a linha de base do TPM ao seu servidor HGS e registrá-lo com o comando a seguir. Recomendamos que você usar uma convenção de nomenclatura que ajuda 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ê tiver alterado a política de integridade de código em execução nos hosts Hyper-V, você precisará registrar a nova política com HGS antes que esses hosts podem atestar com êxito. Em um host de referência, que atua como uma imagem mestra para os computadores confiáveis do Hyper-V em seu ambiente, capture uma nova CI diretiva usando o New-CIPolicycomando. Encorajamos você a usar o FilePublisher nível e Hash fallback para políticas de CI host do Hyper-V. Você deve primeiro criar uma política de CI no modo de auditoria para garantir que tudo está funcionando conforme o esperado. Após a validação uma carga de trabalho de exemplo no sistema, você pode impor a política e copie a versão imposta para HGS. Para obter uma lista completa das opções de configuração de política de integridade de código, consulte o 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 ter sua política criada, testado e imposta, copie o arquivo binário (. p7b) para o servidor HGS e registrar 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 o Hgs_NoDumps política estiver desabilitada e Hgs_DumpEncryption política estiver habilitada, hosts guardados têm permissão para ter despejos de memória (incluindo despejos de memória) seja habilitado, desde os despejos são criptografados. Hosts guardados só passará Atestado se eles têm despejos de memória desabilitados ou esteja criptografando-los com uma chave conhecida para HGS. Por padrão, nenhuma chave de criptografia de despejo de memória é configurado em HGS.

Para adicionar uma chave de criptografia de despejo de memória para HGS, use o Add-HgsAttestationDumpPolicycmdlet para fornecer HGS com o hash da sua chave de criptografia de despejo de memória. Se você capturar uma linha de base do TPM em um host do Hyper-V configurado com a criptografia de despejo de memória, o hash está incluído no tcglog e pode ser fornecido para o Add-HgsAttestationDumpPolicycmdlet.

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

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

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

Certifique-se de adicionar cada chave de criptografia de despejo exclusivo para HGS se você optar por usar chaves diferentes em sua malha protegida. Os hosts que esteja criptografando despejos de memória com uma chave conhecida não HGS não passará Atestado.

Consulte a documentação do Hyper-V para obter mais informações sobre Configurando despejar criptografia em hosts.

Verifique se o sistema foi aprovado Atestado

Depois de registrar as informações necessárias com HGS, você deve verificar se o host for aprovado Atestado. No host do Hyper-V recém-adicionado, execute Set-HgsClientConfiguratione forneça as URLs corretas para o cluster HGS. Essas URLs podem ser obtidos executando Get-HgsServerem qualquer nó HGS.

Set-HgsClientConfiguration -KeyProtectionServerUrl 'http://hgs.relecloud.com/KeyProtection' -AttestationServerUrl 'http://hgs.relecloud.com/Attestation'

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

Get-HgsTrace -RunDiagnostics -Detailed

Reveja as políticas de Atestado

Para examinar o estado atual das políticas configuradas em HGS, execute os seguintes comandos em qualquer nó 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 diretiva ativada que não cumpre o requisito de segurança (por exemplo, um antigo política integridade de código que agora é considerado inseguro), você pode desativá-la, substituindo o nome da política no comando a seguir:

Disable-HgsAttestationPolicy -Name 'PolicyName'

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

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

Alterar modos de Atestado

Se você começou sua malha protegida usando Atestado confiável de administrador, provavelmente vai querer atualizar para o modo de Atestado do TPM mais forte muito assim que você tem os hosts suficiente TPM 2.0-compatible em seu ambiente. Quando você estiver pronto para a troca, você pode pré-carregar todos os artefatos de Atestado (CI políticas, linhas de base do TPM e identificadores TPM) no HGS enquanto continua a executar HGS com Atestado confiável de administrador. Para fazer isso, siga as instruções no autorizar um novo host Guardo seção.

Depois de adicionar todas as políticas para HGS, a próxima etapa é executar uma tentativa de Atestado sintéticos nos hosts para ver se eles seriam passar Atestado no modo do TPM. Isso não afeta o estado operacional atual do HGS. Os comandos a seguir devem ser executados em um computador que tem acesso a todos os hosts pelo menos um nó HGS e o ambiente. Se o firewall ou outras políticas de segurança evitar isso, você pode pular esta etapa. Quando possível, recomendamos executar o Atestado sintético para oferecer a você uma boa indicação se "inversão" para o modo de TPM fará com que o tempo de inatividade para as 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.relecloud.com'

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

Depois de diagnósticos completos, examine as informações de meio para determinar se qualquer hosts falharia Atestado no modo do TPM. Execute novamente o diagnóstico até que você obtenha um "pass" de cada host depois prosseguir para alterar HGS para o modo do TPM.

Mudando para o modo de TPM leva alguns segundos para ser concluída. Execute o seguinte comando em qualquer nó HGS para atualizar o modo de Atestado.

Set-HgsServer -TrustTpm

Se ocorrerem problemas e precisar voltar para o modo do Active Directory, você pode fazer isso executandoSet-HgsServer -TrustActiveDirectory.

Depois de confirmar que tudo está funcionando conforme o esperado, você deve remover todos os grupos de host do Active Directory confiáveis de HGS e remover a relação de confiança entre os domínios HGS e malha. Se você deixar a relação de confiança do Active Directory no local, você o risco de alguém habilitando novamente a confiança e alternar HGS para o modo do Active Directory, que pode permitir código não confiável seja executado desmarcada nos hosts protegidos.

Gerenciamento de chaves

A solução de malha guardados usa vários pares de chaves pública/privada para validar a integridade dos vários componentes da solução e criptografem os segredos de locatário. O serviço guardião de Host está configurado com pelo menos dois certificados (com chaves pública e privada), que são usados para assinar e criptografar as chaves usadas para iniciar VMs protegidas. Essas chaves devem ser gerenciados com cuidado. Se a chave privada é adquirida por um adversário, eles poderão unshield qualquer VMs em execução no sua malha ou configurar um cluster HGS impostor que usa mais fracas políticas de Atestado para ignorar as proteções que você colocar no lugar. Você perder as chaves privadas durante um desastre e não encontrá-los em um backup, você precisará configurar um novo par de chaves e ter cada VM inserido novamente para autorizar os certificados de novo.

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

Adicionando novas chaves

Enquanto HGS deve ser inicializado com um conjunto de chaves, você pode adicionar mais de uma criptografia e a chave para HGS de assinatura. Os dois motivos mais comuns por que você adicionaria novas chaves para HGS são:

  1. Para dar suporte a cenários "traga seu próprio pen drive" onde locatários copiar suas chaves privadas para o módulo de segurança de hardware e autorizar somente suas chaves recomece suas VMs protegidos.
  2. Para substituir as chaves existentes para HGS, primeiro adicionando as novas chaves e manter os dois conjuntos de chaves até cada VM configuração foi atualizada para usar as novas chaves.

O processo para adicionar chaves do novo varia de acordo com o tipo de certificado que você está usando.

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

Nossa abordagem recomendada para proteger chaves de HGS é usar certificados criados em um módulo de segurança de hardware (HSM). HSMs garantir o uso de suas chaves está vinculado ao acesso físico a um dispositivo sensíveis à segurança no seu datacenter. Cada HSM é diferente e tem um único processo para criar certificados e registrá-los com HGS. As etapas a seguir foram projetadas para fornecer orientação aproximada para usando o HSM feito certificados. Consulte a documentação do fornecedor do HSM para recursos e as etapas exatas.

  1. Instale o software HSM em cada nó HGS no cluster. Dependendo se você tem uma rede ou um dispositivo local do HSM, talvez seja necessário configurar o HSM para conceder acesso ao seu computador ao seu armazenamento de chave.
  2. Criar 2 certificados no HSM com chaves RSA de 2048 bits para criptografia e assinatura
    1. Criar um certificado de criptografia com o codificação de dados propriedade uso em seu HSM de chave
    2. Criar um certificado de assinatura com o Assinatura Digital propriedade uso em seu HSM de chave
  3. Instale os certificados no repositório de certificados local do nó cada HGS por orientações do fornecedor do HSM.
  4. Se o HSM usa permissões completas para conceder permissão para usar a chave privada a usuários ou aplicativos específicos, você precisará conceder acesso de contas de serviço seu HGS grupo gerenciado para o certificado. Você pode encontrar o nome da conta gMSA HGS executando (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName
  5. Adicione os certificados de assinatura e criptografia para HGS, substituindo as impressões digitais com os seus 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 exportable

Se você tiver feito o software certificado emitido por da sua empresa ou uma autoridade de certificação pública que tem uma chave privada não exportable, você precisará adicionar o certificado para HGS usando sua impressão digital.

  1. Instale o certificado no computador de acordo com instruções da autoridade de certificação.
  2. Conceda o HGS grupo gerenciado serviço conta acesso de leitura para a chave privada do certificado. Você pode encontrar o nome da conta gMSA HGS executando (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName
  3. Registrar o certificado com HGS usando o seguinte comando e a substituição em impressão digital do certificado (alterar criptografia para conectando para certificados de assinatura):

     Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"
    
Importante

Você precisará instalar a chave privada e concede acesso de leitura para a conta gMSA em cada nó HGS manualmente. HGS automaticamente não pode duplicar as chaves privadas para qualquer registrado por sua impressão digital do certificado.

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

Se você tiver um certificado de backup de software com uma chave privada exportable que pode ser armazenado no formato de arquivo PFX e protegido com uma senha, HGS automaticamente pode gerenciar seus certificados para você. Certificados adicionados com arquivos PFX são automaticamente replicados para todos os nós do cluster HGS e HGS protege o acesso às chaves particulares. Para adicionar um novo certificado usando um arquivo PFX, execute os seguintes comandos em qualquer nó HGS (alterar criptografia para conectando para certificados de assinatura):

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

Identificando e alterando os certificados principais enquanto HGS pode dar suporte a vários certificados de assinatura e criptografia, ele usa um par como seus certificados "principais". Estes são os certificados que serão usados se alguém baixa os metadados de responsável para que o cluster HGS. Para verificar os certificados que estão marcados como seu principais certificados, execute o seguinte comando:

Get-HgsKeyProtectionCertificate -IsPrimary $true

Para definir um novo criptografia principal ou um certificado de assinatura, encontre a impressão digital do certificado desejado e marcá-la como principal usando os seguintes comandos:

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

Renovando ou substituindo chaves

Quando você cria os certificados usados pelo HGS, os certificados serão atribuídos a data de validade de acordo com a política da sua autoridade de certificação e suas informações de solicitação. Normalmente, em cenários em que a validade do certificado é importante, como proteger as comunicações HTTP, certificados devem ser renovados antes que elas expirem para evitar uma mensagem de erro preocupante ou interrupção do serviço. HGS não usa certificados nesse sentido. HGS é simplesmente usando certificados como uma maneira conveniente para criar e armazenar um par de chaves assimétricas. Uma criptografia expirada ou um certificado de assinatura em HGS não indica um pontos fracos ou perda de proteção para VMs protegidas. Além disso, as verificações de revogação de certificados não são executadas por HGS. Se for revogado da autoridade de emissão ou um certificado HGS, isso não afetará uso dos HGS do certificado.

O único momento em que você precisa se preocupar em um certificado HGS é se você tiver motivos para acreditar que tem sua chave privada foi roubado. Nesse caso, a integridade do seu VMs protegidos é em risco porque a posse de metade privada do par de chaves de assinatura e a criptografia de HGS é suficiente para remover as proteções blindagem em uma VM ou levantar a um servidor HGS falso que tem mais fracas políticas de Atestado.

Se você estiver nessa situação, ou é necessários por padrões de conformidade para atualizar regularmente as chaves de certificado, as etapas a seguir descrevem o processo para alterar as teclas em um servidor HGS. Observe que a orientação a seguir representa uma tarefa considerável resultará em uma interrupção de serviço para cada VM servido pelo cluster HGS. Planejamento apropriado para alterar chaves HGS é necessária para minimizar a interrupção de serviço e garantir a segurança do locatário VMs.

Em um nó HGS, execute as seguintes etapas para registrar um novo par de criptografia e certificados de assinatura. Consulte a seção sobre adicionando novas chaves para obter informações detalhadas as várias maneiras de adicionar novas chaves para HGS.

  1. Crie um novo par de criptografia e certificados de assinatura do seu servidor HGS. Idealmente, eles serão criados em um módulo de segurança de hardware.
  2. Registrar a nova criptografia e assinatura certificados com HgsKeyProtectionCertificate adicionar

     Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>
     Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>
    
  3. Se você usou impressões digitais, você precisará ir para cada nó no cluster para instalar a chave privada e conceder o acesso de gMSA HGS à chave.
  4. Verifique os novos certificados os certificados padrão em HGS

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

Neste ponto, protegendo dados criados com os metadados obtidos do nó HGS usará os novos certificados, mas VMs existentes continuarão a funcionar porque os certificados mais antigos ainda existem. Para garantir que todas as VMs existentes funcionarão com as novas chaves, você precisará atualizar o protetor de chave em cada VM. Isso é uma ação que exige que o proprietário da VM (pessoa ou entidade em posse do responsável "proprietário") para ser envolvidos. Para cada VM protegido, execute as seguintes etapas:

  1. Desligar a VM. A VM não pode ser ativada novamente até que sejam concluídas as etapas restantes do contrário, 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 ao proprietário VM
  4. Ter o download do proprietário as informações atualizadas responsável do HGS e importá-lo no sistema local
  5. Ler o KP atual na memória, conceder o acesso de responsável novo para o KP e salvá-lo para 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 para a malha de hospedagem
  7. Aplica a KP para a VM original:

    $updatedKP = Get-Content -Path .\updatedVM001.kp
    Set-VMKeyProtector -VMName VM001 -KeyProtector $updatedKP
    
  8. Por fim, inicie a máquina Virtual e certifique-se de que ele é executado com êxito.
Observação

Se o proprietário da VM define um protetor de chave incorreto na VM e não autoriza sua malha para executar a VM, será possível inicializar a VM protegida. Para retornar à última protetor de chave boa conhecido, execute Set-VMKeyProtector -RestoreLastKnownGoodKeyProtector

Depois que todas as VMs foram atualizadas para autorizar as novas chaves do responsável, você pode desabilitar e remover as chaves antigas.

  1. Obtenha as impressões digitais que os certificados de antigo Get-HgsKeyProtectionCertificate -IsPrimary $false
  2. Desabilite cada certificado, substituindo o tipo de certificado e a impressão digital no comando a seguir: Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsEnabled $false
  3. Após verificar VMs ainda são capazes to start com os certificados desabilitados, remova os certificados HGS com Remove-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>
Importante

Backups VM conterá informações antigas do protetor de chave que permitem que os certificados antigos ser usado para iniciar a VM. Caso você esteja ciente de que sua chave particular foi comprometida, você deve presumir que os backups VM podem ser comprometidos, também e tomar a ação apropriada. Destruir a VM a configuração de (.vmcx) os backups removerá os protetores de chave, às custas de necessidade de usar a senha de recuperação do BitLocker para inicializar a VM na próxima vez.

Chave replicação entre nós

Cada nó no cluster HGS deve ser configurado com a mesma criptografia, assinatura e (quando configurado) certificados SSL. Isso é necessário para garantir que os hosts de Hyper-V entrar em contato com a qualquer nó em cluster podem ter suas solicitações atendidas com êxito.

Se você inicializou o servidor HGS com certificados baseados em PFX e HGS replicará automaticamente a chave pública e privada desses certificados em cada nó no cluster. Você só precisa adicioná-las em um nó.

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

  1. Instale a chave privada em cada nó HGS
  2. Conceda HGS grupo gerenciado acesso à conta service (gMSA) para a chave privada em cada nó que essas tarefas Adicionar carga operacional extra, mas elas são necessárias para backup HSM chaves e certificados com chaves privadas não exportable.

Certificados SSL nunca são replicadas em qualquer forma. É sua responsabilidade para inicializar cada servidor HGS com o mesmo certificado SSL e atualizar cada servidor sempre que você escolher renovar ou substituir o certificado SSL. Quando substituindo o certificado SSL, é recomendável que você faz isso usando o conjunto HgsServer cmdlet.

HGS unconfiguring

Se você precisar desativarem ou significativamente reconfigurar um servidor HGS, você pode fazê-lo usando o limpar HgsServer ou desinstalar HgsServer cmdlets.

Limpando a configuração HGS

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

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

Se o servidor é o último nó HGS no cluster, o cluster e ele é correspondente nome da rede distribuído recurso também será destruído.

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

Depois que a operação clear é concluída, o servidor HGS pode ser reinicializado com Initialize HgsServer. Se você usou instalar HgsServer para configurar um domínio do Active Directory Domain Services, esse domínio permanecerá configurado e operacionais após a operação clara.

Desinstalando HGS

Se você quiser remover um nó de cluster HGS e rebaixar o controlador de domínio Active Directory em execução, use o desinstalar HgsServer cmdlet. Este cmdlet fará as seguintes alterações no servidor em que ele é executado:

  • Os serviços de proteção de chave e de Atestado cancela o registro
  • Remove o ponto de extremidade de gerenciamento de JEA "microsoft.windows.hgs"
  • Remove o computador local do cluster de failover HGS
  • Rebaixa o controlador de domínio Active Directory, se configurado

Se o servidor é o último nó HGS no cluster, o domínio, cluster de failover e distribuído recurso nome da rede do cluster também serão destruídas.

# 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 seja concluída e o computador for reiniciado, você poderá reinstalar ADDC e HGS usando instalar HgsServer ou ingressar o computador em um domínio e inicialize o servidor HGS nesse domínio com Initialize HgsServer.

Se você não pretende usar o computador como um nó HGS, você pode remover a função do Windows.

Uninstall-WindowsFeature HostGuardianServiceRole
© 2017 Microsoft