HVCI no Windows: integridade da memória, drivers e bloqueio UEFI

O que é HVCI no Windows para a integridade da memória?

HVCI no Windows protege através da integridade da memória, uma proteção do Windows que executa a integridade do código do kernel no ambiente isolado fornecido pela segurança baseada em virtualização (VBS). A sua implementação exige três respostas separadas: qual é a configuração pretendida, se a integridade da memória está realmente em execução em cada dispositivo de destino e se a recuperação continua a ser possível após a escolha do modo de bloqueio UEFI. Uma GPO de domínio, por si só, responde apenas a parte da primeira pergunta. Orientações de ativação da Microsoft

Para uma equipa AD, o resultado útil é uma implementação testada com evidências por dispositivo. Comece com uma população representativa, resolva as dependências dos drivers, meça o serviço após o reinício e registe a decisão sobre o bloqueio. Inclua no relatório as máquinas que não puderam ser medidas; omiti-las silenciosamente faz a cobertura da política parecer proteção verificada.

Este guia utiliza documentação Microsoft Learn verificada em 3 de outubro de 2026 e as duas verificações do collector descritas abaixo. Os comandos Windows são exemplos da documentação ou adaptações identificadas apenas de leitura; não foram executados num parque Windows para este artigo. Não se afirma qualquer cobertura do parque nem a realização de um teste de compatibilidade bem-sucedido.

O nosso guia de Credential Guard após uma atualização utiliza o mesmo método de evidências WMI para um serviço diferente: o isolamento de determinados segredos. A integridade da memória diz respeito à integridade do código do kernel. Provar que um serviço está em execução não estabelece que o outro também está.

Como diferem a política, o estado de execução e o bloqueio UEFI

O mesmo número tem significados diferentes consoante a definição. A referência da política VirtualizationBasedTechnology da Microsoft documenta o modo da política e o seu mapeamento para a GPO Device Guard. A página de ativação documenta separadamente os valores locais Enabled e Locked.

Os caminhos locais da tabela encontram-se sob HKLM\SYSTEM\CurrentControlSet\Control. O valor da política encontra-se sob HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard. Não escreva Enabled=2 para reproduzir o modo sem bloqueio da política. Não interprete um identificador de serviço WMI como um modo do registo. Preserve o caminho completo e o nome do valor nas evidências, para que outro administrador possa interpretá-los sem reconstruir a recolha.

Um registo de alteração útil mantém a intenção da política, a política aplicada, as definições locais e a observação do estado de execução como campos separados. Se uma GPO especificar um modo enquanto um endpoint apresentar outro, investigue a configuração aplicada antes de considerar a alteração concluída. Se as definições coincidirem, mas o estado de execução diferir, investigue o endpoint em vez de editar repetidamente a mesma GPO.

O bloqueio UEFI também altera a decisão de recuperação. O procedimento GPO da Microsoft permite uma implementação sem bloqueio e alerta que selecionar o modo com bloqueio restringe a desativação remota. Decida quem pode aceder ao menu do firmware e recuperar a máquina antes de incorporar essa restrição na administração de produção. Instruções GPO da Microsoft

Deteção: recolher evidências no dispositivo de destino

Utilize uma sessão PowerShell com privilégios elevados no destino. A Microsoft fornece este comando na sua referência Win32_DeviceGuard:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

A seguinte adaptação apenas de leitura seleciona os campos necessários para esta investigação:

$state = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
$state | Select-Object SecurityServicesConfigured, SecurityServicesRunning, VirtualizationBasedSecurityStatus

Interprete os arrays de serviços pela presença dos valores. Um resultado que contenha tanto 1 como 2 inclui a integridade da memória; 1 identifica Credential Guard. VirtualizationBasedSecurityStatus=2 descreve VBS em execução, enquanto a presença de 2 em SecurityServicesRunning identifica a integridade da memória em execução. Definições das propriedades WMI da Microsoft

Trate a recolha como uma observação com host, momento e contexto de arranque. Guarde os arrays completos, mesmo que o painel apresente posteriormente um valor booleano. Distinga uma consulta bem-sucedida sem integridade da memória de uma consulta que falhou. Falhas de autenticação, dispositivos inacessíveis e resultados em falta pertencem a uma categoria desconhecida com uma ação de seguimento.

Comparar a política e as definições locais de bloqueio

