Политика ограничения применения программного обеспечения windows xp

Чтобы использовать эту возможность, откройте оснастку «Локальные параметры безопасности» («Панель управления — Администрирование — Локальная политика безопасности» или наберите secpol.msc из меню «Выполнить») и выберите в левой части оснастки пункт «Политики ограниченного использования программ».

Политики ограниченного использования программ предоставляют механизм идентификации программ и управления возможностями их выполнения. Существует два варианта установки правил ограничения:

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

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

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

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

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

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

Для ограничения запуска программ их следует идентифицировать, а затем установить правило. Рассмотрим два основных варианта:

Ограничение с помощью создания правила для хеша — хеш представляет собой своего рода цифровой «отпечаток пальцев», являющийся уникальным для программы или файла и вычисляющийся по специальным математическим алгоритмам. Файл может быть переименован или перемещен в другую папку или на другой компьютер, но его хеш останется неизменным. При внесении изменений в файл его хеш изменяется. Но как правило, код программы является неизменным и хеш однозначно идентифицирует файл. Чтобы создать правило для хеша, перейдите в пункт «Дополнительные правила», выберите в меню «Действие» пункт «Создать правило для хеша». В открывшемся окне вы можете или ввести заранее вычисленный хеш,

(например, для программы «Блокнот» это fc15cc1d4dda7e73939fc6ec7fadc98e:66048:32771)

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

— «Не разрешено» — программа не будет выполняться;

— «Неограниченный» — возможность запуска определяется правами пользователя.

В пункт «Комментарии» вы можете ввести заметки, объясняющие данное правило.

Ограничение с помощью создания правила для пути — правило для пути идентифицирует программы по полному пути к файлу или папке. То есть мы можем указать папку, программы из которой запускаться не будут (или наоборот, будут, в зависимости какое разрешение нам требуется создать). Чтобы создать правило для пути, перейдите в пункт «Дополнительные правила», выберите в меню «Действие» пункт «Создать правило для пути». При указании пути могут быть использованы подстановочные символы * (заменяет неограниченное количество символов) и ? (заменяет один символ) и общие пути, например %userprofile%, %windir%, %appdata%, %programfiles% и %temp%. При указании в качестве пути папки правило распространяется на все вложенные папки и файлы. При конфликте правил для пути приоритет имеет правило с большим ограничением. Ниже приведен набор путей в порядке от высшего приоритета (наибольшее ограничение) к низшему приоритету.

диск:папка1папка2имя_файла.расширение
диск:папка1папка2*.расширение
диск:папка1папка2
диск:папка1

При конфликте двух похожих правил для пути приоритет имеет правило с большим ограничением. Например, если имеется правило для пути C:Windows с уровнем безопасности «Не разрешено» и правило для пути %windir% с уровнем «Неограниченный» (по сути это идентификация одного и того же пути разными способами), будет применяться более строгое правило с уровнем безопасности «Не разрешено».

Правило для хеша имеет приоритет над правилом для пути, то есть если мы имеем две правила, одно из них — правило для хеша notepad.exe с уровнем безопасности «не разрешено», а другое — правило для пути c:windowsnotepad.exe с уровнем безопасности «неограниченный», то будет действовать правило для хеша, то есть программа запущена не будет.

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

— устанавливаем уровень безопасности по умолчанию «Не разрешено»;

— в пункте «Принудительный» устанавливаем применение политик для всех пользователей кроме локальных администраторов;

— создаем правило для пути для системного диска и устанавливаем уровень безопасности как «Неограниченный»;
— устанавливаем ограничение на запись в системный диск для пользователей (оставляем чтение и выполнение и просмотр содержимого) с помощью средств ограничения доступа (NTFS) или с помощью программы Folder Guard (FAT32) (устанавливаем системный диск только чтение);

— устанавливаем исключения на запись и изменение некоторых нужных файлов на системном диске для пользователей (например, если какая-то программа хранит параметры конфигурации в файле, и пользователю разрешается изменять эти параметры), если это необходимо, с помощью средств ограничения доступа (NTFS) или с помощью программы Folder Guard (FAT32).

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

Что получаем в итоге: все программы установленные на системном диске работоспособны; запуск исполняемых файлов запрещен на всех разделах жесткого диска кроме системного, а также невозможен запуск с дискеты или CD, пользователи не имеют прав на запись в раздел диска на который установлена система, соответственно пользователи не могут запускать или инсталлировать никакие новые программы.

