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

ЧАСТЬ ТРЕТЬЯ. КОНФИГУРАЦИЯ БЛОКИРУЮЩИХ ПОЛИТИК.

Какое количество политик (объектов GPO) создать, в каких ситуациях следует создавать дополнительные политики? На это влияют следующие факторы:

• Раздельные реализации AWL: AppLocker или SRP;
• Возможность раздельного отключения политик для определённых контейнеров АД. Например, когда требуется временно выключить AWL для одного-двух департаментов, но не выключать для всех остальных;
• Делегирование управления. Если компания имеет представительства в различных странах (например, Латвия и Россия), и в каждой стране имеется своя IT-поддержка, то для базовой политики SRP я предпочту создать два дополнения: SRP Workstations LV и SRP Workstations RU. Затем можно делегировать управление этими дополнениями IT-отделам соответствующих стран, разрешив конфигурацию базовой политики только доменным администраторам;
• Разбиение большого количества дополнительных правил на несколько GPO. Количество правил может зависеть в том числе и от политических установок руководства компании. Например, IT-директор может заявить «да, наши пользователи устанавливают программы дезорганизованно, но сделайте AWL так, чтобы им ничего не пришлось переделывать». Такая позиция потребует применить сотни путей и хэшей, которые будет лучше разнести по нескольким GPO согласно структуре департаментов или другому признаку;
• Существенные различия в конфигурации AWL: например, для департамента продаж, где все сотрудники работают с ограниченными привилегиями, можно включить AWL, нацеленный только на стандартных пользователей, в то время как для компьютеров химического анализа, где все сотрудники обладают привилегиями администратора, следует задействовать фильтрацию всех пользователей, в том числе администраторов.

Для типичной компании я применяю следующий набор политик:

• SRP Audit Only, которая уже была описана ранее, подключается к корневой папке домена. Её же можно будет задействовать для создания исключений из общих правил. Например, подключить к специальному контейнеру, чтобы помещаемые в него компьютеры могли работать без ограничений AWL;
• SRP Template, шаблон с первичной конфигурацией для создания всех новых блокирующих политик;
• SRP Servers Baseline, задействующая основные, общие для большинства серверов «белые списки». Политика нацеливается на контейнер Servers, содержащего учётные записи всех серверов домена (кроме контроллеров), а также контейнер Domain Controllers;
• SRP Workstations Baseline, содержащая базовую, общую для большинства рабочих станций конфигурацию «белых списков». Политика нацеливается на контейнер Computers, содержащую учётные записи всех рабочих станций. Действие политики распространяется и на стандартных пользователей, и на администраторов;
• SRP Workstations Baseline NoAdmins. Отличие этой политики от предыдущей в том, что её действие распространяется только на стандартных пользователей, но не на членов локальной группы Администраторов.

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

• SRP Servers %ServerRole%, являющиеся расширениями основной политики для группы серверов, играющих особые роли — например, терминальных серверов. Потребность в таких расширениях может возникнуть в компании с достаточно большим количеством серверов и делегированным управлением;
• SRP Workstations %Attribute%, являющиеся расширениями основной политики для отдельной группы рабочих станций. Признаком группы может быть страна, департамент, делегирование управления отдельному IT-персоналу или особый функционал (например, компьютеры SCADA).

