Controle de Aplicativos Administração Dicas & problemas conhecidos

Este artigo aborda dicas e truques para administradores e problemas conhecidos com o Controle de Aplicativos para Empresas. Teste essa configuração em seu laboratório antes de habilitá-la na produção.

Administração dicas e sugestões

Locais dos arquivos de política de Controle de Aplicativos

As políticas de controle de aplicativos de vários formatos de política são encontradas nos seguintes locais, dependendo se a política está assinada ou não e do método de implantação de política usado.

• <Volume do Sistema Operacional>\Windows\System32\CodeIntegrity\CiPolicies\Active\{PolicyId GUID}.cip
• <EFI System Partition>\Microsoft\Boot\CiPolicies\Active\{PolicyId GUID}.cip

O valor {PolicyId GUID} é exclusivo por política e definido no XML de política com o <elemento PolicyId> .

Para políticas de controle de aplicativos de formato de política única, além dos dois locais anteriores, procure também um arquivo chamado SiPolicy.p7b nos seguintes locais:

• <EFI System Partition>\Microsoft\Boot\SiPolicy.p7b
• <Volume do Sistema Operacional>\Windows\System32\CodeIntegrity\SiPolicy.p7b

Ordem de precedência da regra de arquivo

Quando o mecanismo de controle de aplicativos avalia arquivos em relação ao conjunto ativo de políticas no dispositivo, as regras são aplicadas na ordem a seguir. Depois que um arquivo encontrar uma correspondência, o Controle de Aplicativos interromperá o processamento posterior.

1. Todos os arquivos que corresponderem a uma regra de negação explícita são bloqueados, mesmo que você crie outras regras para tentar permiti-lo. As regras de negação podem usar qualquer nível de regra. Use o nível de regra mais específico prático ao criar regras de negação para evitar bloquear mais do que o pretendido.

2. Todos os arquivos que correspondam a uma regra de permissão explícita são executados.

3. Qualquer arquivo que tenha um atributo estendido (EA) do Instalador Gerenciado ou do Gráfico de Segurança Inteligente (ISG) é executado se a política habilitar a opção de correspondência (instalador gerenciado ou ISG).

4. Qualquer arquivo que não seja permitido com base nas condições anteriores terá sua reputação verificada usando o ISG quando essa opção estiver habilitada na política. O arquivo é executado se o ISG decidir que é seguro e um novo EA de ISG for gravado no arquivo.

5. Qualquer arquivo não permitido por uma regra explícita, ou baseado no ISG ou instalador gerenciado, é bloqueado implicitamente.

Problemas conhecidos

As políticas de Controle de Aplicativos no modo de Auditoria podem afetar o desempenho em um dispositivo

Quando um arquivo é avaliado em relação ao conjunto atual de políticas de Controle de Aplicativos, o mecanismo de Controle de Aplicativos define EAs (Atributos Estendidos) do kernel no arquivo quando ele passa as políticas ativas. Posteriormente, se o mesmo arquivo for executado, o controle de aplicativos verificará os EAs e reutilizará o resultado armazenado em cache, desde que as políticas em vigor permaneçam inalteradas. Esse mecanismo de cache garante que o Controle de Aplicativos seja dimensionado mesmo quando muitas políticas estão ativas, contendo um grande número de regras. No entanto, essa otimização de desempenho não é usada para políticas no modo de auditoria. Você pode observar uma diferença de desempenho em alguns casos entre sistemas com apenas políticas aplicadas em comparação com sistemas com políticas de auditoria.

A opção Gráfico de Segurança Inteligente (ISG) pode afetar o desempenho quando a nuvem é verificada para muitos arquivos

A opção ISG é uma funcionalidade incrivelmente importante do Controle de Aplicativos que facilita a complexidade do gerenciamento de regras para arquivos e aplicativos individuais. Mas, como ele depende de modelos de inteligência artificial (IA) baseados em nuvem, você deve evitar depender do ISG para tomar decisões sobre os aplicativos e arquivos importantes que você precisa executar. A dependência do ISG não é recomendada para cargas de trabalho críticas, código do sistema operacional Windows, especialmente código executado durante a inicialização ou situações em que o desempenho é mais crítico. Sempre que possível, você deve garantir que existam regras explícitas na política ou usar instaladores gerenciados em vez do ISG como uma forma de reduzir a sobrecarga de gerenciamento de políticas.

