Безопасность

Блокировка приложений с помощью политик ограниченного использования программ

Крис Корио (Chris Corio) and Durga Prasad Sayana

Краткий обзор:

• Как работают политики ограниченного использования программ
• Инвентаризация приложений в своей среде
• Создание и применение политик

Когда специалисты по ИТ ищут способы уменьшить совокупную стоимость владения настольных машин, в голову обычно приходят две стратегии. Первый – это устранить

учетные записи пользователей настольных компьютеров из группы администраторов. А второй – ограничить круг приложений, которые пользователи могут запускать. Решение таких проблем в корпоративной среде может быть непростым, но Windows Vista® предлагает некоторые технологии, которые могут помочь в достижении этих целей.

Windows Vista и ее функция контроля учетных записей пользователей (UAC) – это гигантский шаг вперед в плане помощи специалистам по ИТ в переводе их корпоративных пользователей в группу пользователей («Обычные пользователи»). UAC переориентировал контекст безопасности по умолчанию для всех приложений с администраторов на пользователей. Этот перенос в группу пользователей все еще является нешуточной задачей, но по мере того, как отрасль приспосабливается к новой парадигме, задача со временем станет легче.

После анализа проблем переноса пользователей в группу пользователей (или порой в ходе этого процесса) многие администраторы составляют каталог приложений, необходимых их пользователям, и обдумывают действия по допуску лишь этих приложений. Функция политики ограниченного использования программ разработана, чтобы помочь специалистам по ИТ именно в этом.

Она позволяет просто указать, запуск каких приложений допустим, и затем развернуть политику с помощью групповой политики. Внедрение такой политики на всем предприятии может уменьшить совокупную стоимость владения (TCO), поскольку такая блокировка уменьшит проблемы, связанные с неподдерживаемыми приложениями. (Политики ограниченного использования программ также можно использовать рядом интересных и весьма радикальных способов, о которых мы рассказываем в боковой врезке «Минималистическая политика ограниченного использования программ».)

Как работают политики ограниченного использования программ

Политика ограниченного использования программ имеет своей целью контроль за тем, какой именно код может исполнять пользователь на компьютере, работающем под управлением Windows Vista. Администратор создает политику, определяющую, что может (или не может) выполняться в его среде. Эта политика затем вычисляется каждый раз и в каждом месте, где возникает возможность исполнения кода. В число этих моментов входят создание процесса, вызов ShellExecute и запуск сценария. (Мы подробнее рассмотрим все это чуть позже.)

Если определено, что приложению позволено исполняться, то приложение запустится. Однако если определено, что приложению не позволено исполняться, то приложение будет заблокировано, а пользователь уведомлен. Например, при попытке запустить недозволенный пасьянс «Косынка» из меню «Пуск» будет получен диалог, подобный показанному на рис. 1.

Рис. 1** При блокировании приложения появляется диалог **(Щелкните изображение, чтобы увеличить его)

Интерфейсом пользователя для определения политик ограниченного использования программ является редактор объектов групповой политики (GPOE), и именно там создается политика блокировки. Существует широкий набор методов для определения того, какой код может или не может выполняться. После завершения и тестирования политики ее можно развернуть.

Определение политик ограниченного использования программ

Первое значимое решение, которое будет принято, решение, которое существенно повлияет на работу политик ограниченного использования программ в среде, – это выбор типа правила по умолчанию. Политики ограниченного использования программ могут быть развернуты в одном из двух режимов: списка разрешений или списка запретов. По сути выбирается, следует ли создать политику, описывающую каждое приложение, выполнение которого дозволено, или политику, определяющую каждое приложение, которое не может выполняться.

В режиме списка разрешений правилом по умолчанию внутри политики является ограничение, и все приложения, выполнение которых не дозволено прямо, блокируются. В режиме списка запретов правилом по умолчанию является отсутствие ограничений, и блокируются только прямо указанные приложения.

Как несложно догадаться, режим списка запретов является нереалистичным подходом, если необходимо широкое уменьшение TCO и преимущества безопасности, вытекающие из блокировки приложений. Создание и поддерживание широкого списка, который блокирует все вредоносные программы и иные проблемные приложения, будет практически невозможным; в силу этого мы рекомендуем применять политики ограниченного использования программ в режиме списка разрешений, а это значит, что правилом по умолчанию будет ограничение.