Можно создать файл журнала применения политик ограниченного использования программ, для этого откройте редактор системного реестра, перейдите в раздел

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsSaferCodeIdentifiers] и создайте строковый параметр

LogFileName=x:xxname.log где x:xxname.log — путь и имя файла журнала, например, c:MYLOGsafetylog.log Теперь каждое применение политики ограничения программ будет фиксироваться в этом файле. Файл рекомендуется использовать для отладки правил. Не забудьте выставить соответствующие права на этот файл чтобы он был доступен для записи от имени пользователя.

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

Автор: Михаил
Источник:

silicontaiga.ru

Оцените статью: Голосов

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

Политики ограниченного использования программ (Software Restriction Policies) — это технология клиентов Windows 7, доступная для Windows XP, Windows Vista, Windows Server 2003 и Windows Server 2008. Политики ограниченного использования программ управляются при помощи групповой политики. Соответствующий узел находится в узле Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Политики ограниченного использования программ (Computer Configuration\Windows Settings\Security Settings\Software Restriction Policies). Для этих политик доступны параметры Неограниченный (Unrestricted), разрешающий выполнение приложений, и Запрещено (Disallowed), блокирующий выполнение приложений.

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

В принципе, возможности политик ограниченного использования программ и AppLocker во многом перекрываются. Преимущество политик ограниченного использования программ заключается в том, что они могут применяться на компьютерах Windows XP и Windows Vista, а также в изданиях Windows 7, не поддерживающих AppLocker. С другой стороны, в политиках ограниченного использования программ все правила должны настраиваться вручную, поскольку отсутствуют встроенные мастера для их создания. Политики ограниченного использования программ применяются в заданном порядке, в котором более конкретные правила имеют приоритет по сравнению с более общими правилами. Приоритет правил от более конкретизированных (правила хеша) до менее конкретизированных (по умолчанию) таков:

1. Правила хеша (hash rules).
2. Правила сертификатов (certificate rules).
3. Правила пути (path rules).
4. Правила зоны (zone rules).
5. Правила по умолчанию (default rules).

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

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

Уровни безопасности и правила по умолчанию

Узел Уровни безопасности (Security Levels) позволяет задавать правила ограниченного использования программ по умолчанию. Правило по умолчанию применяется, когда к приложению не применима никакая другая политика. Одновременно допускается активировать только одно правило по умолчанию. Три правила по умолчанию таковы:

• Запрещено (Disallowed). Если включено это правило, пользователи смогут выполнять приложение, только если оно разрешено существующей политикой ограниченного использования программ.
• Обычный пользователь (Basic User). Если включено это правило, пользователи смогут выполнять приложения, для которых не требуются административные полномочия. К приложению, требующему административных полномочий, пользователи получат доступ, только если было создано правило, охватывающее это приложение.
• Неограниченный (Unrestricted). Если это правило задано в качестве правила по умолчанию, пользователь сможет выполнять это приложение, если оно не заблокировано существующей политикой ограниченного использования программ.

Если вы предполагаете ограничить возможности пользователей списком разрешенных приложений, настройте правило по умолчанию Запрещено (Disallowed). Это гарантирует запрет на запуск любого приложения, не разрешенного явным образом. Если вы хотите лишь заблокировать пару проблемных программ, но не хотите запрещать использование всех прочих приложений, используемых в вашей среде, настройте правило по умолчанию Неограниченный (Unrestricted). Это позволяет запускать любое приложение, если оно не заблокировано явным образом.

Способы применения политик

Окно Свойства: Применение (Enforcement Properties), позволяет задать применение политик ограниченного использования программ ко всем файлам ПО, за исключением библиотек, например, DLL, или ко всем файлам ПО, включая библиотеки. Если по умолчанию задан уровень Запрещено (Disallowed) и вы настроили применение политик к любым файлам ПО, для использования конкретной программы, вам необходимо будет настроить правила для библиотек DLL, используемых этой программой. Майкрософт не рекомендует ограничивать использование библиотек DLL, если среда, которой вы управляете, не требует повышенной безопасности. Это связано, главным образом, с тем, что управление правилами для библиотек DLL значительно увеличивает объем работы по сопровождению политик ограниченного использования программ.

Окно Свойства: Применение (Enforcement Properties) позволяет настраивать применение политик ограниченного использования программ для всех пользователей или для всех пользователей, кроме администраторов. При помощи этой политики вы также можете задать, какие правила сертификатов будут принудительно применяться или игнорироваться. Недостаток принудительного применения правил сертификатов заключается в том, что они существенно снижают производительность компьютера.

