Solucionar problemas do Serviço Guardião do Host

Artigo
12/26/2023

Este artigo descreve resoluções para problemas comuns encontrados ao implantar ou operar um servidor do HGS (Serviço Guardião do Host) em um tecido protegido.

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 protegido em seus servidores HGS e hosts Hyper-V para reduzir as causas potenciais.

Certificados

O HGS requer vários certificados para operar, incluindo o certificado de criptografia e assinatura configurado pelo administrador, bem como 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 relacionados aos certificados configurados no HGS.

Permissões de certificado

O HGS deve ser capaz de acessar as chaves públicas e privadas dos certificados de criptografia e de assinatura adicionados ao HGS pela impressão digital do certificado. Especificamente, a gMSA (conta de serviço gerenciada por grupo) que executa o serviço HGS precisa de acesso às chaves. Para localizar o gMSA usado pelo HGS, execute o seguinte comando em um prompt do PowerShell elevado em seu servidor HGS:

(Get-IISAppPool -Name KeyProtection).ProcessModel.UserName

A forma como você concede acesso à conta gMSA para usar a chave privada depende de onde a chave é armazenada: no computador como um arquivo de certificado local, em um HSM (módulo de segurança de hardware) ou usando um provedor de armazenamento de chaves de terceiros personalizado.

Conceder acesso a chaves privadas com suporte de software

Se você estiver usando um certificado autoassinado ou um certificado emitido por uma autoridade de certificado que não está armazenado em um módulo de segurança de hardware ou um provedor de armazenamento de chaves personalizado, poderá alterar as permissões de chave privada executando as seguintes etapas:

Abra o gerenciador de certificados local (certlm.msc).
ExpandaCertificadosPessoais> 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 do HGS encontrado anteriormente e selecione OK.
Verifique se o 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 Do PowerShell do Guarded Fabric Tools, que permitirá gerenciar as permissões no PowerShell.

Abra um console do PowerShell elevado no computador Server Core ou use o PowerShell Remoting com uma conta que tenha permissões de administrador local no HGS.
Execute os comandos a seguir para instalar o módulo Do PowerShell do Guarded Fabric Tools 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 com suporte de provedor personalizado ou HSM

Se as chaves privadas do certificado forem apoiadas por um HSM (módulo de segurança de hardware) ou um KSP (provedor de armazenamento de chaves personalizada), o modelo de permissão dependerá do fornecedor de software específico. Para obter os melhores resultados, consulte a documentação ou o site de suporte do fornecedor para obter informações sobre como as permissões de chave privada são tratadas para seu dispositivo/software específico. Em todos os casos, o gMSA usado pelo HGS requer permissões de leitura nas chaves privadas de certificado de criptografia, assinatura e comunicações para que possa executar operações de assinatura e criptografia.

Alguns módulos de segurança de hardware não dão suporte à concessão de acesso de contas de usuário específicas a uma chave privada; em vez disso, eles permitem o acesso da conta de computador a 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

Veja abaixo as opções de configuração sugeridas para ajudá-lo a usar com êxito as chaves apoiadas por HSM com o HGS com base nas experiências da Microsoft e de seus parceiros. Essas dicas são fornecidas para sua conveniência e não são garantidas como corretas no momento da leitura, nem são endossadas pelos fabricantes de HSM. Entre em contato com o fabricante do HSM para obter informações precisas relativas ao dispositivo específico se você tiver mais perguntas.

