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

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

С чего начать: структура, а не политики

Самая частая ошибка — сразу кидаться настраивать политики. Сначала нужна структура организационных подразделений (OU), потому что именно к ним привязываются GPO. У меня получилось четыре корневых ветки:

domain.local
├── Администраторы      — учётки и группы админов, разделённые по ролям
├── Компьютеры
│   └── Клиентские устройства → по отделам
├── Пользователи        → те же отделы, что и у компьютеров
├── Серверы             → контроллеры домена, файловые, приложения, ИБ
└── Служебные объекты   → сервисные аккаунты, интеграции

Правила, которые сэкономили мне много времени:

  • Структура пользователей зеркалит структуру компьютеров. Добавили отдел — создаём подразделение в обеих ветках. Тогда политики для отдела всегда понятно куда привязывать.
  • Администраторы — отдельная ветка с разделением по ролям: администраторы домена, серверов, рабочих станций, GPO, безопасности. Это фундамент для модели разделения привилегий (tiering).
  • Отдельное OU для неопознанных компьютеров. Всё, что попало в домен в обход регламента, оказывается там, на виду, под отдельной политикой.

Порядок в групповых политиках

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

  1. GPO создаются только в контейнере «Объекты групповой политики», в OU — только ссылки. Так одна политика может применяться к нескольким подразделениям, и её не нужно искать по всему дереву.
  2. Префикс в имени показывает назначение и порядок:
00_  базовые настройки ПК и пользователей, обновления, время, Defender
10_  безопасность: пароли, аудит, файрвол, BitLocker, USB, LSA, AppLocker
11_  CIS Level 1, разбитый по разделам бенчмарка
20_  установка программ
21_  настройка программ
30_  права и доступ: локальные админы, запрет входа доменных админов на ПК, RDP
40_  политики конкретных отделов

В итоге получилось около 150 политик, и в каждой видно, к какой группе она относится. Для каждой политики в базе знаний есть заметка: что делает, куда привязана, кто может редактировать.

Установка ПО через GPO

Отдельный большой блок — 20_ и 21_: установка и настройка программ. Браузеры, офисные пакеты, архиваторы, мессенджеры, средства разработки для отдела разработки, графические редакторы для маркетинга — всё раскатывается политиками на нужные OU, а не руками. Плюсы:

  • новый сотрудник получает готовое рабочее место после входа в домен;
  • одинаковые версии и настройки у всех;
  • пользователям не нужны права администратора, чтобы что-то поставить, — а это главное условие для всего остального hardening.

Hardening по CIS Level 1

CIS Benchmark для Windows — это сотни параметров. Я не стал делать одну гигантскую политику, а разбил Level 1 по разделам бенчмарка — так проще разбираться, что сломалось, и откатывать по частям:

  • политика паролей и блокировки учётной записи после нескольких неудачных попыток;
  • назначение прав пользователя — кто может входить локально, по сети, через RDP, кто может отлаживать процессы;
  • права входа — запрет входа в систему для служебных и гостевых учёток;
  • политика аудита — что пишется в журнал безопасности (без этого SIEM слеп);
  • настройка служб — отключение ненужных и рискованных служб;
  • контроль учётных записей (UAC) и базовые параметры безопасности.

Как внедрять, чтобы ничего не сломать: сначала тестовое OU с парой компьютеров из разных отделов, неделя наблюдения, сбор жалоб, корректировка — и только потом привязка ко всем компьютерам. Особенно внимательно — с правами пользователя и службами: именно они ломают специфичный софт (бухгалтерию, клиент-банки, средства электронной подписи).

Что сверх бенчмарка

LAPS — уникальный пароль локального администратора

Одинаковый пароль локального администратора на всех ПК — подарок атакующему: скомпрометировал одну машину, получил все. LAPS генерирует на каждом компьютере свой пароль и хранит его в AD, доступ на чтение — только у нужной группы администраторов. Мои параметры:

  • длина 14 символов, все классы символов;
  • смена каждые 30 дней;
  • локальная учётка администратора переименована, встроенная отключена.

