В Windows Server 2008 и Windows Vista реализована функция BitLocker, обеспечивающая шифрование данных на уровне тома на компьютерах с операционными системами Server 2008 и Vista. Windows Server 2008 R2 и Windows 7 включают в себя функцию AppLocker, которая отслеживает работу приложений и позволяет администраторам Windows ограничить набор приложений, которые можно запускать на рабочих станциях и серверах, входящих в определенный домен.
AppLocker является расширенной версией политик ограничения доступа к программному обеспечению (SRP), использовавшихся в Windows Server 2003. SPR и AppLocker призваны бороться с запуском вредоносного кода на платформах Windows. Также можно задействовать SRP и AppLocker для того, чтобы заблокировать доступ пользователей к играм, таким как «Сапер», или запретить запуск браузера, который не является стандартным в вашей организации.
В этой статье я сравниваю AppLocker и SRP, причем особое внимание уделяется возможным подводным камням и особенностям, о которых необходимо знать, прежде чем приступить к использованию AppLocker в рабочей среде. В таблице приведен список основных различий между SRP и AppLocker.
Черные и белые списки
Средства защиты от вредоносного кода, такие как антивирусы и антишпионы, часто используют технологию, известную как черные списки. Программы, использующие подобную технологию, позволяют сохранять на компьютере любые файлы, кроме тех, которые заражены вредоносным кодом, информация о котором содержится в черном списке. Если файл заражен, программа удаляет его или отправляет в карантин.
Наиболее современный подход в борьбе с вредоносными программами — создание белых списков. Этот подход полностью противоположен созданию черных списков, поскольку в данном случае защитной программой блокируются все файлы, кроме тех, которые содержатся в ее белом списке.
Когда речь идет о защите компьютера от запуска нежелательного программного обеспечения, использование белых списков предпочтительно. Они значительно облегчают жизнь системного администратора, поскольку в современном сетевом мире пользователям обычно разрешен запуск небольшого количества приложений; список же блокируемых программ значительно больше и включает в себя все многообразие неопознанного вредоносного кода, которое пользователи могут загрузить из Интернета. Однако при неправильном использовании белых списков возникает риск «самоблокировки», например если пренебречь необходимостью добавить в белый список административные инструменты. Также по невнимательности можно оставить своих пользователей без рабочих инструментов, если забыть добавить в белый список какое-либо из необходимых им приложений.
И SRP, и AppLocker поддерживают создание белых и черных списков, несмотря на то что политики по умолчанию у них разные. AppLocker использует белые списки по умолчанию, то есть блокирует все подряд; системный администратор должен явным образом указать приложения, которые могут быть запущены. Со своей стороны, в настройках SRP по умолчанию используются черные списки, что позволяется запускать любые приложения; системный администратор должен определить исключения для тех приложений, которые должны быть заблокированы. Установка белых списков в SRP сопряжена с некоторыми сложностями, поэтому подавляющее большинство системных администраторов использует этот инструмент только с черными списками. Для создания защиты, основанной на контроле приложений посредством использования белых списков, намного лучше приспособлен AppLocker.
Настройка правил AppLocker
Для начала необходимо знать, как настраивать в AppLocker правила ограничения приложений. Как и в SRP, для настройки и применения правил AppLocker можно использовать объект групповой политики (GPO). Также для настройки правил AppLocker возможно применение команды PowerShell (в отличие от SRP). Дополнительную информацию об использовании команд PowerShell для настройки AppLocker можно найти в блоге MSDN Windows PowerShell по адресу blogs.msdn.com/powershell/archive/2009/06/02/gettingstarted-with-applocker-managementusing-powershell.aspx.
GPO для AppLocker расположен в контейнере ComputerConfigurationWindows SettingsSecuritySettingsApplication Control Policies, как показано на экране 1. Обратите внимание, что также можно настроить правила в контейнере Software Restriction Policies. Эти две технологии могут сосуществовать — SRP применим на всех платформах Windows, выпущенных после Windows XP и Windows Server 2003, однако AppLocker доступен только на Windows Server 2008 R2 и Windows 7 редакций Ultimate и Enterprise. Поскольку правила политик, используемые в этих двух технологиях, сильно различаются, компания Microsoft не предусматривает автоматическую конвертацию политик из SRP в политики AppLocker (например, если система с Server 2008 модернизируется до Server 2008 R2).
AppLocker поддерживает три типа правил: правила исполняемых файлов, правила установщика Windows и правила сценариев. Эти типы правил сгруппированы в коллекции правил и представлены в виде субконтейнеров контейнера AppLocker в настройках GPO, как показано на экране 1.
- Правила исполняемых файлов могут разрешать или запрещать запуск файлов *.exe и *.com.
- Правила установщика Windows могут разрешать или запрещать исполнение файлов *.msi (файлы установщика Windows) и *.msp (файлы обновлений установщика Windows).
- Правила сценариев могут разрешать или запрещать исполнение файлов сценариев различных типов (*.ps1, *.bat, *.cmd, *.vbs, *.js).
Если щелкнуть правой кнопкой мыши по одному из трех контейнеров, содержащих коллекции правил, AppLocker предложит три варианта для создания правил: «Создать новое правило», «Создать правила автоматически» и «Создать правила по умолчанию».
Создать правила по умолчанию. Предпочтительным вариантом для начала работы по определению правил AppLocker является «Создать правила по умолчанию». Правила по умолчанию формируются автоматически; эти правила специально созданы таким образом, чтобы позволить Windows полноценно запуститься и предоставить администратору возможность осуществлять настройку системы. Согласно используемому в AppLocker по умолчанию подходу белых списков обе задачи очень важны и, таким образом, риск «самоблокировки» сведен к минимуму. Для обеспечения безопасности сети AppLocker предложит автоматически создать правила по умолчанию, если произведена попытка создать новое правило, но правила по умолчанию еще не сформированы.
Создаваемые по умолчанию правила AppLocker являются относительно открытыми. Например, они включают правило, которое предоставляет членам группы локальных администраторов доступ ко всем локальным файлам. Лучшая практика AppLocker заключается в следующем: сначала необходимо создать правила по умолчанию, а затем уточнить их путем создания вручную более жестких правил через вариант «Создать новое правило» (как, я объясню ниже). Правила по умолчанию могут быть созданы отдельно для каждого из трех типов правил: правил для исполняемых файлов, правил установщика Windows и правил сценариев.
Создать правила автоматически. При выборе варианта «Создать правила автоматически» AppLocker, по сути, создает для вас белый список. AppLocker анализирует содержимое папки, указанной в мастере автоматического создания правил, и предлагает набор правил для находящихся в ней файлов. Эта важная новая функция AppLocker отсутствует в SRP. В SRP необходимо задать белый список самостоятельно. Для создания белого списка AppLocker на определенной группе систем я рекомендую использовать эталонный компьютер. Использование одного белого списка на нескольких компьютерах и его импорт в объект групповой политики является относительно простой задачей, благодаря удобному механизму экспорта/импорта AppLocker.
Чтобы автоматически создать набор правил, выберите «Автоматически создать правила» в контекстном меню разделов «Правила для исполняемых файлов», «Правила установщика Windows» или «Правила сценариев». На первом экране мастера необходимо выбрать расположение файловой системы на эталонной системе, указать пользователей или группы, к которым следует применить белый список (это важная настройка, которая отсутствует в SRP), и ввести имя для итогового набора правил.
Далее требуется указать, будут создаваемые правила основываться на хеше файлов или на их местоположении. Использование хеша позволяет уникальным образом идентифицировать файл, однако при этом возникает необходимость пересмотра правила, если файл будет изменен (например, после применения обновления). Кроме того, использование хешей может отрицательным образом сказаться на производительности системы.
Также мастер позволяет просматривать список проанализированных файлов (включая возможность отмены создания правила для заданного файла), предварительно просматривать список правил и выполнять поиск в нем. На экране 2 показан заключительный шаг при создании списка правил.
Создать новое правило. Другой подход к созданию правил AppLocker заключается в их ручном определении, с использованием варианта «Создать новое правило». Обычно этот способ применяется в качестве завершающего при доведении до совершенства правил, созданных с использованием двух вариантов, рассмотренных выше.
Используя мастер создания правил, можно создавать новые разрешающие или запрещающие правила для файлов, осуществлять выбор группы или пользователя, к которым необходимо применить созданное правило, а также определять, каким образом AppLocker будет идентифицировать файлы — с использованием хеша, местоположения или издателя файла. AppLocker использует эту идентификацию в качестве основного условия. В дальнейшем можно более конкретно идентифицировать файлы, добавляя с помощью мастера различные исключения в основное условие (основанные на хеше, расположении или издателе).
Если выбрана идентификация, основанная на издателе, AppLocker будет идентифицировать файл, полагаясь на цифровую подпись, присвоенную файлу издателем в процессе подписания программного продукта. Вариант с идентификацией, основанной на издателе, показан на экране 3. Используя бегунок, можно ограничить идентификацию только именем издателя (общая идентификация) либо применить расширенную идентификацию, вплоть до точной версии файла (конкретная идентификация). Мастер также позволяет указать пользовательские значения для издателя, названия продукта, а также имени и версии файла.
Обратите внимание, что AppLocker не предлагает такой вариант идентификации файла, как определение сетевой зоны (она же зона Интернета). Этот вариант используется в SRP и позволяет идентифицировать код, загруженный с сайта, основываясь на зоне Интернета, к которой этот сайт принадлежит.
Применение правил AppLocker
Подобно SRP, AppLocker не задействован по умолчанию. Одно лишь создание правил вовсе не означает их немедленного применения на всех клиентских системах. Для того чтобы правила были задействованы, необходимо два дополнительных шага. Во‑первых, требуется определить, будут правила задействованы «по полной программе» либо будут запущены только в режиме аудита. Во‑вторых, нужно удостовериться, что на целевых системах запущена служба идентификации приложений.
Настройки применения правил AppLocker определяются в свойствах его объекта групповой политики. Как показано на экране 4, для каждой из трех основных коллекций правил (правила для исполняемых файлов, правила установщика Windows и правила сценариев) можно определить, является ли правило заданным (по умолчанию правило не задано) и указать, применять ли данное правило полностью либо запустить его только в режиме аудита.
/IMAGE/1288782791_42.jpg)
Вариант «Только аудит» — это новая полезная функция, которая отсутствует в SRP. Если коллекция правил установлена в режим «Только аудит», правила, содержащиеся в данной коллекции, не задействуются, но, как только пользователь запускает приложение, попадающее под действие какого-либо из этих правил, информация о правиле и о приложении записывается в локальный журнал событий AppLocker.
Я рекомендую ставить флажок «Правило задано» и выбирать в выпадающем меню «Только аудит» для каждой из трех коллекций правил. Это позволит не только избежать «самоблокировок», но и понять, все ли интересующие приложения охвачены правилами и не являются ли эти правила слишком свободными либо слишком жесткими. Также я рекомендую использовать режим «Только аудит» до тех пор, пока не будут выявлены все аспекты, как положительные, так и отрицательные, применения заданных правил.
Обратите внимание, что на закладке «Дополнительно» в свойствах контейнера AppLocker присутствует настройка четвертой коллекции правил AppLocker: DLL, включающей в себя файлы форматов *.dll и *.ocx. Компания Microsoft разместила настройку этой коллекции правил отдельно от остальных, поскольку при ее включении происходит значительное падение производительности, связанное с проверкой соответствующих типов файлов. К тому же процесс создания белого списка для всех разрешенных DLL требует привлечения значительных административных ресурсов. Включать защиту DLL следует только в тех организациях, для которых вопросы информационной безопасности являются особенно критичными (например, правительственные или оборонные организации).
Последним шагом, гарантирующим полную функциональность AppLocker, является запуск на серверах Server 2008 R2 и системах с Windows 7 службы идентификации приложений. По умолчанию данная служба находится в режиме ручного запуска. Для полноценного функционирования AppLocker ее необходимо перевести в режим автоматического запуска. Для единовременной настройки всех систем можно использовать настройки объекта групповой политики GPO. Также следует помнить, что любое лицо с правами локального администратора может остановить службу контроля приложений и таким образом обойти применение правил AppLocker. Соответственно, все административные учетные записи должны находиться под особенно строгим контролем.
Значительный шаг вперед
Как и SRP, AppLocker требует регулярного обновления правил, чтобы правильно обрабатывать новые версии и обновления защищаемых приложений. Пока еще AppLocker не умеет работать с обновлениями приложений в динамической и «бесшумной» манере. Для этих целей больше подойдут приложения сторонних компаний, также работающие на принципах создания белых списков (например, Bouncer от Coretrace, Parity от Bit9). К тому же такие приложения обеспечивают более широкую поддержку различных платформ и типов файлов. Но, так или иначе, появление AppLocker является значительным шагом в направлении поддержки работы с белыми списками в Server 2008 R2 и Windows 7 по сравнению с черными списками SRP. Администраторы Windows смогут по достоинству оценить способность AppLocker автоматически создавать белые списки, работать в режиме «Только аудит» и ограничивать применение правил указанными учетными записями и группами.
Жан де Клерк (jan.declercq@hp.com) — сотрудник Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасностью в продуктах Microsoft