Аудит групповых политик с NetWrix Group Policy Change Reporter

NetWrix Group Policy Change Reporter Обзор программы для аудита групповых

политик

NetWrix Group Policy Change Reporter – обзор программы для аудита групповых политик

2

СОДЕРЖАНИЕ

Почему Вам нужен аудит групповых политик? .......................................................................... 3

Штатные инструменты аудита групповых политики в Windows Server и их недостатки ....... 4

Характеристики решения для аудита групповых политик ........................................................ 5

Обзор NetWrix Group Policy Change Reporter ............................................................................. 5

Как программа работает? ......................................................................................................... 6

Пример работы программы ..................................................................................................... 7

Отчеты ......................................................................................................................................... 8

Хранение данных аудита ........................................................................................................ 11

Заключение .................................................................................................................................. 12

Скачать программу ...................................................................................................................... 13

О компании NetWrix ................................................................................................................... 13


3

Почему Вам нужен аудит групповых политик?

Представьте себе ситуацию, Вы руководите IT-службой крупной компании, у Вас несколько

доменов и несколько тысяч пользователей в Active Directory. В подчинении у Вас как минимум

несколько системных администраторов, каждый из которых выполняет свои обязанности.

Неожиданно сотрудники в одном из подразделений жалуются на то, что они никак не могут

придумать себе новые пароли после истечения срока действия старых – система не принимает

заново создаваемые пароли. После быстрого просмотра политики паролей соответсвующего

подразделения Вы понимаете, что длина и сложность пароля были изменены. Чтобы узнать, что

стало причиной, Вы обращаетесь к журналам событий и понимаете, что информации о том, когда

и кем была изменена политика паролей, нет – журналы уже перезаписались. Кто изменил

политику – останется тайной.

А вот еще один пример: администратор вдруг обнаруживает, что один из пользователей может

ставить без каких-либо проблем ПО на свою машину. И это при том, что в групповой политике для

OU, в которой состоит пользователь, такая установка была запрещена. Опять-таки информацию о

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

сквозь “шум” неинформативных данных.

Все это приводит к однозначному выводу IT-служба компании должна уделять внимание

происходящим в групповых политиках изменениях. Делать это необходимо, чтобы не допустить

как образования дыр в системе информационной безопасности (“какой там софт поставит

нерадивый пользователь?”), так и обеспечения непрерывности деятельности (когда 200 человек

одновременно не могут зайти на свои машины, так как не в состоянии придумать подходящий

пароль).

Только на практике выходит так, что контроль над изменениями групповых политик редко кто

практикует. И лишь при возникновении проблемы или обнаружении подозрительной активности

начинается поиск источника проблемы путем анализа журналов событий и опроса коллег.

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

случае с групповыми политиками можно не сомневаться, что администратор захотел бы знать, что

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

посыплется вал звонков от пользователей, чья работа теперь встала.


4

Штатные инструменты аудита групповых политики в Windows

Server и их недостатки

Чтобы оперативно расследовать и предупрежать подобных инцеденты, необходимо быть в курсе

происходящих в групповых политиках изменений. Можно попытаться решить эту проблему

штатными средствами.

Например, просматривать журналы событий вручную. Однако даже если мы заблоговременно

настроили аудит и позаботились о возможной перезаписи данных в журнале, просмотр событий

журнала случится только полсе поступления жалоб от пользователей. И поможет только в поисках

виновника, а не предотвращении проблемы.

В Windows Server 2008 R2 процесс отслеживания изменений (и предупреждения связаных с ними

проблем) становится немного проще. Наряду с более удобным просмотрщиком событий (Event

Viewer) появилась возможность настроить почтовые оповещения на определенные события, что

позволяет быть на шаг впереди, ведь теперь присутствует возможность исправить ситуацию до

того, как она докатится до конечного пользователя.

Однако даже с расширением штатных возможностей аудита в Windows Server 2008 R2 возникают

сразу несколько отягчающих факторов. Какие события выбрать? Как оперативно фильтровать их

содержимое, когда в событиях с одинаковым номером может содержаться информация о разных

обьектах (например, событие 4662 генерируется как для изменений груповых политик, так и для

других обьктов в Active Directory)? События содержат только GUID, а не имя конкретной групповой

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

опознания GUID’a. А что если таких событий десятки?

Как видно из примеров, приведенных выше, штатная система аудита далека от идеальной, и

отдельным моментом также стоит отметить отображение значений “до” и “после” по каждому