HSM Brand/Series	Suggestion
Gemalto SafeNet	Verifique se a Propriedade de Uso de Chave no arquivo de solicitação de certificado está definida como 0xa0, permitindo que o certificado seja usado para assinatura e criptografia. Além disso, você deve conceder à conta gMSA acesso de leitura à chave privada usando a ferramenta do gerenciador de certificados local (consulte 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. Além disso, você pode precisar conceder ao gMSA acesso de leitura à chave privada usando o gerenciador de certificados local (consulte etapas acima).
Utimaco CryptoServers	Verifique se a Propriedade de Uso de Chave no arquivo de solicitação de certificado está definida como 0x13, permitindo que o certificado seja usado para criptografia, descriptografia e assinatura.

Solicitações de certificado

Se você estiver usando uma autoridade de certificado para emitir seus certificados em um ambiente 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 necessário
Algoritmo	RSA
Tamanho da chave	Pelo menos 2048 bits
Uso de chave	Assinatura/Sinal/DigitalSignature

Certificados de criptografia

Propriedade CSR	Valor necessário
Algoritmo	RSA
Tamanho da chave	Pelo menos 2048 bits
Uso de chave	Criptografia/Criptografar/DataEncipherment

Modelos do Active Directory Certificate Services

Se você estiver usando modelos de certificado do ADCS (Active Directory Certificate Services) para criar os certificados, recomendamos que você use um modelo com as seguintes configurações:

Propriedade de modelo do ADCS	Valor necessário
Categoria provedor	Provedor de armazenamento de chaves
Nome do algoritmo	RSA
Tamanho mínimo da chave	2048
Objetivo	Assinatura e criptografia
Extensão de uso de chave	Assinatura Digital, Encipherment de Chave, Encipherment de Dados ("Permitir criptografia de dados do usuário")

Desvio de tempo

Se o tempo do servidor tiver se afastado significativamente do de outros nós HGS ou hosts hyper-V em seu tecido protegido, você poderá encontrar problemas com a validade do certificado do signatário de atestado. O certificado do signatário de atestado é criado e renovado nos bastidores do HGS e é usado para assinar certificados de integridade emitidos para hosts protegidos pelo Serviço de Atestado.

Para atualizar o certificado do signatário de atestado, execute o comando a seguir em um prompt do PowerShell elevado.

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 > de Agendadores de TarefasMicrosoft Windows>>HGSServer e executando a tarefa chamada AttestationSignerCertRenewalTask.

Alternar modos de atestado

Se você alternar o HGS do modo TPM para o modo Active Directory ou vice-versa usando o cmdlet Set-HgsServer , pode levar até 10 minutos para que cada nó no cluster do HGS comece a impor o novo modo de atestado.

Isso é um 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 o uso do novo modo de atestado.

Problema conhecido ao alternar do TPM para o modo AD

Se você inicializou seu cluster HGS no modo TPM e posteriormente mudar para o modo Active Directory, haverá um problema conhecido que impede que outros nós no cluster do HGS mudem para o novo modo de atestado. Para garantir que todos os servidores HGS estejam aplicando o modo de atestado correto, execute Set-HgsServer -TrustActiveDirectory em cada nó do cluster do HGS.

Esse problema não se aplica se você estiver mudando do modo TPM para o modo AD e o cluster foi originalmente configurado no modo AD.

Você pode verificar o modo de atestado do 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 o servidor HGS para a atualização cumulativa mais recente do Windows e ative as novas políticas de atestado.

Certifique-se de atualizar seus hosts do 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 do 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 identificador de plataforma fornecido: o certificado de chave de endosso (EKcert) e a chave de endosso público (EKpub). O EKcert identifica o fabricante do TPM, fornecendo garantias de que o TPM é autêntico e fabricado por meio da cadeia de suprimentos normal. O EKpub identifica exclusivamente esse TPM específico e é uma das medidas que o HGS usa para conceder acesso a um host para executar VMs blindadas.

Você receberá um erro ao registrar um host TPM se uma das duas condições for verdadeira:

O arquivo identificador de plataforma não contém um certificado de chave de endosso.
O arquivo identificador de plataforma contém um certificado de chave de endosso, mas esse certificado não é confiável em seu sistema.

Certos fabricantes de TPM não incluem EKcerts em seus TPMs.

Se você suspeitar que esse é o caso do TPM, confirme com o OEM que seus TPMs não devem ter um EKcert e use o -Force sinalizador para registrar manualmente o host com HGS. Se o TPM deve ter um EKcert, mas um não foi encontrado no arquivo identificador de plataforma, verifique se você está usando um console do PowerShell 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 TPM confiáveis em cada servidor HGS e que 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ário, você deve ser capaz de executar Add-HgsAttestationTpmHost com êxito.

Privilégios da conta de serviço gerenciada por grupo (gMSA)

A conta de serviço do HGS (gMSA usada para o pool de aplicativos do Serviço de Proteção de Chaves no IIS) precisa receber o privilégio Gerar auditorias de segurança , também conhecido como SeAuditPrivilege. Se esse privilégio estiver ausente, a configuração inicial do HGS terá êxito e o IIS será iniciado, no entanto, o Serviço de Proteção de Chave não é funcional e retorna o erro HTTP 500 ("Erro do 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)

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 notar que nenhum dos cmdlets do Serviço de Proteção de Chaves (por exemplo, Get-HgsKeyProtectionCertificate) funciona e, em vez disso, retorna erros.

Para resolve esse problema, você precisa conceder ao gMSA a "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ê pode usar SecEdit.exe ferramenta para exportar a política de segurança atual, fazer as edições necessárias no arquivo de configuração (que é um texto simples) e importá-la de volta.

Observação

Ao configurar essa configuração, a lista de princípios de segurança definidos para um privilégio substitui totalmente os padrões (ele não concatenia). 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 do gMSA que você está adicionando.

Compartilhar via