Solucionar problemas do Serviço Guardião de Host
Este artigo descreve resoluções de problemas comuns encontrados durante a implantação ou a operação de um servidor HGS (Serviço Guardião de Host) em uma malha protegida.
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016
Se você não tiver certeza da natureza do problema, primeiro tente executar o diagnóstico de malha protegida em seus servidores HGS e hosts Hyper-V para restringir as possíveis causas.
Certificados
O HGS exige vários certificados para funcionar, incluindo o certificado de assinatura e criptografia configurada pelo administrador, além de um certificado de atestado gerenciado pelo próprio HGS. Se esses certificados estiverem configurados incorretamente, o HGS não poderá atender a solicitações de hosts Hyper-V que desejam atestar ou desbloquear protetores de chave para VMs blindadas. As seções a seguir abordam problemas comuns relativos a certificados configurados no HGS.
Permissões de certificado
O HGS precisa ser capaz de acessar tanto as chaves públicas quanto privadas dos certificados de assinatura e criptografia adicionados ao HGS pela impressão digital do certificado. Mais especificamente, a gMSA (conta do serviço gerenciado de grupo) que executa o serviço HGS precisa de acesso a essas chaves. Para encontrar a gMSA usada pelo HGS, execute o seguinte comando em um prompt do PowerShell com privilégios elevados no seu servidor HGS:
(Get-IISAppPool -Name KeyProtection).ProcessModel.UserName
Como você concede acesso à conta gMSA para uso da chave privada depende de onde a chave está armazenada: no computador como arquivo de certificado local, em um HSM (módulo de segurança de hardware) ou pelo uso de um provedor de armazenamento de chave terceirizado personalizado.
Conceder acesso a chaves privadas apoiadas por software
Se você estiver usando um certificado autoassinado ou um certificado emitido por uma autoridade de certificação que não esteja armazenado em um módulo de segurança de hardware ou provedor de armazenamento de chave personalizada, poderá alterar as permissões de chave privada executando as seguintes etapas:
- Abra o gerenciador de certificados local (certlm.msc).
- Expanda Certificados Pessoais> e localize o certificado de assinatura ou criptografia que você deseja atualizar.
- Clique com o botão direito do mouse no certificado e selecione Todas as Tarefas>Gerenciar Chaves Privadas.
- Selecione Adicionar para conceder um novo acesso de usuário à chave privada do certificado.
- No seletor de objetos, insira o nome da conta gMSA para o HGS encontrada anteriormente e selecione OK.
- Verifique se a gMSA tem acesso de Leitura ao certificado.
- Selecione OK para fechar a janela de permissão.
Se você estiver executando o HGS no Server Core ou estiver gerenciando o servidor remotamente, não poderá gerenciar chaves privadas usando o gerenciador de certificados local. Em vez disso, você precisa baixar o módulo PowerShell Guarded Fabric Tools, que permitirá que você gerencie as permissões no PowerShell.
- Abra um console do PowerShell com privilégios elevados no computador do Server Core ou use a Comunicação Remota do PowerShell com uma conta que tenha permissões de administrador no HGS.
- Execute os comandos a seguir para instalar o módulo do PowerShell Ferramentas de Malha Protegida e conceder à conta gMSA acesso à chave privada.
$certificateThumbprint = '<ENTER CERTIFICATE THUMBPRINT HERE>'
# Install the Guarded Fabric Tools module, if necessary
Install-Module -Name GuardedFabricTools -Repository PSGallery
# Import the module into the current session
Import-Module -Name GuardedFabricTools
# Get the certificate object
$cert = Get-Item "Cert:\LocalMachine\My\$certificateThumbprint"
# Get the gMSA account name
$gMSA = (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName
# Grant the gMSA read access to the certificate
$cert.Acl = $cert.Acl | Add-AccessRule $gMSA Read Allow
Conceder acesso a chaves privadas apoiadas pelo provedor personalizado ou HSM
Se as chaves privadas do certificado forem apoiadas por um módulo de segurança de hardware (HSM) ou um provedor de armazenamento de chave personalizada (KSP), o modelo de permissão dependerá do seu fornecedor de software específico. Para os melhores resultados, confira a documentação ou o site de suporte do seu fornecedor para mais informações sobre como as permissões de chave privada do seu dispositivo/software específico são tratadas. Em todo caso, a gMSA usada pelo HGS exige permissões de leitura nas chaves privadas dos certificados de criptografia, assinatura e comunicações para poder fazer as operações de assinatura e criptografia.
Alguns módulos de segurança de hardware não dão suporte à concessão de acesso a contas de usuário específicas a uma chave privada; em vez disso, eles permitem que a conta do computador acesse todas as chaves em um conjunto de chaves específico. Para esses dispositivos, geralmente é suficiente dar ao computador acesso às suas chaves e o HGS é capaz de aproveitar essa conexão.
Dicas para HSMs
Abaixo estão opções de configurações sugeridas para ajudar você a usar chaves apoiadas por HSM com êxito em HGS com base nas experiências da Microsoft e de seus parceiros. Essas dicas são fornecidas para sua conveniência e não têm garantia de estarem corretas no momento da leitura, nem são endossadas pelos fabricantes do HSM. Contate seu fabricante de HSM para obter informações precisas sobre seu dispositivo específicos em caso de dúvida.
| Marca/série do HSM | Sugestão |
|---|---|
| Gemalto SafeNet | Verifique se a Propriedade de Uso da Chave no arquivo de solicitação de certificado está definida como 0xa0, o que permite que o certificado seja usado para assinatura e criptografia. Além disso, você precisa conceder à conta gMSA acesso de leitura à chave privada usando a ferramenta gerenciadora de certificados local (confira as etapas acima). |
| nCipher nShield | Verifique se cada nó HGS tem acesso ao mundo de segurança que contém as chaves de assinatura e criptografia. Você pode também ter que conceder à gMSA acesso de leitura à chave privada usando o gerenciador de certificado local (confira as etapas acima). |
| Utimaco CryptoServers | Verifique se a Propriedade de Uso da Chave no arquivo de solicitação de certificado está definida como 0x13, o que permite que o certificado seja usado para assinatura, criptografia e descriptografia. |
Solicitações de certificado
Se você estiver usando uma autoridade de certificação para emitir seus certificados em um ambiente de PKI (infraestrutura de chave pública), precisará garantir que sua solicitação de certificado inclua os requisitos mínimos para o uso dessas chaves pelo HGS.
Certificados de autenticação
| Propriedade CSR | Valor obrigatório |
|---|---|
| Algoritmo | RSA |
| Key size | Pelo menos 2048 bits |
| Uso de chave | Assinatura/Sign/DigitalSignature |
Certificados de criptografia
| Propriedade CSR | Valor obrigatório |
|---|---|
| Algoritmo | RSA |
| Key size | Pelo menos 2048 bits |
| Uso de chave | Criptografia/Encrypt/DataEncipherment |
Modelos de Serviços de Certificados do Active Directory
Se você estiver usando modelos de certificado ADCS (Serviços de Certificados do Active Directory) para criar os certificados, recomendamos que você use um modelo com as seguintes configurações:
| Propriedade do modelo ADCS | Valor obrigatório |
|---|---|
| Categoria do provedor | Provedor de armazenamento de chaves |
| Nome do algoritmo | RSA |
| Tamanho mínimo de chave | 2.048 |
| Finalidade | Assinatura e criptografia |
| Extensão de uso de chave | Assinatura digital, Criptografia de Chave, Criptografia de Dados (“Permitir criptografia de dados do usuário”) |
Desvio do tempo
Se a hora do seu servidor se desviou muito da hora de outros nós HGS ou hosts Hyper-V na malha protegida, você poderá ver problemas na validade do certificado de assinatura do atestado. O certificado de assinatura do atestado é criado e renovado nos bastidores no HGS e é usado para assinar certificados de integridade emitidos para hosts protegidos pelo Serviço de Atestado.
Para atualizar o certificado de assinatura do atestado, execute o comando a seguir em um prompt do PowerShell com privilégios elevados.
Start-ScheduledTask -TaskPath \Microsoft\Windows\HGSServer -TaskName
AttestationSignerCertRenewalTask
Como alternativa, você pode executar manualmente a tarefa agendada abrindo o Agendador de Tarefas (taskschd.msc), navegando até a Biblioteca>do Agendador de Tarefas Microsoft>Windows>HGSServer e executando a tarefa chamada AttestationSignerCertRenewalTask.
Alternando modos de atestado
Se você mudar o HGS do modo TPM para o modo Active Directory ou vice-versa usando o cmdlet Set-HgsServer, poderá demorar até 10 minutos para que cada nó em seu cluster do HSG comece a impor o novo modo de atestado.
Esse comportamento é normal.
É recomendável que você não remova nenhuma política que permita hosts do modo de atestado anterior até verificar se todos os hosts estão atestando com êxito usando o novo modo de atestado.
Problema conhecido na mudança dos modos TPM para AD
Se você inicializou o cluster do HGS no modo TPM e depois alternou para o modo Active Directory, há um problema conhecido que impede que outros nós no cluster do HGS alternem para o novo modo de atestado.
Para garantir que todos os servidores HGS estejam impondo o modo de atestado correto, execute Set-HgsServer -TrustActiveDirectory em cada nó do cluster HGS.
Esse problema não se aplica se você estiver alternando do modo TPM para o modo AD e o cluster tiver sido originalmente configurado no modo AD.
Você pode verificar o modo de atestado do seu servidor HGS executando Get-HgsServer.
Políticas de criptografia de despejo de memória
Se você estiver tentando configurar políticas de criptografia de despejo de memória e não vir as políticas de despejo padrão do HGS (Hgs_NoDumps, Hgs_DumpEncryption e Hgs_DumpEncryptionKey) ou o cmdlet de política de despejo (Add-HgsAttestationDumpPolicy), é provável que você não tenha a atualização cumulativa mais recente instalada.
Para corrigir isso, atualize seu servidor HGS com a atualização do Windows cumulativa mais recente e ative as novas políticas de atestado.
Certifique-se de atualizar seus hosts Hyper-V para a mesma atualização cumulativa antes de ativar as novas políticas de atestado, pois os hosts que não têm os novos recursos de criptografia de despejo instalados provavelmente falharão no atestado depois que a política HGS for ativada.
Mensagens de erro de certificado de chave de endosso
Quando você registra um host usando o cmdlet Add-HgsAttestationTpmHost , dois identificadores TPM são extraídos do arquivo de identificador de plataforma fornecido: o certificado de chave de endosso (EKcert) e a chave de endosso pública (EKpub). O EKcert identifica o fabricante do TPM, assegurando que o TPM é autêntico e foi fabricado por uma cadeia logística normal. O EKpub identifica esse TPM de forma exclusiva e é uma das medidas que o HGS usa para conceder a um host acesso para executar VMs blindadas.
Você receberá um erro ao registrar um host TPM se uma das duas condições for verdadeira:
- O arquivo de identificador de plataforma não contém um certificado de chave de endosso.
- O arquivo de identificador de plataforma contém um certificado de chave de endosso, mas esse certificado não é confiável em seu sistema.
Determinados fabricantes de TPM não incluem EKcerts em seus TPMs.
Se você suspeita que esse é o caso com seu TPM, confirme com seu OEM que seus TPMs não devem ter um EKcert e use o sinalizador -Force para registrar manualmente o host no HGS.
Se o TPM deve ter um EKcert, mas um não foi encontrado no arquivo de identificador de plataforma, verifique se você está usando um console do PowerShell de administrador (elevado) ao executar Get-PlatformIdentifier no host.
Se você recebeu o erro de que seu EKcert não é confiável, verifique se você instalou o pacote de certificados raiz do TPM confiável em cada servidor HGS e se o certificado raiz do fornecedor do TPM está presente no repositório "TrustedTPM_RootCA" do computador local. Todos os certificados intermediários aplicáveis também precisam ser instalados no repositório "TrustedTPM_IntermediateCA" no computador local.
Depois de instalar os certificados raiz e intermediários, você deverá poder executar Add-HgsAttestationTpmHost com êxito.
Privilégios da gMSA (conta do serviço gerenciado de grupo)
A conta do serviço HGS (gMSA usada para o pool de aplicativos do Serviço de Proteção de Chaves no IIS) precisa receber privilégio de Gerar auditorias de segurança, também conhecido como SeAuditPrivilege. Se esse privilégio estiver ausente, a configuração inicial do HGS será bem-sucedida e o IIS será iniciado, no entanto, o Serviço de Proteção de Chave não funcionará e retornará o erro HTTP 500 ("Erro de Servidor no Aplicativo /KeyProtection"). Você também pode observar as seguintes mensagens de aviso no log de eventos do aplicativo.
System.ComponentModel.Win32Exception (0x80004005): A required privilege is not held by the client
at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.NativeUtility.RegisterAuditSource(String pszSourceName, SafeAuditProviderHandle& phAuditProvider)
at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.SecurityLog.RegisterAuditSource(String sourceName)
ou
Failed to register the security event source.
at System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app)
at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)
Failed to register the security event source.
at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.SecurityLog.RegisterAuditSource(String sourceName)
at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.SecurityLog.ReportAudit(EventLogEntryType eventType, UInt32 eventId, Object[] os)
at Microsoft.Windows.KpsServer.KpsServerHttpApplication.Application_Start()
A required privilege is not held by the client
at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.NativeUtility.RegisterAuditSource(String pszSourceName, SafeAuditProviderHandle& phAuditProvider)
at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.SecurityLog.RegisterAuditSource(String sourceName)
Além disso, você pode observar que nenhum dos cmdlets do Serviço de Proteção de Chave (por exemplo, Get-HgsKeyProtectionCertificate) funciona e, em vez disso, retorna erros.
Para resolver esse problema, você precisa conceder à gMSA a opção "Gerar auditorias de segurança" (SeAuditPrivilege). Para fazer isso, você pode usar a política de segurança local SecPol.msc em cada nó do cluster HGS ou Política de Grupo. Como alternativa, você poderia usar a ferramenta SecEdit.exe para exportar a política de segurança atual, fazer as edições necessárias no arquivo de configuração (que está em texto sem formatação) e importá-la novamente.
Observação
Ao definir essa configuração, a lista de princípios de segurança definidos para um privilégio substitui totalmente os padrões (ela não concatena). Portanto, ao definir essa configuração de política, certifique-se de incluir os dois detentores padrão desse privilégio (serviço de rede e serviço local), além da gMSA que você está adicionando.