Ao considerar sua tolerância aos impactos do ISG no desempenho, considere também os efeitos adicionais no desempenho do problema anterior que afeta o desempenho das políticas do modo de auditoria. Tente evitar a execução de políticas no modo de auditoria que dependem muito da autorização do ISG para um grande número de arquivos.

Falha de parada de inicialização (tela azul) ocorrerá se mais de 32 políticas estiverem ativas

Até que você aplique a atualização de segurança do Windows lançada em ou após 9 de abril de 2024, seu dispositivo está limitado a 32 políticas ativas. Se o número máximo de políticas for excedido, o dispositivo exibirá uma tela azul fazendo referência a ci.dll com um bug marcar valor de 0x0000003b. Considere esse limite máximo de contagem de políticas ao planejar suas políticas de Controle de Aplicativos. Todas as políticas de caixa de entrada do Windows ativas no dispositivo também contam para esse limite. Para remover o limite máximo de política, instale a atualização de segurança do Windows lançada em ou após 9 de abril de 2024 e reinicie o dispositivo. Caso contrário, reduza o número de políticas no dispositivo para permanecer abaixo de 32 políticas.

As políticas de modo de auditoria podem alterar o comportamento de alguns aplicativos ou causar falhas no aplicativo

Embora o modo de auditoria do Controle de Aplicativos seja projetado para evitar qualquer efeito sobre os aplicativos, alguns recursos são sempre ativados/sempre aplicados com qualquer política de Controle de Aplicativos que ative a integridade do código do modo de usuário ( UMCI) com a opção 0 Habilitada:UMCI. Aqui está uma lista de alterações conhecidas do sistema no modo de auditoria:

• Alguns hosts de script podem bloquear ou executar código com menos privilégios, mesmo no modo de auditoria. Consulte Imposição de script com controle de aplicativo para obter informações sobre comportamentos individuais do host de script.
• Opção 19 habilitada: código dinâmico A segurança sempre será aplicada se alguma política UMCI incluir essa opção em algumas versões do Windows e do Windows Server. Consulte Controle de Aplicativos e .NET.

As imagens nativas do .NET podem gerar eventos de bloqueio de falsos positivos

Em alguns casos, os logs de integridade de código em que erros e avisos do Controle de Aplicativos para Empresas são gravados incluem eventos de erro para imagens nativas geradas para assemblies .NET. Normalmente, os blocos de imagem nativa são funcionalmente benignos, pois uma imagem nativa bloqueada retorna ao assembly correspondente e o .NET regenera a imagem nativa em sua próxima janela de manutenção programada. Para evitar isso, compile seu aplicativo .NET em código nativo com antecedência recurso.

O .NET não carrega objetos COM (Component Object Model) com GUIDs incompatíveis

Os objetos COM facilitam a comunicação e o trabalho conjunto de diferentes componentes de software. Para serem usados por outro componente, os objetos COM devem ser registrados no sistema operacional. O registro inclui um GUID calculado com base no código do objeto. O carregamento e a ativação do objeto COM são feitos usando outra parte do registro chamada nome do tipo. Às vezes, existe uma incompatibilidade entre o GUID registrado e o GUID real do código do objeto COM ativado. As incompatibilidades podem vir de bugs no código de registro do objeto COM do aplicativo ou se o código do objeto COM for alterado de uma maneira que afete o GUID. Normalmente, o Windows e o .NET perdoam essa condição e executam o código do objeto COM independentemente. Mas permitir que objetos COM sejam carregados onde há incompatibilidades de GUID deixa o sistema vulnerável a invasores que podem explorar a confusão de GUID para executar código não intencional.

Para aumentar a eficácia protetora do Controle de Aplicativos em um sistema vulnerável a essa técnica de ataque, o .NET aplica uma validação extra para marcar se o GUID do objeto COM registrado corresponde ao calculado pelo sistema. Se uma incompatibilidade for encontrada, o .NET não carregará o objeto COM e um erro geral de carregamento COM será gerado. Os aplicativos que usam objetos COM com essa condição podem se comportar de maneiras inesperadas e devem ser atualizados para corrigir problemas com o código de registro de objeto COM do aplicativo.

