Конечный пользователь отдыхает

ОБЗОРЫ

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

Программный пакет PolicyMaker Application Security 2.5 (PMAS) - разработка фирмы DesktopStandard - представляет собой набор прекрасных инструментов, помогающих компаниям решить проблему совместимости приложений для настольных компьютеров, на использование которых накладываются ограничения. Однако структура управления, построенная на базе групповой политики Microsoft (Microsoft Group Policy), может оказаться недостаточной в больших и сложных доменах, а использование "черных списков" для наложения ограничений на работу приложений грозит быстро стать слишком громоздким механизмом.

PMAS 2.5 является четким и элегантным решением для снятия проблем, связанных с работой унаследованных приложений у пользователей, не обладающих правами администратора в отношении настольных компьютеров. Вместо расширения полномочий с помощью команды Run as, предполагающей введение пользователем имени и пароля администратора, а также вместо предъявления администратору требования о вторжении в файловую систему и предоставлении списка контроля доступа (Access Control List, ACL), с тем чтобы заставить работать приложения, с которыми возникают проблемы, PMAS изменяет на лету статус безопасности приложения. В результате процесс получает более широкие полномочия, а в остальном сессия пользователя или настройки уровня безопасности не затрагиваются.

Лаборатория eWeek Labs провела весьма успешные испытания PMAS 2.5 с рядом приложений, которые зависают, если пользователь не обладает правами администратора. Просто добавив с помощью этого инструментария встроенную учетную запись администратора в настройки приложения (application token), мы быстро получили возможность применять Microsoft AntiSpyware Beta 1, различные средства управления для Lenovo ThinkPad и TurboTax компании Intuit - оба этих продукта наделены функцией AutoUpdate - Nero 7 Ultra Edition и старую версию Paint Shop Pro фирмы Jasc. В каждом случае процесс по-прежнему принадлежит пользователю с ограниченными правами, но в настройки безопасности (security token), не вызывая конфликтов, добавляются права локального администратора.

С помощью PMAS 2.5 компании DesktopStandard нам удалось добиться предоставления

приложению особых полномочий (вверху). Средства управления PMAS полностью

интегрированы в среду управления групповой политикой (внизу)

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

Однако для применения программы DiskMon компании Sysinternals пользователям с ограниченными правами потребуется предпринять дополнительные шаги. Нам пришлось явным образом добавить привилегии "отладка" и "загрузка драйверов". Но с помощью интерфейса политики (см. верхний рисунок) сделать это было совсем не сложно.

Управляющая консоль PMAS полностью интегрирована в среду управления Windows Group Policy. Администраторы могут добавлять политики PMAS либо к объекту "пользователь", либо к объекту "политика по отношению к группе компьютеров" (см. нижний рисунок). Мы просто установили интегрируемые компоненты PMAS, драйвер системы безопасности и клиентские расширения на нашей рабочей станции, с которой осуществлялось управление групповой политикой. После этого лицензия на использование PolicyMaker и его настройки были автоматически сохранены в домене SYSVOL (системный том).

Администраторам необходимо будет устанавливать драйвер безопасности и клиентские расширения на управляемых рабочих станциях, чтобы можно было видеть и соблюдать политику PMAS. Правда, PMAS содержит небольшой инсталляционный пакет MSI (Management System Information), который устанавливается с помощью групповой политики.

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

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

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

Конкурирующие продукты, такие, как Protection Manager 1.0 компании Winternals, лишены данного недостатка, поскольку средства управления и развертывания конкретной политики вынесены за пределы групповой политики.

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

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

Поставки PMAS 2.5 начались в феврале; стартовая цена - 27 долл. на каждый управляемый компьютер. PMAS облегчает переход к предоставлению пользователям минимальных полномочий, что может дать предприятиям экономию за счет снижения вероятных дополнительных расходов на обеспечение безопасности ПК, таких, как проверка выделенных компьютеров на наличие шпионского ПО. Тем не менее цена PMAS представляется чрезмерно высокой.

Компания DesktopStandard предоставляет скидку, если вы приобретаете пакет, куда входят и другие разработанные ею инструменты, базирующиеся на использовании групповой политики: PolicyMaker Standard Edition, PolicyMaker Share Manager и служба рассылки исправлений PolicyMaker Update. Цена пакета - 36,4 долл. на один компьютер.

Р-р-р-разрушить

PMAS 2.5 предоставляет также возможность изоляции процессов (функция Process Isolation), чтобы защитить компьютеры пользователей от атак, предпринимаемых с разрушительными целями. PMAS пресекает такие атаки путем изоляции различных процессов, лишая их возможности обмениваться сообщениями друг с другом (посредством системы Win32).

Когда применяется изоляция процессов, PMAS заставляет новые процессы запускаться в рамках безымянной задачи Win32. Во время испытаний, когда мы изучали такую задачу с помощью инструмента ProcessExplorer 10.06 компании Sysinternals, для каждого подпроцесса, протекающего в рамках задачи, PMAS явным образом отключил многие привилегии, разрешаемые операционной системой в условиях нормальной эксплуатации.

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

Хотя PMAS расширяет полномочия, этот инструмент является не лучшим решением для ограничения прав процессов или введения запрета на исполнение. Для блокирования приложений PMAS использует "черный список". В результате мы могли легко создать правило, которое заставляло бы, скажем, администраторов домена запускать Internet Explorer с ограниченными привилегиями. Но составить законченный и всеобъемлющий список приложений, доступ к которым запрещен в масштабе всего предприятия, оказалось невозможным.

С техническим аналитиком Эндрю Гарсиа можно связаться по адресу: andrew_garcia@ziffdavis.com.

С результатами проведенного в Лаборатории eWeek Labs анализа продукта Microsoft LUA (Least-Privileged User Account) можно ознакомиться по адресу: blog.eweek.com/blogs/eweek_labs.