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

Некоторые вполне себе удачные ИТ-технологии не внедряются или неверно применяются потому, что у людей нет понимания, как это делать правильно, а заниматься собственными исследованиями не каждый захочет. К таким технологиям в настоящий момент относится и столь важная концепция безопасности, как «белые списки» программ (Application Whitelisting, AWL), которая в Microsoft Windows реализована в виде Политик ограничения программ (Software Restriction Policies, SRP) и AppLocker (SRPv2). Возможно, она непопулярна среди ИТ-администраторов в первую очередь из-за относительной сложности внедрения и диагностики. В этой статье я поделюсь своим опытом внедрения SRP на предприятии, попытавшись сформулировать основные положения правильной конфигурации политик в доменах Active Directory (AD).

 

Приведённый ниже опыт получен как с нескольких компаний размером порядка 1000 хостов, так и с большого количества маленьких компаний. Некоторые политики было проще реализовать на небольших объёмах, так как в них количество администраторов не превышало двух-трёх; компании побольше дали понимание того, как обычные сотрудники службы техподдержки взаимодействуют с администраторами и другими сотрудниками. Далее я буду описывать свой фреймворк внедрения SRP применительно для компании с парой-тройкой администраторов и десятком сотрудников техподдержки.

 

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

 

 

Заручитесь поддержкой руководства, без этого проект реализован быть не может. Особенность многих технологий безопасности заключается в том, что по сути своей они являются набором ограничений. Привилегии обычного пользователя (Limited User Account, LUA) не позволяют переконфигурировать параметры операционной системы; антивирусная программа в меру своих возможностей не позволяет запускаться вирусам; AWL не позволяет запускать нежелательные программы. Это всё — ограничения, и некоторые люди считают их для себя неприемлемыми. Местами вам придётся вести разъяснительную работу, убеждая сотрудников, что компания может и должна приложить усилия по сохранению выданной им в пользование техники в работоспособном состоянии. Руководство должно вникнуть в суть AWL и поддерживать его реализацию. Конечно, наиболее сговорчивыми и понятливыми в этом смысле были те руководители, кто пострадал, вкусив все прелести вирусов-шифровальщиков. Но однажды у меня был и противоположный опыт, когда новоявленный ИТ-директор спросил: «Какие такие белые списки, что это такое? Из-за них может что-то отказать? У тебя есть где-то реализованный проект SRP с хотя бы сотней серверов в одной компании? Нет? Ну тогда закрой рот и иди займись другими делами».

 

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

1. Руководитель проекта принимает решение, когда и на каких конкретно компьютерах задействовать политику AWL;
2. Инженер проекта проанализирует журналы списка запускаемых целевой аудиторией программ и при необходимости поставит вопрос, запуск каких нестандартных программ следует разрешить в политике;
3. Руководитель проекта принимает решение, какие из означенных программ разрешить, а какие можно блокировать, не обращая на них внимания;
4. Инженер проекта высылает уведомления целевой аудитории и службе техподдержки и включает политику;
5. Через некоторое время кто-то из целевой аудитории позвонит в техподдержку и сообщит, что у него перестала работать важная программа — например, SharePoint Designer;
6. Сотрудник техподдержки читает журнал SRP и обнаруживает, что программа генерирует в папке %Temp% пользователя динамические библиотеки, которые затем пытается исполнить. Выполняется эскалация инцидента;
7. Ответственный инженер попытается добавить нужные библиотеки в политику и обнаруживает, что библиотеки каждый раз генерируются с разными хэшами, а сертификат задействовать нельзя, так как его нет вообще. И вот тут он понимает, что находится на распутье, пытаясь принять правильное решение, как именно составить разрешающее правило. А вдруг придётся вообще отказаться от AWL на данном компьютере?

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

 

Выберите наиболее подходящую технологию Application Whitelisting. Software Restriction Policies и AppLocker имеют общий принцип работы, но обладают различными характеристиками. Ничто не мешает вам выбрать для себя даже некое стороннее решение или продукт (например, Lumension AppControl), но вам всё равно придётся столкнуться со всеми организационными вопросами, рассмотренными в данной статье. Эти проблемы универсальны. Почему для своих проектов я выбираю именно SRP?

1. SRP поддерживается на ОС начиная с Windows XP/2003, а AppLocker — только с Windows 7/2008R2. Да, на дворе уже почти 2016-й год, но многие компании ещё не готовы отказаться от имеющегося оборудования и перейти на более новые системы. Разводить зоопарк AWL-решений в смешанной среде я бы не стал, так как поддерживать такую конфигурацию было бы вдвое сложнее;
2. SRP работает начиная с Windows Professional, а AppLocker требует для себя лицензию Enterprise/Ultimate. Опять же, далеко не все компании оформляют подписку на Windows Enterprise, ведь Windows Professional OEM гораздо дешевле в долгосрочной перспективе;
3. SRP при необходимости можно мгновенно перевести из режима «белых списков» в режим «чёрных списков» (условно назовём это «режимом аудита»), тем самым отключая все блокировки. Это пригождается как для диагностики, так и для установки программ, если действие политики распространяется на администраторов в том числе;
4. AppLocker имеет свои неоспоримые преимущества перед SRP (например, детальный контроль версий запускаемых программ и возможность задействовать исключения), но в моих реализациях они никогда не были востребованы.

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

 

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

 