изменению. Их попросту не существует. Получается, что в случае с групповыми политиками

администратор должен держать их содержимое в голове или выполнять периодически экспорт

политик и затем сравнивать вручную, чем же они отличаются.

Конечно использование штатной системы аудита дает определенный контроль над

происходящими изменениями, но все же избежать следующих недостатков не удастся:

1. Анализ информации об изменении в событиях достаточно трудоемок, требует

определенных знаний для восприятия и не может быть представлен в исходном виде тем

людям, которые не слишком хорошо разбираются в данных вопросах (например, высшему

руководству)

2. Анализ журналов безопасности должен осуществляться вручную на каждом контроллере

домена

3. Отсутствует консолидация данных

4. Перезапись журналов – возможна потеря событий


5

5. Фиксируется лишь сам факт изменения, отсутствует очевидная информация о том, что же

именно изменилось

И многое другое…

Отчасти описанные выше проблемы позволяют решить различные методы обработки журналов

(начиная от скриптов и утилит, которые позволяются анализировать логи, до

специализированных SIEM-решений). Однако и они не решают всех описанных проблем.

Например, в них не приводятся значения “до” и “после» по каждому изменению, в результате

чего администратор должен вручную создавать и поддерживать в актуальном состоянии архив с

текущими настройками груповых политик.

Характеристики решения для аудита групповых политик

Недостатки штатной системы аудита и растущие потребности в управлении IT-инфраструктурой

приводят к возникновению сторонних специализированных решений для аудита изменений.

Исходя из описанных выше недостатков штатной системы определим, какие характеристики

лежат в основе решений для аудита групповых политик:

Отображение изменяемого значения обекта в виде “до” и “после” изменения,

Автоматическая генерация отчетов об произошедших изменениях за конкретный

промежуток времени (например, за каждые 12 часов или сутки),

Возможность фильтрации данных и получения информации об изменениях отдельных

политик.

Обязательно наглядность представляемой информации (кто, что, где и когда изменил),

Возможность хранить данные аудита в специализированном хранилище (в базе данных

SQL, в архиве на файл-сервере или в обоих местах сразу)

Резервирование и восстановление групповых политик.

Обзор NetWrix Group Policy Change Reporter

Что же представляет из себя решение NetWrix Group Policy Change Reporter, осуществляющее

аудит изменений групповых политик? Прежде всего, расскажем как продукт работет.


6

Как программа работает?

Во время сбора даных продукт делает снимки текущего состояния груповых политик и собирает

информацию из журналов безопасности со всех контроллеров домена, в котором производится

аудит.

После сбора данных они складываются в указанное место хранения (например, на выделенный

файл-сервер), после чего осуществляется их анализ, Обнаруженные изменения загружаются в базу

данных (в случае если она подключена к продукту), а также высылаются в виде отчета на

указанные адреса электронной почты.

Инициализация сбора даных основана на планировщике заданий, в котором создается

запланированое задание (автоматически при конфигурации продукта), которое запускает сбор

данных.

По умолчанию отчет высылается раз в сутки (в 3 часа ночи) и содержит информацию по

изменениям за прошедшие 24 часа. Однако частота и время отправки отчета могут быть легко

изменены. Также отправка отчета может быть инициирована вручную в любой момент времени.


7

Пример работы программы

Рассмотрим результаты работы продукта, а именно воспроизведем сценарий, описанный в начале

данной статьи – отредактируем политику, примененную на подразделение главного офиса (central

office) компании N:

- изменим минимальную длину пароля с 7 до 14 символов

- понизим максимальный срок действия пароля для с 45 дней до 20

- включим сложность пароля (meet password complexity requirements)

- разрешим пользователям устанавливать ПО .

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

Отчет наглядно отображает сделаные нами изменения. В нашем примере администратор John

Smith по ошибке снизил максимальный срок действия пароля с 45 до 20 дней, из за чего у ряда

пользователей срок действия пароля истек на 25 дней раньше, более того минимальная длина

пароля увеличилась на 7 символов – представьте ситуацию, ожидающую пользователей?

John Smith сделал эти изменения после окончания рабочего дня в 8:13 вечера, а отчет был

сгенерирован в три ночи. Тем самым утром администратор уже с утра был в курсе изменений и

сумел их исправить до того, как они вылились в проблему.

Как вы можете видеть, в отчет включаются значения “до” и “после” по каждому изменению. Что

