Трёхуровневая модель администрирования Active Directory: защита Domain Admins от компрометации

Меня зовут Семёнов Евгений Сергеевич, я возглавляю АйТи Фреш. Скажу вам честно: по нашим данным, на 8 из 10 доменов в Москве, которые мы проверяем, учётка Domain Admin используется для всего подряд. Представьте: ею заходят на сервер, работают на обычном ПК, проверяют почту, а порой даже запускают браузер! С точки зрения безопасности, это, конечно, катастрофа. Ещё в 2014 году Microsoft выпустила свою рекомендацию по разделению административного доступа на три уровня — так называемую Tiered Administration Model. Сегодня я хочу рассказать, как мы внедряем её в стандартной корпоративной сети, рассчитанной до 50 рабочих мест, при этом не тратясь на дорогие решения.

Почему обычная схема «одна админская учётка на всё» опасна

Давайте представим стандартный сценарий атаки на корпоративную сеть, каким он будет в 2026 году. Пользователю на почту приходит фишинговое письмо, а внутри — Word-документ с макросом. Он его открывает. Антивирус при этом молчит — увы, Cobalt Strike обновляется быстрее любых сигнатур. И вот на этом ПК уже сидит агент удалённого доступа. Что дальше? Атакующий терпеливо ждёт, пока на этот компьютер зайдёт администратор, например, чтобы починить принтер. Как только Domain Admin входит, его NTLM-хеш и Kerberos-тикеты оседают прямо в памяти LSASS. Mimikatz легко вытаскивает все эти секреты, и буквально через 5 минут у атакующего уже есть учётка Domain Admin со всеми правами. Жутко, правда?

И это, поверьте мне, не просто теория. Все крупные шифровальщики в 2024–2025 годах работали именно по такой схеме: сначала проникали через рядового пользователя, затем повышали свои права до Domain Admin за счёт украденного хеша, а потом шифровали все серверы через групповую политику или WMI. И вот тут-то Tier-модель и вступает в игру! Она эту цепочку попросту ломает: даже если атакующий поймает учётку обычного админа, он всё равно не сможет получить доступ к контроллеру домена.

Архитектура трёх уровней по Microsoft

Вот главный принцип, который мы используем: учётная запись уровня N имеет право управлять оборудованием своего уровня N и всем, что ниже, но она НИКОГДА не сможет залогиниться на оборудование более высокого уровня. То есть, представьте: учётка Tier 0 (она же Domain Admin) может входить на контроллеры домена (DC) и на серверы. Учётка Tier 1 (Server Admin) — только на серверы и рабочие станции. А вот Tier 2 (Workstation Admin) — исключительно на рабочие станции наших пользователей.

А что делать, если сисадмину нужно работать сразу с разными уровнями? Мы советуем ему использовать под каждый уровень свою отдельную учётную запись. Вот представьте: один и тот же человек по сути пользуется тремя аккаунтами — ivanov-t0, ivanov-t1, ivanov-t2. И, конечно, у него есть ещё обычный ivanov для повседневных задач, вроде проверки почты, работы с документами или простого выхода в интернет через браузер.

Шаг 1. Создаём OU-структуру под Tier-модель

Прежде чем городить групповые политики, наводим порядок в дереве AD. Стандартная структура:

# PowerShell на DC
$base = "DC=corp,DC=example,DC=ru"

New-ADOrganizationalUnit -Name "Tier 0" -Path $base
New-ADOrganizationalUnit -Name "Servers" -Path "OU=Tier 0,$base"
New-ADOrganizationalUnit -Name "Admins" -Path "OU=Tier 0,$base"
New-ADOrganizationalUnit -Name "Groups" -Path "OU=Tier 0,$base"

New-ADOrganizationalUnit -Name "Tier 1" -Path $base
New-ADOrganizationalUnit -Name "Servers" -Path "OU=Tier 1,$base"
New-ADOrganizationalUnit -Name "Admins" -Path "OU=Tier 1,$base"
New-ADOrganizationalUnit -Name "Groups" -Path "OU=Tier 1,$base"

