Verificacao de politicas App Control: WDAC além do marcador GPO

O que é a verificação de políticas do App Control?

A verificação de políticas do App Control estabelece quais políticas do App Control for Business um dispositivo Windows possui, como chegaram ao dispositivo e se o comportamento observado corresponde às regras de aplicações aprovadas. Um Objeto de Política de Grupo (GPO) que contém um caminho de implementação descreve a intenção de configuração. Não estabelece que o dispositivo de destino obteve o binário, carregou a versão pretendida ou a aplicou.

Para uma equipa de Active Directory que investiga uma constatação sobre a implementação do WDAC, o resultado útil é um registo de evidências específico de cada dispositivo. Identifique a política e o responsável pela sua distribuição, teste os fluxos de trabalho necessários em modo de auditoria, reveja as regras propostas e aprove a aplicação efetiva com um caminho de recuperação. Mantenha os dispositivos inacessíveis e as medições em falta visíveis como casos por resolver.

Este guia utiliza documentação do Microsoft Learn verificada em 4 de outubro de 2026 e a implementação do coletor identificada abaixo. Os comandos são exemplos documentados para um administrador Windows autorizado; não foram executados num parque Windows para este artigo. Não se afirma que houve uma implementação bem-sucedida, cobertura dos endpoints, exposição a CVE ou conformidade com a ANSSI.

O nosso guia de integridade da memória HVCI explica o isolamento da integridade do código do kernel na memória e a compatibilidade dos drivers. Este procedimento verifica políticas de autorização de aplicações, o seu formato e os seus eventos. Registe ambas as proteções quando forem relevantes, com evidências separadas para cada uma.

Como funciona: o formato da política e a distribuição devem corresponder

O procedimento de implementação por GPO da Microsoft suporta apenas o formato de política única. A definição encontra-se em Computer Configuration → Administrative Templates → System → Device Guard → Deploy App Control for Business. A definição ativada indica um caminho de implementação local ou UNC; uma partilha deve ser acessível às contas dos computadores. O procedimento termina com o reinício do computador de teste.

A mesma página orienta os administradores que implementam uma nova política base assinada com a integridade da memória ativada a utilizar a implementação por script e a ativá-la através de um reinício. Não substitua essa instrução por uma atualização em funcionamento apenas porque uma ferramenta de gestão a oferece. O procedimento por script da Microsoft identifica o caso afetado do Windows 11 anterior à versão 24H2 e a cópia necessária para os locais do sistema e da EFI, seguida de reinício. Verifique a compilação do dispositivo de destino e o procedimento relevante antes de escolher um mecanismo de ativação.

A visão geral da implementação da Microsoft distingue o XML com uma PolicyID para o formato de múltiplas políticas do caso de política única. Descreve a conversão para um binário e a implementação através de MDM, Configuration Manager, scripts ou Política de Grupo. A ausência de um marcador GPO não permite excluir esses outros métodos de distribuição.

Antes de alterar qualquer elemento, crie um registo para cada grupo piloto:

Estes campos constituem uma proposta de registo de investigação, não medições de um ambiente de cliente. Resolva a falta de responsabilidade definida antes de emitir alterações: um administrador deve conseguir explicar qual será a fonte que distribuirá a próxima versão e qual o operador que a poderá retirar.

Deteção: inventariar o destino e correlacionar eventos

Passo 1: identificar as políticas no dispositivo piloto

A referência técnica do CiTool documenta --list-policies, com o alias -lp, como uma listagem de políticas ativas e inativas. O CiTool está incluído a partir do Windows 11 22H2 e do Windows Server 2025. Num dispositivo de destino suportado, conserve a saída completa:

CiTool --list-policies

A saída documentada inclui Policy ID, Base Policy ID, nome amigável, versão, estado da assinatura, presença do ficheiro e estado de ativação. Compare as identidades e versões com o artefacto aprovado. A referência define Is Currently Enforced como a indicação de que o ficheiro da política está ativo; não utilize apenas essa designação para decidir se as opções das regras estão em modo de auditoria ou de aplicação efetiva.