Инвентаризация приложений в своей среде

Если требуется разработать политику, которая укажет, какие приложения могут выполняться, необходимо определить, какие именно приложения требуются пользователям. Функция политики ограниченного использования программ предлагает функцию расширенного ведения журнала с очень простой политикой, помогающую понять, какие именно приложения работают в среде.

На тестовом наборе компьютеров внутри среды разверните политики ограниченного использования программ с отсутствием ограничений в качестве правила по умолчанию и удалите все прочие дополнительные правила. План состоит в том, чтобы включить политику ограниченного использования программ, но не позволить ей ограничивать приложения, а вместо этого использовать ее для простого отслеживания того, что работает.

Далее создайте следующий параметр реестра, чтобы включить функцию расширенного ведения журнала и указать путь к месту, в которое следует записывать файл журнала:

"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>

Теперь, когда запускается приложение и проверяется политика ограниченного использования программ (она проверятся, несмотря на то, что сейчас позволяет работать всему), в файле журнала появляется запись.

В каждую запись в журнале входит сторона, вызывающая политику ограниченного использования программ, и идентификационный номер вызывающего процесса (PID), проверяемая цель, тип правила политики ограниченного использования, который был затронут, и идентификатор для правила. Вот пример записи, созданной при двойном щелчке пользователя программы notepad.exe:

explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}

Этот файл журнала представляет весь исполняемый код, который политика ограниченного использования программ будет проверять, когда она включена и установлена на блокировку приложений. Это значит, что для каждой записи в файле журнала необходимо решить, должна ли она быть учтена в разрешенном списке. Обратите внимание, что можно будет увидеть несколько проверяемых двоичных файлов, являющихся частью Windows® и требуемых системой для работы.

Описываемый нами здесь прием ведения журнала предоставляет четкий способ понять, какие именно приложения политика ограниченного использования программ встретит в определенной среде. Но это не единственное возможное решение задачи.

Инвентаризатор, входящий в набор средств обеспечения совместимости приложений Майкрософт версии 5.0, дает возможность проведения инвентаризации приложений в среде. Это средство предлагает набор различных способов обнаружения установленных приложений и сводит результаты в центральную базу данных.

Создание дополнительных правил

Теперь, когда имеется список приложений, которым должно быть позволено работать в среде, можно приступать к созданию самих правил, которые позволят им работать. Функция политики ограниченного использования программ использует два способа определения политики – один основан на криптографических свойствах приложения (таких как хэш-код), а второй определяет доверенный путь или папку, в которых должны находиться доверенные приложения.

На рис. 2 показано, где следует добавить правила в узле политик ограниченного использования программ GPOE (gpedit.msc), чтобы позволить приложениям работать. Самым прямолинейным способом определения приложений в среде является создание правила хэширования для каждого двоичного файла, встреченного в фазе ведения журнала.

Рис. 2** Использование gpedit.msc для создания политик ограниченного использования программ **(Щелкните изображение, чтобы увеличить его)

Поскольку хэш-код является уникальным значением, которое возвращает определенный набор файлов, каждый двоичный файл в политике должен иметь особый хэш-код. Этот подход особенно безопасен и позволяет выполняться только конкретным двоичным файлам в политике.

Само собой, у него есть свои недостатки. Например, в среде может запросто находиться несколько тысяч двоичных файлов. Создание всех этих правил в интерфейсе пользователя политик ограниченного использования программ может быть сложным, а по мере того, как число правил становится особенно большим, производительность может пострадать. Вдобавок, при каждом обновлении приложений в среде будет требоваться развертывание в среде одного или нескольких новых правил хэширования. Обновление настолько крупной политики по мере обновления приложений может стать тяжкой ношей.

К счастью, этой ноши можно избежать, поскольку существуют два других пути определения правил, упрощающие использование политик ограниченного использования программ в среде. Продвигаясь далее по пути криптографической безопасности, можно создать правило, допускающее выполнение любого двоичного файла, подписанного определенным сертификатом.

Это помогает упростить обслуживание списка политик, поскольку при обновлении приложения новые двоичные файлы обычно будут подписываться тем же сертификатом, что и предыдущие. Однако, если предыдущая версия двоичного файла не должна выполняться в среде, необходимо добавить ограничивающее правило хэширования, чтобы предотвратить его допуск.

