Аудит GPO в Active Directory: 47 политик, 12 мёртвых, три ослабляют пароли

Когда клиент пришёл с запросом на аудит в рамках подготовки к ISO 27001 и приведению в соответствие с 152-ФЗ, мы ожидали стандартного набора: проверить права доступа, журналирование, сегментацию. Про групповые политики в задании отдельно не было ни слова. Но именно там обнаружилось самое интересное - в хорошем смысле неожиданное.

Зачем вообще смотреть на GPO

ISO 27001 требует контроля конфигурации и задокументированного управления политиками безопасности. 152-ФЗ - технических мер защиты ИСПДн. Оба стандарта сходятся в одном: не только «что настроено», но и «насколько это реально применяется». GPO в Active Directory - один из центральных механизмов раздачи конфигурации на пользователей и компьютеры. Если с ним беспорядок, остальные технические меры теряют опору.

Мы уже разбирали права доступа в AD - там картина была показательной. С GPO оказалось не лучше.

Что нашли

Инвентаризацию объектов групповой политики сделали через GPMC - Group Policy Management Console. Сначала простой экспорт: список всех GPO в домене с их статусом и привязками. Результат: 47 политик.

Дальше - проверка каждой на предмет link'ов: к каким OU, сайтам или домену применяется данная политика. И вот тут начались откровения.

Двенадцать политик не были привязаны ни к одному объекту AD. Висели в домене как заброшенные файлы на рабочем столе - есть, занимают место, никуда не применяются. Большинство из них - артефакты проектов двух-трёхлетней давности: кто-то создавал GPO под конкретную задачу, задача решилась или умерла, а политику никто не почистил.

Три из этих двенадцати привлекли особое внимание. Они содержали настройки парольной политики - и настройки мягкие. Минимальная длина пароля меньше стандартного, отключённое требование сложности, увеличенный срок действия. Судя по датам создания, политики были сделаны для унаследованных OU, которые потом переструктурировали. OU переехали в другую ветку или были удалены; GPO остались. Пока они не привязаны - не применяются. Но привязать их обратно - дело одного клика.

Дополнительно нашли несколько политик с конфликтующими настройками, применённых к пересекающимся OU. В одном случае две политики с разными значениями ScreenSaver timeout применялись к одной и той же OU с разными приоритетами - что побеждает, зависело от порядка обработки, и никто из ИТ-отдела клиента это не отслеживал осознанно.

Как разбирались

Подход был прямолинейным. Для каждой из 47 политик:

• Статус применения - есть ли хотя бы один живой link.
• Содержимое - какие настройки реально задаёт политика. Не только название, а Settings Report из GPMC.
• Целевые объекты - если link есть, то на какие OU, и актуальны ли они.
• Владелец - кто создавал, когда последний раз редактировалось. Атрибуты GPO это хранят.

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

Что сделали

Чистка прошла в два этапа. Сначала - документирование: для каждой из 47 политик записали назначение, целевые объекты, кто ответственный с точки зрения ИТ-отдела клиента. Это заняло больше времени, чем сама уборка, но без документирования чистка не имеет смысла - картина вернётся к исходной при первом же не задокументированном изменении.

Потом - удаление двенадцати мёртвых политик. Три с парольными настройками удалили в первую очередь. Остальные девять - после согласования с клиентом: несколько из них описывали вещи, которые теоретически ещё могли понадобиться. Создали архивный документ с экспортом их настроек - на случай «а вдруг пригодится».

Конфликтующие политики разрулили через явную расстановку приоритетов и документирование логики: какая политика над какой стоит и почему.

Наблюдение

У клиента нормальный ИТ-отдел. Люди знают своё дело. GPO-помойка - не следствие халтуры, а нормальное накопление технического долга в живой среде: проекты приходят, уходят, инфраструктура меняется, а административные объекты остаются. Без периодического аудита это неизбежно.

Второй момент: 47 GPO для компании этого размера - многовато. Это само по себе сигнал. Чем больше политик, тем сложнее контролировать их взаимодействие, тем выше вероятность конфликтов и тем сложнее объяснить аудитору, что реально применяется и почему.

ISO 27001 потребует не только актуального состояния, но и процесса: кто создаёт новые GPO, кто их ревьюит, как удаляются ненужные. Это следующий шаг, который клиент сейчас прорабатывает.

В рамках аудита информационной безопасности GPO-ревью мы теперь включаем в стандартный объём при работе с Windows-инфраструктурой. Не потому что хочется перестраховаться, а потому что второй раз убедились: там почти всегда есть что найти.