Соображения безопасности для AppLocker
В этом разделе для специалистов по ИТ рассматриваются вопросы обеспечения безопасности, которые следует учитывать при внедрении AppLocker.
Целью AppLocker является ограничение доступа к программному обеспечению, а также к данным, которые использует это программное обеспечение, определенной группе пользователей или пользователей из определенной бизнес-группы. Ниже представлены соображения безопасности для AppLocker.
AppLocker развертывается на предприятии и администрируется централизованно теми специалистами отдела ИТ, которые имеют доверенные учетные данные. Это позволяет обеспечить соответствие процессов создания и развертывания политик похожим процессам развертывания политик и ограничениям безопасности.
Политики AppLocker распространяются в пределах домена через известные процессы и при помощи известных способов посредством групповой политики. Однако политики AppLocker можно также устанавливать на отдельных компьютерах, если у данного лица имеются права администратора, причем эти политики могут не соответствовать политикам безопасности организации. Параметры принудительного применения для локальных политик переопределяются теми же политиками AppLocker, указанными в объекте групповой политики. Однако, поскольку правила AppLocker можно добавлять, локальная политика, которая не входит в объект групповой политики, все равно будет применяться на этом компьютере.
Майкрософт не предоставляет способа разработки каких-либо расширений для AppLocker. Интерфейсы не являются общедоступными. Пользователь с учетными данными администратора может автоматизировать некоторые процессы AppLocker с помощью командлетов Windows PowerShell. Подробные сведения об использовании командлетов Windows PowerShell с AppLocker см. в статье AppLocker Cmdlets in Windows PowerShell (Командлеты AppLocker в Windows PowerShell).
AppLocker работает в контексте Administrator или LocalSystem, которые имеют набор самых высоких прав. Этот контекст безопасности может потенциально использоваться для злоупотреблений. Если пользователь с учетными данными администратора вносит изменения в политику AppLocker на локальном устройстве, присоединенном к домену, эти изменения могут быть перезаписаны или запрещены объектом групповой политики, содержащим правило AppLocker для этого же файла (или пути), которое было изменено на локальном устройстве. Однако, поскольку правила AppLocker можно добавлять, локальная политика, которая не входит в объект групповой политики, все равно будет применяться на этом компьютере. Если локальный компьютер не присоединен к домену и не администрируется при помощи групповой политики, сотрудник с учетными данными администратора может изменить политику AppLocker.
При обеспечении защиты файлов в каталоге при помощи правила с типом условия "путь", используя в нем действия "разрешить" или "запретить", все равно необходимо и рекомендуется ограничить доступ к этим файлам, установив списки управления доступом в соответствии с политикой безопасности.
AppLocker не защищает от запуска 16-разрядных двоичных файлов DOS на виртуальной машине DOS (NTVDM). Эта технология позволяет запускать старые 16-разрядные программы DOS и Windows на компьютерах на базе процессора Intel 80386 и более поздних версий при наличии на этом же устройстве другой операционной системы, управляющей аппаратным обеспечением. В результате получается, что 16-разрядные двоичные файлы могут выполняться в Windows Server 2008 R2 и Windows 7, когда AppLocker настроен в иных случаях блокировать двоичные файлы и библиотеки. Если требуется запретить запуск 16-разрядных приложений, то для NTVDM.exe следует настроить правило отказа в коллекции правил для исполняемых файлов.
Нельзя использовать AppLocker (или политики ограниченного использования программ) для предотвращения выполнения кода вне подсистемы Win32. В частности, это относится к подсистеме POSIX в Windows NT. Если требуется запретить запуск приложений в подсистеме POSIX, следует отключить эту подсистему.
AppLocker может управлять только файлами VBScript, JScript, BAT, CMD и сценариями Windows PowerShell. AppLocker не может управлять всем интерпретированным кодом, который выполняется в хост-процессе, например сценариями и макросами Perl. Интерпретируемый код — это форма исполняемого кода, который выполняется в рамках хост-процесса. Например, пакетные файлы Windows (BAT), выполняемые в контексте командного узла Windows (cmd.exe). Чтобы управлять интерпретируемым кодом при помощи AppLocker, хост-процесс должен вызывать AppLocker перед началом выполнения интерпретируемого кода, после чего применить решение, возвращенное AppLocker. Не все хост-процессы обращаются к AppLocker, поэтому AppLocker не может управлять каждым видом интерпретируемого кода, например макросами Microsoft Office.
Важно
Если требуется разрешить запуск этих хост-процессов, необходимо настроить соответствующие параметры безопасности для них. Например, настройте параметры безопасности в Microsoft Office, чтобы обеспечить загрузку только подписанных и доверенных макросов.
Привила AppLocker либо разрешают, либо запрещают запуск приложения. AppLocker не контролирует работу приложений после их запуска. Приложения могут содержать флажки, передаваемые функциям, которые сигнализируют AppLocker обходить правила и разрешить загрузку другого файла EXE или DLL. На практике приложение, запуск которого разрешен AppLocker, может использовать эти флаги для обхода правил AppLocker и запуска дочерних процессов. Необходимо тщательно изучить каждое приложение перед тем, как разрешить их запуск при помощи правил AppLocker.
Примечание
Два флага, которые описывают это условие, — это SANDBOX_INERT, который можно передать в CreateRestrictedToken, и LOAD_IGNORE_CODE_AUTHZ_LEVEL, который можно передать в LoadLibraryEx. Оба этих флага дают сигнал AppLocker обойти правила и разрешить загрузку дочернего файла EXE или DLL.