«Безопасность в ИТ — это не про железки и софт, это про доверие. Вы даёте человеку ключи от королевства и надеетесь, что он не отопрёт двери грабителям по ошибке. Разделение привилегий — это не просто галочка для ФСТЭК, а отказ от этой слепой надежды. Это технический механизм, который заменяет доверие контролируемой необходимостью.»
Принцип разделения учётных записей: две жизни администратора
Серьёзная практика начинается с простого правила: у каждого инженера должно быть как минимум две личности в корпоративной сети. Первая — обычный сотрудник с почтой, браузером и офисным пакетом. Вторая — администратор, появляющийся строго по необходимости, как спецназ.
- Обычная учётная запись используется для всего: чтения почты, работы с документами, звонков, доступа к внутренним порталам. Её права минимальны, а компрометация не приводит к катастрофе.
- Привилегированная запись активируется только для конкретных задач: настройки политик, обслуживания серверов, управления инфраструктурой. После выполнения работы сессия завершается. Для этой учётки браузер и почтовый клиент должны быть технически заблокированы.
Ключевое отличие не в пароле, а в контексте использования. Если вы заходите в почту с правами Domain Admin, вы уже проиграли — один фишинговый письмо может стать билетом для злоумышленника во всю сеть.
Иерархия привилегий в Active Directory: кто чем командует
Active Directory создавалась в эпоху, когда разделению прав не уделяли такого внимания. В результате в ней сохранились группы с колоссальной силой, унаследованные от прошлого. Понимание этой иерархии критично для грамотного делегирования.
| Группа / роль | Область влияния | Типичные задачи | Правила обращения |
|---|---|---|---|
| Enterprise Admins | Весь лес доменов (Forest) | Создание и удаление доменов, доверие между лесами, управление схемой на уровне леса. | Учётные данные должны храниться физически (например, в сейфе). Используются раз в несколько лет для глобальных изменений. Членство должно быть пустым по умолчанию. |
| Schema Admins | Схема данных всего леса | Изменение классов и атрибутов объектов в AD (например, добавление поля в объект «пользователь»). | Аналогично Enterprise Admins. Изменение схемы необратимо и может сломать совместимость. Практически не используется. |
| Domain Admins | Конкретный домен | Полный контроль над всеми объектами домена: пользователи, компьютеры, групповые политики (GPO). | Основная группа для управления инфраструктурой. Но членство должно быть минимальным. Для рутинных задач создаются делегированные роли. |
| Administrators на контроллере домена | Конкретный сервер (Domain Controller) | Локальное администрирование контроллера домена. | По умолчанию включает Domain Admins. Опасная группа, так как даёт прямой доступ к сердцу AD. Нужно вычищать из неё все лишние учётки. |
| Встроенные операторские группы (Server Operators, Backup Operators) | Домен или отдельные серверы | Запуск служб, управление ресурсами, выполнение резервного копирования. | Полезны для делегирования. Например, Backup Operators могут восстанавливать файлы, но не имеют прав на изменение системных настроек. Их возможности часто недооценивают. |
Ошибка, которую совершают многие: добавляют инженера поддержки в группу Domain Admins, чтобы он мог сбросить пароль. Это всё равно что давать мастер-ключ от всего офиса уборщику, чтобы он мог зайти в кладовку. Вместо этого нужно создавать отдельные группы с делегированными правами только на сброс паролей в определённом подразделении (OU).
Почему «принцип наименьших привилегий» — это не бюрократия
Этот принцип часто воспринимают как формальность, замедляющую работу. На деле он работает как механизм сдерживания ошибок и злонамеренных действий. Если у учетной записи нет прав на удаление учёток, то даже если её скомпрометируют или администратор совершит ошибку в скрипте, массового удаления пользователей не произойдёт. Это недоверие, встроенное в систему, которое в итоге защищает всех, включая самого администратора.
Техническая реализация: от политик до PAM
Теория бесполезна без конкретных настроек. Вот практические шаги по внедрению разделения.
1. Создание и изоляция административных учёток
Названия вроде «ivanov_adm» или «adm.ivanov» — это стандарт. Но важнее парольная политика: для таких учёток должен действовать отдельный, более строгий Password Policy Objects (FGPP) с длиной пароля от 16 символов. Эти учётки должны быть явно исключены из политик блокировки после нескольких неудачных попыток входа, чтобы предотвратить DoS-атаку на админ-аккаунт.
2. Жёсткие ограничения через групповые политики (GPO)
Административная учётная запись — это инструмент, а не рабочее место. Её нужно ограничить технически.
Конфигурация компьютера / Политики / Настройки Windows / Параметры безопасности:
- Отклонить вход в систему через службы удаленных рабочих столов: Группа "Администраторы домена"
- Запретить вход в систему с помощью пакетного задания: Группа "Администраторы домена"
- Разрешить вход в систему только на определённых рабочих станциях (например, выделенные "админ-станции")
Конфигурация пользователя / Политики / Административные шаблоны / Система:
- Запуск только указанных приложений Windows: Включить, список разрешённых .exe (mmc.exe, powershell.exe и т.д.)
3. Контроль сессий с помощью PAM
Системы управления привилегированным доступом (Privileged Access Management) — следующий уровень. Они работают по принципу «just-in-time»: права выдаются на короткий сеанс по утверждённому запросу. Все действия в сессии записываются на видео (keystroke logging + screen recording). Пароль от админ-учётки хранится не в голове сотрудника, а в защищённом хранилище (вейлере), и система сама подставляет его в RDP-сессию. Это устраняет риски, связанные с человеческим фактором, и предоставляет бесспорный аудиторский след.
4. Многофакторная аутентификация (MFA) — обязательный минимум
Для любой привилегированной сессии MFA не должна быть опцией. Это правило, которое перешло из рекомендаций в обязательные требования. Причём второй фактор должен быть аппаратным (токен, смарт-карта) или биометрическим. Push-уведомление на тот же телефон, которым пользуются для личной почты, — уже недостаточный уровень для критичной инфраструктуры.
Что происходит, когда правилами пренебрегают: два сценария
Сценарий «Как надо»
Инженер получает фишинговое письмо на свою обычную рабочую почту. Переходит по ссылке, и на компьютер загружается вредоносный код. Скрипт пытается поднять привилегии и обнаружить другие учётки в системе, но находит только сессию обычного пользователя. Он может украсть документы или зашифровать файлы на локальном диске, но не может попасть на файловый сервер, в домен или на критичные системы. Инцидент локализован на одной рабочей станции. Ущерб — несколько часов простоя и переустановка ОС.
Сценарий «Как бывает»
Тот же инженер по привычке проверяет почту, войдя в систему с правами локального администратора (или, что хуже, Domain Admin). Тот же вредоносный код запускается уже в контексте высоких привилегий. Он без препятствий крадёт хэши паролей из памяти (LSASS), находит сохранённые пароли в менеджере, использует их для горизонтального перемещения по сети. Через несколько часов злоумышленники получают доступ к контроллерам домена, шифруют резервные копии и выставляют многомиллионный выкуп. Восстановление занимает недели, а полное доверие к инфраструктуре уже подорвано.
Эффект от внедрения разделения привилегий — не в предотвращении всех атак, а в резком снижении их разрушительного потенциала. Это превращает потенциальный кризис всего предприятия в управляемый инцидент уровня отдела ИТ.