Управление приложениями для бизнеса и .NET
Приложения .NET (написанные на языке высокого уровня, например C#) компилируются в промежуточный язык (IL). IL — это компактный формат кода, который может поддерживаться в любой операционной системе или архитектуре. Большинство приложений .NET используют API- интерфейсы, поддерживаемые в нескольких средах, для выполнения которых требуется только среда выполнения .NET. Для выполнения на ЦП, например Arm64 или x64, необходимо компилировать il в машинный код. Когда .NET компилирует IL в собственный образ (NI) на устройстве с политикой пользовательского режима управления приложениями, сначала проверяет, передает ли исходный IL-файл текущие политики управления приложениями. Если это так, .NET задает расширенный атрибут NTFS (EA) в созданном NI-файле, чтобы элемент управления приложениями знал, что он также является доверенным. Когда приложение .NET запускается, элемент управления приложениями видит EA в NI-файле и разрешает его.
Значение EA, установленное в ni-файле, применяется только к активным политикам управления приложениями. Если одна из активных политик управления приложениями обновлена или применяется новая политика, ea в NI-файле становится недействительным. При следующем запуске приложения элемент управления приложения заблокирует NI-файл. .NET корректно обрабатывает блок и возвращается к исходному коду IL. Если il-код по-прежнему передает последние политики управления приложениями, приложение запускается без каких-либо функциональных последствий. Так как il-код теперь компилируется во время выполнения, вы можете заметить небольшое влияние на производительность приложения. Когда .NET необходимо вернуться к IL, .NET также запланирует выполнение процесса в следующем окне обслуживания для повторного создания всех NI-файлов, таким образом повторно создав ea app Control EA для всего кода, который проходит последние политики управления приложениями.
В некоторых случаях, если NI-файл заблокирован, в журнале событий CodeIntegrity — Operational может отображаться событие блока "ложноположительные срабатывания", как описано в разделе Советы по управлению приложениями Администратор & известные проблемы.
Чтобы снизить влияние на производительность, вызванное тем, что советник по управлению приложениями недействителен или отсутствует, выполните следующие действия:
- Избегайте частого обновления политик управления приложениями.
- Запустите
ngen update(на всех архитектурах компьютера), чтобы заставить .NET повторно создавать все NI-файлы сразу после применения изменений в политиках управления приложениями. - Перенос приложений в .NET Core (.NET 6 или более поздней версии).
Управление приложениями и усиление защиты .NET
Исследователи безопасности обнаружили, что некоторые возможности .NET, позволяющие приложениям загружать библиотеки из внешних источников или создавать новый код во время выполнения, можно использовать для обхода элементов управления приложением. Для устранения этой потенциальной уязвимости элемент управления приложениями включает параметр под названием Dynamic Code Security , который работает с .NET для проверки кода, загруженного во время выполнения.
Если включен параметр "Безопасность динамического кода", политика управления приложениями применяется к библиотекам, которые загружает .NET из внешних источников. Например, любые удаленные источники, такие как Интернет или сетевая папка.
Важно.
Защита динамического кода .NET включается и применяется, если для какой-либо политики управления приложениями с включенным UMCI установлен параметр 19 Enabled:Dynamic Code Security. Для этой функции нет режима аудита. Перед включением приложения на большом количестве устройств следует протестировать с помощью этого параметра.
Кроме того, он обнаруживает незаконное изменение кода, созданного на диск .NET, и блокирует загрузку кода, который был изменен.
По умолчанию динамическая безопасность кода не включена, так как существующие политики могут не учитывать внешние загруженные библиотеки. Кроме того, некоторые функции загрузки .NET, включая загрузку неподписанных сборок, созданных с помощью System.Reflection.Emit, в настоящее время не поддерживаются с включенной динамической безопасностью кода. Корпорация Майкрософт рекомендует протестировать dynamic Code Security в режиме аудита, прежде чем применять его, чтобы определить, следует ли включать в политику новые библиотеки.
Кроме того, клиенты могут предварительно выполнить компиляцию для развертывания, чтобы предотвратить завершение допустимого исполняемого файла, так как он пытается загрузить динамически созданный код без знака. Сведения о том, как устранить эту проблему, см. в разделе "Предварительная компиляция только для развертывания" в документе ASP.NET Обзор предварительной компиляции .
Чтобы включить dynamic Code Security, добавьте следующий параметр в <Rules> раздел политики управления приложениями:
<Rule>
<Option>Enabled:Dynamic Code Security</Option>
</Rule>