Внедрение политик всегда начинайте с ИТ-департамента. Сотрудники технической поддержки не смогут квалифицированно оказать помощь другим, если сами не обладают опытом работы на компьютере, защищённом AWL. Их типичная реакция на любую техническую проблему может приобрести вид «вы тут что-то накрутили, вот теперь сами и решайте», в конечном итоге выливаясь в «это всё опять из-за политик! Хватит уже, давайте выводить компьютеры из домена» по любому поводу, с AWL или другими политиками никак не связанному. Дайте сотрудникам ИТ-департамента привыкнуть к наличию «белых списков», прочувствовать суть их работы. Настоятельно рекомендуйте им настроить и протестировать AWL на своих домашних компьютерах, хуже от этого им точно не станет.

 

 

Выдайте сотрудникам техподдержки письменную инструкцию, как проводить базовую диагностику SRP. Инструкция должна быть краткой и ёмкой (правда, у меня получилось пять страниц со снимками экрана), при этом никаким особым приёмам учить людей не нужно. В этом документе расскажите суть внедрённой политики, обозначьте визуальные признаки её срабатывания, покажите местонахождение детального журнала SRP, и разъясните, как действовать при необходимости отключить SRP . При наличии подозрений, что именно SRP мешает работе нужной программы, сотрудник может выполнить поиск слова Disallowed в детальном журнале и, если такое слово было найдено, перевести SRP в режим аудита и проверить работоспособность программы ещё раз. Этого будет вполне достаточно, чтобы либо снять возникшие подозрения, либо доложить администратору о необходимости скорректировать политику и решить проблему.

 

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

1. Если это ещё не сделано, структурируйте Active Directory по странам, департаментам, отделам. Разделите сервера, рабочие станции, технологические машины по контейнерам. Чтобы снизить риски блокирования работы компании в случае неудачной конфигурации политики, задействовать AWL следует пошагово, контейнер за контейнером.
2. Убедитесь, что всем сотрудникам техподдержки присвоены две учётные записи (User Account), УЗ. Для выполнения своих обычных задач (почта, Интернет, удалённая поддержка) они обязаны использовать УЗ с ограниченными привилегиями, прибегая к административным только по доказанной необходимости — например, для установки или обновления программ или драйверов;
3. Административные УЗ, однако, не должны быть привилегированными на компьютерах самого отдела техподдержки. Эти рабочие станции не предназначены для тестов или игр, за ними работают люди, обладающие чувствительными, опасными УЗ. Компрометация компьютеров техподдержки может привести к захвату всего домена и уничтожению всех данных, поэтому управляются они, например, только администратором домена;
4. Запретите сотрудникам техподдержки использовать съёмные носители, а также свободно скачивать с Интернета программы для установки на компьютеры других пользователей. Все утверждённые администратором установочные файлы должны храниться только на декларированном общем ресурсе (Distribution Share), откуда могут устанавливаться либо вручную, либо средствами автоматизации Windows Update / System Center (WSUS/SCCM);
5. Все новые инсталляции рабочих мест (и переинсталляция старых) должны производиться уже в соответствии с базовой политикой SRP (SRP Baseline). На практике это означает, что операционная система ставится либо по верному шаблону вручную, либо распространяется с Windows Deployment Services (WDS). Шаблон предписывает все программы либо устанавливать в Program Files, либо запускать из централизованного хранилища на файл-сервере, также блокируя разрешениями NTFS возможные вольности со стороны пользователя.

 

Разработайте график внедрения политик. Успех проекта целиком и полностью зависит от компетентности и целеустремлённости системного инженера. Подход вида «инженер разработал для вас фреймворк, теперь внедряйте всё пошагово сами», к сожалению, не работает, люди просто не будут этого делать. Определите временные рамки, распишите последовательность контейнеров и еженедельно неуклонно продвигайтесь на шаг вперёд. Последовательно проверяйте результаты, полученные от внедрения политик на предыдущей неделе и задействуйте следующую партию хостов. Навскидку определить сроки сложно, это зависит от специфики компании. Например, реализовать SRP в учебном заведении размером 10 000 хостов оказалось проще и быстрее, чем в страховой компании размером 1000 хостов — всего три месяца против двенадцати. Причина — заранее реализованная стандартизация студенческих рабочих мест, комплектация программного обеспечения для 9000 хостов была единой.

 

Развивайте проект сначала на самых простых компьютерах. Не спешите включать ограничения для рабочих станций разработчиков (программистов) и компьютеров, контролирующих технологические агрегаты. Наращивайте сложность и добивайтесь успехов постепенно, чтобы не получать сбои производства и негативные отзывы о проекте с самого начала. Если что-то не получается сделать красиво с наскоку, лучше делайте это Quick-n-Dirty, но продвигайтесь вперёд. Лучше иметь неидеальную, но работающую систему «белых списков», чем долго что-то испытывать, тюнинговать, в результате не имея ничего — ни опыта внедрения, ни работающей системы. Улучшать фреймворк можно и в дальнейшем, это вообще бесконечный процесс. Когда основные сложные моменты будут решены, можете переходить к рабочим станциям «вольных художников».

 

Ведите количественный учёт продвижения проекта. Насколько далеко удалось продвинуться за прошедший период? Каков процент компьютеров, на которых ещё предстоит внедрить AWL? Эти показатели можно попытаться оценить средствами объективного контроля — например, всё теми же групповыми политиками или отчётами SCCM. Отчётность должна формироваться автоматически по нескольку раз в день, чтобы любые изменения были сразу заметны. Учтите, что некоторые проекты могут считаться успешно законченными, даже если политика покрывает не весь домен, а колеблется в пределах 95%-98% от общего числа компьютеров, поддерживающих AWL. Сложнее будет ответить на другие вопросы: нет ли компьютеров, которые только симулируют работу «белых списков», а на самом деле разрешают запускать всё без разбору? Возможно ли, что сотрудники техподдержки или рядовые пользователи втихую пытаются обойти ограничения?

 

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