Esta adaptação PowerShell apenas de leitura lê as definições identificadas; caminhos ou valores em falta devem ser registados como ausentes, sem serem silenciosamente substituídos por zero:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard' -Name HypervisorEnforcedCodeIntegrity
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity' -Name Enabled, Locked
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard' -Name EnableVirtualizationBasedSecurity, RequirePlatformSecurityFeatures, Locked

Compare estas observações com o modo aprovado e um relatório da política resultante para esse host. Uma definição exportada de uma GPO sem relação com o destino não é evidência suficiente de que o destino a recebeu. Registe configurações em conflito e erros de recolha em vez de os transformar numa simples classificação de protegido/não protegido.

As propriedades documentadas de Win32_DeviceGuard acima não fornecem uma propriedade Locked. Leia separadamente os marcadores do registo identificados. Descrevem a configuração do bloqueio e não devem ser apresentados como uma atestação independente do firmware. Da mesma forma, um resultado CIM que mostre a integridade da memória em execução não prova que o bloqueio UEFI é imposto. Referência de configuração e validação da Microsoft

Compatibilidade dos drivers: conceber um piloto que exercite o trabalho real

As orientações de compatibilidade dos drivers da Microsoft combinam verificações Code Integrity no Driver Verifier, testes funcionais com a integridade da memória ativada e o Windows HLK HyperVisor Code Integrity Readiness Test. Distinguem a preparação para assinatura dos testes funcionais completos. Um driver carregado durante um arranque não exerceu necessariamente todos os caminhos de execução relevantes.

Para o responsável por um driver ou uma equipa de engenharia, o comando Verifier documentado é:

verifier.exe /flags 0x02000000 /driver <driver.sys>

Substitua o marcador pelo driver selecionado num ambiente de teste que possa ser recuperado. Driver Verifier é uma ferramenta de teste, não um comando para distribuir indiscriminadamente pelos endpoints de produção. Registe o driver selecionado, as condições de teste, os resultados e a via de recuperação. Coordene as falhas com o fornecedor do driver em vez de tratar uma desativação permanente como a única solução.

Para a equipa de implementação, construa uma matriz de modelos de dispositivos, revisões de firmware, builds Windows, pacotes de drivers e fluxos de trabalho de negócio. Inclua as combinações realmente presentes na população de destino. Escolha máquinas piloto que exponham diferenças relevantes; um conjunto conveniente de portáteis idênticos pode deixar outras famílias de hardware por testar.

Teste o trabalho que essas máquinas têm de realizar: arranque, periféricos, aplicações necessárias e as suas operações dependentes de drivers. Defina os resultados esperados antes de começar e associe as falhas a um pacote e a um responsável identificados. São recomendações de implementação, não uma afirmação de que uma determinada aplicação ou dispositivo do seu ambiente é incompatível.

Atribua a cada exceção um motivo, a população afetada, um responsável, a correção prevista e uma data de revisão. Separe uma falha de compatibilidade demonstrada da suposição de que uma exceção antiga continua a ser necessária. Peça aos fornecedores um pacote atualizado ou evidências de teste de suporte e volte a executar o fluxo de trabalho relevante com a integridade da memória ativa. O inventário de exceções delimita a próxima vaga de implementação.

Correção: implementar a GPO por fases e comprovar o resultado após reinício (Remediation)

1. Aprovar a população e o plano de recuperação

Atribua responsáveis pela revisão do hardware, testes de drivers, alterações GPO e recuperação. Registe o modo de bloqueio pretendido, o âmbito do piloto e as exclusões antes de editar a política. Defina uma regra de aceitação que exija tanto uma observação do estado de execução como a aprovação dos fluxos de trabalho necessários; a simples criação de uma GPO não deve encerrar a tarefa.

Para estações de trabalho de administração, enquadre esta decisão na arquitetura mais ampla descrita no nosso guia ANSSI para Active Directory: vias de administração, utilização dedicada e fronteiras de confiança. Reforçar uma funcionalidade Windows não demonstra que a arquitetura de administração é sólida nem estabelece conformidade ANSSI.

2. Aplicar uma configuração suportada com âmbito limitado

Siga o procedimento GPO da Microsoft em Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security. Ative a política e selecione a opção pretendida em Virtualization Based Protection of Code Integrity. Ligue e filtre a GPO para a população piloto aprovada; inspecione a política aplicada ao destino antes de alargar o âmbito. Procedimento de implementação da Microsoft