Назначенные типы файлов

Политика Назначенные типы файлов (Designated File Types), позволяет определять, по каким расширениям будут распознаваться исполняемые файлы, подпадающие под действие политик ограниченного использования программ. Список расширений редактируется при помощи кнопок Добавить (Add) и Удалить (Remove). Стандартные расширения (.com, .exe, и .vbs) удалить нельзя. Они всегда распознаются как исполняемые.

Правила пути

Правило пути позволяют указать в качестве объекта политики ограниченного использования программ файл, папку или параметр реестра. Чем конкретнее задано правило пути, тем выше его приоритет. Например, если у вас есть правило, задающее неограниченное использование файла C:\Program files\Application\App.exe, и правило, запрещающее использование файлов из папки C:\Program files\Application, приоритет будет иметь более специализированное правило: приложение будет выполняться. В правилах пути могут использоваться символы подстановки. Например, вполне возможно существование правила для пути C:\Program files\Application*.exe. Правила с использованием символов подстановки являются менее конкретными, чем правила, использующие полный путь к файлу.
Недостатком правил пути является то, что в них предполагается неизменность расположения файлов и папок. Например, если вы создали правило пути для блокирования приложения C:\Apps\Filesharing.exe, злоумышленник сможет выполнить его, переместив файл в другую папку или присвоив ему другое имя. Правила пути работают только в том случае, если права доступа ОС не позволяют перемещать или переименовывать файлы.

Правила хеша

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

Правила сертификатов

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

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

Правила интернет-зоны применяются только к пакетам установщика Windows (.msi), полученным при помощи Internet Explorer. К другим приложениям, например файлам .ехе, правила зоны неприменимы, даже если эти файлы также получены через Internet Explorer. Правила зоны определяют возможность использования пакета в зависимость от сайта, с которого он был скачан. Возможные расположения включают Интернет, интрасеть, ограниченные сайты (Restricted Sites), доверенные сайты (Trusted Sites) и Мой компьютер.

Более подробную информацию о политиках ограниченного использования программ вы найдете по адресу What Are Software Restriction Policies?

Политика ограничения программного обеспечения Software Restriction Policy (SRP) появилась в октябре 2001 года вместе с запуском операционной системы Microsoft Windows XP Professional. Правда тогда она жила достаточно спокойной жизнью – даже слишком спокойной, как вы могли заметить. Цель этой статьи заключается в том, чтобы оживить SRP в реальной жизни, чтобы заставить администраторов во всем мире пересмотреть их политики относительно программного обеспечения (software policies), и может быть, даже реализовать SRP в это самом мощном проявлении – на основе белых списков (Whitelisting).

Преимущества SRP

Деловые пользователи организуют свою совместную работу с использованием электронной почты (e-mail), мгновенных сообщений (instant-messaging), особых приложений (peer-to-peer application) и т.п. как никогда ранее. Они используют Интернет для поиска и обмена информацией, и такое тип взаимодействия постоянно увеличивается, что может привести к возникновению угроз со стороны вредоносного кода. Пользователи также переносят неконтролируемые данные в картах памяти (memory stick), MP3 плееры и т.п. из дома в офис и обратно – эти данные могут представлять собой что угодно, от документов Word или таблиц Excel, до игр, хакерских инструментов и различного вредоносного программного обеспечения. Ноутбуки в настоящее время более распространены, чем настольные компьютеры, и с их помощью можно подключаться к неконтролируемым сетям, как проводным, так и на основе беспроводной технологии, тем самым, подвергая их большой опасности стать объектом атаки или взлома.

Именно поэтому я могу привести множество причин, по которым необходимо реализовать SRP:

Таблица 1

Большинство администраторов IT и менеджеров хотят устранить риск заражения компьютеров вирусами, и другими угрозами, о которых рассказывалось в таблице 1. Это можно сделать с использованием SRP, которая позволяет задать, какие приложения и какие компоненты ActiveX могут быть запущены на компьютере, или же разрешить запускаться только сценариям с цифровой подписью. Мы также может разрешить запускать на корпоративном компьютере только разрешенные приложения с использованием встроенной технологии. Мы можем заблокировать компьютеры клиентов и даже серверы, таким образом, чтобы они могли делать лишь то, что мы хотим разрешить и не более того. Все это совершенно бесплатно и находится прямо перед нами …

