Politica efetiva do AppLocker: testar regras do utilizador

O que é a política efetiva do AppLocker?

A politica efetiva do AppLocker é a política que se aplica num determinado computador Windows através de Group Policy, combinando a política AppLocker local com as políticas AppLocker de domínio aplicadas. Analisar essa política ajuda a determinar quais as regras que devem afetar um ficheiro para o utilizador pretendido. Uma GPO chamada «AppLocker» é uma designação administrativa; não comprova essas regras, o respetivo modo nem uma execução bloqueada. Referência de Get-AppLockerPolicy

Para uma equipa de Active Directory que investiga um resultado de controlo de aplicações, o resultado útil é um registo de evidências associado a um dispositivo, utilizador e carga de trabalho. Identifique o canal de implementação, preserve a política efetiva, analise as suas coleções, avalie ficheiros representativos e planeie um teste de execução controlado. Mantenha visíveis as medições em falta até que um administrador as possa recolher.

Este guia utiliza documentação primária verificada em 4 de outubro de 2026 e a implementação do collector descrita abaixo. Os comandos PowerShell são exemplos baseados na documentação para administradores autorizados. Não foram executados num endpoint para este artigo; não se apresentam resultados de testes nem se afirma uma remediação bem-sucedida.

Como funciona: identificar o canal de implementação e as coleções

Passo 1: distinguir Group Policy da implementação por CSP

Pergunte ao responsável pela gestão de dispositivos se o AppLocker é disponibilizado através de Group Policy ou do AppLocker configuration service provider (CSP). A referência da Microsoft de Get-AppLockerPolicy afirma explicitamente que o cmdlet apenas compreende implementações GP e pode devolver dados incorretos quando a política foi aplicada através de CSP. Uma exportação GP vazia não resolve a questão do CSP.

A referência de AppLocker CSP documenta restrições ao lançamento de aplicações através de nós de política específicos de cada coleção. Num dispositivo gerido por CSP, preserve o perfil de gestão responsável, os payloads das coleções e as evidências de aplicação da política no dispositivo através desse canal. Defina como a equipa de gestão irá comprovar o estado aplicado no dispositivo antes de afirmar que existe cobertura. O procedimento de exportação GP deste artigo não pode fornecer essas evidências para CSP.

Registe o seguinte antes de escolher o percurso de verificação:

Estes campos constituem uma proposta de registo de análise. Preencha-os com observações reais; um nome de política ou uma atribuição não confirmada não é suficiente para dar uma linha por concluída.

Passo 2: registar as coleções e os modos de imposição

A Microsoft define cinco coleções de regras AppLocker: ficheiros executáveis, ficheiros Windows Installer, scripts, DLLs e aplicações empacotadas e respetivos instaladores. Um teste limitado a executáveis deixa outras coleções aplicáveis por examinar. A coleção DLL não está ativada por predefinição; analise as suas implicações de compatibilidade e desempenho antes de a acrescentar ao piloto.

Para cada coleção relevante, conserve as regras, SIDs de utilizadores ou grupos, condições, exceções e modo configurado. O esquema XML da referência CSP inclui os valores AuditOnly, Enabled e NotConfigured para a imposição das coleções. Preserve o valor exato observado, juntamente com a definição na consola e a origem da implementação; não resuma toda a política como «ativada» por uma coleção estar em modo de imposição.

O procedimento Audit only da Microsoft distingue a avaliação de regras e o registo de decisões da sua imposição. Uma coleção em auditoria pode identificar ficheiros que seriam recusados enquanto esses ficheiros continuam a executar-se. Registe uma coleção ausente ou um modo ambíguo como uma questão de análise separada, em vez de inferir proteção a partir de outra coleção.

Se o ambiente também utilizar WDAC, o nosso guia de verificação da identidade e ativação de políticas App Control explica o inventário CiTool e as evidências de políticas Code Integrity. O nosso guia de verificação de GUIDs e ações de Defender ASR nos endpoints verifica a configuração de regras de comportamento com Get-MpPreference. Conserve as evidências próprias de cada controlo quando coexistem.

Deteção: exportar, avaliar e correlacionar evidências de execução

Passo 1: exportar a política efetiva implementada por GP

No computador avaliado e gerido por GP, o procedimento de teste da Microsoft utiliza uma sessão administrativa de Windows PowerShell para exportar a política:

Get-AppLockerPolicy -Effective -XML > C:\Effective.xml

