Фреймворк конфигурации и управления политиками Software Restriction Policies — IV

Политики «белых списков» помогают защитить систему от несанкционированных изменений — то есть, законсервировать её. Но полная консервация невозможна: следует ставить обновления операционной системы, иногда требуется менять программы. Как вносить санкционированные изменения?

ЧАСТЬ ЧЕТВЁРТАЯ. ОТКЛЮЧЕНИЕ ПОЛИТИК APPLICATION WHITELISTING

Одной из технических проблем является установка программ и обновлений. Эти операции могут осуществляться как автоматически, так и вручную. Учётную запись SYSTEM политики SRP не затрагивают, что позволяет без проблем автоматизировать обновления и установку программ средствами System Center Configuration Manager (SCCM), WSUS Package Publisher (WPP) или даже сценариями загрузки (Startup Scripts). Но далеко не всегда эти средства доступны, а установка возможна или возня с автоматизацией целесообразна.

А вот ручная установка программ на защищённый «белыми списками» компьютер может оказаться проблематичной. Ведь AWL не даст запуститься инсталлятору, который распаковывает свои файлы во временную папку и пытается их запустить оттуда. Запуск инсталлятора из отдельной разрешённой папки не поможет, так как у него будет своё мнение, что откуда запускать. Эта проблема может быть решена следующими способами:

1. Выполнять установку от лица специальной учётной записи, для которой сконфигурированы разрешения запуска любых программ;
2. Сконфигурировать AWL так, чтобы защита не распространялась на членов локальной группы Administrators, применив для этого политику Workstations Baseline NoAdmins. Соответственно, работе администраторов в процессе инсталляции ничто препятствовать не будет;
3. Для установки программ временно отключать AWL отдельным ярлыком или командой. Этот метод актуален для сценария, когда администраторы защищены «белыми списками» наряду со всеми другими пользователями (применена политика Workstations Baseline).

У каждого метода имеются свои преимущества и недостатки. Например, наличие дополнительной учётной записи может облегчить аудит, но усложняет поддержку системы и не всегда отвечает задаче снижения рисков. В моих доменах Active Directory для доменного администратора вполне типично иметь две-три учётные записи: стандартную для обычной работы, ограниченно привилегированную для поддержки рабочих станций и полноправную доменную для конфигурации Active Directory. И это не считая различного рода сервисов без интеграции с AD: бизнес-систем, почтового сервера, роутеров, видеонаблюдения, да чего угодно ещё. Этого уже более чем достаточно, чтобы либо начать записывать пароли на бумаге, либо ставить одинаковый пароль на всё. Добавление ещё одной учётной записи может вызвать злоупотребление ею (постоянное применение не по делу) либо даже полное отторжение администратором всей системы AWL вообще («уберите все эти ваши защиты, дайте нам нормально работать»).

Если вы решили применить этот метод, выполните следующие настройки:

• Создайте группу Software Installers и включите в неё все учётные записи, от лица которых будет производиться установка программ;
• Создайте пустой объект политики SRP Software Installers и разрешите её исполнение только группе Software Installers;
• В разделе User Configuration > Policies > Windows Settings > Security Settings > Software Restriction Policies создайте новую конфигурацию SRP;
• В подразделе Additional Rules добавьте правило: C:\ = Unrestricted. Таким образом, всё пространство системного диска становится для конкретных пользователей разрешённым для запуска программ (кроме отдельно указанных запретов);
• Пристыкуйте SRP Software Installers к контейнеру, в котором хранятся учётные записи пользователей из группы Software Installers.

Ещё один недостаток данного метода заключается в том, что если эта политика применится на компьютере, для которого вообще не настроена политика SRP в разделе Computer Configuration, это может вызвать спонтанное порождение и применение фантомной SRP в разделе Computer Configuration с нежелательными последствиями.

