Controlo de Aplicações para Empresas e .NET

As aplicações .NET (como escritas numa linguagem de alto nível como C#) são compiladas para uma Linguagem Intermédia (IL). IL é um formato de código compacto que pode ser suportado em qualquer sistema operativo ou arquitetura. A maioria das aplicações .NET utiliza APIs que são suportadas em vários ambientes, o que requer apenas o runtime do .NET para executar. O IL tem de ser compilado para código nativo para poder ser executado numa CPU, por exemplo Arm64 ou x64. Quando o .NET compila IL para imagem nativa (NI) num dispositivo com uma política de modo de utilizador do Controlo de Aplicações, verifica primeiro se o ficheiro IL original passa as políticas atuais do Controlo de Aplicações. Em caso afirmativo, o .NET define um atributo expandido NTFS (EA) no ficheiro NI gerado para que o Controlo de Aplicações também confie no mesmo. Quando a aplicação .NET é executada, o Controlo de Aplicações vê o EA no ficheiro NI e permite-o.

O EA definido no ficheiro NI aplica-se apenas às políticas de Controlo de Aplicações atualmente ativas. Se uma das políticas ativas do Controlo de Aplicações for atualizada ou for aplicada uma nova política, o EA no ficheiro NI será invalidado. Da próxima vez que a aplicação for executada, o Controlo de Aplicações bloqueará o ficheiro NI. O .NET processa o bloco corretamente e volta ao código IL original. Se o IL continuar a passar as políticas de Controlo de Aplicações mais recentes, a aplicação será executada sem qualquer impacto funcional. Uma vez que o IL está agora a ser compilado no runtime, poderá notar um ligeiro impacto no desempenho da aplicação. Quando o .NET tem de reverter para IL, o .NET também agendará um processo para ser executado na próxima janela de manutenção para regenerar todos os ficheiros NI, restabelecendo assim o EA de Controlo de Aplicações para todo o código que passa as políticas de Controlo de Aplicações mais recentes.

Em alguns casos, se um ficheiro NI estiver bloqueado, poderá ver um evento de bloco "falso positivo" no registo de eventos CodeIntegrity – Operacional, conforme descrito em Sugestões de Administração do Controlo de Aplicações & Problemas Conhecidos.

Para mitigar qualquer impacto no desempenho causado quando o EA de Controlo de Aplicações não é válido ou está em falta:

• Evite atualizar as políticas de Controlo de Aplicações com frequência.
• Execute ngen update (em todas as arquiteturas de máquina) para forçar o .NET a regenerar todos os ficheiros NI imediatamente após aplicar alterações às políticas de Controlo de Aplicações.
• Migrar aplicações para o .NET Core (.NET 6 ou superior).

Controlo de Aplicações e proteção de .NET

Os investigadores de segurança descobriram que algumas capacidades do .NET que permitem que as aplicações carreguem bibliotecas a partir de origens externas ou gerem novo código no runtime podem ser utilizadas para contornar os controlos do Controlo de Aplicações. Para resolver esta potencial vulnerabilidade, o Controlo de Aplicações inclui uma opção denominada Segurança de Código Dinâmico que funciona com o .NET para verificar o código carregado no runtime.

Quando a opção Segurança do Código Dinâmico está ativada, a política de Controlo de Aplicações é aplicada às bibliotecas que o .NET carrega a partir de origens externas. Por exemplo, quaisquer origens remotas, como a Internet ou uma partilha de rede.

Além disso, deteta adulteração no código gerado para o disco por .NET e bloqueia o carregamento de código que foi adulterado.

A Segurança do Código Dinâmico não está ativada por predefinição porque as políticas existentes podem não ter em conta bibliotecas carregadas externamente. Além disso, algumas funcionalidades de carregamento do .NET, incluindo o carregamento de assemblagens não assinadas criadas com System.Reflection.Emit, não são atualmente suportadas com a Segurança de Código Dinâmico ativada. A Microsoft recomenda testar a Segurança do Código Dinâmico no modo de auditoria antes de a impor para descobrir se devem ser incluídas novas bibliotecas na política.

Além disso, os clientes podem pré-configurar a implementação apenas para impedir que um executável permitido seja terminado porque tenta carregar código gerado dinamicamente não assinado. Veja a secção "Pré-conclusão apenas para Implementação" no documento Descrição Geral da Pré-conclusão do ASP.NET para saber como corrigir esse problema.

Para ativar a Segurança de Código Dinâmico, adicione a seguinte opção à <Rules> secção da política de Controlo de Aplicações:

<Rule>
    <Option>Enabled:Dynamic Code Security</Option>
</Rule>