Escolha um local autorizado para as evidências e preserve a exportação original com os dados do host, momento e canal de implementação. Analise todas as coleções aplicáveis antes de testar ficheiros. Uma falha de exportação é uma falha de recolha; uma exportação com conteúdo inesperado exige investigação em relação à configuração pretendida. Nenhum destes resultados se torna conforme por se omitir o dispositivo.

Utilize esta exportação para avaliar o estado GP observado. Se for avaliada uma política proposta, identifique-a como candidata e conserve-a separadamente. Testar um ficheiro XML candidato não comprova que um dispositivo recebeu essa versão candidata.

Passo 2: testar ficheiros representativos para o utilizador pretendido

O mesmo procedimento da Microsoft fornece este exemplo, utilizando um diretório Office e um utilizador de exemplo:

Get-ChildItem 'C:\Program Files\Microsoft Office\' -filter *.exe -Recurse | Convert-Path | Test-AppLockerPolicy -XMLPolicy C:\Effective.xml -User contoso\zwie -Filter Denied,DeniedByDefault | Export-CSV C:\BlockedFiles.csv

Substitua o diretório, a identidade e o local de saída por valores aprovados para a avaliação. Este comando avalia ficheiros em relação à política especificada e exporta decisões filtradas. O nome do ficheiro não transforma o CSV num registo de bloqueios de execução. O filtro de executáveis do exemplo também não testa scripts, instaladores, dependências DLL nem aplicações empacotadas.

A referência de Test-AppLockerPolicy apresenta Allowed, AllowedByDefault, Denied e DeniedByDefault como filtros de decisão. Conserve uma avaliação sem filtros, além de qualquer relatório específico de ficheiros recusados. Caso contrário, um relatório vazio limitado às recusas não permite saber quais os ficheiros avaliados nem confirmar que os casos proibidos pretendidos foram incluídos.

Especifique uma conta individual representativa para regras com grupos aninhados, tal como recomenda a referência do cmdlet. Testar um nome de grupo ou o administrador que recolheu a exportação pode responder a uma questão de autorização diferente do acesso do utilizador pretendido. Repita a avaliação para populações de utilizadores materialmente distintas e conserve as suas identidades com os resultados.

Construa um conjunto finito de testes com os responsáveis pelas aplicações. Inclua fluxos aprovados de lançamento, instalação, atualização e scripts, quando relevantes, além de ficheiros benignos intencionalmente fora do conjunto de aplicações aprovado. Para cada caso, registe a decisão esperada, a identidade do ficheiro ou pacote, a coleção aplicável, o utilizador e o resultado da avaliação. Os ficheiros em falta e os erros de avaliação continuam a ser lacunas explícitas. Não fabrique um resultado aprovado a partir de uma análise de diretório demasiado limitada.

Passo 3: analisar os registos AppLocker corretos

O procedimento de monitorização da Microsoft situa os registos AppLocker em Applications and Services Logs → Microsoft → Windows → AppLocker. Analise EXE and DLL para esses tipos de ficheiro e MSI and Script para instaladores e scripts; inclua Packaged app-Deployment e Packaged app-Execution quando essas coleções estiverem no âmbito da avaliação.

A referência de eventos AppLocker documenta estas distinções úteis:

A documentação de regras de scripts da Microsoft qualifica os eventos de bloqueio de scripts: o host de scripts implementa a imposição. Os scripts PowerShell comunicados como bloqueados podem continuar a executar-se em Constrained Language Mode; os scripts autorizados executam-se em Full Language Mode. Num teste de script, registe o host, o modo de linguagem e as operações observadas, em vez de tratar apenas o evento 8007 como prova de que nenhum código de script foi executado.

Conserve os detalhes completos dos eventos, incluindo ficheiro, momento, contexto da regra e identidade, com o registo do teste. Um evento relativo a uma tentativa de execução de um ficheiro não comprova cobertura para todas as cargas de trabalho ou utilizadores. Registos sem atividade exigem verificar as atividades exercitadas, as permissões de recolha e a retenção antes de serem interpretados.

Remediação: validar um piloto recuperável da auditoria à imposição (Remediation)

Passo 1: aprovar o comportamento esperado antes de alterar regras

Resolva três decisões operacionais: quais as evidências que cobrem o canal de implementação, quais as coleções e modos que afetam o utilizador pretendido e quais os cenários autorizados e proibidos que serão validados no laboratório. Nomeie o responsável pela política, os aprovadores das aplicações e o operador de recuperação. Preserve a política atual e um procedimento de recuperação aprovado antes de distribuir uma alteração.