O comando documentado de atualização da política, executado num Command Prompt com privilégios elevados, é:

gpupdate /force

Agende um reinício para a recolha de evidências do piloto. Após o arranque, repita a observação CIM e a comparação das definições locais. Registe os arrays e o modo observados junto do pedido de alteração. Não deduza um resultado para todo o parque a partir de uma máquina bem-sucedida; cada destino não medido mantém o seu próprio estado por resolver.

3. Documentar a recuperação antes de selecionar o bloqueio UEFI

Para instabilidade após a ativação, o procedimento de resolução de problemas da Microsoft começa por desativar as políticas de ativação, passando depois a utilizar Windows Recovery Environment (Windows RE) para definir o valor Enabled do cenário como 0 e reiniciar. O comando documentado é:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 0 /f

Construa o procedimento operacional de recuperação específico da máquina com base nesse processo. Valide o acesso a Windows RE e ao registo da instalação afetada, identifique o operador e teste como será retirada a política de ativação. Não suponha que uma alteração normal do registo por acesso remoto pode recuperar uma máquina incapaz de arrancar.

Com bloqueio UEFI, a Microsoft exige adicionalmente a desativação de Secure Boot para concluir esses passos de recuperação. Esse requisito torna o acesso ao firmware parte do plano. Selecione o bloqueio apenas quando a via física de recuperação, o operador autorizado e o procedimento de reversão estiverem documentados. Inclua no procedimento operacional a reposição da configuração de firmware aprovada e a revalidação. Orientações de recuperação da Microsoft

4. Expandir com base nas evidências conservadas

Reveja as observações e as falhas do piloto antes da vaga seguinte. Preserve as exceções e os dispositivos desconhecidos no mesmo inventário que as medições bem-sucedidas. Volte a verificar após alterações relevantes dos drivers ou da plataforma. Um registo de encerramento útil contém a política aprovada, o âmbito de destino, o contexto de arranque, a evidência de serviços em execução, o resultado dos testes funcionais e o responsável pela recuperação.

Como a EtcSec deteta este problema

O etc-collector da EtcSec disponibiliza duas verificações de configuração GPO para este tema. O comportamento seguinte provém das ramificações reais de Detect(), não de um teste de endpoints:

gpoSetsAtLeast e gpoMaxValue percorrem as GPOs recolhidas, ignoram objetos de política/definições em falta e ignoram valores não definidos. O máximo começa em -1. O parser Registry.pol mapeia um DWORD chamado HypervisorEnforcedCodeIntegrity numa chave que contém deviceguard para HVCIEnabled. Não obtém as medições separadas Enabled e Locked do cenário de execução.

O máximo é um agregado numérico, não uma classificação de segurança nem um cálculo da precedência das GPOs. Se uma política tiver 1 e outra tiver 2, o máximo é 2 e a verificação Low é acionada. Valores acima de 2 também entram nessa mesma ramificação de constatação, porque o código não valida o enum. Não são modos de bloqueio válidos documentados e devem ser investigados como dados inesperados.

Count 1 é a contagem de constatações do detetor, não uma contagem de endpoints expostos. Nenhuma das verificações calcula o Resultant Set of Policy (RSoP) por máquina, avalia ligações/filtragem GPO ou consulta o estado de execução por WMI. Uma definição positiva em qualquer ponto pode suprimir a verificação OFF mesmo quando a cobertura dos destinos é incompleta. A ausência de um valor GPO pode coexistir com ativação através de outro mecanismo; não estabelece que a integridade da memória está desativada em execução.

Utilize estas verificações para iniciar a investigação da política e acrescente depois evidências independentes dos dispositivos. Os nomes e comentários dos detetores não provam, por si só, conformidade ANSSI, bloqueio efetivo do firmware, compatibilidade dos drivers ou proteção bem-sucedida em todo o parque. Essas conclusões precisam de evidências e revisão próprias.

Fontes

• Microsoft Learn: ativar a integridade da memória, GPO, registo, WMI e recuperação
• Microsoft Learn: compatibilidade dos drivers com integridade da memória e VBS
• Microsoft Learn: valores da política VirtualizationBasedTechnology e mapeamento GPO