Политики ограничения программного обеспечения Software Restriction Policies срабатывает в момент выполнения, пользователь получает блокирующее сообщение, похожее на то, что изображено на рисунке 1, если пытается запустить запрещенный код. На рисунке 2 изображено окно, которое появляется при попытки выполнить запрещенный сценарий.

Картинка с сайта: www.cyberguru.ru

Картинка с сайта: www.cyberguru.ru

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

Вы можете сказать, что ваши пользователи не могут устанавливать запрещенное программное обеспечение, т.к. они не являются локальными администраторами на своих компьютерах (что очень хорошо), но все дело в том, что выполняемые модули всех типов могут при этом по-прежнему запускаться и выполнять запрещенные вещи. В качестве примера я могу упомянуть небольшую утилиту под названием ProduKey, которая очень полезна, если вы забыли ваши лицензионные ключи Microsoft product keys (для Exchange, Office, SQL или самой операционной системы Windows). С точки зрения администратора это сталкивает нас с еще одной проблемой: даже пользователи с ограниченными правами могут прочитать лицензионные номера (product keys) на локальной машине. Это значит, что пользователи могут найти ваши корпоративные ключи Volume License Keys (VLK) и установить их на свои домашние компьютеры!

Единственный способ избежать этого – это создать политику, которая блокирует все файлы с названием ‘produkey.exe’, но пользователи могут просто переименовать файл и затем снова запустить его. Другой способ – это заблокировать значение HASH, криптографический оттиск, файла ProduKey.exe (последняя версия 1.6), но это значение отличается с каждой новой версией – и что еще хуже: значение HASH можно изменить с помощью специальных утилит, например, SuperStorm и других похожих инструментов. Предположим, вам удалось блокировать ProduKey, но у вас еще много работы, чтобы ограничить приложение с аналогичной функциональностью.

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

Черные списки против белых списков

Первые фильтры для портов на сетевых маршрутизаторах (network router) в начале 1990-х годов были настроены на блокировку особых портов, и разрешали все извне, растущего интернета. Сетевые администраторы (Network administrator) всегда были на шаг позади хакеров, которые мгновенно изменили атаки для проникновения через новые службы. Когда сетевые администраторы блокировали входящий TELNET, то был атакован RLOGIN или FTP. Эта была бесконечная война с хакерами, которая могла привести лишь к реализации на брандмауэре правила «Default Deny» (запретить все по умолчанию). По умолчанию ничего не разрешалось до тех пор, пока мы не зададим некоторые исключения из правила по умолчанию.

Взгляните также на антивирусные приложения, которым необходимо постоянно обновлять описания вирусов, чтобы идентифицировать код, который нельзя запускать на сетевых компьютерах – вместо того, чтобы обратить этот процесс и описать все, что нам нужно запускать, и запретить все остальное программное обеспечение. То же самое справедливо и для приложений, которые запускаются сегодня на компьютерах по всему миру. Для чего по умолчанию разрешено запускать все программы, когда мы в большинстве случаев точно знаем приложения, которые нам понадобятся для работы? Почему не ввести правило «Default deny all applications (по умолчанию запретить все приложения)» на наших клиентских компьютерах и делать исключении из этого правило по умолчанию для приложений, которые можно запускать пользователям?

Подход «Default deny all applications (по умолчанию запретить все приложения)» известен также как белый список (Whitelisting или WL). При настройке SRP в режиме белого списка (WL mode) уровень безопасности по умолчанию (Default Security Level) устанавливается в ‘Disallowed (запрещено)’ – затем создаются дополнительные правила с исключениями для правила по умолчанию. Подумайте об этом, ни один файл нельзя будет запустить на компьютере до тех пор, пока вы не указали это в политике – разве вам не нравится такая идея!

Если мы хотим использовать WL, то мы должны закончить список разрешенного программного обеспечения – и если мы хотим использовать метод идентификации (identification method) на основе HASH, то нам нужен доступ к выполняемым файлам. Если мы хотим использовать правило сертификатов (certificate rule), то нам нужен файл сертификата (certificate file с расширением .CER или .CRT) или просто доступ к подписанному выполняемому файлу.