AppLocker — запрет запуска лишнего

Пользователи без прав администратора уже не могут ставить программы в Program Files, но могут запускать что угодно из своего профиля и Temp — именно оттуда стартует большая часть вредоносов. AppLocker закрывает это:

  • разрешено всё, что подписано доверенными издателями и лежит в системных каталогах;
  • запрещены скриптовые хосты (wscript, cscript) для обычных пользователей;
  • для легитимных программ, которые ставятся в профиль пользователя, — точечные исключения по пути или издателю.

Перед включением запрета обязательно поработайте в режиме «только аудит»: журнал AppLocker покажет, что именно было бы заблокировано, и вы соберёте список исключений без жалоб пользователей.

Защита учётных данных

  • LSA Protection (RunAsPPL) — процесс LSASS защищён от чтения памяти, что резко усложняет кражу хешей и паролей инструментами вроде mimikatz;
  • запрет сохранения паролей в Windows и отключение анонимного доступа;
  • доменные администраторы не могут входить на рабочие станции — их учётные данные не остаются в памяти пользовательских ПК.

Защита данных и периметра ПК

  • BitLocker — шифрование дисков, ключи восстановления хранятся в AD;
  • блокировка USB-накопителей и отключение автозапуска;
  • Windows Firewall с централизованными правилами;
  • SmartScreen и запрет Microsoft Store.

Аудит: доверяй, но проверяй

Политики со временем «плывут»: кто-то добавил исключение, кто-то создал учётку с бессрочным паролем, кто-то выдал права на OU. Поэтому я написал скрипт, который регулярно выгружает состояние домена — пользователей, группы, GPO и их привязки, права на OU, состояние репликации — и сравниваю выгрузки между собой. Что обычно всплывает при таком аудите:

  • учётные записи с флагом «пароль не истекает» — их нужно вычищать поэтапно, начиная с админских и сервисных;
  • слишком короткая минимальная длина пароля на уровне домена;
  • лишние участники привилегированных групп и учётки с признаком AdminCount=1, которые давно не админы;
  • избыточные права на OU (GenericAll, WriteDacl, WriteOwner) у нестандартных групп — потенциальный путь к эскалации привилегий;
  • отключённые и непривязанные политики, которые никто не помнит зачем создавал.

Каждая находка попадает в план с приоритетом, а изменения между выгрузками — в журнал.

Чеклист, по которому я проверяю домен

Короткая выжимка того, что стоит проверить в любом домене:

  • у пользователей нет прав локального администратора;
  • администраторы работают под обычной учёткой, а привилегированную используют только для администрирования;
  • учётки администраторов разделены по уровням: домен, серверы, рабочие станции — и не входят туда, где им не положено;
  • LAPS развёрнут везде, сетевой вход локальным администраторам запрещён;
  • сервисные учётки — gMSA, без паролей в скриптах и без интерактивного входа;
  • LM и NTLMv1 отключены, SMB Signing включён, на контроллерах — LDAP Signing и Channel Binding;
  • RunAsPPL включён, на дисках BitLocker;
  • блокировка учётной записи после неудачных попыток и оповещение о ней в SIEM.

Итоги

  • Начинайте со структуры OU и правил именования — без них через полгода политики превратятся в хаос.
  • Режьте CIS Benchmark на части и внедряйте через тестовое OU.
  • LAPS, AppLocker в режиме аудита, LSA Protection и запрет входа доменных админов на ПК дают максимум защиты на единицу усилий.
  • Домен нужно регулярно аудировать — политики и права «плывут» сами по себе.
  • Домен — это источник событий для SIEM: политика аудита из CIS как раз и делает видимыми перебор паролей, блокировки и подозрительные входы. Об этом — в статье «SOC на Wazuh с нуля».