New-ADOrganizationalUnit -Name "Tier 2" -Path $base
New-ADOrganizationalUnit -Name "Workstations" -Path "OU=Tier 2,$base"
New-ADOrganizationalUnit -Name "Admins" -Path "OU=Tier 2,$base"
New-ADOrganizationalUnit -Name "Groups" -Path "OU=Tier 2,$base"

Перемещаем существующие объекты: контроллеры — в Tier 0/Servers, файловые серверы и серверы 1С — в Tier 1/Servers, рабочие станции — в Tier 2/Workstations.

Шаг 2. Создаём раздельные административные учётки

Что мы делаем дальше? Для каждого штатного администратора мы создаём по три (или две, если ваша команда совсем небольшая) дополнительные учётные записи. Вот они:

$ivanov = "Иванов Пётр Сергеевич"

# Tier 0 - для работы с DC и AD
New-ADUser -Name "ivanov-t0" -DisplayName "$ivanov [Tier 0]" `
  -Path "OU=Admins,OU=Tier 0,$base" `
  -AccountPassword (Read-Host -AsSecureString "Password T0") `
  -Enabled $true -CannotChangePassword:$false `
  -PasswordNeverExpires:$false

# Tier 1 - для серверов
New-ADUser -Name "ivanov-t1" -DisplayName "$ivanov [Tier 1]" `
  -Path "OU=Admins,OU=Tier 1,$base" `
  -AccountPassword (Read-Host -AsSecureString "Password T1") `
  -Enabled $true

# Tier 2 - для рабочих станций
New-ADUser -Name "ivanov-t2" -DisplayName "$ivanov [Tier 2]" `
  -Path "OU=Admins,OU=Tier 2,$base" `
  -AccountPassword (Read-Host -AsSecureString "Password T2") `
  -Enabled $true

Дальше — добавляем учётки в группы. Tier 0 — в Domain Admins. Tier 1 — в группу с правами локального администратора на серверах (создаётся отдельно). Tier 2 — в группу локальных админов рабочих станций.

И вот тут я хочу особо подчеркнуть: это критически важно! Задайте сложные, уникальные пароли для каждой, абсолютно каждой учётки. Никаких «один пароль на всё» — это просто табу! В больших сетях мы, конечно, решаем эту задачу с помощью LAPS-подобных инструментов, например, PAM Workflows в SUBPAM или Azure AD PIM. А вот в малых компаниях каждый админ просто использует свой личный менеджер паролей.

Шаг 3. GPO-ограничения «Deny logon»

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

Первая GPO называется «Tier 0 Deny on Tier 1+2». Мы привязываем её к организационным единицам OU Tier 1/Servers и Tier 2/Workstations:

Computer Configuration → Policies → Windows Settings → Security Settings →
  Local Policies → User Rights Assignment

Deny log on locally:
  - Domain Admins
  - Enterprise Admins
  - Schema Admins
  - GG-Tier0-Admins (своя группа Tier 0 учёток)

Deny log on through Remote Desktop Services:
  - те же группы

Deny access to this computer from the network:
  - те же группы

Deny log on as a batch job:
  - те же группы

Deny log on as a service:
  - те же группы

GPO «Tier 1 Deny on Tier 2 and Tier 0» — привязываем к OU Tier 0/Servers и Tier 2/Workstations:

Deny log on locally / Remote Desktop / Network:
  - GG-Tier1-Admins

GPO «Tier 2 Deny on Tier 0 and Tier 1» — привязываем к OU Tier 0/Servers и Tier 1/Servers:

Deny log on locally / Remote Desktop / Network:
  - GG-Tier2-Admins

После применения политик попытка логина админа Tier 2 на сервер вернёт ошибку «The local policy of this system does not permit you to log on interactively». Это правильно. Принцип «least privilege» в действии.

