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.
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.
Regras de negação explícitas – um ficheiro é bloqueado se existir uma regra de negação explícita para o mesmo, mesmo que sejam criadas 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.
Regras de permissão explícitas – se existir uma regra de permissão explícita para o ficheiro, o ficheiro é executado.
Em seguida, o Controlo de Aplicações verifica o atributo expandido do Instalador Gerido (EA) ou o EA (Intelligent Security Graph) no ficheiro. Se existir um EA e a política ativar a opção correspondente, o ficheiro é permitido.
Por fim, o Controlo de Aplicações faz uma chamada na cloud para o ISG para obter reputação sobre o ficheiro, se a política ativar a opção ISG.
Qualquer ficheiro não permitido por uma regra explícita ou baseado em ISG ou MI é bloqueado implicitamente.
Problemas conhecidos
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 permanecerá 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 o impacto 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. Veja Controlo de Aplicações e .NET.
As imagens nativas de .NET podem gerar eventos de bloco 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.
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.
As Instalações MSI iniciadas diretamente a partir da Internet são bloqueadas pelo Controlo de Aplicações
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.
Considerações sobre a política de Etiquetagem de AppId
Políticas de Etiquetagem AppId que não são criadas com base nos modelos base do Controlo de Aplicações ou que não permitem que os signatários da caixa de entrada do Windows possam causar um aumento significativo nos tempos de arranque (~2 minutos).
Se não conseguir adicionar os signatários do Windows à lista de permissões ou criar os modelos base do Controlo de Aplicações, adicione a seguinte regra às suas políticas para melhorar o desempenho:
Uma vez que as políticas de Etiquetagem AppId são avaliadas, mas não podem etiquetar ficheiros dll, esta regra abreviada a avaliação dll e melhora o desempenho da avaliação.