Nos sistemas em que essa ferramenta não está disponível, utilize o procedimento de implementação específico do sistema operativo e os artefactos de política conservados. Um comando indisponível é uma limitação de inventário, não prova de que o App Control está ausente. Distinga uma recolha falhada de um inventário bem-sucedido sem a política esperada.

Passo 2: consultar os registos corretos

No Visualizador de Eventos, examine Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational e Applications and Services Logs → Microsoft → Windows → AppLocker → MSI and Script. A referência de eventos da Microsoft documenta estes sinais:

O registo MSI and Script não está disponível no Windows Server Core. O App Control também não regista normalmente cada binário permitido. Por isso, registos sem atividade não constituem um inventário completo de execução nem provam que todas as aplicações estão autorizadas.

Conserve os detalhes dos eventos com o dispositivo, a hora, a identidade da política quando fornecida, as opções observadas e o fluxo de trabalho exercitado. Compare a observação da política carregada com a identidade, a versão e o modo pretendidos. Investigue IDs inesperados e explique qualquer alteração de versão antes de atribuir a atividade posterior à implementação.

Passo 3: executar o trabalho necessário em modo de auditoria

Execute fluxos autorizados de instalação, arranque, atualização e administração no piloto. Peça aos responsáveis pelas aplicações que identifiquem dependências e resultados esperados. Registe o que foi efetivamente exercitado; uma máquina inativa fornece poucas evidências de compatibilidade. Conserve as lacunas de recolha e os limites de retenção dos registos juntamente com a revisão.

O nosso guia de regras ASR do Defender por GPO compara GUIDs de regras de comportamento, ações e exclusões com a configuração dos endpoints. Aqui, a revisão diz respeito à identidade e ao formato da política do App Control, assim como às decisões sobre binários e scripts. Uma observação da configuração ASR não permite encerrar esta investigação do App Control.

Correção: rever as evidências de auditoria antes da aplicação efetiva (Remediation)

Passo 1: aprovar um piloto recuperável

Nomeie o responsável pela implementação, quem aprova as regras de aplicações e o operador de recuperação. Defina quais os dispositivos que entram no piloto, quais os fluxos de trabalho que devem passar e quais as falhas que interrompem a expansão. Pergunte explicitamente: que formato e método de distribuição estão em uso, as novas políticas base assinadas são combinadas com integridade da memória e quem aprova exceções e reversões?

A Microsoft recomenda anéis de implementação e avaliação em auditoria antes da aplicação efetiva na sua visão geral da implementação. Escolha o método a partir do registo de sistema operativo, formato e assinatura acima. Conserve os artefactos anteriores e um procedimento de recuperação testado antes de distribuir o candidato.

Passo 2: gerar candidatos e depois rever cada regra

O fluxo de trabalho com eventos de auditoria da Microsoft exige uma política em modo de auditoria já implementada. Execute o comando documentado numa sessão PowerShell com privilégios elevados para gerar regras candidatas a partir dos eventos de auditoria:

$EventsPolicy=$env:userprofile+"\Desktop\EventsPolicy.xml"
$EventsPolicyWarnings=$env:userprofile+"\Desktop\EventsPolicyWarnings.txt"
New-CIPolicy -FilePath $EventsPolicy -Audit -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash -UserPEs -MultiplePolicyFormat 3> $EventsPolicyWarnings

Este exemplo produz o formato de múltiplas políticas; não é um binário para implementar através da definição GPO de política única. Reveja o XML gerado e os avisos. Conserve apenas regras para aplicações, binários e scripts aprovados e depois integre-as na base ou utilize uma política suplementar permitida. Os ficheiros que já não estão no disco não recebem regras geradas automaticamente por este processo.

Execute novamente os fluxos de trabalho necessários depois de implementar a política de auditoria revista. Mantenha proibida a atividade não permitida; um evento de auditoria não é uma instrução para confiar na sua origem. Investigue eventos sem explicação e avisos por resolver antes de avançar.

Passo 3: preparar o artefacto de aplicação efetiva