Шаг 4. PAW — Privileged Access Workstation

Итак, что такое PAW? Это сокращение для отдельной, максимально защищённой рабочей станции. Именно с неё мы выполняем все операции уровня Tier 0 и Tier 1. Самое главное: на ней нет никакой почты. Нет браузера для выхода в интернет. Нет мессенджеров. И даже офисных программ! Только самое необходимое: AD Tools, RDP, PowerShell ISE и менеджер паролей. Наша цель здесь предельно проста — полностью отрезать саму возможность фишинга и любого заражения с этой машины.

В малой компании PAW — это виртуальная машина Hyper-V на ноутбуке админа. В средней — отдельный физический ПК в серверной, к которому админ подходит для работы с DC. В крупной — выделенная зона с физической изоляцией и контролем доступа.

Минимальная конфигурация PAW:

• Чистая установка Windows 10/11 LTSC, без офиса и сторонних программ.
• Отдельный VLAN или хотя бы отдельные firewall-правила: разрешён доступ только к DC и серверным VLAN, запрещены обращения в интернет (кроме Windows Update через WSUS).
• Локальный администратор — отдельная сложная учётка, не Domain Admin.
• Включён Credential Guard и Device Guard, BitLocker, защита от LSASS-чтения через WDAC-политику.
• Логирование всех действий через Sysmon + централизованный сбор в Wazuh/Splunk.
• Запрет USB-устройств кроме клавиатуры и мыши через GPO.

Шаг 5. Дополнительная закалка Tier 0

Помимо разделения по уровням, для Tier 0 (контроллеры домена) нужны дополнительные меры:

• Protected Users group. Все учётные записи Tier 0 включаем в Protected Users — группа отключает кеширование креденшелов на удалённых машинах, NTLM, Kerberos delegation, DES/RC4.
• Authentication Policies and Silos. Создаём Authentication Silo для Tier 0, привязываем учётки и компьютеры — это ограничивает, на каких машинах учётка может вообще аутентифицироваться.
• SMB signing и LDAP signing — обязательны на DC, чтобы исключить man-in-the-middle.
• Отключение SMBv1, NTLMv1, LM hash storage — устаревшие протоколы должны быть выключены везде.
• Регулярная ротация krbtgt-пароля. Раз в 6 месяцев — одной командой Reset-KrbTgtKey -Server DC01 с дальнейшей повторной заменой через сутки. Это инвалидирует Golden Ticket.

Реальный кейс: внедрение Tier-модели в страховой компании

Хочу рассказать вам об одном случае. Весной 2025 года к нам обратился клиент — это была региональная страховая компания. У них было 75 рабочих мест, 6 серверов и 2 контроллера домена. После проверки от регулятора, которая проводилась по приказу ФСТЭК, им срочно потребовалось привести администрирование AD к лучшим мировым практикам. До того, как мы приехали, у них было 4 учётки Domain Admin, которыми, представьте, пользовались для всего подряд: от установки обычных принтеров до правки прав доступа на корпоративном файл-сервере.

За пять рабочих дней мы:

• Перестроили OU-структуру под три уровня.
• Создали 12 разделённых административных учёток (3 уровня × 4 админа).
• Настроили GPO с deny logon политиками.
• Подняли отдельную виртуальную машину PAW для работы с DC, доступ через Remote Desktop с двух выделенных ноутбуков IT-руководителя.
• Включили все Tier 0 учётки в Protected Users.
• Прописали процедуры эскалации в инструкции для админов.
• Провели обучение IT-команды (3 часа теории + практика).

Я помню, в первую неделю мы получили 6 жалоб со словами «не могу залогиниться». И что самое главное — все эти жалобы были абсолютно правильными! Админы пытались войти под учёткой Tier 0 на ПК пользователя, а модель, как вы понимаете, работала именно так, как было задумано. А вот в долгосрочной перспективе IT-руководитель компании заметил, что админам стало гораздо проще понимать, что именно они делают. Ведь теперь каждое действие требует осознанного выбора правильной учётки. Кстати, стоимость наших работ составила 145 000 руб. за внедрение и сопровождение в течение месяца.