очень удобно для оценки критичности того или иного изменения.


8

Отчеты

Сама структуру отчета, построена по следующему принципу:

Какой тип изменения был сделан (Change type)

Когда изменение произошло (When Changed)

Кто осуществил изменение (Who Changed)

Где изменение произошло, т.е. на каком контролере домена (Where Changed)

Какой объект груповой политики был изменен и какие именно изменения были сделаны

(Group Policy object)

Для большей наглядности разные типы измений (добвление, удаление, модификация)

маркируются разными цветами, что очень удобно и позволяет легко выделить критичный тип

изменений (например, удаление) в отчете.

В нашем примере график отправки отчетов был настроен на отправку раз в сутки, и отчет был

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

расписанию, Вы можете инициировать его отправку вручную, нажав на кнопку Run для нужного

Вам домена:


9

Отдельным пунктом следует отметить библиотеку отчетов, работающих на базе SQL Reporting

Services (Advanced Reports):

Библиотека разбита на подкатегории отчетов, разработанных под конкретные цели и задачи

аудита. Например, если нам необходимо поднять все изменения, произошедшие в групповых

политиках за несколько месяцев, мы можем воспользоваться отчетом All Group Policy Changes,

который отражает все сделаные изменения за указанный промежуток времени. Все отчеты также

позволяют фильтровать выводимую информацию, например, в нашем отчете ниже мы вывели все

изменения, сделанные пользователем Administrator.


10

В случае же если нас интересуют изменения какого-то конкретных параметров политик, мы

можем воспользоваться соответствующим отчетом, например, изменения параметров политик,

входящих в состав Административных шаблонов (Administrative Templates Changes):


11

Стоит отметить, что на каждый из отчетов, входящих в состав библиотеки, может быть настроена

подписка, по которой отчет будет автоматически доставляться на указанные адреса электронной

почты в соответствие с заданным графиком.

Хранение данных аудита

Отдельно стоит сказать про хранение данных аудита. В отличие от штатных инструментов,

хранение данных организовано на двух уровнях. Обнаруженные изменения сохраняются в базе

SQL-сервера – это первый уровень хранения данных. В то время как для хранения снимков

груповых политик и сопуствующих данных используется второй уровень хранения –данные

сохраняются в файловом хранилище. Данные хранилища могут быть в любой момент

использованы для генерации изменений (за конкретный период) и загрузки изменения в базу

SQL-сервера (например, в случае перехода на новый SQL сервер).

Срок хранения данных ограничивается лишь внутренними целями компании. Таким образом,

можно быть уверенным, что информацию о любом изменении, осуществленном в прошлом,

можно будет оперативно получить и проанализировать. Например, получить ретроспективную

информацию об изменении политики паролей за прошедший год. Ряд таких отчетов требуется

нормативами по информационной безопасности для отдельных отраслей.


12

Также стоит добавить, что продукт автоматически создает резервные копии групповых политик,

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

восстановления политик.

Заключение

Быть в курсе изменений групповых политик необходимо. Оперативное разрешение проблем

позволяет избежать как простоя в работе компании, так и возможных инцидентов нарушения

информационной безопасности. И в этом помогает NetWrix Group Policy Change Reporter.


13

Скачать программу

Программа доступна для скачивания на сайте компании NetWrix

www.netwrix.com/ru/group_policy_auditing_change_reporting_freeware.html

О компании NetWrix

NetWrix Corporation – высокоспециализированный разработчик программных решений для

аудита изменений IT-инфраструктуры. Аудит изменений – ключевая компетенция компании

NetWrix, и никто из других разработчиков настолько не сфокусирован на этой области. NetWrix

предлагает решения для аудита изменений IT-инфраструктуры, которые были признаны

профессионалами по всему миру, о чем свидетельствуют многочисленные награды компании.

Основанная в 2006 году, компания занимает первое место в сфере аудита изменений, и тысячи

удовлетворенных клиентов по всему миру тому подтверждение. Штаб-квартира компании

находится в США, Нью-Джерси, Парамус, а ее региональные подразделения в Лос-Анжелесе,

Майами, Тампе, Бостоне, Санкт-Петербурге и Великобритании.

http://www.netwrix.com/ru/group_policy_auditing_change_reporting_freeware.html

http://www.netwrix.com/ru/group_policy_auditing_change_reporting_freeware.html

Technology

Аудит групповых политик с NetWrix Group Policy Change Reporter