Черный список (Blacklisting BL) после подключения SRP имеет уровень безопасности по умолчанию (default Security Level) также известный, как ‘Unrestricted (неограниченный)’. BL можно назвать задачей Sisyphean – он никогда не заканчивается и кроме того, он на обеспечивает такого уровня безопасности, который можно получить с помощью белых списков WL does. Благодаря большому количеству и формам, которые может принимать вредоносный код, блокировка всех их становится достаточно сложной задачей, не важно используете ли вы при этом отпечатки кода, или имен файлов. Зачем поддерживать список из более миллиона типов вредоносного кода – список, который быстро разрастается – вместо того, чтобы поддерживать список из всего лишь 50 или 100 приложений, необходимых для работы организации?

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

Доказательством этой концепции является инструмент под названием Gpdisable, созданный Марком Руссиновичем (Mark Russinovich) несколько лет назад, и который является наглядным примером, почему WL лучше BL. С помощью Gpdisable, или любого другого аналогичного инструмента, даже ограниченные пользователи могут блокировать политики групп на запущенном клиенте Windows – включая SRP – за исключением того случая, когда SRP усилен использованием Whitelisting!

Лишь правило «Default deny all applications (по умолчанию запретить все приложения)» пройдет проверку временем. К несчастью, на по-прежнему нужно антивирусное программное обеспечение для защиты от загрузки и исполнения вредоносного кода. Давайте также не забывать, что SRP «лишь» защищает локальную систему от исполнении нежелательного программного обеспечения, она не защищает от записи исполняемых файлов на жесткий диск, или от вложений с электронной почтой.

Будущее

Я надеюсь, что компания Microsoft продолжит упрощать процесс разрешения новых приложений в ближайшие годы. Было бы здорово, если бы появилась возможность импорта SRP или определенных значений HASH, необходимых для определенных приложений. Это потребует, чтобы сторонние производители предоставляли шаблон SRP «template» вместе со своими приложениями, чтобы сетевые администраторы (network administrator) могли легко их импортировать, а не создавать собственноручно новые политики. Такие шаблоны должны состоять из HASH значений для всех исполняемых файлов, а также необходимых библиотек Dynamic Link Libraries (DLL).

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

Я хочу поделиться с вами идеей относительного того, как упросить администрирование белых списков (WL administration). Когда разговор идее о правилах для HASH, администратору необходимо открыть объект политики групп Group Policy Object (GPO) и перейти к файлам. Если этот процесс можно запланировать и записать с помощью сценариев, то все, что необходимо было бы сделать сетевым администраторам – это поместить выполняемый файл в центральную ‘разрешенную (approval)’ директорию (с правильно назначенными разрешениями NTFS), то при запуске сценария автоматически создавалось значение HASH, и это значение добавлялось к значения в разрешенной политике в соответствующем объекте GPO. Это также можно сделать для сертификатов, просто поместить сертификат в центральную папку, подождать, пока не появится процесс или сценарий. Пока что это все мечты, но будем надеяться, что кто-нибудь однажды сделает этот сон явью – может быть даже компания Microsoft…

Опасная зона

Перед тем, как мы продолжим, очень важно указать на то, что перед тем, как реализовать SRP на ваших промышленных компьютерах, вы должны ее тщательно спланировать и проверить. Это можно сделать в Active Directory (AD) изолировав одну тестовую машину или пользовательский объект в организационной единице (Organizational Unit или OU) или задав разрешение «Apply Group Policy»(применить политику группы) для объекта Group Policy Object (GPO) только для одной тестовой машины или пользовательской учетной записи. SRP можно использовать даже на отдельно стоящей машине, если вы вовсе не хотите касаться промышленной среды. Я рекомендую использовать для основного тестирования виртуальные компьютеры и компьютеры, максимально похожие на промышленные, для окончательных тестов. После тщательного тестирования SRP необходимо реализовать для опытных пользователей в группах, лучше идти небольшими шагами, чем сразу попасть в беду!

Внедрение SRP

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

Следующий список представляет собой краткий обзор того, о чем необходимо помнить при внедрении SRP в среде Windows.

При проектировании установки SRP необходимо принять различные решения, например:

1. Выбрать между объектами групп GPO пользователей или компьютеров — для каких объектов AD должны быть применены политики SRP?
2. Выбрать между черным списком (Blacklisting BL) и белым списком (Whitelisting (WL) (WL – рекомендуется использовать по возможности)
3. Если используется подход на основе BL, необходимо составить список всего, что не должно запускаться
4. Если используется подход на основе WL, необходимо составить список всего, что должно запускаться
5. Выбрать, как настройки SRP использовать (форсирование, определенные типы файлов, исключения для администраторов)
6. Выбрать типы правил, которые будут использоваться (путь, HASH, сертификат или зона интернет)

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

1. Проверить основную функциональность в виртуальной лаборатории (с помощью Virtual PC/Server, VMware или других)
2. Проверить функциональность в вашей среде, используя для этого условия максимально приближенные к промышленным.
3. Проверить на небольших группах опытных пользователей по 5-10 пользователей на протяжении несколько недель, затем увеличивать
4. Продолжить со следующей опытной группой лишь после успешной реализации для предыдущей группы опытных пользователей
5. Убедиться, что проверены все различные типы пользователей и типы компьютеров, которые вы хотите обезопасить с помощью SRP
6. Убедиться, что проверены все обновления, патчи для операционных систем, обновления приложений сторонних производителей и т.п.
7. Также сфокусироваться на производительности различного аппаратного обеспечения в вашей организации. Реализация SRP в большинстве случаев влияет немного на производительность, в зависимости от того, как она реализована (смотрите раздел о Trusted Publishers)
8. Иногда приложения запускают другие приложения, поэтому необходимо убедиться, что все это находиться под контролем
9. По умолчанию блокируются ярлыки Desktop (рабочий стол) и Start (пуск) (.LNK), поэтому в случае необходимости это нужно исправить
10. Убедитесь, что запускаются все сценарии администратора (в том числе сценарий, запускающиеся при входе login в SYSVOL/NETLOGON)

Перед внедрением SRP в промышленной среде, необходимо определить некоторые процедуры:

1. Необходимо описать технологический процесс относительно того, какие приложения, обновления и т.п. необходимо протестировать, утвердить и внедрить в сеть, чтобы все знали о необходимых процедурах
2. Убедиться, что управляющий персонал знает обо всех преимуществах и недостатках SRP, и что они согласны с решением о его внедрении
3. Необходимо иметь запасной план, описывающий, как быстро отказаться от SRP GPO для определенных пользователей, групп, компьютеров, сайтов и т.д.
4. Образование пользователей: информировать пользователей, почему важен SRP, и какие процедуры необходимы для приобретения нового программного обеспечения
5. Небольшая подсказка: добавляйте комментарии к правилам SRP, по прошествии некоторого времени это позволит сохранить вам немного времени

Различные пути к SRP

Настройка политики ограничения программного обеспечения (Software Restriction Policy) включает в себя несколько этапов:

1. Создание объекта политики групп для пользователя (User GPO) или для компьютера (Computer GPO) и размещение его на сайте (Site), домене (Domain) или организационной единице OU (или в качестве локальной политики) и подключение SRP для политики группы (Group Policy). Настройки SRP расположены здесь (смотрите рисунок 1):

   Computer Configuration| Windows Settings | Security Settings | Software Restriction Policies

   User Configuration | Windows Settings | Security Settings | Software Restriction Policies

   При первом обращении к SRP в GPO будет доступна настройка «New Software Restriction Policies» (новая политика ограничения программного обеспечения).

   

   Картинка с сайта: www.cyberguru.ru

   Рисунок 1

2. Установка Default Security Level (уровень безопасности по умолчанию). На рисунке 2 показано, как с помощью нажатия правой кнопки мыши уровень установлен на «Set as default» (установить по умолчанию).
   • По умолчанию уровень «Unrestricted» (без ограничений), что значит, что программное обеспечение может быть запущено, и что необходимо задать дополнительные правила для запрещения определенного программного обеспечения (software) – такой подход известен, как черный список Blacklisting.
   • Самый безопасный уровень – это «Disallowed» (запрещен), что значит, что никакое программное обеспечение не может быть запущено, и что необходимо задать дополнительные правила для разрешения программного обеспечения – такой подход известен, как белые списки Whitelisting.
   • По умолчанию система создает несколько правил, которые позволяют операционной системе работать без всякого неудобного блокирования NB! Если эти правила удалить или изменить не подумав, то система может выйти из строя.
   

   Картинка с сайта: www.cyberguru.ru

   Рисунок 2

3. В операционных системах Windows Vista и Longhorn у нас появился новый уровень под названием «Basic User» (основной пользователь), который позволяет программам запускаться от имени пользователя, у которого нет прав администратора, поэтому пользователь может получить доступ лишь к ресурсам, доступным для обычных пользователей. Этого уровня мы больше не коснемся в этой статье.
   • Типы файлов можно добавлять и удалять, что лучше подстроиться под вашу среду, но список файлов по умолчанию включает основные типы исполняемых файлов: BAT, CMD, COM, EXE, HTA, LNK, MSI, OCX, PIF, REG & SCR и дополнительно такие расширения: ADE, ADP, BAS, CHM, CPL, CRT, HLP, INF, INS, ISP, MDB, MDE, MSC, MSP, MST, PCD, SHS, URL, VB & WSC.
   • Примечание: Как говорится в окне Designated Files Type Properties (свойства заданных типов файлов), список является дополнением к стандартным типам файлов, таким как EXE, DLL и VBS – я не смог получить их полный список, но выяснил, что VBS, VBE, JS и JSE блокируются, хотя они и не в списке. Я бы предпочел иметь единый список, который администраторы по всему миру смогли бы исправлять в случае необходимости.
   

   Картинка с сайта: www.cyberguru.ru

   Рисунок 3

4. Определение исключений (exception) для уровня безопасности по умолчанию (Default Security Level). Они также известны, как «Additional Rules» (дополнительные правила). Пожалуйста, посмотрите раздел «Additional Rules» (дополнительные правила) в этой статье для подробной информации.
5. Настройка «Enforcement Properties» (форсирующие свойства). Посмотрите на рисунок 4, она включает:
   • «All software files» (все файлы программного обеспечения): У нас также есть настройка для проверки DLL (Dynamic Link Libraries), когда они выполняются. Это не является настройкой по умолчанию и влияет на производительность и задачи планирования реализации и поддержки.
   • «All users except local administrators» (все пользователи за исключением локальных администраторов): Здесь мы можем выбрать, будет ли SRP касаться локальных администраторов (Local administrators). По умолчанию SRP касается всех пользователей. Эта настройка применима лишь для политики для компьютера (computer policies).
   • «Enforce certificate rules» (форсирование правил для сертификатов): Настройка позволяет задать, будут ли использоваться правила для сертификатов.
   • Примечание: Как говориться в диалоговом окне, изображенном на рисунке 4 «Правила для сертификатов отрицательно влияют на производительность вашего компьютера «.
   

   Картинка с сайта: www.cyberguru.ru

   Рисунок 4

6. Настройка «Trusted Publishers Properties» (свойства доверительных издателей), также известных, как настройки политики Authenticode policy (смотрите Рисунок 5). В этом диалоговом окне мы можем выбрать, кто может выбирать Trusted Publisher (доверительных издателей) для правил сертификатов. У нас есть также возможность проверки аннулирования сертификата.
   

   Картинка с сайта: www.cyberguru.ru

   Рисунок 5

Дополнительные правила

При настройке дополнительных правил (Additional Rules), необходимо определиться с методом, или с парой методов относительно того, как идентифицировать программное обеспечение. У нас есть 4 различных метода идентификации программного обеспечения:

1. HASH правилаHASH – это зашифрованный отпечаток, который остается вне зависимости от изменения названия файла и его расположения. Это особенно хорошо при использовании WL, но не так эффективно при использовании BL (причина этого частично описана примером с использованием инструмента под названием ProduKey в моей первой статье об SRP): MD5 или SHA-1 HASH позволяет четко идентифицировать двоичный файл программного приложения «ProduKey.exe», поэтому, если разрешить запускать лишь приложения с определенным значением HASH, позволит гарантировать, что можно запускать лишь определенную версию исполняемого файла. Однако, если запретить файл с определенным значением HASH запускаться, мы лишь введем такое ограничение для одной версии этого приложения и хитрые пользователи могут достаточно просто изменить файл, и он уже не будет подходить под ограничение. Слово «unknown» (неизвестен) очень важно в этом случае – оно является ключевым при выборе между белыми списками BL и черными списками WL – хотим ли мы разрешить пользователям запускать неизвестное программное обеспечение?

Если пользователь не сможет запустить старую версию определенного приложения, предположим, она нерабочая и приводит к нарушению работы системы, то использование правила «deny this HASH value» (запретить это значение HASH) – будет хорошим решением. Пожалуйста, помните, что у новой версии того же самого приложения будет новое значение HASH, которое необходимо будет разрешить или запретить.

2. Правила для сертификатовПравила для сертификатов используют подписанные хэши и обеспечивают очень мощную идентификацию, но если мы доверяем определенному сертификату, то мы доверяем всем программным продуктами, которые подписаны с использованием этого сертификата. Это может быть и хорошо и плохо. Это может быть хорошо, если мы, например, получаем приложение от стороннего производителя, которые подписал все необходимые файлы приложения (может быть, включая DLL), поэтому вместо того, чтобы делать новые правила для HASH, мы просто создаем одно правило, которое доверяет сертификату, и продолжаем работать. Но если я доверяю цифровому сертификату, который используется для подписи некоторых инструментов от Microsoft (или любого другого поставщика) – то теперь мои пользователи могут запускать все приложения, которые подписаны этим сертификатом… Hmm, проблема в том, чтобы узнать, что именно подписано этим сертификатом? Без таких знаний мы не знаем, что у нас разрешено. Вместо того, чтобы разрешить одно приложение, необходимое для наших пользователей, мы должны разрешить сотни приложений этого производителя запускаться на наших системах.

Тестирование правил для сертификатов можно осуществить с помощью этих инструментов: File Signing Tool (Signcode.exe) & Certificate Creation Tool (Makecert.exe).

3. Правила для путейПравила для путей – это самые распространенные и простые в использовании правила. Правила для путей позволяют разрешить или запретить запускать файл из определенного места (например, «C:\Scripts\Script.VBS»), имя файла (т.е. «Script.VBS»), папки (т.е. «C:\Scripts»), путь UNC (т.е.»\\SERVER\SHARE\File.VBS») или путь в реестре (т.е. «%[Registry Hive]\[Registry Key Name]\[Value Name]%»). Пути могут использовать переменные окружения (т.e. «%WINDIR%») и шаблоны «?» = один символ (т.е. «\\SERVER??\Share\Script.VBS») и «*» = любое количество символов (т.е. «*.VBS»).

Если вы используете правила для путей, необходимо учитывать следующее:

• Если задан путь к какой-либо папке, то правило будет затрагивать также все исполняемые файлы в дочерних папках
• Если у пользователя есть доступ на запись для папки, для которой задано Unrestricted (без ограничений), то пользователя может копировать любой файл в эту директорию и выполнить его оттуда. При проектировании необходимо учесть это, может быть, благодаря использованию ACL (Access Control List или списков контроля доступа) при использовании политики групп Group Policies
• Если у пользователя есть доступ на запись к папке, для которой задано Unrestricted, то пользователь может переписать этот выполняемый другим, чтобы обмануть SRP
• Если путь к папке включает в себя переменные окружения, например, %TEMP%, то даже пользователь с ограниченными правами может изменить переменную окружения, используя команду SET, на другой путь (SET TEMP=C:\MyFolder) – и после этого пользователь может контролировать это приложение.

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

4. Интернет зонаЗоны безопасности Internet Explorer security zone можно использовать для контроля установки программного обеспечения, но это относиться лишь к установочным пакетам Windows Installer packages (.MSI), которые запущены из одной из Интернет зон по умолчанию. Эти правила редко используются.

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

Ограничения SRP

Необходимо также учесть некоторые ограничения SRP. Область действия политики ограничения программного обеспечения (Software Restriction Policies) – это не вся операционная система, как вы могли ожидать. SRP не применяется для следующего кода:

• Драйвера или другое установленное программное обеспечение в режиме ядра
• Любая программа, выполняемая под учетной записью SYSTEM
• Макрос внутри документов Microsoft Office (у нас есть другие способы для их блокировки с использованием политик групп)
• Программы, написанные для common language runtime (эти программы используют политику Code Access Security Policy)

Заключение

Политики ограничения программного обеспечения (Software Restriction Policies) требуют особого и долгого технологического процесса при внедрении нового программного обеспечения и обновления в среде, но кроме этого за их счет достигается уровень безопасности (security level) гораздо выше, чем при установке «default allow all» (разрешить все по умолчанию). Некоторые среды могут не подходить для SRP, как мне кажется, большинство сетей имеют компьютеры и пользователей, для которых технология SRP technology великолепно подходит.

Необходимо назначение, понимание и упорная работа для реализации политики «Default Deny» (запретить по умолчанию) – именно поэтому она редко реализуется… Но одно определенно, правильная реализация таких политик позволит администратору спать по ночам спокойно.

На протяжении следующей пары лет будет очень интересно посмотреть, продолжит ли компания Microsoft разрабатывать эту часть политики групп Group Policy – или же появится что-то лучшее, кто знает…

Якоб Хейдельберг (Jakob H. Heidelberg)