По умолчанию, для политик ограниченного использования программ отключена проверка правил сертификатов. Это необходимо по двум причинам.

Во-первых, правила сертификатов в политиках ограниченного использования программ определены тем, что находится в хранилище доверенных издателей системы. Поскольку хранилище доверенных издателей используется не только для правил политик ограниченного использования программ, использование его для компонента политик ограниченного использования программ требует дополнительного времени и умственных усилий.

Вторая причина состоит в том, что для определения, верна ли подпись файла, необходимо взять хэш-код файла и сравнить его с информацией подписи. Хэширование файла – весьма трудозатратная операция, поскольку весь файл необходимо считать с диска и обработать для вычисления этого хэш-кода.

Чтобы включить правила сертификатов, перейдите к узлу политик ограниченного использования программ и выберите «Объект принудительного применения» в области результатов. Далее дважды щелкните для открытия его диалога свойств и выберите обеспечение выполнения правил сертификатов с помощью переключателя.

Другим обычным способом определения кода является использование пути кода на локальном компьютере. Это эффективная и экономичная методика, но имеющая один недостаток – необходимость удостовериться, что параметры безопасности установлены на папке верно.

Если добавлено определенное правило пути, и это правило позволяет пользователям записывать там файлы (на рабочий стол, к примеру), то они смогут запускать что хотят, просто помещая исполняемый файл в эту папку. Однако если пользователи не входят в группу администраторов, обычно у них нет возможности изменять что-либо в каталогах Program Files или Windows. Это значит, что если все приложения помещены в каталог Program Files, а пользователи не являются администраторами, то следует воспользоваться правилами путей для получения простой и эффективной политики.

Правила путей предлагают некоторые другие функции, делающие их более подходящими для некоторых сред. Они допускают подстановочные символы и позволяют использовать переменные среды для упрощения правил, которые являются переносимыми в среде, – в конце концов, %systemdrive% может и не быть c:\ для некоторых пользователей.

Что касается производительности и обслуживания, то это, вероятно, самый беспроблемный путь определения кода. О правилах путей определенно следует подумать, но необходимо помнить о дополнительных соображениях безопасности.

Правила зон сетей

В политику ограниченного использования программ входит также тип правил, именуемых правилами зон сетей. Первоначальное предназначение этих правил было основано на идее, что источники определенного исполняемого кода могут быть найдены и наделены доверием, и что в силу этого код может быть допущен к выполнению. Увы, это особенно сложная задача, и в результате они никогда не работали особенно хорошо. Сейчас эти правила не соблюдаются в большинстве точек входа политики ограниченного использования программ.

В случаях, когда большинство приложений устанавливаются в каталог %Program Files%, но существуют другие исполняемые файлы, установленные в других местах и подписанные определенным сертификатом, имеет смысл использовать правила различных типов. Немного правил хэширования, несколько правил путей – и подходящая политика готова.

Но помните, что эти правила обрабатываются в определенном порядке (как показано на рис. 3). Наиболее конкретными являются правила сертификатов, далее следуют правила хэширования, затем правила путей и, наконец, правила путей с подстановочными символами в них. Так что если код части обнаружен правилом хэширования и правилом пути, приоритетным будет уровень безопасности правила хэширования.

Рис. 3** Порядок обработки правил **(Щелкните изображение, чтобы увеличить его)

Применение политик

Политики ограниченного использования программ обеспечивают широту охвата на защищаемой системе. Идея состоит в том, что любое место, из которого может быть исполнен код, должно быть интегрировано с политикой ограниченного использования программ и, в свою очередь, проверять политику, чтобы увидеть, допустим ли запуск исполняемого кода.

Хотя имеется много мест, проверяющих политику ограниченного использования программ, наиболее прямолинейной точкой входа является CreateProcess. При работе CreateProcess политика проверяется, чтобы определить, допустимо ли исполнение двоичного файла, представляющего приложение. Проверка политики выполняется интерфейсом API SaferIdentifyLevel, документация по которому общедоступна. Общая процедура проиллюстрирован на рис. 4. (Мы расскажем о SaferIdentifyLevel подробнее чуть погодя.)

Рис. 4** Использование SaferIdentifyLevel для определения возможнсти исполнения двоичного файла **(Щелкните изображение, чтобы увеличить его)