O procedimento de aplicação efetiva da Microsoft parte de políticas de auditoria revistas. Copia o XML de auditoria para um ficheiro separado de aplicação efetiva e, opcionalmente, altera a identidade da política para uma implementação em paralelo. Decida deliberadamente se vai substituir a política existente ou utilizar uma nova identidade; as relações com políticas suplementares devem seguir essa escolha.

Com $EnforcedPolicyXML a apontar para a cópia preparada, a alteração documentada do modo é:

Set-RuleOption -FilePath $EnforcedPolicyXML -Option 3 -Delete

O mesmo procedimento recomenda considerar as opções 9 e 10 para o primeiro anel de aplicação efetiva: uma opção anterior ao arranque para desativar a aplicação efetiva durante uma única sessão de arranque e um retorno à auditoria quando um driver crítico para o arranque é bloqueado. Converta o XML revisto para binário, aplique o processo de assinatura necessário e implemente-o com o método suportado escolhido. Conserve a identidade do artefacto e o modo esperado no registo da alteração.

Depois da ativação, repita o inventário, a revisão da política carregada e os testes funcionais. Examine os eventos de aplicação efetiva face às expectativas aprovadas. Avance para o próximo anel apenas depois de os revisores designados aceitarem as evidências, as exceções e a preparação para recuperação; a edição da GPO, por si só, não é o critério de encerramento.

Passo 4: testar a retirada e a recuperação

O procedimento de remoção de políticas da Microsoft exige primeiro a desativação do método de distribuição, para que a política não volte a ser implementada. Para uma base assinada, implemente uma substituição assinada com a opção 6, a mesma PolicyId, uma versão igual ou superior e uma secção UpdatePolicySigners. Assine-a com um certificado indicado na secção UpdatePolicySigners da política original e reinicie antes da remoção. Não suponha que uma eliminação local retira com segurança uma base assinada.

Num sistema suportado, depois de cumprir esses pré-requisitos, execute o exemplo documentado de remoção numa janela de comandos com privilégios elevados:

CiTool.exe -rp "{PolicyId GUID}" -json

Substitua o marcador pelo ID da política aprovado. Os requisitos de reinício variam consoante a versão do Windows e a assinatura da política; utilize o procedimento ligado para o dispositivo de destino. O procedimento de recuperação deve também abranger um dispositivo que não arranca, acesso autorizado ao firmware e disponibilidade da chave de recuperação. Teste esse caminho em equipamento recuperável antes da aplicação efetiva.

Como a EtcSec deteta esta situação

O etc-collector da EtcSec inclui BP039_CCI_NOT_DEPLOYED. No commit revisto 6a04c34b5ce01d3abf747c1d1c2f671eaa1d5e85, o seu Detect() em bp039-cci-not-deployed.go percorre todas as entradas GPOPolicies recolhidas, ignorando objetos de política ou de definições em falta. Qualquer cadeia DeviceGuardConfigCIPolicyFilePath não vazia devolve nil, ou seja, nenhuma constatação. Caso contrário, devolve gravidade Low, Count 1, incluindo quando não foram recolhidas políticas.

Esse ramo verifica um único marcador. Não valida o ficheiro referido, o seu formato binário, a assinatura, a versão, o âmbito de destino ou o estado de aplicação efetiva. Um valor positivo numa GPO sem relação com o destino basta para suprimir a constatação; o código não calcula a política resultante para cada dispositivo. Count 1 é uma contagem de constatações, não uma contagem de computadores desprotegidos.

O registrypol_parser.go revisto exige uma chave que contenha codeintegrity para mapear ConfigCIPolicyFilePath. A definição GPO real utiliza o ramo DeviceGuard, pelo que esse caminho não preenche o marcador esperado. Separadamente, CollectGPOPolicies em smb/client.go insere um objeto de política mesmo quando os seus ficheiros não foram lidos com sucesso. Um objeto no mapa não é, por isso, prova de uma recolha bem-sucedida das definições.

Anexe à investigação o inventário independente dos dispositivos, os artefactos de política aprovados, os eventos relevantes e as decisões de revisão das regras. Resolva explicitamente as falhas de recolha. Encerre a questão operacional com base nessas evidências e nos critérios de aceitação acordados, em vez de editar uma GPO apenas para silenciar uma verificação de marcador.