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

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 с рабочими станциями и серверами приложений. Тогда даже при утечке пароля админ не сможет залогиниться на скомпрометированный ПК.

Active Directory 17 апреля 2026 · 13 мин чтения

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

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

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

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

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

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

Уровень	Что входит	Какие учётки
Tier 0	Контроллеры домена, AD CS, AD FS, Azure AD Connect, серверы PAM, ADFS, серверы резервного копирования AD	Domain Admins, Enterprise Admins, Schema Admins, Cert Publishers
Tier 1	Серверы приложений (1С, Exchange, файловые), баз данных, гипервизоров	Server Admins, App Owners, DBA
Tier 2	Рабочие станции пользователей, ноутбуки, тонкие клиенты	Workstation Admins, Helpdesk

Главный принцип: учётка с уровня 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 рабочих мест я внедряю упрощённую модель:

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

Этого достаточно, чтобы при компрометации пользовательского ПК атакующий не получил доступ к домену. Стоимость внедрения — обычно 35–60 тыс. руб. за работы, без покупки дополнительного ПО.

Защитим ваш AD от современных атак

Я лично провожу аудит безопасности Active Directory с проверкой 40+ контролей: учётные записи, GPO, Kerberos, NTLM, SMB, репликация, шаблоны сертификатов. По итогам — план внедрения Tier-модели и закалки контроллеров под ваш масштаб. Бесплатный аудит за 2–3 часа на месте.

Телефон: +7 903 729-62-41
Telegram: @ITfresh_Boss
Семёнов Евгений Сергеевич, директор АйТи Фреш

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 с рабочими станциями и серверами приложений. Тогда даже при утечке пароля админ не сможет залогиниться на скомпрометированный ПК.