Следующим наиболее часто (после CreateProcess) используемым интерфейсом API, в котором применяется политика ограниченного использования программ, является ShellExecute. Это интерфейс API, который вызывается, когда пользователь щелкает приложение в меню «Пуск» или дважды щелкает что-нибудь на рабочем столе.

ShellExecute может быть вызван на широком наборе форматов файлов. В таких случаях, как файл TXT, вызов ShellExecute на файле не приводит к реальному исполнению файла – само собой, технически файл открывается. По этой причине политика ограниченного использования программ содержит список типов исполняемых файлов, позволяющий ей контролировать, какие типы файлов проверяются при вызове ShellExecute. Настроить этот список типов исполняемых файлов можно в интерфейсе пользователя политики ограниченного использования программ.

Помимо CreateProcess и ShellExecute, имеются две другие ключевые точки интеграции: LoadLibrary и серверы сценариев. Важность LoadLibrary как места для проверки исполняемого кода очевидна, но, увы, LoadLibrary представляет некоторые особые ограничения.

У большинства приложений имеется один исполняемый файл и несколько загружаемых библиотек DLL. При этом в системе обычно работает масса приложений. Это значит, что LoadLibrary потребует массы проверок политики. В зависимости от существующей политики определения кода использование этой точки входа может оказаться очень ресурсоемким – представьте себе проверку хэш-кода каждой библиотеки DLL, загружаемой на системе, что включает в себя хэширование двоичного файла и сравнение его со списком из, возможно, тысяч хэш-кодов.

По умолчанию эта функция отключена, но ее можно включить вручную. Чтобы сделать это, перейдите к узлу политик ограниченного использования программ в gpedit.msc и дважды щелкните «Применение». После этого выберите переключатель «Все файлы программ».

Как мы уже упоминали, политика ограниченного использования программ интегрирована с большинством серверов сценариев в системе. В их число входят cmd, VBScript, Cscript и JScript®. Эти, а также другие точки входа используют основной интерфейс API применения политики ограниченного использования программ: SaferIdentifyLevel.

SaferIdentifyLevel определяет, допустимо ли выполнение определенного исполняемого файла, рассматривая информацию о идентификации в соответствующих политиках ограниченного использования программ. Это интерфейс API, документация по которому общедоступна. Серверы сценариев и исполняемые среды сторонних разработчиков могут и должны использовать его в целях интеграции с политикой ограниченного использования программ, чтобы политика могла определить, следует ли допустить выполнение элемента исполняемого кода.

Работа в качестве обычного пользователя

Не столь известной возможностью политики ограниченного использования программ является возможность фильтрации полномочий определенных приложений после их запуска. Эта функция появилась в Windows XP, но не была представлена в интерфейсе пользователя политики ограниченного использования программ до выхода Windows Vista.

В этом роде она была предшественником контроля учетных записей Windows Vista, поскольку ее можно было использовать для запуска приложения в качестве обычного пользователя, даже если пользователь был членом группы администраторов. Именно это происходит при создании правила и установки уровня безопасности на «Обычный пользователь» в пользовательском интерфейсе дополнительных правил.

Как функция фильтрации маркеров контроля учетных записей, так и правила для обычных пользователей политик ограниченного использования программ пользуются нижележащим интерфейсом API, реализующим то же поведение, что и интерфейс API CreateRestrictedToken. Однако общие архитектурные различия в технологиях очень значительны. Но контроль учетных записей отличается от политики ограниченного использования программ в ряде ключевых аспектов.

Во-первых, в Windows Vista со включенным контролем учетных записей каждое приложение запускается с маркером безопасности, подобным члену по умолчанию группы «Пользователи», даже если пользователь является администратором. Это достижимо с помощью политики ограниченного использования программ, но при этом нет никакой возможности запустить приложение с помощью реального маркера администратора – например, когда пользователю нужно установить приложение Изменение в контексте безопасности по умолчанию и простота доступа к принадлежащему пользователю маркеру полного администратора являются ключевыми преимуществами контроля учетных записей.

Второе различие состоит в том, что в случае исполняемых файлов сам код выражается с уровнем прав, необходимых для его функционирования. Это ключевое различие, поскольку независимые поставщики программного обеспечения (ISV) и разработчики понимают потребности своего кода. Например, если приложению панели управления необходимо изменить что-либо, требующее для этого прав администратора, оно может указать это в своем манифесте. Таким образом, поставщик ПО может описать права, необходимые приложению, вместо того, чтобы навязывать ему определенный уровень прав без возможности этот уровень изменить.

