Политика ограничения программного обеспечения Software Restriction Policy (SRP)

Политика ограничения программного обеспечения 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

Большинство корпораций хотят:	Чтобы защититься от таких опасностей:
Защитить компьютеры от заражения	Malware, программы-шпионы (spyware), вирусы, Трояны (Trojan horses), Denial of Service (DoS) атаки.
Запретить запускать нежелаемое программное обеспечение на корпоративных компьютерах	Игры и другое программное обеспечение, неотносящееся к работе, снижают производительность и приводят к дополнительному потреблению сетевых и компьютерных ресурсов
Запретить запускать нелицензионное программное обеспечение на корпоративных компьютерах	Запуск нелицензионного программного обеспечения может привести к привлечению к ответственности Running unauthorized software on the corpora – ни одна организация не хочет быть привлечена за пиратство…
Запретить запускать неподдерживаемое программное обеспечение на корпоративных компьютерах	Предупредить конфликты приложений, которые могут привести к сбоям системы, несовместимости с производственным программным обеспечением, сложной отладке и т.п.
Запретить запускать неизвестное программное обеспечение на корпоративных компьютерах	Которое может (и скорее всего так и будет) повредить вам …
Снизить общие затраты на имущество Total Cost of Ownership (TCO)	Вирусные атаки приводят к дополнительным затратам денег

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

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

С помощью 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" (новая политика ограничения программного обеспечения).

   
   Рисунок 1
2. Установка Default Security Level (уровень безопасности по умолчанию). На рисунке 2 показано, как с помощью нажатия правой кнопки мыши уровень установлен на "Set as default" (установить по умолчанию).
   • По умолчанию уровень "Unrestricted" (без ограничений), что значит, что программное обеспечение может быть запущено, и что необходимо задать дополнительные правила для запрещения определенного программного обеспечения (software) – такой подход известен, как черный список Blacklisting.
   • Самый безопасный уровень – это "Disallowed" (запрещен), что значит, что никакое программное обеспечение не может быть запущено, и что необходимо задать дополнительные правила для разрешения программного обеспечения – такой подход известен, как белые списки Whitelisting.
   • По умолчанию система создает несколько правил, которые позволяют операционной системе работать без всякого неудобного блокирования NB! Если эти правила удалить или изменить не подумав, то система может выйти из строя.
   
   Рисунок 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 блокируются, хотя они и не в списке. Я бы предпочел иметь единый список, который администраторы по всему миру смогли бы исправлять в случае необходимости.
   
   Рисунок 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 "Правила для сертификатов отрицательно влияют на производительность вашего компьютера ".
   
   Рисунок 4
6. Настройка "Trusted Publishers Properties" (свойства доверительных издателей), также известных, как настройки политики Authenticode policy (смотрите Рисунок 5). В этом диалоговом окне мы можем выбрать, кто может выбирать Trusted Publisher (доверительных издателей) для правил сертификатов. У нас есть также возможность проверки аннулирования сертификата.
   
   Рисунок 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)