Entender Windows Defender regras de política e regras de arquivo do WDAC (Controle de Aplicativos)

Aplica-se a:

• Windows 10
• Windows 11
• Windows Server 2016 e mais recente

Observação

Alguns recursos do Windows Defender Application Control só estão disponíveis em versões específicas do Windows. Saiba mais sobre a disponibilidade Windows Defender recursos do Controle de Aplicativos.

Windows Defender WDAC (Controle de Aplicativos) pode controlar o que é executado no Windows 10 e no Windows 11, definindo políticas que especificam se um driver ou aplicativo é confiável. Uma política inclui regras de política que controlam opções como o modo de auditoria e regras de arquivo (ou níveis de regra de arquivo) que especificam como os aplicativos são identificados e confiáveis.

Windows Defender o Controle de Aplicativos é usado para restringir os dispositivos a executarem somente aplicativos aprovados, enquanto o sistema operacional é protegido contra ataques de memória kernel usando a HVCI (integridade de código protegida por hipervisor).

Implantar as regras de política do Windows Defender Application Control

Para modificar as opções de regra de política de um XML Windows Defender política de Controle de Aplicativo existente, use Set-RuleOption. Os exemplos a seguir mostram como usar esse cmdlet para adicionar e remover uma opção de regra em uma política existente do WDAC:

• Para garantir que a UMCI esteja habilitada para uma política do WDAC -UserPEs que foi criada com a opção (modo de usuário), adicione a opção de regra 0 a uma política existente executando o seguinte comando:

  Set-RuleOption -FilePath <Path to policy XML> -Option 0

  Uma política criada sem a opção -UserPEs não tem regras para o código de modo de usuário. Se você habilitar UMCI (Opção 0) para essa política, o WDAC bloqueará todos os aplicativos e até mesmo o código de sessão de usuário crítico do Windows. No modo de auditoria, o WDAC simplesmente registra um evento, mas, quando imposto, todo o código do modo de usuário será bloqueado. Para criar uma política que inclui executáveis de modo de usuário (aplicativos), execute New-CIPolicy com a -UserPEs opção.

• Para desabilitar a UMCI em uma política do WDAC existente, apague a opção de regra 0 executando o seguinte comando:

  Set-RuleOption -FilePath <Path to policy XML> -Option 0 -Delete

Você pode definir diversas opções de regra em uma política do WDAC. A Tabela 1 descreve cada opção de regra e se elas têm políticas complementares. No entanto, a opção 5 não é implementada, pois é reservada para trabalho futuro e não há suporte para a opção 7.

Observação

Recomendamos que você use o modo Enabled:Audit inicialmente porque ele permite que você teste novas políticas Windows Defender Controle de Aplicativos antes de imponha-las. Com o modo de auditoria, nenhum aplicativo é bloqueado; em vez disso, a política registra um evento sempre que um aplicativo fora da política é iniciado. Para permitir esses aplicativos, você pode capturar as informações de política do log de eventos e mesclar essas informações na política existente. Quando o modo Enabled:Audit é excluído, a política é executada no modo imposto.

Tabela 1. Política do Windows Defender Application Control - opções de regra de política

Opção de regra	Descrição	Opção complementar válida
0 Enabled:UMCI	As políticas do WDAC restringem binários dos modos kernel e de usuário. Por padrão, somente binários do modo kernel são restritos. Habilitar essa opção de regra valida executáveis do modo de usuário e scripts.	Não
1 Enabled:Boot Menu Protection	No momento, não há suporte para essa opção.	Não
2 Required:WHQL	Por padrão, os drivers herdados que não são assinados pelo Windows WHQL (Hardware Quality Labs) têm permissão para serem executados. Habilitar essa regra requer que todo driver executado seja assinado por WHQL e remova o suporte ao driver herdado. Os drivers de kernel criados para Windows 10 devem ser certificados por WHQL.	Não
3 Enabled:Audit Mode (padrão)	Instrui o WDAC a registrar informações sobre aplicativos, binários e scripts que teriam sido bloqueados se a política fosse imposta. Você pode usar essa opção para identificar o impacto potencial da política do WDAC e usar os eventos de auditoria para refinar a política antes da imposição. Para impor uma política do WDAC, exclua essa opção.	Não
4 Desabilitado: Versão de pré-lançamento	Se habilitadas, as políticas do WDAC não confiarão em binários assinados por flightroot. Essa opção seria usada por organizações que só querem executar binários liberados, não builds do Windows de pré-lançamento.	Não
5 Enabled:Inherit Default Policy	Essa opção é reservada para uso futuro e atualmente não tem efeito.	Sim
6 Enabled:Unsigned System Integrity Policy (padrão)	Permite que a política permaneça não assinada. Quando essa opção é removida, a política deve ser assinada. Os certificados confiáveis para atualizações futuras de política devem ser identificados na seção UpdatePolicySigners.	Sim
7 Allowed:Debug Policy Augmented	No momento, não há suporte para essa opção.	Sim
8 Required:EV Signers	No momento, não há suporte para essa opção.	Não
9 Enabled:Advanced Boot Options Menu	O menu de pré-inicialização F8 permanece desabilitado por padrão para todas as políticas do WDAC. Definir essa opção de regra permite que o menu F8 seja exibido para usuários presentes fisicamente.	Não
10 Enabled:Boot Audit on Failure	Usada quando a política do WDAC está em modo de imposição. Quando um driver falha durante a inicialização, a política do WDAC é colocada no modo de auditoria de maneira que o Windows seja carregado. Os administradores podem validar o motivo da falha no log de eventos CodeIntegrity.	Não
11 Disabled:Script Enforcement	Essa opção desabilita as opções de imposição de script. Scripts do PowerShell não assinados e o PowerShell interativo não são mais restritos ao Modo de Linguagem Restrita. OBSERVAÇÃO: essa opção é necessária para executar arquivos HTA e tem suporte em builds 1709, 1803 e 1809 com o LCU 2019 10C ou superior e em dispositivos com o Atualização de maio de 2019 para o Windows 10 (1903) e superior. Usá-lo em versões do Windows sem a atualização adequada pode ter resultados indesejados.	Não
12 Required:Enforce Store Applications	Se essa opção de regra estiver habilitada, as políticas do WDAC também serão aplicadas aos Aplicativos Universais do Windows.	Não
13 Enabled:Managed Installer	Use essa opção para permitir automaticamente aplicativos instalados por um instalador gerenciado. Para obter mais informações, consulte Autorizar aplicativos implantados com um instalador gerenciado do WDAC	Sim
14 Enabled:Intelligent Security Graph Authorization	Use essa opção para aceitar automaticamente aplicativos com reputação "bem conhecida" conforme definido pelo gráfico de segurança inteligente (ISG) da Microsoft.	Sim
15 Enabled:Invalidate EAs on Reboot	Quando a opção de gráfico de segurança inteligente (14) é usada, o WDAC define um atributo de arquivo estendido que indica que o arquivo foi autorizado a ser executado. Essa opção fará com que o WDAC revalida periodicamente a reputação dos arquivos que foram autorizados pelo ISG.	Não
16 Enabled:Update Policy No Reboot	Use essa opção para permitir a aplicação de futuras atualizações da política do WDAC sem exigir uma reinicialização do sistema. OBSERVAÇÃO: essa opção só tem suporte no Windows 10, versão 1709 e posteriores.	Não
17 Enabled:Allow Supplemental Policies	Use essa opção em uma política base para permitir que políticas complementares a expandam. OBSERVAÇÃO: essa opção só tem suporte no Windows 10, versão 1903 e superior.	Não
18 Disabled:Runtime FilePath Rule Protection	Essa opção desabilita a verificação de runtime padrão que só permite regras de FilePath para caminhos que só podem ser graváveis por um administrador. OBSERVAÇÃO: essa opção só tem suporte no Windows 10, versão 1903 e superior.	Sim
19 Enabled:Dynamic Code Security	Habilita a imposição de política para aplicativos .NET e bibliotecas carregadas dinamicamente. OBSERVAÇÃO: essa opção só tem suporte no Windows 10, versão 1803 e superior.	Não
20 Enabled:Revoked Expired As Unsigned	Use essa opção para tratar binários assinados com certificados expirados e/ou revogados como "Binários não assinados" para o processo/componentes do modo de usuário, em cenários de assinatura corporativa.	Não

Níveis de regra de arquivo do Windows Defender Application Control

Os níveis de regra de arquivo permitem que os administradores especifiquem o nível no qual desejam que os aplicativos sejam considerados confiáveis. Esse nível de confiança pode ser tão granular quanto o hash de cada binário ou tão geral quanto um certificado de AUTORIDADE de Certificação. Você especifica níveis de regra de arquivo ao usar cmdlets do PowerShell do WDAC para criar e modificar políticas.

Cada nível de regra de arquivo tem vantagens e desvantagens. Use a Tabela 2 para selecionar o nível de proteção apropriado para seus recursos administrativos disponíveis e Windows Defender de implantação do Controle de Aplicativos.

Tabela 2. Política do Windows Defender Application Control - níveis de regra de arquivo

Nível da regra	Descrição
Hash	Especifica valores de hash de imagem Authenticode/PE individuais para cada binário descoberto. Esse nível é o nível mais específico e requer mais esforço para manter os valores de hash das versões atuais do produto. Sempre que um binário é atualizado, o valor de hash muda, logo, exigindo uma atualização de política.
FileName	Especifica o nome de arquivo original para cada binário. Embora os valores de hash de um aplicativo sejam modificados quando atualizados, os nomes de arquivo normalmente não são. Esse nível oferece segurança menos específica do que o nível de hash, mas normalmente não requer uma atualização de política quando qualquer binário é modificado.
FilePath	A partir Windows 10 versão 1903, esse nível permite que binários executem de locais de caminho de arquivo específicos. Mais informações sobre regras de nível filePath podem ser encontradas abaixo.
SignedVersion	Esse nível combina a regra de editor com um número de versão. Ele permite que qualquer coisa seja executada do publicador especificado com uma versão em ou acima do número de versão especificado.
Editor	Esse nível combina o nível pcaCertificate (normalmente um certificado abaixo da raiz) e o CN (nome comum) do certificado folha. Você pode usar esse nível de regra para confiar em um certificado emitido por uma AC específica e emitido para uma empresa específica em que você confia (como a Intel, para drivers de dispositivo).
FilePublisher	Esse nível combina o atributo "FileName" do arquivo assinado, mais "Publisher" (certificado PCA com CN de folha), além de um número de versão mínimo. Essa opção confia em arquivos específicos do editor especificado, com uma versão igual ou superior à do número de versão especificado.
LeafCertificate	Adiciona signatários confiáveis no nível de certificado de assinatura individual. A vantagem de usar esse nível em comparação com o nível de hash individual é que novas versões do produto terão valores de hash diferentes, mas normalmente o mesmo certificado de assinatura. Quando esse nível é usado, nenhuma atualização de política seria necessária para executar a nova versão do aplicativo. No entanto, os certificados folha têm períodos de validade muito mais curtos do que outros níveis de certificado, portanto, a política Windows Defender Controle de Aplicativos deve ser atualizada sempre que esses certificados mudarem.
PcaCertificate	Adiciona o certificado mais alto disponível na cadeia de certificados fornecida aos signatários. Esse nível normalmente é um certificado abaixo do certificado raiz porque a verificação não valida nada além dos certificados incluídos na assinatura fornecida (ele não fica online ou verifica os repositórios raiz locais).
RootCertificate	Atualmente incompatível.
WHQL	Confiará em binários se eles tiverem sido validados e assinados pelo WHQL. Esse nível é principalmente para binários de kernel.
WHQLPublisher	Esse nível combina o nível WHQL e o CN no certificado folha e é principalmente para binários de kernel.
WHQLFilePublisher	Especifica que os binários estão validados e assinados por WHQL, com um editor específico (WHQLPublisher), e que o binário é a versão especificada ou mais recente. Esse nível é principalmente para binários de kernel.

Observação

Ao criar Windows Defender de Controle de Aplicativo com New-CIPolicy, você pode especificar um nível de regra de arquivo primário, incluindo o parâmetro -Level. Para binários descobertos que não possam ser confiáveis com base em critérios de regra de arquivo primário, use o parâmetro –Fallback. Por exemplo, se o nível de regra de arquivo primário for PCACertificate, mas você também quiser confiar nos aplicativos não assinados, usar o nível de regra de hash como fallback adicionará os valores de hash de binários que não têm um certificado de assinatura.

Observação

• O WDAC só dá suporte a regras de signante para chaves de assinatura de certificado RSA com um máximo de 4096 bits.
• O código usa CN para os campos CertSubject e CertIssuer na política. Você pode usar o certutil da caixa de entrada para examinar o formato subjacente para garantir que UTF-8 não esteja sendo usado para o CN. Por exemplo, você pode usar cadeia de caracteres imprimível, IA5 ou BMP.

Exemplo de níveis de regra de arquivo em uso

Por exemplo, considere um profissional de TI em um departamento que executa muitos servidores. Eles só querem executar software assinado pelas empresas que fornecem seu hardware, sistema operacional, antivírus e outros softwares importantes. Eles sabem que seus servidores também executam um aplicativo escrito internamente que não é assinado, mas é raramente atualizado. Eles desejam permitir que esse aplicativo seja executado.

Para criar a política Windows Defender Controle de Aplicativos, eles criam um servidor de referência em seu hardware padrão e instalam todo o software que seus servidores são conhecidos por executar. Em seguida, eles executam a New-CIPolicy com -Level Publisher (para permitir o software de seus fornecedores, os "Fornecedores") e -Fallback Hash (para permitir o aplicativo não assinado, interno). Eles implantam a política no modo de auditoria para determinar o impacto potencial da imposição da política. Com a ajuda dos dados de auditoria, eles atualizam suas políticas do WDAC para incluir qualquer outro software que desejem executar. Em seguida, eles habilitam a política do WDAC no modo imposto para seus servidores.

Como parte das operações normais, eles eventualmente instalarão atualizações de software ou, talvez, adicionarão software dos mesmos provedores de software. Como o "Publicador" permanece o mesmo nessas atualizações e software, eles não precisarão atualizar a política do WDAC. Se o aplicativo interno não assinado for atualizado, ele também deverá atualizar a política do WDAC para permitir a nova versão.

Ordem de precedência da regra de arquivo

Windows Defender Controle de Aplicativos tem uma lógica de conflito de regra de arquivo interna que é convertida em ordem de precedência. Primeiro, ele processará todas as regras de negação explícitas encontradas. Em seguida, ele processará todas as regras de permissão explícitas. Se não existir nenhuma regra de negação ou permissão, o WDAC verificará se há EA do Instalador Gerenciado. Por fim, se nenhum desses conjuntos existir, o WDAC fará fallback no ISG.

Mais informações sobre regras de caminho de arquivo

As regras de caminho de arquivo não fornecem as mesmas garantias de segurança que as regras explícitas de signatário, pois são baseadas em permissões de acesso mutáveis. As regras de caminho de arquivo são mais adequadas para ambientes em que a maioria dos usuários está executando como padrão, em vez de administrador. As regras de caminho são mais adequadas para permitir que os caminhos que você espera permaneçam somente graváveis pelo administrador. Talvez você queira evitar regras de caminho para diretórios em que os usuários padrão podem modificar ACLs na pasta.

Por padrão, o Windows Defender Application Control executa uma verificação de capacidade de gravação do usuário em runtime que garante que as permissões atuais no caminho do arquivo especificado e seus diretórios pai (recursivamente) não permitam acesso de gravação de usuários padrão.

Há uma lista definida de SIDs que o WDAC reconhece como administradores. Se um caminho de arquivo permitir permissões de gravação para qualquer SID que não esteja nesta lista, o caminho do arquivo será considerado gravável pelo usuário, mesmo que o SID esteja associado a um usuário administrador personalizado. Para lidar com esses casos especiais, você pode substituir a verificação gravável do administrador de runtime do WDAC pela opção Disabled:Runtime FilePath Rule Protection descrita acima.

A lista de SIDs de administrador conhecidos do WDAC é:

S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.

Quando as regras de caminho de arquivo estão sendo geradas usando New-CIPolicy, uma regra de caminho exclusiva e totalmente qualificada é gerada para cada arquivo descoberto nos caminhos verificados. Para criar regras que, em vez disso, permitem todos os arquivos em um caminho de pasta especificado, use New-CIPolicyRule para definir regras que contêm caracteres curinga, usando a opção -FilePathRules .

Caracteres curinga podem ser usados no início ou no final de uma regra de caminho; apenas um curinga é permitido por regra de caminho. Caracteres curinga colocados no final de um caminho autorizam todos os arquivos nesse caminho e seus subdiretórios recursivamente (por exemplo, C:\* incluiria C:\foo\* ). Caracteres curinga colocados no início de um caminho permitirão o nome de arquivo especificado exato em qualquer caminho (por exemplo, *\bar.exe permitiria e C:\bar.exe C:\foo\bar.exe). Não há suporte para caracteres curinga no meio de um caminho (por exemplo, C:\*\foo.exe). Sem um curinga, a regra permitirá apenas um arquivo específico (por exemplo, C:\foo\bar.exe).