В общем случае, количество политик следует свести к минимуму. Любая политика SRP состоит из двух частей: общая конфигурация и дополнительные правила (Additional Rules), в которых прописаны все пути, хэши, сертификаты. Когда к доменному компьютеру применяется одновременно несколько политик, их общая часть перезаписывается обычным методом LSDOU («кто ближе, тот и прав»), а вот дополнительные правила (пути, хэши) суммируются (подробнее о сложении политик: https://sysadmins.lv/blog-en/software-restriction-policies-rule-ordering.aspx). Как результат, для корректной обработки некоторых изменений вам может потребоваться вносить их во все ваши SRP GPO, либо для какой-то из политик верхнего уровня установить принудительный режим применения (Enforced), что может вызвать дополнительные сложности управления.

Какие конкретно параметры блокирующих политик задать?

Некоторые параметры будут общими для большинства блокирующих политик SRP. Их можно сразу отразить в шаблоне SRP Template:

• В репозитории политик создайте новый объект SRP Template. Подключать его никуда не потребуется;
• В разделе Computer Configuration > Policies > Windows Settings > Security Settings > Software Restriction Policies создайте новую конфигурацию SRP;
• В подразделе Security Levels назначьте правило по умолчанию: Disallowed;
• В объекте Designated File Types удалите LNK;
• В объекте Enforcement укажите параметр Apply To: All Software Files;
• В объекте Enforcement укажите параметр Apply To: All Users;
• В подразделе Additional Rules удалите все встроенные правила и добавьте новые: C:\Windows\, C:\Program Files\, C:\Program Files (x86)\. Причиной такой переконфигурации является некорректная обработка переменных при вызовах исполняемых модулей со сменой архитектуры. Например, когда 64-разрядный Outlook вызывает на исполнение 32-разрядный Acrobat Reader при открытии PDF-приложения к письму, переменная %ProgramFilesDir% не обновляется, и встроенные правила необоснованно срабатывают на отказ (то есть, случается false positive);
• Сразу же можно добавить пути, гарантированно требующиеся для всех компьютеров домена. Например, это могут быть пути вида \\WindowsNT.LV\NetLogon\ для исполнения сценариев входа и загрузки и \\DeploymentServer\Install\ для сервера распространения программ, \\FileServer\Applications\ для сервера приложений.

На базе SRP Template создайте объекты SRP Baseline:

• В репозитории политик скопируйте объект политики SRP Template и вставьте три копии для Baseline-объектов;
• В подразделе Additional Rules скорректируйте или добавьте пути, которые требуется всем компьютерам, подпадающим под действие конкретной Baseline-политики;
• Для политики SRP Workstations Baseline NoAdmins параметр Enforcement переключите в Apply To: All Users except Local Administrators.

В какой последовательности и к каким контейнерам Active Directory подключать созданные объекты политик?

• Одно из важнейших предварительных условий — структурирование учётных записей компьютеров по контейнерам Active Directory (Organizational Unit, OU). Ситуации, когда SRP можно задействовать сразу на всю компанию без структурирования, очень редки. Как правило, это или маленькие компании с числом рабочих станций до ста, или заведения с большим количеством унифицированных рабочих станций — например, университет;
• В типичной компании для рабочих станций я задействую AWL последовательно, раз в неделю подключая политику к каждому следующему выбранному OU. Когда все подразделения будут задействованы, политика подключается к контейнеру более высокого уровня и отключается от всех дочерних контейнеров;
• Перед включением политики для очередного подразделения следует провести аудит запускаемых программ и принять решение, что делать с файлами, загружаемыми из нестандартных мест. Если будет принято решение эти программы добавить в «белые списки», оцените, не следует ли создать отдельный SRP GPO для этой компании/страны/подразделения;
• Возможно, для некоторых компьютеров «с наскоку» включить AWL не получится из-за большого количества нестандартных программ. В текущем OU создайте подконтейнер SRP Audit Only, туда же подключите политику SRP Audit Only и переместите эти компьютеры. Они могут оставаться в «подвешенном» состоянии некоторое время, чтобы не задерживать ход проекта;
• Для серверов логика включения AWL может несколько отличаться. Сначала создайте подконтейнер SRP Audit Only и подключите к нему политику SRP Audit Only. Поместите все серверы в этот контейнер и по очереди вытаскивайте в родительский OU, к которому будет подключена политика SRP Servers Baseline. Учтите, что для полноценного первого включения SRP требуется делать рестарт системы!
• Если метод «OU by OU» не подходит, вы можете создать группу вида WindowsNT Servers SRP-Enabled, куда добавлять учётные записи серверов по мере внедрения проекта. К контейнеру Servers подключите политику SRP Servers Baseline, но укажите право её применения только указанной группе. Недостаток этого метода в том, что он может требовать дополнительного рестарта для вступления членства в группе в силу;

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

• Какие-то программы придётся объявить неразрешёнными. Например, если пользователь скачал игру и запускает её из папки своего профиля;
• Какие-то версии программ придётся запретить, но предоставить сотрудникам правильные версии альтернативным способом. Например, пользователь установил себе браузер Firefox Portable и обосновывает его наличие рабочей необходимостью. В этом случае версию Portable лучше заблокировать, но предоставить сотрудникам возможность установки поддерживающую массовое распространение и групповые политики версию FireFox Community Edition подсредством WSUS или SCCM;
• Какие-то программы можно переместить на сервер распространения или сервер приложений. Например, если сотрудникам отдела техподдержки требуются утилиты SysInternals, вы можете опубликовать их в доступной только для чтения общей папке, путь до которой уже добавлен в политику;
• Какие-то программы можно переместить во внесённую в AWL доступную для записи локальную папку вида C:\Applications. Сотрудники, занимающиеся тестированием или обновлением различных версий программ, смогут сохранять и запускать оттуда всё необходимое. Разумеется, они смогут сохранить туда также и неразрешённые программы, но риски случайного запуска вируса из приложенного к письму файла всё же будут снижены;
• Какие-то необходимые для работы программы можно задекларировать в AWL. Вам нужно будет только решить, добавить ли их в GPO Baseline или создать новую политику, расширяющую AWL для нужд конкретного подразделения, что зависит в том числе от факторов, описанных в начале статьи.

В следующей части я расскажу, как поддерживать компьютеры, защищённые политиками AWL.