Представьте себе ситуацию, Вы руководите IT-службой крупной компании, у Вас несколько доменов и несколько тысяч пользователей в Active Directory. В подчинении у Вас как минимум несколько системных администраторов, каждый из которых выполняет свои обязанности. Неожиданно сотрудники в одном из подразделений жалуются на то, что они никак не могут придумать себе новые пароли после истечения срока действия старых – система не принимает заново создаваемые пароли. После быстрого просмотра политики паролей соответсвующего подразделения Вы понимаете, что длина и сложность пароля были изменены. Чтобы узнать, что стало причиной, Вы обращаетесь к журналам событий и понимаете, что информации о том, когда и кем была изменена политика паролей, нет – журналы уже перезаписались. Кто изменил политику – останется тайной.
А вот еще один пример: администратор вдруг обнаруживает, что один из пользователей может ставить без каких-либо проблем ПО на свою машину. И это при том, что в групповой политике для OU, в которой состоит пользователь, такая установка была запрещена. Опять-таки информацию о том, кто и когда разрешил такую установку необходимо искать в журналах событий, продираясь сквозь “шум” неинформативных данных.
Все это приводит к однозначному выводу IT-служба компании должна уделять внимание происходящим в групповых политиках изменениях. Делать это необходимо, чтобы не допустить как образования дыр в системе информационной безопасности (“какой там софт поставит нерадивый пользователь?”), так и обеспечения непрерывности деятельности (когда 200 человек одновременно не могут зайти на свои машины, так как не в состоянии придумать подходящий пароль).
Только на практике выходит так, что контроль над изменениями групповых политик редко кто практикует. И лишь при возникновении проблемы или обнаружении подозрительной активности начинается поиск источника проблемы путем анализа журналов событий и опроса коллег.
Однако важно не только выяснить причины проблемы, но и предупредить самое ее появление. В случае с групповыми политиками можно не сомневаться, что администратор захотел бы знать, что политика паролей была изменена и предпринять необходимые действия до того как к нему посыплется вал звонков от пользователей, чья работа теперь встала.
Чтобы оперативно расследовать и предупрежать подобных инцеденты, необходимо быть в курсе происходящих в групповых политиках изменений. Можно попытаться решить эту проблему штатными средствами.
Например, просматривать журналы событий вручную. Однако даже если мы заблоговременно настроили аудит и позаботились о возможной перезаписи данных в журнале, просмотр событий журнала случится только после поступления жалоб от пользователей. И поможет только в поисках виновника, а не предотвращении проблемы.
В Windows Server 2008 R2 процесс отслеживания изменений (и предупреждения связаных с ними проблем) становится немного проще. Наряду с более удобным просмотрщиком событий (Event Viewer) появилась возможность настроить почтовые оповещения на определенные события, что позволяет быть на шаг впереди, ведь теперь присутствует возможность исправить ситуацию до того, как она докатится до конечного пользователя.
Однако даже с расширением штатных возможностей аудита в Windows Server 2008 R2 возникают сразу несколько отягчающих факторов. Какие события выбрать? Как оперативно фильтровать их содержимое, когда в событиях с одинаковым номером может содержаться информация о разных обьектах (например, событие 4662 генерируется как для изменений груповых политик, так и для других обьктов в Active Directory)? События содержат только GUID, а не имя конкретной групповой политики, что вынуждает после получения необходимого события проводить еще и процедуру опознания GUID’a. А что если таких событий десятки?
Как видно из примеров, приведенных выше, штатная система аудита далека от идеальной, и отдельным моментом также стоит отметить отображение значений “до” и “после” по каждому изменению. Их попросту не существует. Получается, что в случае с групповыми политиками администратор должен держать их содержимое в голове или выполнять периодически экспорт политик и затем сравнивать вручную, чем же они отличаются.
Конечно использование штатной системы аудита дает определенный контроль над происходящими изменениями, но все же избежать следующих недостатков не удастся:
- Анализ информации об изменении в событиях достаточно трудоемок, требует определенных знаний для восприятия и не может быть представлен в исходном виде тем людям, которые не слишком хорошо разбираются в данных вопросах (например, высшему руководству)
- Анализ журналов безопасности должен осуществляться вручную на каждом контроллере домена
- Отсутствует консолидация данных
- Перезапись журналов – возможна потеря событий
- Фиксируется лишь сам факт изменения, отсутствует очевидная информация о том, что же именно изменилось
И многое другое…
Отчасти описанные выше проблемы позволяют решить различные методы обработки журналов (начиная от скриптов и утилит, которые позволяются анализировать логи, до специализированных SIEM-решений). Однако и они не решают всех описанных проблем. Например, в них не приводятся значения “до” и “после» по каждому изменению, в результате чего администратор должен вручную создавать и поддерживать в актуальном состоянии архив с текущими настройками груповых политик.
Недостатки штатной системы аудита и растущие потребности в управлении IT-инфраструктурой приводят к возникновению сторонних специализированных решений для аудита изменений. Исходя из описанных выше недостатков штатной системы определим, какие характеристики лежат в основе решений для аудита групповых политик:
- Отображение изменяемого значения обекта в виде “до” и “после” изменения,
- Автоматическая генерация отчетов об произошедших изменениях за конкретный промежуток времени (например, за каждые 12 часов или сутки),
- Возможность фильтрации данных и получения информации об изменениях отдельных политик,
- Обязательно наглядность представляемой информации (кто, что, где и когда изменил),
- Возможность хранить данные аудита в специализированном хранилище (в базе данных SQL, в архиве на файл-сервере или в обоих местах сразу),
- Резервирование и восстановление групповых политик.
Мы рассмотрим в статье одно из таких решений — нашу программу NetWrix Group Policy Change Reporter, осуществляющую аудит изменений групповых политик. Прежде всего, расскажем как продукт работает.
- Во время сбора даных продукт делает снимки текущего состояния груповых политик и собирает информацию из журналов безопасности со всех контроллеров домена, в котором производится аудит.
- После сбора данных они складываются в указанное место хранения (например, на выделенный файл-сервер), после чего осуществляется их анализ, Обнаруженные изменения загружаются в базу данных (в случае если она подключена к продукту), а также высылаются в виде отчета на указанные адреса электронной почты.
- Инициализация сбора даных основана на планировщике заданий, в котором создается запланированое задание (автоматически при конфигурации продукта), которое запускает сбор данных.
- По умолчанию отчет высылается раз в сутки (в 3 часа ночи) и содержит информацию по изменениям за прошедшие 24 часа. Однако частота и время отправки отчета могут быть легко изменены. Также отправка отчета может быть инициирована вручную в любой момент времени.
Работа программы:
Рассмотрим результаты работы продукта, а именно воспроизведем сценарий, описанный в начале данной статьи – отредактируем политику, примененную на подразделение главного офиса (central office) компании N:
- изменим минимальную длину пароля с 7 до 14 символов
- понизим максимальный срок действия пароля для с 45 дней до 20
- включим сложность пароля (meet password complexity requirements)
- разрешим пользователям устанавливать ПО
Итак, сбор данных завершен, и мы получили отчет следующего содержания:
Подробнее
Отчет наглядно отображает сделаные нами изменения. В нашем примере администратор John Smith по ошибке снизил максимальный срок действия пароля с 45 до 20 дней, из за чего у ряда пользователей срок действия пароля истек на 25 дней раньше, более того минимальная длина пароля увеличилась на 7 символов – представьте ситуацию, ожидающую пользователей?
John Smith сделал эти изменения после окончания рабочего дня в 8:13 вечера, а отчет был сгенерирован в три ночи. Тем самым утром администратор уже с утра был в курсе изменений и сумел их исправить до того, как они вылились в проблему.
Как вы можете видеть, в отчет включаются значения “до” и “после” по каждому изменению. Что очень удобно для оценки критичности того или иного изменения.
Сама структура отчета, построена по следующему принципу:
- Какой тип изменения был сделан (Change type)
- Когда изменение произошло (When Changed)
- Кто осуществил изменение (Who Changed)
- Где изменение произошло, т.е. на каком контролере домена (Where Changed)
- Какой объект груповой политики был изменен и какие именно изменения были сделаны (Group Policy object)
Для большей наглядности разные типы измений (добавление, удаление, модификация) маркируются разными цветами, что очень удобно и позволяет легко выделить критичный тип изменений (например, удаление) в отчете.
В нашем примере график отправки отчетов был настроен на отправку раз в сутки, и отчет был сгенерирован автоматически ночью, однако в случае, если Вы не хотите дожидаться отчета по расписанию, Вы можете инициировать его отправку вручную, нажав на кнопку Run для нужного Вам домена:
Отдельным пунктом следует отметить библиотеку отчетов, работающих на базе SQL Reporting Services (Advanced Reports):
Библиотека разбита на подкатегории отчетов, разработанных под конкретные цели и задачи аудита. Например, если нам необходимо поднять все изменения, произошедшие в групповых политиках за несколько месяцев, мы можем воспользоваться отчетом All Group Policy Changes, который отражает все сделаные изменения за указанный промежуток времени. Все отчеты также позволяют фильтровать выводимую информацию, например, в нашем отчете ниже мы вывели все изменения, сделанные пользователем Administrator.
В случае же если нас интересуют изменения какого-то конкретных параметров политик, мы можем воспользоваться соответствующим отчетом, например, изменения параметров политик, входящих в состав Административных шаблонов (Administrative Templates Changes):
Стоит отметить, что на каждый из отчетов, входящих в состав библиотеки, может быть настроена подписка, по которой отчет будет автоматически доставляться на указанные адреса электронной почты в соответствие с заданным графиком.
Отдельно стоит сказать про хранение данных аудита. В отличие от штатных инструментов, хранение данных организовано на двух уровнях. Обнаруженные изменения сохраняются в базе SQL-сервера – это первый уровень хранения данных. В то время как для хранения снимков груповых политик и сопуствующих данных используется второй уровень хранения –данные сохраняются в файловом хранилище. Данные хранилища могут быть в любой момент использованы для генерации изменений (за конкретный период) и загрузки изменения в базу SQL-сервера (например, в случае перехода на новый SQL сервер).
Срок хранения данных ограничивается лишь внутренними целями компании. Таким образом, можно быть уверенным, что информацию о любом изменении, осуществленном в прошлом, можно будет оперативно получить и проанализировать. Например, получить ретроспективную информацию об изменении политики паролей за прошедший год. Ряд таких отчетов требуется нормативами по информационной безопасности для отдельных отраслей.
Также стоит добавить, что продукт автоматически создает резервные копии групповых политик, которые в последствие могут быть использованы для отката сделанных изменений и восстановления политик.
Итог:
Быть в курсе изменений групповых политик необходимо. Оперативное разрешение проблем позволяет избежать как простоя в работе компании, так и возможных инцидентов нарушения информационной безопасности. И в этом помогает NetWrix Group Policy Change Reporter.
P.S. Программа выпускается в базовой бесплатной и полной версиях. Ознакомиться с их различиями и скачать программу Вы можете на нашем сайте.
Автор: NetWrixRU