Utilize equipamento piloto recuperável e material de teste benigno. Acorde quais os fluxos necessários que devem continuar disponíveis e quais os casos proibidos que devem falhar após a imposição. Uma falha num fluxo necessário de administração ou de negócio interrompe a expansão até que o responsável analise a regra. Um resultado inesperadamente autorizado para um caso proibido também exige investigação; o funcionamento bem-sucedido do negócio, por si só, não comprova a restrição pretendida.

Passo 2: configurar Audit only e exercitar o piloto

Para uma política gerida por GPO, utilize a Group Policy Management Console para gerir a GPO responsável. O procedimento Audit only da Microsoft orienta os administradores a abrir AppLocker → Properties → Enforcement, selecionar Configured para cada coleção escolhida, selecionar Audit only e confirmar. Local Security Policy é a ferramenta correspondente para a gestão de políticas locais.

Antes de exercitar o piloto, verifique se Application Identity (AppIDSvc) está em execução. A Microsoft afirma que parar este serviço impede a imposição do AppLocker. Para implementação por Group Policy, configure o arranque automático em pelo menos uma GPO que aplique regras AppLocker, em Computer Configuration → Windows Settings → Security Settings → System Services → Application Identity. Conserve o estado observado do serviço com a exportação da política. Procedimento do serviço Application Identity

Após a aplicação, recolha novamente a política e repita as avaliações para o utilizador pretendido. Exercite os cenários aprovados no piloto e analise os eventos de auditoria em relação às decisões esperadas. Peça aos responsáveis pelas aplicações que expliquem as dependências e as exceções propostas. Mantenha cada exceção associada a um requisito específico, aprovador e decisão de análise. Não converta todos os ficheiros auditados em regras de autorização apenas para eliminar o ruído da auditoria.

Passo 3: impor as coleções aprovadas e validar a execução

O procedimento Enforce rules da Microsoft utiliza o mesmo separador Properties → Enforcement: selecione Configured para a coleção a alterar e escolha Enforce rules. Faça essa alteração através do responsável e canal estabelecidos após a análise do piloto. Uma implementação CSP necessita do seu próprio procedimento de gestão aprovado.

Volte a exportar a política GP após a aplicação, compare coleções e modos e repita a avaliação das regras. Depois execute os testes de execução aprovados como o utilizador pretendido no piloto. Registe o comportamento real e os eventos correspondentes para os cenários necessários e proibidos. Se o comportamento divergir da avaliação, investigue o artefacto da política, o estado da aplicação, o contexto do utilizador e a coleção aplicável antes de expandir.

Avance para outras populações apenas quando os revisores nomeados aceitarem as evidências e a preparação para recuperação. Mantenha os dispositivos desconhecidos e as cargas de trabalho não testadas no registo da alteração. O critério de conclusão é o comportamento aprovado observado na população avaliada, com limitações e exceções registadas.

Como o EtcSec deteta esta situação

O etc-collector do EtcSec inclui ANSSI_R37_APPLOCKER_NOT_ENFORCED. No commit 0423094759d50002457031317098417993e19510, Detect() em public/internal/audit/detectors/ad/compliance/anssi/anssi-r37-applocker-not-enforced.go:41 converte o DisplayName de cada GPO recolhida para minúsculas e procura applocker, wdac, code integrity ou srp. Um nome correspondente é suficiente para manter Count 0; a ausência de nomes correspondentes produz Count 1, com gravidade Medium. Esta contagem não é uma contagem de endpoints desprotegidos.

O predicado não lê regras XML AppLocker, modos das coleções nem autorizações específicas de utilizadores. Não comprova a aplicação da GPO a um dispositivo. Um nome sugestivo pode suprimir o sinal sem imposição; uma política real com outro nome pode manter o sinal presente. Alterar o nome de uma GPO modifica esta heurística sem comprovar qualquer melhoria de segurança.

O provider LDAP em public/internal/providers/ldap/client.go:1007 obtém metadados de GPOs. Uma falha de pesquisa devolve um erro, mas public/internal/audit/engine.go:521 descarta o erro de GetGPOs ao atribuir as GPOs devolvidas. Consequentemente, este sinal, por si só, não consegue distinguir uma recolha de GPOs falhada de uma recolha bem-sucedida sem indícios nos nomes. Comprove a qualidade da recolha de forma independente antes de o interpretar.

R37 é um identificador histórico do detetor, não o número da recomendação normativa de AppLocker. O código associa esta verificação a ANSSI PA-099 R11. O guia PA-099, datado de 2 de outubro de 2023, página 28 recomenda o reforço de sistemas e software que contribui para o isolamento de Tiers. Esta recomendação abrangente não transforma a heurística de nomes num teste de conformidade específico de AppLocker.