Пока стоит избегать правил обычных пользователей, если нет настоящего знакомства с их работой. Контроль учетных записей является отличным способом вывести пользователей настольных систем из группы администраторов, так что стоит серьезно обдумать простое оставление контроля учетных записей в корпоративной среде.

Нынешнее применение политик ограниченного использования программ

При использовании политики ограниченного использования программ следует учитывать немало движущихся частей. Но это выглядит не так, как можно подумать, и на самом деле читатели уже могут использовать политики ограниченного использования программ, не осознавая этого. Например, при установке родительского контроля в системе Windows Vista политики ограниченного использования программ используются для контроля над исполнением приложений.

Политика ограниченного использования программ была важным технологически усовершенствованием, когда она впервые появилась в Windows XP. Но на самом деле блокировка приложений лишь сейчас начинает привлекать внимание специалистов по ИТ.

У функции политики ограниченного использования программ в Windows Vista еще есть свои шероховатости, которые нужно отполировать, но очевидно, что администраторы желают иметь этот повышенный контроль над тем, что исполняется в их средах. К счастью для всех нас, эта технология продолжит развиваться, упростит для специалистов по ИТ управление их системами и понизит затраты на поддержание среды Microsoft Windows.

Минималистическая политика ограниченного использования программ

Одним из применений политики ограниченного использования программ является создание политики, фиксирующей Windows в режиме интерактивного терминала. Майкрософт даже производит набор средств, именуемый SteadyState™, для создания такого терминала. Однако если необходимо только блокировать приложения, которые могут выполняться, это можно сделать проще.

Чтобы допустить минимальный набор приложений, требующихся для входа в Windows Vista, создайте политику, позволяющую logonui.exe и userinit.exe запускаться из %windir%\system32. Большинству пользователей, вероятно, также потребуется допустить запуск следующих приложений:

dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....

Если необходима оболочка Windows по умолчанию, следует добавить также %windir%\explorer.exe.

В качестве альтернативы можно выбрать загрузку прямо в приложение, такое как Internet Explorer®. В таком случае будет необходимо вписать iexplore.exe вместо explorer.exe.

Другим аспектов этой минималистической политики является отказ от помещения пользователей в группу администраторов. Это важно, поскольку иначе они могут обойти политику. Однако поскольку они будут иметь возможность запускать лишь самый базовый набор приложений и не будут иметь прав администратора, у них не будет прав для установки приложений или обслуживания системы.

Для таких машин необходим какой-то способ делать это. Если предстоит обновлять и обслуживать эти компьютеры путем локального входа в систему через учетную запись администратора, следует также выбрать переключатель, применяющий политику ограниченного использования программ ко всем пользователям, кроме локальных администраторов. В политику должны также входить consent.exe и cmd.exe. Это позволит администратору запускать любые варианты администрирования из командной строки администратора.

Обратите внимание, что контроль учетных записей ограничивает права маркера безопасности по умолчанию пользователя, чтобы он не выглядел членом группы администраторов. Даже если вышеуказанный параметр установлен на неприменение политики к администраторам, она все же будет применена к пользователям. Только после прохода через повышение уровня прав в контроле учетных записей, администратор действительно получает полные права администратора, и политика ограниченного использования программ перестает применяться к нему.

**Крис Корио (Chris Corio)**Крис Корио (Chris Corio) проработал в группе безопасности Windows корпорации Майкрософт более пяти лет. Его основными занятиями в Майкрософт были технологии безопасности приложений и методы управления, обеспечивающие безопасность Windows. С Крисом можно связаться по адресу winsecurity@chriscorio.com.

Durga Prasad SayanaДурга Прасад Саяна (Durga Prasad Sayana) – специалист по разработке и тестированию программного обеспечения в группе базовой безопасности Windows. Его основными интересами являются технологии безопасности и тестирование программного обеспечения. Связаться с ним можно по адресу durgas@microsoft.com.

© 2008 Корпорация Майкрософт и CMP Media, LLC. Все права защищены. Запрещается воспроизведение статьи или ее части без разрешения.