Грабли при внедрении Tier-модели

За много лет внедрений мы собрали список типовых ошибок:

• Слишком жёсткие deny с самого начала. Приведут к тому, что админы не смогут зайти даже к легитимным задачам. Внедряйте поэтапно: сначала аудит логинов, потом разделение учёток, потом deny.
• Забыть про сервисные учётки. SCCM, Veeam, мониторинг — всё это с правами на серверах. Для них надо создавать отдельные группы и не мешать с интерактивными админами.
• PAW без обновлений. Чистый PAW без интернета — частая ошибка: его забывают обновлять. Настройте WSUS-канал или периодические патчи через флешку с гипервизора.
• Один пароль на все Tier-учётки. Бесполезно. Каждая учётка должна иметь уникальный сложный пароль, лучше — храниться в менеджере паролей с MFA.
• Игнорирование локальных админов на ПК. Если у каждого пользователя пароль локального администратора одинаковый — атакующий, попавший на одну машину, идёт по всем. LAPS обязателен.

Минимальный вариант для офиса 30–50 рабочих мест

Но не пугайтесь, полная PAW-инфраструктура — это, конечно, больше для регулируемых организаций. А вот в типичной коммерческой компании, где 30–50 рабочих мест, я обычно внедряю немного упрощённую модель. Вот как она выглядит:

1. Создаются две доп.учётки на админа: ivanov-t0 для DC и ivanov-t1 для серверов и рабочих станций.
2. Поднимается одна виртуальная Windows 10 на ноутбуке админа — это «полу-PAW», с которой выполняется работа с DC.
3. Внедряются deny logon GPO для Domain Admins на всё, что не контроллер домена.
4. Все Domain Admins добавляются в Protected Users.
5. Раз в 6 месяцев — ротация krbtgt-пароля.

И этого, поверьте, вполне достаточно, чтобы, даже если пользовательский ПК будет скомпрометирован, атакующий всё равно не смог получить доступ к вашему домену. Стоимость внедрения такой модели обычно колеблется от 35 до 60 тыс. руб. за все работы, при этом не требуется покупать никакого дополнительного ПО.

FAQ — частые вопросы по Tiered Admin Model

Зачем нужна трёхуровневая модель администрирования?

Tier-модель защищает привилегированные учётные записи от компрометации через скомпрометированные рабочие станции. Если админ заходит на заражённый ПК с правами Domain Admin, его хеш утекает и атакующий получает полный контроль над доменом. Tiered Admin Model изолирует уровни доступа.

Что такое Tier 0, 1 и 2?

Tier 0 — контроллеры домена, AD CS, корневые серверы безопасности. Tier 1 — серверы приложений, баз данных, файловые. Tier 2 — рабочие станции пользователей. Учётка одного уровня не должна логиниться на оборудование другого уровня.

Что такое PAW и зачем оно нужно?

PAW (Privileged Access Workstation) — изолированная защищённая рабочая станция, с которой админ выполняет привилегированные действия. На ней нет почты, браузера, мессенджеров — только инструменты администрирования. Минимизирует риск компрометации админских учёток.

Можно ли внедрить Tier-модель на маленькой компании?

Да, упрощённая версия работает даже на 30–50 рабочих местах: отдельные административные учётки, отдельная виртуальная машина для администрирования, GPO с ограничением логина. Полный PAW с физической изоляцией нужен только для крупных и регулируемых организаций.

Как ограничить логин Domain Admin на обычные ПК?

Через GPO «Deny log on locally» и «Deny log on through Remote Desktop Services» для группы Domain Admins. Применяется на OU с рабочими станциями и серверами приложений. Тогда даже при утечке пароля админ не сможет залогиниться на скомпрометированный ПК.