Управление приложениями для бизнеса и .NET
Warning
При принудительном применении элемента управления приложениями .NET не загружает некоторые объекты COM, если их идентификатор GUID регистрации не совпадает с идентификатором GUID, вычисляемым системой во время выполнения. В этом случае пользователь видит диалоговое окно общей ошибки загрузки COM, но в системе не регистрируется никаких событий или других сведений. Дополнительные сведения см. в разделе Советы по Администратор управлению приложениями & известные проблемы: .NET не загружает COM-объекты с несовпадениями GUID.
Приложения .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 или более поздней версии) и включите собственный AOT.
Управление приложениями и усиление защиты динамического кода .NET
Исследователи безопасности обнаружили, что некоторые возможности .NET, позволяющие приложениям загружать библиотеки из внешних источников или создавать новый код во время выполнения, можно использовать для обхода управления приложениями. Для устранения этой потенциальной уязвимости элемент управления приложениями включает параметр под названием Dynamic Code Security , который работает с .NET для проверки кода, загруженного во время выполнения.
Если включена защита динамического кода, политика управления приложениями применяется к библиотекам, которые платформа .NET загружает из внешних или удаленных источников, таких как Интернет или сетевая папка. Он также обнаруживает незаконное изменение кода, созданного на диск .NET, и блокирует загрузку измененного кода. Кроме того, некоторые функции загрузки .NET, не поддерживаемые динамической безопасностью кода, включая загрузку неподписанных сборок, созданных с помощью System.Reflection.Emit, всегда блокируются.
Как правило, при блокировке динамического кода его родительский процесс останавливается или завершается сбоем. Чтобы избежать этого с помощью ASP.NET, можно выполнить предварительную компиляцию динамического кода только для развертывания. См. раздел Предварительная компиляция только для развертывания в ASP.NET Обзор предварительной компиляции.
Важно.
.NET Dynamic Code Security работает в режиме аудита только в Windows 11 24H2 и более поздних версий, а также Windows Server 2025 и более поздних версий. Режим аудита для динамической безопасности кода в Windows 10 или более ранних версиях Windows 11 и Windows Server не существует. Если какая-либо политика управления приложениями задает параметр 19 Enabled:Dynamic Code Security в предыдущих версиях, то динамическое усиление защиты безопасности кода включается и применяется , даже если политика находится в режиме аудита. Всегда тщательно тестируйте приложения и используйте безопасные методики развертывания при развертывании политик управления приложениями в рабочей среде.
Динамическая безопасность кода устраняет потенциальные методы атаки, часто называемые атаками второго порядка. Это означает, что злоумышленник имеет доступ к системе и может выполнять код. Атаки второго порядка могут быть попытками получить сохраняемость или еще больше скрыть действия злоумышленников. Хотя динамическая безопасность кода важна и рекомендуется, корпорация Майкрософт также рекомендует протестировать политику в режиме аудита в системах под управлением Windows 11 24H2 и более поздних версий или Windows Server 2025 и более поздних версиях, прежде чем применять ее.
Код, заблокированный dynamic Code Security, регистрируется с идентификатором события 3114 в журнале событий CodeIntegrity — Operational . За исключением кода, загруженного с помощью одной из неподдерживаемых функций .NET, таких как System.Reflection.Emit, можно создавать правила, позволяющие блокировать динамический код, используя сведения из событий. См . статью Использование мастера управления приложениями для создания правил из журналов событий элемента управления приложениями.
Примечание.
.NET пытается выполнить динамически создаваемый код двумя разными способами. Если политика управления приложениями блокирует первый метод, .NET пытается использовать второй метод. Каждая из двух попыток вызывает отдельное событие 3114. Когда событие 3114 возникает изолированно, его можно игнорировать как "ложноположительный результат", так как оно охватывает только первую попытку .NET выполнить код. Только если вы видите два события 3114 в миллисекундах для одного и того же кода, это указывает на фактическую проблему для проверки.
Чтобы включить динамическую безопасность кода, добавьте параметр 19 — Enabled:Dynamic Code Security в политику управления приложениями с помощью мастера управления приложениями, командлета PowerShell set-ruleoption или добавьте следующий код <Rules> в раздел XML-кода политики управления приложениями:
<Rule>
<Option>Enabled:Dynamic Code Security</Option>
</Rule>