Sugestões de Administração de Controlo de Aplicações & Problemas Conhecidos
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.
Este artigo aborda sugestões e truques para administradores e problemas conhecidos com o Controlo de Aplicações para Empresas. Teste esta configuração no laboratório antes de a ativar na produção.
sugestões e sugestões de Administração
Localizações dos ficheiros da política de Controlo de Aplicações
São encontradas várias políticas de Controlo de Aplicações em formato de política nas seguintes localizações, consoante a política esteja ou não assinada e o método de implementação de políticas que foi utilizado.
- <Volume> do SO\Windows\System32\CodeIntegrity\CiPolicies\Active\{PolicyId GUID}.cip
- <Partição> do Sistema EFI\Microsoft\Boot\CiPolicies\Active\{PolicyId GUID}.cip
O valor de {PolicyId GUID} é exclusivo pela política e definido no XML da política com o <elemento PolicyId> .
Para políticas de Controlo de Aplicações de formato de política única, além das duas localizações anteriores, procure também um ficheiro chamado SiPolicy.p7b nas seguintes localizações:
- <Partição> do Sistema EFI\Microsoft\Boot\SiPolicy.p7b
- <Volume> do SO\Windows\System32\CodeIntegrity\SiPolicy.p7b
Observação
Pode existir uma política de Controlo de Aplicações com o formato de política única GUID {A244370E-44C9-4C06-B551-F6016E563076} em qualquer uma das localizações do ficheiro de política.
Ordem de Precedência da Regra de Ficheiro
Quando o motor de Controlo de Aplicações avalia ficheiros relativamente ao conjunto ativo de políticas no dispositivo, as regras são aplicadas pela seguinte ordem. Assim que um ficheiro encontrar uma correspondência, o Controlo de Aplicações deixa de ser processado.
Qualquer ficheiro que corresponda a uma regra de negação explícita é bloqueado, mesmo que crie outras regras para tentar permitir. As regras de negação podem utilizar qualquer nível de regra. Utilize o nível de regra mais específico prático ao criar regras de negação para evitar bloquear mais do que pretende.
Qualquer ficheiro que corresponda a uma regra de permissão explícita é executado.
Qualquer ficheiro que tenha um atributo expandido do Managed Installer ou do Graph de Segurança Inteligente (ISG) é executado se a política ativar a opção correspondente (instalador gerido ou ISG).
Qualquer ficheiro que não seja permitido com base nas condições anteriores é verificado quanto à reputação através do ISG quando essa opção está ativada na política. O ficheiro é executado se o ISG decidir que é seguro e um novo ISG EA for escrito no ficheiro.
Qualquer ficheiro não permitido por uma regra explícita, ou com base no ISG ou instalador gerido, é bloqueado implicitamente.
Problemas conhecidos
As políticas de Controlo de Aplicações no Modo de auditoria podem afetar o desempenho num dispositivo
Quando um ficheiro é avaliado relativamente ao conjunto atual de políticas de Controlo de Aplicações, o motor de Controlo de Aplicações define os Atributos Expandidos (EAs) do kernel no ficheiro quando transmite as políticas ativas. Mais tarde, se o mesmo ficheiro for executado, o Controlo de Aplicações verifica os EAs e reutiliza o resultado em cache, desde que as políticas em vigor permaneçam inalteradas. Este mecanismo de colocação em cache garante que o Controlo de Aplicações dimensiona mesmo quando muitas políticas estão ativas que contêm um grande número de regras. No entanto, esta otimização de desempenho não é utilizada para políticas no modo de auditoria. Poderá observar uma diferença de desempenho em alguns casos entre sistemas com apenas políticas impostas 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 cloud é verificada para muitos ficheiros
A opção ISG é uma capacidade incrivelmente importante do Controlo de Aplicações que facilita a complexidade da gestão de regras para aplicações e ficheiros individuais. No entanto, uma vez que se baseia em modelos de inteligência artificial (IA) baseados na cloud, deve evitar confiar no ISG para tomar decisões sobre as aplicações e ficheiros importantes que precisa de executar. A dependência do ISG não é recomendada para cargas de trabalho críticas, código do SO Windows, especialmente código que é executado durante o arranque ou situações em que o desempenho é mais crítico. Sempre que possível, deve garantir que existem regras explícitas na política ou utilizar instaladores geridos em vez do ISG como forma de reduzir a sobrecarga de gestão de políticas.
Ao considerar a tolerância para os impactos de desempenho do ISG, considere também os efeitos de desempenho adicionados do problema anterior que afetam o desempenho das políticas do modo de auditoria. Tente evitar executar políticas no modo de auditoria que dependem fortemente da autorização ISG para um grande número de ficheiros.
Falha na paragem de arranque (ecrã azul) ocorre se estiverem ativas mais de 32 políticas
Até aplicar a atualização de segurança do Windows disponibilizada em ou depois de 9 de abril de 2024, o seu dispositivo está limitado a 32 políticas ativas. Se o número máximo de políticas for excedido, os ecrãs azuis do dispositivo referenciam ci.dll com um erro marcar valor de 0x0000003b. Considere este limite máximo de contagem de políticas ao planear as políticas de Controlo de Aplicações. Todas as políticas de caixa de entrada do Windows que estejam ativas no dispositivo também contam para este limite. Para remover o limite máximo de políticas, instale a atualização de segurança do Windows disponibilizada em ou depois de 9 de abril de 2024 e, em seguida, reinicie o dispositivo. Caso contrário, reduza o número de políticas no dispositivo para permanecer abaixo das 32 políticas.
Observação
O limite de políticas não foi removido no Windows 11 21H2 e permanece limitado a 32 políticas.
As políticas do modo de auditoria podem alterar o comportamento de algumas aplicações ou causar falhas de aplicações
Embora o modo de auditoria do Controlo de Aplicações tenha sido concebido para evitar qualquer efeito nas aplicações, algumas funcionalidades são sempre ativadas/sempre impostas com qualquer política de Controlo de Aplicações que ativa a integridade do código do modo de utilizador (UMCI) com a opção 0 Ativada:UMCI. Eis uma lista de alterações conhecidas do sistema no modo de auditoria:
- Alguns anfitriões de script podem bloquear código ou executar código com menos privilégios mesmo no modo de auditoria. Veja Imposição de scripts com o Controlo de Aplicações para obter informações sobre os comportamentos individuais do anfitrião de scripts.
- Opção 19 Ativada:A Segurança de Código Dinâmico é sempre imposta se qualquer política UMCI incluir essa opção em algumas versões do Windows e Windows Server. Veja Controlo de Aplicações e .NET.
As imagens nativas de .NET podem gerar eventos de blocos falsos positivos
Em alguns casos, os registos de integridade do código em que os erros e avisos do Controlo de Aplicações para Empresas são escritos incluem eventos de erro para imagens nativas geradas para assemblagens .NET. Normalmente, os blocos de imagens nativos são funcionalmente benignos, uma vez que uma imagem nativa bloqueada reverte para a assemblagem correspondente e o .NET regenera a imagem nativa na próxima janela de manutenção agendada. Para evitar isso, compile a sua aplicação .NET em código nativo com antecedência .
O .NET não carrega objetos de Modelo de Objeto de Componente (COM) com GUIDs não correspondentes
Os objetos COM facilitam a comunicação e o trabalho em conjunto de diferentes componentes de software. Para serem utilizados por outro componente, os objetos COM têm de ser registados no sistema operativo. O registo inclui um GUID calculado com base no código do objeto. O carregamento e a ativação do objeto COM são efetuadas com outra parte do registo denominada nome do tipo. Por vezes, existe um erro de correspondência entre o GUID registado e o GUID real do código do objeto COM ativado. As incompatibilidades podem ser provenientes de erros no código de registo de objetos COM da aplicação ou se o código do objeto COM for alterado de uma forma que afete o GUID. Normalmente, o Windows e o .NET estão a perdoar esta condição e a executar o código do objeto COM, independentemente disso. No entanto, permitir que os objetos COM sejam carregados onde existem incompatibilidades de GUID deixa o sistema vulnerável a atacantes que podem explorar a confusão do GUID para executar código não intencional.
Para aumentar a eficácia protetora do Controlo de Aplicações num sistema vulnerável a esta técnica de ataque, o .NET aplica uma validação extra aos marcar que o GUID do objeto COM registado corresponde ao calculado pelo sistema. Se for encontrado um erro de correspondência, o .NET não carrega o objeto COM e é gerado um erro de carga COM geral. As aplicações que utilizam objetos COM com esta condição podem comportar-se de formas inesperadas e têm de ser atualizadas para corrigir problemas com o código de registo de objetos COM da aplicação.
Uma vez que este comportamento só ocorre quando a política de Controlo de Aplicações é imposta no código do modo de utilizador, não pode detetá-la no modo de auditoria. Não existem registos ou outros eventos quando um objeto COM não é carregado devido à validação extra marcar. Reparar ou reinstalar a aplicação pode resolve o problema temporariamente, mas é necessária uma atualização da aplicação para corrigir o problema de registo COM e evitar instâncias futuras do problema.
Não existem opções de controlo de políticas para gerir . A verificação guid do NET marcar, o que significa que a marcar é sempre executada. Se vir falhas de objetos COM após a implementação de uma política de Controlo de Aplicações, contacte o programador de software ou o Fornecedor Independente de Software (ISV) que produz a aplicação para pedir uma correção para o problema.
As assinaturas que utilizam criptografia de curva elíptica (ECC) não são suportadas
As regras baseadas no signatário do Controlo de Aplicações só funcionam com a criptografia RSA. Os algoritmos ECC, como ECDSA, não são suportados. Se o Controlo de Aplicações bloquear um ficheiro baseado em assinaturas ECC, os eventos de informações de assinatura 3089 correspondentes mostram VerificationError = 23. Em vez disso, pode autorizar os ficheiros através de 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.
Os instaladores MSI são tratados como graváveis pelo utilizador no Windows 10 quando permitidos pela regra FilePath
Os ficheiros do instalador MSI são sempre detetados como graváveis pelo utilizador no Windows 10 e no Windows Server 2022 e anterior. Se precisar de permitir ficheiros MSI com regras filePath, tem de definir a opção 18 Desativado:Runtime FilePath Rule Protection na sua política de Controlo de Aplicações.
Os instaladores MSI iniciados diretamente a partir da Internet estão bloqueados
Falha ao instalar .msi ficheiros diretamente da Internet para um computador protegido pelo Controlo de Aplicações. 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 solução, transfira o ficheiro MSI e execute-o localmente:
msiexec -i c:\temp\Windows10_Version_1511_ADMX.msi
Arranque lento e desempenho com políticas personalizadas
O Controlo de Aplicações avalia todos os processos que são executados, incluindo os processos do Windows na caixa de entrada. Pode causar tempos de arranque mais lentos, desempenho degradado e possivelmente problemas de arranque se as políticas não forem baseadas nos modelos do Controlo de Aplicações ou não confiarem nos signatários do Windows. Por estes motivos, deve utilizar os modelos base do Controlo de Aplicações sempre que possível para criar as suas políticas.
A política de Identificação de AppId avalia os ficheiros DLL que não estão no âmbito da identificação
Quando utiliza políticas de Etiquetagem AppId, o resultado são os metadados, as "etiquetas", adicionados ao token de processo de qualquer ficheiro executável que transmita a política. Em seguida, pode utilizar as etiquetas para alterar o comportamento de uma aplicação ou componente que compreenda a etiqueta AppId e procure uma etiqueta correspondente num processo. Por exemplo, pode definir uma regra da Firewall do Windows que utiliza uma etiqueta personalizada para identificar processos que devem ser autorizados a ligar através da Firewall. As Etiquetas AppId só se aplicam a ficheiros executáveis (EXEs) e nunca se aplicam a outros tipos de código, como Bibliotecas de Ligação Dinâmica (DLLs). No entanto, quando uma DLL é executada, o Controlo de Aplicações avalia o ficheiro em relação à sua política, a menos que exista uma regra para permitir todos os ficheiros desse tipo. Para avaliar a política de curto-circuito para DLLs e reduzir ainda mais o impacto do Controlo de Aplicações no desempenho, adicione a seguinte regra às políticas de Etiquetagem appId:
