Compreender as regras de políticas e regras de ficheiros do Controlo de Aplicações para Empresas
Observação
Algumas capacidades do Controlo de Aplicações para Empresas só estão disponíveis em versões específicas do Windows. Saiba mais sobre a disponibilidade das funcionalidades do Controlo de Aplicações.
O Controlo de Aplicações para Empresas pode controlar o que é executado nos seus dispositivos Windows ao definir políticas que especifiquem se um controlador ou aplicação é fidedigno. Uma política inclui regras de política que controlam opções como o modo de auditoria e regras de ficheiros (ou níveis de regras de ficheiro) que especificam como identificar aplicações fidedignas pela sua organização.
Regras de política do Controlo de Aplicações para Empresas
Para modificar as opções de regra de política de um XML de política de Controlo de Aplicações existente, utilize o Assistente de Política de Controlo de Aplicações ou o cmdlet Set-RuleOption do PowerShell.
Pode definir várias opções de regra numa política de Controlo de Aplicações. A Tabela 1 descreve cada opção de regra e se as políticas suplementares podem defini-las. Algumas opções de regra estão reservadas para trabalho futuro ou não são suportadas.
Observação
Recomendamos que utilize o Modo Ativado:Auditoria inicialmente porque lhe permite testar novas políticas de Controlo de Aplicações antes de as impor. Com o modo de auditoria, as aplicações são executadas normalmente, mas o Controlo de Aplicações regista eventos sempre que um ficheiro é executado que não é permitido pela política. Para permitir estes ficheiros, pode capturar as informações da política do registo de eventos e, em seguida, intercalar essas informações na política existente. Quando o Modo Ativado:Auditoria é eliminado, a política é executada no modo imposto.
Algumas aplicações podem comportar-se de forma diferente mesmo quando a política está no modo de auditoria. Quando uma opção pode alterar comportamentos no modo de auditoria, isso é indicado na Tabela 1. Deve sempre testar cuidadosamente as suas aplicações ao implementar atualizações significativas nas suas políticas de Controlo de Aplicações.
Tabela 1. Política de Controlo de Aplicações para Empresas - opções de regras de política
| Opção de regra | Descrição | Opção suplementar válida |
|---|---|---|
| 0 Enabled:UMCI | As políticas de Controlo de Aplicações restringem os binários do modo kernel e do modo de utilizador. 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 | Esta opção não é atualmente suportada. | Não |
| 2 Required:WHQL | Por predefinição, os controladores de kernel que não estejam assinados no Windows Hardware Quality Labs (WHQL) têm permissão para serem executados. Ativar esta regra requer que todos os controladores estejam assinados com WHQL e remova o suporte do controlador legado. Os controladores kernel criados para Windows 10 devem ter certificação WHQL. | Não |
| 3 Enabled:Audit Mode (padrão) | Instrui o Controlo de Aplicações a registar informações sobre aplicações, binários e scripts que teriam sido bloqueados se a política fosse imposta. Pode utilizar esta opção para identificar o impacto potencial da política de Controlo de Aplicações e utilizar os eventos de auditoria para refinar a política antes da aplicação. Para impor uma política de Controlo de Aplicações, elimine esta opção. | Não |
| 4 Desabilitado: Versão de pré-lançamento | Se estiver ativada, os binários das compilações do Windows Insider não são fidedignos. Esta opção é útil para organizações que apenas querem executar binários lançados e não pré-lançamento de compilações do Windows. | Não |
| 5 Enabled:Inherit Default Policy | Esta opção está reservada para utilização futura 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 esta opção é removida, a política tem de ser assinada e todas as políticas suplementares também têm de ser assinadas. Os certificados fidedignos para futuras atualizações de políticas têm de ser identificados na secção UpdatePolicySigners. Os certificados fidedignos para políticas suplementares têm de ser identificados na secção SupplementalPolicySigners. | Sim |
| 7 Allowed:Debug Policy Augmented | Esta opção não é atualmente suportada. | Sim |
| 8 Required:EV Signers | Esta opção não é atualmente suportada. | Não |
| 9 Enabled:Advanced Boot Options Menu | O menu de pré-arranque F8 está desativado por predefinição para todas as políticas de Controlo de Aplicações. 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 | Utilizado quando a política de Controlo de Aplicações está no modo de imposição. Quando um controlador crítico de arranque falha durante o arranque, a política de Controlo de Aplicações é colocada no modo de auditoria para que o Windows seja carregado. Os administradores podem validar o motivo da falha no log de eventos CodeIntegrity. | Não |
| 11 Disabled:Script Enforcement | Esta opção desativa as opções de imposição de scripts, abrangendo o PowerShell, o Anfitrião de Script Baseado no Windows (wscript.exe), o Anfitrião de Script Baseado na Consola do Windows (cscript.exe), os ficheiros HTA executados no Anfitrião de Aplicações HTML da Microsoft (mshta.exe) e o MSXML. Alguns anfitriões de scripts podem comportar-se de forma diferente mesmo quando a política está no modo de auditoria. Para obter mais informações sobre a imposição de scripts, veja Imposição de scripts com o Controlo de Aplicações. NOTA: esta opção não é suportada no Windows Server 2016 ou Windows 10 1607 LTSB e não deve ser utilizada nesses sistemas operativos. |
Não |
| 12 Required:Enforce Store Applications | Se esta opção de regra estiver ativada, as políticas de Controlo de Aplicações também se aplicam às aplicações Universais do Windows. | Não |
| 13 Enabled:Managed Installer | Utilize esta opção para permitir automaticamente aplicações instaladas por um instalador gerido. Para obter mais informações, veja Autorizar aplicações implementadas com um instalador gerido pelo Controlo de Aplicações | Sim |
| 14 Enabled:Intelligent Security Graph Authorization | Utilize esta opção para permitir automaticamente aplicações com uma reputação "conhecida como boa", conforme definido pelo Graph de Segurança Inteligente (ISG) da Microsoft. | Sim |
| 15 Enabled:Invalidate EAs on Reboot | Quando a opção Gráfico de Segurança Inteligente (14) é utilizada, o Controlo de Aplicações define um atributo de ficheiro expandido que indica que o ficheiro foi autorizado a ser executado. Esta opção faz com que o Controlo de Aplicações revalida periodicamente a reputação dos ficheiros anteriormente autorizados pelo ISG. | Não |
| 16 Enabled:Update Policy No Reboot | Utilize esta opção para permitir que futuras atualizações de políticas de Controlo de Aplicações sejam aplicadas sem que seja necessário reiniciar o sistema. NOTA: esta opção só é suportada no Windows 10, versão 1709 e posterior, ou no Windows Server 2019 e posterior. |
Não |
| 17 Ativado:Permitir Políticas Suplementares | Utilize esta opção numa política base para permitir que as políticas suplementares a expandam. NOTA: esta opção só é suportada no Windows 10, versão 1903 e posterior ou Windows Server 2022 e posterior. |
Não |
| 18 Desativado:Runtime FilePath Rule Protection | Esta opção desativa a marcar de runtime predefinida que só permite regras filePath para caminhos que só são graváveis por um administrador. NOTA: esta opção só é suportada no Windows 10, versão 1903 e posterior ou Windows Server 2022 e posterior. |
Sim |
| 19 Ativado:Segurança de Código Dinâmico | Permite a imposição de políticas para aplicações .NET e bibliotecas carregadas dinamicamente. NOTA: esta opção só é suportada no Windows 10, versão 1803 e posterior, ou no Windows Server 2019 e posterior. NOTA: esta opção é sempre imposta se qualquer política UMCI de Controlo de Aplicações a ativar. Não existe nenhum modo de auditoria para proteção de segurança de código dinâmico .NET. |
Não |
| 20 Ativado:Revogado Expirado Como Não Assinado | Utilize esta opção para tratar binários assinados com certificados revogados ou certificados expirados com o EKU de Assinatura de Duração na assinatura, como "Binários não assinados" para o processo/componentes do modo de utilizador, em cenários de assinatura empresarial. | Não |
| Ativado:Fidedignidade do Código Dinâmico do Modo de Programador | Utilize esta opção para confiar nas aplicações UWP que são depuradas no Visual Studio ou implementadas através do portal do dispositivo quando o Modo de Programador está ativado no sistema. | Não |
Níveis de regras de ficheiros do Controlo de Aplicações para Empresas
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. Este nível de confiança pode ser tão granular como o hash de cada binário ou tão geral como um certificado de AC. Ao utilizar o Assistente de Controlo de Aplicações ou os cmdlets do PowerShell do Controlo de Aplicações, especifica níveis de regra de ficheiro para criar e modificar políticas.
Cada nível de regra de ficheiro tem vantagens e desvantagens. Utilize a Tabela 2 para selecionar o nível de proteção adequado para os recursos administrativos disponíveis e o cenário de implementação do Controlo de Aplicações.
Observação
As regras baseadas no signatário do Controlo de Aplicações só funcionam com criptografia RSA com um comprimento máximo de chave de 4096 bits. Os algoritmos ECC, como ECDSA, não são suportados. Se tentar permitir ficheiros por assinatura com base em assinaturas ECC, verá VerificationError = 23 nos eventos de informações de assinatura correspondentes 3089. Em vez disso, os ficheiros podem ser permitidos por regras de atributos de ficheiros ou hash ou através de outras regras de signatário se o ficheiro também estiver assinado com assinaturas através de RSA.
Tabela 2. Política de Controlo de Aplicações para Empresas - níveis de regras de ficheiro
| Nível da regra | Descrição |
|---|---|
| Hash | Especifica valores hash de imagem Authenticode/PE individuais para cada binário detetado. Este nível é o nível mais específico e requer mais esforço para manter os valores 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 ficheiro 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. Este nível oferece menos segurança 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. Por predefinição, este nível utiliza o atributo OriginalFileName do cabeçalho de recurso do ficheiro. Utilize -SpecificFileNameLevel para escolher um atributo alternativo, como ProductName. |
| FilePath | A partir do Windows 10 versão 1903, este nível permite que os binários executem a partir de localizações de caminho de ficheiro específicas. As regras filePath aplicam-se apenas aos binários do modo de utilizador e não podem ser utilizadas para permitir controladores de modo kernel. Pode encontrar mais informações sobre as regras ao nível do FilePath mais adiante neste artigo. |
| SignedVersion | Este nível combina a regra do publicador com um número de versão. Permite que qualquer coisa seja executada a partir do publicador especificado com uma versão em ou acima do número de versão especificado. |
| Editor | Este nível combina o nível PcaCertificate (normalmente um certificado abaixo da raiz) e o nome comum (CN) do certificado de folha. Pode utilizar este nível de regra para confiar num certificado emitido por uma AC específica e emitido para uma empresa específica em que confia (como a Intel, para controladores de dispositivo). |
| FilePublisher | Este nível combina o atributo "FileName" do ficheiro assinado, além de "Publisher" (certificado PCA com CN de folha) e 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. Por predefinição, este nível utiliza o atributo OriginalFileName do cabeçalho de recurso do ficheiro. Utilize -SpecificFileNameLevel para escolher um atributo alternativo, como ProductName. |
| LeafCertificate | Adiciona signatários confiáveis no nível de certificado de assinatura individual. A vantagem de utilizar este nível em comparação com o nível hash individual é que as novas versões do produto têm valores hash diferentes, mas normalmente o mesmo certificado de assinatura. Quando este nível é utilizado, não será necessária nenhuma atualização de política para executar a nova versão da aplicação. No entanto, normalmente, os certificados de folha têm períodos de validade mais curtos do que outros níveis de certificado, pelo que a política de Controlo de Aplicações tem de ser atualizada sempre que estes certificados forem alterados. |
| PcaCertificate | Adiciona o certificado mais alto disponível na cadeia de certificados fornecida aos signatários. Normalmente, este nível é um certificado abaixo da raiz porque a análise não resolve a cadeia de certificados completa através dos arquivos de raiz locais ou com um marcar online. |
| RootCertificate | Sem suporte. |
| WHQL | Apenas confia nos binários que foram submetidos à Microsoft e assinados pelo Laboratório de Qualificação de Hardware do Windows (WHQL). Este nível destina-se principalmente a binários de kernel. |
| WHQLPublisher | Este nível combina o nível WHQL e o CN no certificado de folha e destina-se principalmente a binários de kernel. |
| WHQLFilePublisher | Este nível combina o atributo "FileName" do ficheiro assinado, além de "WHQLPublisher", mais um número de versão mínimo. Este nível destina-se principalmente a binários de kernel. Por predefinição, este nível utiliza o atributo OriginalFileName do cabeçalho de recurso do ficheiro. Utilize -SpecificFileNameLevel para escolher um atributo alternativo, como ProductName. |
Observação
Quando cria políticas de Controlo de Aplicações com New-CIPolicy, pode especificar um nível de regra de ficheiro principal, 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 ficheiro principal for PCACertificate, mas também quiser confiar nas aplicações não assinadas, utilizar o nível de regra Hash como contingência adiciona os valores hash dos binários que não tinham um certificado de assinatura.
Observação
Quando aplicável, os números de versão mínimo e máximo numa regra de ficheiro são referenciados como MinimumFileVersion e MaximumFileVersion, respetivamente, no XML da política.
- MinimumFileVersion e MaximumFileVersion especificados: para Regras de permissão, são permitidos ficheiros com versões maiores ou iguais a MinimumFileVersion e inferiores ou iguais a MaximumFileVersion. Para regras de negação, o ficheiro com a versão maior ou igual a MinimumFileVersion e menor ou igual a MaximumFileVersion são negados.
- MinimumFileVersion especificado sem MaximumFileVersion: para Regras de permissão, o ficheiro com a versão maior ou igual à versão especificada tem permissão para ser executado. Para Regras de negação, o ficheiro com a versão inferior ou igual à versão especificada é bloqueado.
- MaximumFileVersion especificado sem MinimumFileVersion: para Regras de permissão, o ficheiro com versão inferior ou igual à versão especificada tem permissão para ser executado. Para Regras de negação, o ficheiro com a versão maior ou igual à versão especificada é bloqueado.
Exemplo de níveis de regra de arquivo em uso
Por exemplo, considere um profissional de TI num departamento que executa muitos servidores. Só querem executar software assinado pelas empresas que fornecem o respetivo hardware, sistema operativo, antivírus e outro software importante. 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 de Controlo de Aplicações, criam um servidor de referência no respetivo hardware padrão e instalam todo o software que os respetivos servidores são conhecidos por serem executados. 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). Implementam a política no modo de auditoria para determinar o impacto potencial da aplicação da política. Com a ajuda dos dados de auditoria, atualizam as políticas de Controlo de Aplicações para incluir qualquer outro software que pretendam executar. Em seguida, ativam a política de Controlo de Aplicações no modo imposto para os respetivos servidores.
Como parte das operações normais, acabarão por instalar atualizações de software ou, talvez, adicionar software a partir dos mesmos fornecedores de software. Uma vez que o "Publisher" permanece o mesmo nessas atualizações e software, não precisa de atualizar a política de Controlo de Aplicações. Se a aplicação interna não assinada for atualizada, também terá de atualizar a política de Controlo de Aplicações para permitir a nova versão.
Ordem de precedência da regra de ficheiro
O Controlo de Aplicações tem uma lógica de conflito de regras de ficheiros incorporada que se traduz numa ordem de precedência. Primeiro, processa todas as regras de negação explícitas que encontra. Em seguida, processa quaisquer regras de permissão explícitas. Se não existir nenhuma regra de negação ou permissão, o Controlo de Aplicações verifica a existência de uma afirmação do Instalador Gerido , se permitido pela política. Por fim, o Controlo de Aplicações reverte para o ISG , se permitido pela política.
Observação
Para facilitar a análise das políticas de Controlo de Aplicações, recomendamos que mantenha políticas ALLOW e DENY separadas em versões do Windows que suportem várias políticas de Controlo de Aplicações.
Utilize -SpecificFileNameLevel com regras de nível FileName, FilePublisher ou WHQLFilePublisher
Por predefinição, os níveis de regra FileName, FilePublisher e WHQLFilePublisher utilizam o atributo OriginalFileName do cabeçalho de recurso do ficheiro. Pode utilizar um atributo de cabeçalho de recurso alternativo para as suas regras ao definir -SpecificFileNameLevel. Por exemplo, um programador de software pode utilizar o mesmo ProductName para todos os binários que fazem parte de uma aplicação. Ao utilizar -SpecificFileNameLevel, pode criar uma única regra para abranger todos esses binários na sua política em vez de regras individuais para cada ficheiro.
A Tabela 3 descreve as opções de atributo do cabeçalho do recurso disponíveis que pode definir com -SpecificFileNameLevel.
Tabela 3. -SpecificFileNameLevel options
| Valor SpecificFileNameLevel | Descrição |
|---|---|
| FileDescription | Especifica a descrição do ficheiro fornecida pelo programador do binário. |
| InternalName | Especifica o nome interno do binário. |
| OriginalFileName | Especifica o nome de ficheiro original, ou o nome com o qual o ficheiro foi criado pela primeira vez, do binário. |
| PackageFamilyName | Especifica o nome da família do pacote do binário. O nome da família do pacote consiste em duas partes: o nome do ficheiro e o ID do publicador. |
| NomedoProduto | Especifica o nome do produto com o qual o binário é enviado. |
| Caminho do Ficheiro | Especifica o caminho do ficheiro do binário. |
Mais informações sobre regras de caminhos de ficheiro
As regras do Filepath não fornecem as mesmas garantias de segurança que as regras explícitas do signatário, uma vez que se baseiam em permissões de acesso mutáveis. As regras filepath são mais adequadas para ambientes em que a maioria dos utilizadores está a executar como padrão e não como administrador. As regras de caminho são mais adequadas para permitir caminhos que espera que permaneçam apenas graváveis para administradores. Poderá querer evitar regras de caminho para diretórios em que os utilizadores padrão podem modificar ACLs na pasta.
Caminhos de ficheiro graváveis pelo utilizador
Por predefinição, o Controlo de Aplicações executa uma marcar de escrita de utilizadores no runtime que garante que as permissões atuais no caminho de ficheiro especificado apenas permitem o acesso de escrita para utilizadores administradores.
Existe uma lista definida de SIDs que o Controlo de Aplicações reconhece como administradores. Se um caminho de ficheiro permitir permissões de escrita para qualquer SID que não esteja nesta lista, o caminho do ficheiro é considerado gravável pelo utilizador, mesmo que o SID esteja associado a um utilizador administrador personalizado. Para lidar com estes casos especiais, pode substituir os marcar graváveis por administradores de runtime do Controlo de Aplicações com a opção Desativado:Runtime FilePath Rule Protection descrita anteriormente.
A lista de SIDs de administradores conhecidos do Controlo de Aplicações é:
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 ficheiro são geradas com New-CIPolicy, é gerada uma regra de caminho exclusiva e completamente qualificada para cada ficheiro detetado nos caminhos analisados. Para criar regras que permitam todos os ficheiros num caminho de pasta especificado, utilize New-CIPolicyRule para definir regras que contenham carateres universais, utilizando o comutador -FilePathRules .
Utilizar carateres universais nas regras de caminhos de ficheiro do Controlo de Aplicações
Os carateres universais seguintes podem ser utilizados nas regras de caminhos de ficheiros do Controlo de Aplicações:
| Caráter universal | Significado | Sistemas operacionais compatíveis |
|---|---|---|
* |
Corresponde a zero ou mais carateres. | Windows 11, Windows 10 e Windows Server 2022 |
? |
Corresponde a um único caráter. | apenas Windows 11 |
Também pode utilizar as seguintes macros quando o volume exato pode variar: %OSDRIVE%, %WINDIR%, %SYSTEM32%. Estas macros podem ser utilizadas em combinação com os carateres universais acima.
Observação
No Windows 11, pode utilizar um ou mais carateres universais em qualquer lugar dentro de uma regra de caminho de ficheiro.
Em todas as outras versões do Windows e do Windows Server, só é permitido um caráter universal por regra de caminho e tem de estar no início ou no fim de uma regra de caminho.
Regras de caminhos de ficheiro de exemplo com carateres universais
| Exemplos | Descrição | Sistemas operacionais compatíveis |
|---|---|---|
|
C:\Windows\* D:\EnterpriseApps\MyApp\* %OSDRIVE%\Windows\* |
Os carateres universais colocados no final de um caminho autorizam todos os ficheiros no caminho imediato e os respetivos subdiretórios recursivamente. | Windows 11, Windows 10 e Windows Server 2022 |
| *\bar.exe | Os carateres universais colocados no início de um caminho permitem o nome de ficheiro especificado exato em qualquer localização. | Windows 11, Windows 10 e Windows Server 2022 |
|
C:\*\CCMCACHE\*\7z???? -x64.exe %OSDRIVE%\*\CCMCACHE\*\7z???? -x64.exe |
Os carateres universais utilizados no meio de um caminho permitem que todos os ficheiros que correspondam a esse padrão. Considere cuidadosamente todas as correspondências possíveis, especialmente se a sua política desativar a marcar gravável pelo administrador com a opção Desativado:Runtime FilePath Rule Protection. Neste exemplo, ambos os caminhos hipotéticos corresponderiam:C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe C:\USERS\AppControlUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe |
apenas Windows 11 |
Sem um caráter universal, a regra filepath permite apenas um ficheiro específico (por exemplo, C:\foo\bar.exe).
Observação
Ao criar políticas de Controlo de Aplicações com Configuration Manager, existe uma opção para criar regras para ficheiros e pastas especificados. Estas regras não são regras de caminhos de ficheiros do Controlo de Aplicações. Em vez disso, Configuration Manager efetua uma análise única dos ficheiros e pastas especificados e cria regras para quaisquer binários encontrados nessas localizações no momento da análise. As alterações aos ficheiros e pastas especificados após essa análise não serão permitidas, a menos que a política de Configuration Manager seja reaplicada.
Mais informações sobre hashes
O Controlo de Aplicações utiliza o algoritmo hash de imagem Authenticode/PE ao calcular o hash de um ficheiro. Ao contrário do hash de ficheiro simples mais conhecido, o cálculo hash Authenticode omite a soma de verificação do ficheiro, a Tabela de Certificados e a Tabela de Certificados de Atributos. Por conseguinte, o hash Authenticode de um ficheiro não é alterado quando as assinaturas e carimbos de data/hora do ficheiro são alterados ou quando uma assinatura digital é removida do ficheiro. Com a ajuda do hash Authenticode, o Controlo de Aplicações fornece segurança adicional e menos sobrecarga de gestão para que os clientes não precisem de rever as regras do hash de política quando a assinatura digital no ficheiro é atualizada.
O hash de imagem Authenticode/PE pode ser calculado para ficheiros assinados digitalmente e não assinados.
Por que motivo a análise cria quatro regras de hash por ficheiro XML?
O cmdlet do PowerShell produz um Hash Authenticode Sha1, Hash Sha256, Hash de Página Sha1, Hash de Página Sha256. Durante a validação, o Controlo de Aplicações seleciona os hashes que são calculados com base na forma como o ficheiro é assinado e no cenário em que o ficheiro é utilizado. Por exemplo, se o ficheiro for assinado com hash de página, o Controlo de Aplicações valida cada página do ficheiro e evita carregar todo o ficheiro na memória para calcular o hash de autentico completo sha256.
Nos cmdlets, em vez de tentar prever que hash será utilizado, pré-calculamos e utilizamos os quatro hashes (sha1/sha2 authenticode e sha1/sha2 da primeira página). Este método também é resiliente a alterações na forma como o ficheiro é assinado, uma vez que a política de Controlo de Aplicações já tem mais do que um hash disponível para o ficheiro.
Por que motivo a análise cria oito regras hash para determinados ficheiros?
São criadas regras separadas para UMCI e KMCI. Se os cmdlets não conseguirem determinar que um ficheiro só é executado no modo de utilizador ou no kernel, as regras são criadas para ambos os cenários de assinatura com muita cautela. Se souber que um ficheiro específico só é carregado no modo de utilizador ou kernel, pode remover com segurança as regras adicionais.
Quando é que o Controlo de Aplicações utiliza o valor hash de ficheiro simples?
Existem alguns casos raros em que o formato de um ficheiro não está em conformidade com a especificação Authenticode, pelo que o Controlo de Aplicações volta a utilizar o hash de ficheiro simples. Este comportamento pode ocorrer por vários motivos, como se fossem efetuadas alterações à versão dentro da memória do ficheiro no runtime. Nestes casos, verá que o hash apresentado no evento de informações de assinatura 3089 correlacionado corresponde ao hash de ficheiro simples do evento de bloco 3076/3077. Para criar regras para ficheiros com um formato inválido, pode adicionar regras hash à política para o hash de ficheiro simples com o Assistente de Controlo de Aplicações ou ao editar diretamente o XML da política.