Você também pode usar as macros a seguir quando o volume exato pode variar: %OSDRIVE%, %WINDIR%, %SYSTEM32%.

Observação

Para que outras pessoas entendam melhor as políticas do WDAC que foram implantadas, recomendamos manter políticas ALLOW e DENY separadas no Windows 10, versão 1903 e posterior.

Observação

Atualmente, há um bug em que as MSIs não podem ser permitidos listados nas regras de caminho do arquivo. As MSIs devem ser listadas usando outros tipos de regra, por exemplo, regras de editor ou regras de atributo de arquivo.

Mais informações sobre hashes

O WDAC usa o algoritmo de hash de imagem Authenticode/PE ao calcular o hash de um arquivo. Ao contrário do hash de arquivo simples mais popular, mas menos seguro, o cálculo de hash Authenticode omite a soma de verificação do arquivo e a Tabela de Certificados e a Tabela de Certificados de Atributo. Portanto, o hash Authenticode de um arquivo não é alterado quando o arquivo é assinado novamente ou carimbo de data/hora ou a assinatura digital é removida do arquivo. Com a ajuda do hash Authenticode, o WDAC fornece segurança adicional e menos sobrecarga de gerenciamento para que os clientes não precisem revisar as regras de hash da política quando a assinatura digital no arquivo for atualizada.

O hash de imagem Authenticode/PE pode ser calculado para arquivos assinados digitalmente e não assinados.

Por que a verificação cria quatro regras de hash por arquivo XML?

O cmdlet do PowerShell produzirá um Hash Authenticode Sha1, Hash Sha256, Hash de Página Sha1, Hash de Página Sha256. Durante a validação, a CI escolherá quais hashes calcular, dependendo de como o arquivo é assinado. Por exemplo, se o arquivo tiver um hash de página assinado, o arquivo inteiro não será pageado para fazer um authenticode sha256 completo e apenas corresponderemos usando o hash da primeira página.

Nos cmdlets, em vez de tentar prever qual CI de hash usará, calculamos previamente e usamos os quatro hashes (sha1/sha2 authenticode e sha1/sha2 da primeira página). Esse método também será resiliente, se o status de assinatura do arquivo for alterado e necessário para negar regras para garantir que a alteração/remoção da assinatura não resulte em um hash diferente do que estava na política que está sendo usada pela CI.

Por que a verificação cria oito regras de hash para determinados arquivos XML?

Regras separadas são criadas para UMCI e KMCI. Em alguns casos, arquivos que são puramente modo de usuário ou puramente modo kernel ainda podem gerar ambos os conjuntos, já que a CI nem sempre pode determinar com precisão o que é apenas o modo de usuário versus kernel e erra por precaução.

Windows Defender de nome de arquivo do Controle de Aplicativo

Os níveis de regra de nome de arquivo permitem especificar atributos de arquivo nos quais basear uma regra. As regras de nome de arquivo fornecem as mesmas garantias de segurança que as regras explícitas de signatário fazem, pois são baseadas em atributos de arquivo não mutáveis. A especificação do nível de nome de arquivo ocorre ao criar novas regras de política.

Use a Tabela 3 para selecionar o nível de nome de arquivo apropriado para seus casos de uso. Por exemplo, um APLICATIVO LOB ou de produção e seus binários podem compartilhar o mesmo nome de produto. Essa opção permite que você crie facilmente políticas de destino com base no nível de regra de nome de arquivo do Nome do Produto.

Tabela 3. Windows Defender controle de aplicativo – níveis de nome de arquivo

Nível da regra	Descrição
Descrição do arquivo	Especifica a descrição do arquivo fornecida pelo desenvolvedor do binário.
Nome Interno	Especifica o nome interno do binário.
Nome do arquivo original	Especifica o nome do arquivo original ou o nome com o qual o arquivo foi criado pela primeira vez, do binário.
Nome da Família de Pacotes	Especifica o nome da família de pacotes do binário. O nome da família de pacotes consiste em duas partes: o nome do arquivo e a ID do editor.
Nome do produto	Especifica o nome do produto com o qual o binário é fornecido.