Для оценки второго метода следует уделить некоторое внимание различиям политик для рабочих станций Workstations Baseline и Workstations Baseline NoAdmins. Application Whitelisting может не впечатлить сотрудников технической поддержки, которые поначалу могут не понимать, как это работает. Они могут отказаться работать со словами «вы там наворотили, теперь сами исправляйте». Поэтому на рабочих станциях внедрение AWL можно начать в облегчённом режиме, применив политику Workstations Baseline NoAdmins. В этом сценарии обычные пользователи будут защищены, а сотрудники техподдержки беспрепятственно смогут выполнять администрирование рабочих станций. Со временем они привыкнут, что AWL существует, и тогда можно будет сменить подход. Однако, такой метод неприменим, если по каким-то причинам рядовые сотрудники компании обладают привилегиями администратора на своих рабочих станциях. В этом случае, я бы поспешил с назначением таковым сотрудникам двух учётных записей — стандартной и привилегированной, чтобы повышенные права применялись только по мере необходимости.

На мой взгляд, администраторы — это самые опасные пользователи системы, и их нужно защищать не менее остальных, и я сам всегда работаю под полной защитой AWL, применяя политику Workstations Baseline. Разумеется, если сотрудники техподдержки тоже готовы работать с AWL с самого начала, то так и следует сделать, не увеличивая число политик. В этом сценарии перед установкой программ я переключаю SRP в режим Unrestricted, оперируя значением DWORD DefaultLevel в ключе реестра HKLM\Software\Policies\Microsoft\Windows\safer\CodeIdentifiers:

• DefaultLevel = 0x0 означает, что включён режим Disallowed by Default, «белые списки»;
• DefaultLevel = 0x40000 означает, что включён режим Unrestricted by Default, «чёрные списки»;

Для смены этого значения требуются административные привилегии, поэтому не стоит опасаться, что пользователи смогут переключать режимы SRP по своему желанию. Готовые REG-файлы и заранее приготовленные ярлыки на них можно распространить на все компьютеры в той же политике SRP Audit Only вместе со всеми другими файлами и скриптами:

• Computer Configuration > Preferences > Windows > Files > Action: Update; Source: «\\WindowsNT.LV\NetLogon\Deployment\SRP_*.reg»; Destination: «%WindowsDir%\»;
• User Configuration > Preferences > Windows > Files > Action: Update; Source: «\\WindowsNT.LV\NetLogon\Deployment\SRP*.lnk»; Destination: «%DesktopDir%\»; Targeting: «If user is member of BUILTIN\Administrators» and «DefaultLevel=0x00000000»;

Как результат, на рабочем столе администратора (папка Desktop) появятся иконки, позволяющие произвольно переключать режимы работы SRP:

Дополнительно я бы рекомендовал установить параметр Computer Configuration > Administrative Templates > System > Group Policy > Policy Processing в состояние Enabled с галочкой Process even if policy has not changed. Дело в том, что политика конфигурирует ключи реестра один раз и не имеет обратной связи. Этот параметр включается для того, чтобы политика могла принудительно присвоить значению DefaultLevel = 0x0 при каждом цикле исполнения GPUpdate. По умолчанию это 90-+30 минут на рабочих станциях и 5 минут на контроллерах домена. Пять минут — это очень мало для выполнения инсталляций, поэтому для контроллеров это время я корректирую:

Следует акцентировать, что переключение параметра DefaultLevel не отключает SRP, а лишь переводит в состояние «чёрных списков». Это означает, что все запрещающие правила продолжают работать, и по-настоящему их отключить не так просто. Учитывая, что сложение наследуемых политик SRP также имеет свои особенности, рекомендую по возможности не задействовать Запреты. Управление ресурсами должно быть построено так, чтобы не пришлось применять отдельные Запреты на запуск каких-либо программ, вместо этого должно отрабатывать правило по умолчанию. В этом смысле идеология AWL близка к разрешениям NTFS — иногда запреты NTFS (NTFS Restrictions) применяться могут как таковые, но это требует глубокого понимания механизма их работы. Обычно, если вы применяете запреты NTFS, я считаю это признаком неверного построения дерева ресурсов.

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