Como esse comportamento ocorre apenas quando a política de controle de aplicativos é imposta ao código do modo de usuário, você não pode detectá-lo no modo de auditoria. Não há registro em log ou outros eventos quando um objeto COM não é carregado devido à marca de validação extra. Reparar ou reinstalar o aplicativo pode resolver o problema temporariamente, mas uma atualização do aplicativo é necessária para corrigir o problema de registro COM e evitar instâncias futuras do problema.

Não há opções de controle de política para gerenciar. NET verifica marcar, o que significa que o marcar é sempre executado. Se você vir falhas de objeto COM depois que uma política de Controle de Aplicativos for implantada, entre em contato com o desenvolvedor de software ou com o ISV (fornecedor independente de software) que produz o aplicativo para solicitar uma correção para o problema.

Não há suporte para assinaturas que usam ECC (criptografia de curva elíptica)

As regras baseadas em signatário do Controle de Aplicativos funcionam apenas com a criptografia RSA. Algoritmos ECC, como ECDSA, não têm suporte. Se o Controle de Aplicativos bloquear um arquivo com base em assinaturas ECC, os eventos de informações de assinatura 3089 correspondentes mostrarão VerificationError = 23. Em vez disso, você pode autorizar os arquivos por regras de hash ou atributo de arquivo ou usando outras regras de signatário se o arquivo também for assinado com assinaturas usando RSA.

Os instaladores MSI são tratados como graváveis pelo usuário no Windows 10 quando permitido pela regra FilePath

Os arquivos do instalador MSI sempre são detectados como graváveis pelo usuário no Windows 10 e no Windows Server 2022 e anteriores. Se você precisar permitir arquivos MSI usando regras FilePath, deverá definir a opção 18 Disabled:Runtime FilePath Rule Protection em sua política de Controle de Aplicativos.

Os instaladores MSI iniciados diretamente da Internet são bloqueados

Falha na instalação de arquivos .msi diretamente da Internet em um computador protegido pelo Controle de Aplicativos. Por exemplo, este comando falha:

msiexec -i https://download.microsoft.com/download/2/E/3/2E3A1E42-8F50-4396-9E7E-76209EA4F429/Windows10_Version_1511_ADMX.msi

Como alternativa, baixe o arquivo MSI e execute-o localmente:

msiexec -i c:\temp\Windows10_Version_1511_ADMX.msi

Inicialização lenta e desempenho com políticas personalizadas

O Controle de Aplicativos avalia todos os processos que são executados, incluindo processos da caixa de entrada do Windows. Você poderá causar tempos de inicialização mais lentos, desempenho degradado e, possivelmente, problemas de inicialização se suas políticas não se basearem nos modelos de Controle de Aplicativos ou não confiarem nos signatários do Windows. Por esses motivos, você deve usar os modelos base de Controle de Aplicativos sempre que possível para criar suas políticas.

A política de Marcação AppId avalia arquivos DLL que não estão no escopo para marcação

Quando você usa políticas de Marcação AppId, o resultado são metadados, as "marcas", adicionadas ao token de processo de qualquer arquivo executável que passa a política. Em seguida, você pode usar as marcas para alterar o comportamento de um aplicativo ou componente que entende a marca AppId e procura uma marca correspondente em um processo. Por exemplo, você pode definir uma regra do Firewall do Windows que usa uma marca personalizada para identificar os processos que devem ter permissão para se conectar através do Firewall. As marcas AppId se aplicam apenas a arquivos executáveis (EXEs) e nunca se aplicam a outros tipos de código, como DLLs (Bibliotecas de Vínculo Dinâmico). Mas quando uma DLL é executada, o Controle de Aplicativos avalia o arquivo em relação à sua política, a menos que exista uma regra para permitir todos os arquivos desse tipo. Para causar um curto-circuito na avaliação de políticas para DLLs e reduzir ainda mais o efeito do Controle de Aplicativos no desempenho, adicione a seguinte regra às políticas de Marcação AppId: