Active Directory

8.1 Путь атаки

Red Team не интересует, кому формально подчиняется сервер. Она ищет цепочку от контролируемого endpoint к более сильной идентичности: локальный admin, токен в LSASS, сервисный секрет, delegation, ACL или привилегированная сессия. Blue Team должна разрывать всю цепочку а не закрывать один её видимый шаг.

phishing -> PC-17 -> local admin -> server -> DA credential -> DC
  ^  |
  +---- weak controls -+
Модель attack paths связывает технические решения с их реальным последствием — потерей identity control plane. Архитектурное решение должно быть понятно следующему администратору без устного контекста: кто владелец, какой объект защищается, откуда допустимо управление и как проверить результат.
Не делай так: оценивать защищённость только количеством установленных продуктов безопасности.
Get-ADGroupMember 'Domain Admins' -Recursive |
 Get-ADUser -Properties LastLogonDate | Select SamAccountName,LastLogonDate
Любое изменение сначала проходит инвентаризацию зависимостей, тест в ограниченной области, наблюдение за журналами и план отката. Удобство разовой настройки не равно безопасности жизненного цикла. В production фиксируют дату ревизии, владельца и доказательство проверки, а не только саму команду.
Проверь себя. Что произойдёт при компрометации этого объекта? Какие системы перестанут работать при ротации секрета или отзыве доступа? Кто заметит отказ и за какое время? Ответы превращают набор технических параметров в эксплуатируемый сервис. Если на эти вопросы нет ответа, решение ещё не готово к масштабированию.
Для tiering это означает: любой новый сервер, account, путь администрирования классифицируйте до выдачи доступа а не после инцидента.
ЭтапДоказательство качества
ПроектированиеОбоснование, владелец, граница доступа и rollback
ВнедрениеPilot, журнал изменений и контрольный тест
ЭксплуатацияМониторинг, review прав и актуальная документация
ИнцидентПонятный runbook, контакты и безопасный путь восстановления

8.2 LSASS и станции

После интерактивного входа привилегированного пользователя на устройстве могут появиться credential material, Kerberos tickets и tokens. Компрометация устройства не обязательно равна немедленной краже пароля, но она создаёт возможность для атак на сессию и делает риск неприемлемым для Domain Admin.

Фраза «я подключился только на минуту» не является мерой защиты. Продолжительность не меняет границу: высокопривилегированная идентичность уже использовала небезопасный источник и могла оставить следы в памяти или кэше.

Internet/mail/browser -> Tier 2 workstation
  |
  LSASS
  |
  DA session material
  v
  entire domain
Исключение высоких credential из низкого tier устраняет путь до того, как защитныепродукты должны будут распознать конкретную технику атаки. Архитектурное решение должно быть понятно следующему администратору без устного контекста: кто владелец, какой объект защищается, откуда допустимо управление и как проверить результат.
Не делай так: входить Domain Admin на пользовательский ПК ради ADUC, RDP или установки драйвера.
Get-WinEvent -FilterHashtable @{LogName='Security';Id=4624} -MaxEvents 50 |
 Select TimeCreated,Message
Любое изменение сначала проходит инвентаризацию зависимостей, тест в ограниченной области, наблюдение за журналами и план отката. Удобство разовой настройки не равно безопасности жизненного цикла. В production фиксируют дату ревизии, владельца и доказательство проверки, а не только саму команду.
Проверь себя. Что произойдёт при компрометации этого объекта? Какие системы перестанут работать при ротации секрета или отзыве доступа? Кто заметит отказ и за какое время? Ответы превращают набор технических параметров в эксплуатируемый сервис. Если на эти вопросы нет ответа, решение ещё не готово к масштабированию.
Для tiering это означает: любой новый сервер, account, путь администрирования классифицируйте до выдачи доступа а не после инцидента.
ЭтапДоказательство качества
ПроектированиеОбоснование, владелец, граница доступа и rollback
ВнедрениеPilot, журнал изменений и контрольный тест
ЭксплуатацияМониторинг, review прав и актуальная документация
ИнцидентПонятный runbook, контакты и безопасный путь восстановления

8.3 Модель Tier

Tier 0 управляет идентичностью: DC, AD CS, privileged access tooling, accounts, способные ими управлять. Tier 1 — серверы, приложения. Tier 2 — рабочие станции и пользовательские устройства. Правило направления строго: администратор высокого tier не входит на низший tier.

Tier — не VLAN, не ценность данных, не название OU. Он определяется тем, какой контроль или credential можно украсть через систему. Сервер, управляющий DC или выпускающий доменные сертификаты и фактически Tier 0 даже если назван «utility».

[Tier 0] DC, PKI, identity admins
 ^ no high-tier logon below
[Tier 1] servers, applications
 ^
[Tier 2] workstations, users
Граница tiers ограничивает направление компрометации и упрощает решение о допустимыхсессиях. Архитектурное решение должно быть понятно следующему администратору без устного контекста: кто владелец, какой объект защищается, откуда допустимо управление и как проверить результат.
Не делай так: считать сервер автоматически Tier 1, не изучая его control plane dependencies.
Get-ADComputer -Filter * -Properties OperatingSystem |
 Group-Object OperatingSystem | Sort Count -Descending
Любое изменение сначала проходит инвентаризацию зависимостей, тест в ограниченной области, наблюдение за журналами и план отката. Удобство разовой настройки не равно безопасности жизненного цикла. В production фиксируют дату ревизии, владельца и доказательство проверки, а не только саму команду.
Проверь себя. Что произойдёт при компрометации этого объекта? Какие системы перестанут работать при ротации секрета или отзыве доступа? Кто заметит отказ и за какое время? Ответы превращают набор технических параметров в эксплуатируемый сервис. Если на эти вопросы нет ответа, решение ещё не готово к масштабированию.
Для tiering это означает: любой новый сервер, account, путь администрирования классифицируйте до выдачи доступа а не после инцидента.
ЭтапДоказательство качества
ПроектированиеОбоснование, владелец, граница доступа и rollback
ВнедрениеPilot, журнал изменений и контрольный тест
ЭксплуатацияМониторинг, review прав и актуальная документация
ИнцидентПонятный runbook, контакты и безопасный путь восстановления

8.4 PAW

PAW — выделенная рабочая станция, с которой выполняют административные действия. Её ценность в чистом источнике сессии: ограниченное ПО, обновления, EDR, контролируемые скрипты, отсутствие повседневной почты, личных браузерных расширений и downloads.

PAW не является привилегированным «обычным ноутбуком». Она должна соответствовать tier account: Tier 0 account используется с Tier 0 PAW или управляемого jump host, а не с устройства и где пользователь открывает вложения.

Internet -> daily workstation (Tier 2)

Tier 0 PAW -> jump host -> DC / AD CS
 `--> separate Tier 0 account
Контроль источника снижает вероятность, что админская сессия начнётся на ужескомпрометированном устройстве. Архитектурное решение должно быть понятно следующему администратору без устного контекста: кто владелец, какой объект защищается, откуда допустимо управление и как проверить результат.
Не делай так: разрешить на PAW обычный browsing и email, потому что «так удобнее администратору».
Get-MpComputerStatus | Select AMRunningMode,RealTimeProtectionEnabled
Get-HotFix | Sort InstalledOn -Descending | Select -First 10
Любое изменение сначала проходит инвентаризацию зависимостей, тест в ограниченной области, наблюдение за журналами и план отката. Удобство разовой настройки не равно безопасности жизненного цикла. В production фиксируют дату ревизии, владельца и доказательство проверки, а не только саму команду.
Проверь себя. Что произойдёт при компрометации этого объекта? Какие системы перестанут работать при ротации секрета или отзыве доступа? Кто заметит отказ и за какое время? Ответы превращают набор технических параметров в эксплуатируемый сервис. Если на эти вопросы нет ответа, решение ещё не готово к масштабированию.
Для tiering это означает: любой новый сервер, account, путь администрирования классифицируйте до выдачи доступа а не после инцидента.
ЭтапДоказательство качества
ПроектированиеОбоснование, владелец, граница доступа и rollback
ВнедрениеPilot, журнал изменений и контрольный тест
ЭксплуатацияМониторинг, review прав и актуальная документация
ИнцидентПонятный runbook, контакты и безопасный путь восстановления

8.5 Отдельные учётки

Один сотрудник может иметь user account, helpdesk account, server-admin account и Tier 0 account. Это делает различимыми устройства, policy и события входа. Совместное использование одной учётки стирает границу даже если сеть формально сегментирована.

Just-in-time elevation сокращает время, когда сильная роль доступна. Он полезен, но не отменяет tiers:

  • временный Domain Admin
  • введённый на Tier 2
  • всё равно создаёт опасный credential path
ivanov -> email / Tier 2
adm-ivanov-srv -> Tier 1 server tasks
adm-ivanov-t0 -> PAW only / Tier 0
JIT role: bounded time + approval + audit
Разные account позволяют применить разные политики и расследовать действие бездогадок о контексте входа. Архитектурное решение должно быть понятно следующему администратору без устного контекста: кто владелец, какой объект защищается, откуда допустимо управление и как проверить результат.
Не делай так: добавить ежедневную пользовательскую учётку в Domain Admins для временной задачи.
Get-ADUser adm-ivanov-t0 -Properties MemberOf |
 Select -Expand MemberOf
Любое изменение сначала проходит инвентаризацию зависимостей, тест в ограниченной области, наблюдение за журналами и план отката. Удобство разовой настройки не равно безопасности жизненного цикла. В production фиксируют дату ревизии, владельца и доказательство проверки, а не только саму команду.
Проверь себя. Что произойдёт при компрометации этого объекта? Какие системы перестанут работать при ротации секрета или отзыве доступа? Кто заметит отказ и за какое время? Ответы превращают набор технических параметров в эксплуатируемый сервис. Если на эти вопросы нет ответа, решение ещё не готово к масштабированию.
Для tiering это означает: любой новый сервер, account, путь администрирования классифицируйте до выдачи доступа а не после инцидента.
ЭтапДоказательство качества
ПроектированиеОбоснование, владелец, граница доступа и rollback
ВнедрениеPilot, журнал изменений и контрольный тест
ЭксплуатацияМониторинг, review прав и актуальная документация
ИнцидентПонятный runbook, контакты и безопасный путь восстановления

8.6 LAPS

Одинаковый локальный Administrator password создаёт lateral movement: взлом одного ПК открывает парк устройств. Windows LAPS хранит уникальный пароль в AD, ротирует его, позволяет делегировать чтение только нужной support-группе. Это важно, для Tier 2 и для серверов.

Чтение LAPS password — чувствительная операция. Её ограничивают ACL, журналируют, а доступ выдают по задаче. LAPS — контролируемый break-glass/support путь и не повод выполнять повседневную работу локальным administrator.

PC01 password != PC02 password != SRV01 password
 | | |
 +---- AD LAPS attributes -------+
 read: delegated helpdesk
Уникальный пароль разрушает reuse-путь между хостами и сохраняет recoverability. Архитектурное решение должно быть понятно следующему администратору без устного контекста: кто владелец, какой объект защищается, откуда допустимо управление и как проверить результат.
Не делай так: дать всем helpdesk право читать LAPS password всех Tier 0 и Tier 1 систем.
Get-LapsADPassword -Identity PC01 -AsPlainText
# Выполняйте только с делегированным правом и по заявке.
Любое изменение сначала проходит инвентаризацию зависимостей, тест в ограниченной области, наблюдение за журналами и план отката. Удобство разовой настройки не равно безопасности жизненного цикла. В production фиксируют дату ревизии, владельца и доказательство проверки, а не только саму команду.
Проверь себя. Что произойдёт при компрометации этого объекта? Какие системы перестанут работать при ротации секрета или отзыве доступа? Кто заметит отказ и за какое время? Ответы превращают набор технических параметров в эксплуатируемый сервис. Если на эти вопросы нет ответа, решение ещё не готово к масштабированию.
Для tiering это означает: любой новый сервер, account, путь администрирования классифицируйте до выдачи доступа а не после инцидента.
ЭтапДоказательство качества
ПроектированиеОбоснование, владелец, граница доступа и rollback
ВнедрениеPilot, журнал изменений и контрольный тест
ЭксплуатацияМониторинг, review прав и актуальная документация
ИнцидентПонятный runbook, контакты и безопасный путь восстановления

8.7 Credential Guard

Credential Guard изолирует секреты с VBS на поддерживаемых клиентах, усложняя извлечение credential material. Protected Users ограничивает legacy-аутентификацию и кэширование для совместимых высокоценных identities. Оба механизма полезны, но имеют compatibility impacts и требуют пилота.

Это защитные слои, а не лицензия на плохую архитектуру. Они не превращают заражённую Tier 2 workstation в приемлемый источник Domain Admin сессии и не исправляют лишние права, небезопасную delegation или слабый сервисный пароль.

Tiering: where credential may appear
LAPS: unique local secret
Credential Guard: harder extraction
Protected Users: less legacy exposure
All layers are required
Независимые слои уменьшают вероятность и ценность компрометации, но граница tiersостаётся фундаментом. Архитектурное решение должно быть понятно следующему администратору без устного контекста: кто владелец, какой объект защищается, откуда допустимо управление и как проверить результат.
Не делай так: массово включить Protected Users без проверки legacy protocols и service dependencies.
Get-ADGroupMember 'Protected Users'
Get-CimInstance Win32_DeviceGuard | Format-List *
Любое изменение сначала проходит инвентаризацию зависимостей, тест в ограниченной области, наблюдение за журналами и план отката. Удобство разовой настройки не равно безопасности жизненного цикла. В production фиксируют дату ревизии, владельца и доказательство проверки, а не только саму команду.
Проверь себя. Что произойдёт при компрометации этого объекта? Какие системы перестанут работать при ротации секрета или отзыве доступа? Кто заметит отказ и за какое время? Ответы превращают набор технических параметров в эксплуатируемый сервис. Если на эти вопросы нет ответа, решение ещё не готово к масштабированию.
Для tiering это означает: любой новый сервер, account, путь администрирования классифицируйте до выдачи доступа а не после инцидента.
ЭтапДоказательство качества
ПроектированиеОбоснование, владелец, граница доступа и rollback
ВнедрениеPilot, журнал изменений и контрольный тест
ЭксплуатацияМониторинг, review прав и актуальная документация
ИнцидентПонятный runbook, контакты и безопасный путь восстановления

8.8 Границы входа

Tiering должен проявляться в технических ограничениях: user rights assignment, GPO, restricted groups, firewall, jump hosts, authentication policies, мониторинге logon events. Диаграмма без enforcement не мешает администратору войти туда и куда ему «срочно нужно».

Начинайте с запрета самых опасных направлений и пилотных OU. Политика Deny log on может вызвать outage, если не учесть сервисную учётку или break-glass процедуру, поэтому нужны моделирование и подтверждённый rollback.

GPO enforcement:
Tier 0 accounts -- allowed --> Tier 0 PAW / DC
Tier 0 accounts -- denied ---> Tier 1 / Tier 2
Tier 1 accounts -- denied ---> Tier 2 where applicable
Enforcement переводит правило tiers из договорённости в повторяемое техническоеограничение. Архитектурное решение должно быть понятно следующему администратору без устного контекста: кто владелец, какой объект защищается, откуда допустимо управление и как проверить результат.
Не делай так: включить глобальный Deny policy без pilot OU, анализа сервисных входов и консольногодоступа.
gpresult /h c:	emp\gpresult.html
Get-GPResultantSetOfPolicy -ReportType Html -Path c:	emp
sop.html
Любое изменение сначала проходит инвентаризацию зависимостей, тест в ограниченной области, наблюдение за журналами и план отката. Удобство разовой настройки не равно безопасности жизненного цикла. В production фиксируют дату ревизии, владельца и доказательство проверки, а не только саму команду.
Проверь себя. Что произойдёт при компрометации этого объекта? Какие системы перестанут работать при ротации секрета или отзыве доступа? Кто заметит отказ и за какое время? Ответы превращают набор технических параметров в эксплуатируемый сервис. Если на эти вопросы нет ответа, решение ещё не готово к масштабированию.
Для tiering это означает: любой новый сервер, account, путь администрирования классифицируйте до выдачи доступа а не после инцидента.
ЭтапДоказательство качества
ПроектированиеОбоснование, владелец, граница доступа и rollback
ВнедрениеPilot, журнал изменений и контрольный тест
ЭксплуатацияМониторинг, review прав и актуальная документация
ИнцидентПонятный runbook, контакты и безопасный путь восстановления

8.9 Наблюдение

Границы деградируют через исключения: новый сервер, emergency access, временная группа, миграция приложения. Нужны отчёты о членстве privileged groups, interactive logons, изменениях GPO, чтении критичных секретов. Логи ценны только если их кто-то обрабатывает и имеет полномочия устранить находку.

new admin path detected
 |
inventory -> owner review -> remove / justify -> monitor
 ^   |
 +--------- recurring review -----------+
Постоянная ревизия ловит drift раньше, чем временное исключение станет постояннойатакующей поверхностью. Архитектурное решение должно быть понятно следующему администратору без устного контекста: кто владелец, какой объект защищается, откуда допустимо управление и как проверить результат.
Не делай так: считать tiering завершённым проектом и не пересматривать его после внедрения.
Get-ADGroup -Filter 'AdminCount -eq 1' | Select Name
Get-ADUser -LDAPFilter '(adminCount=1)' | Select SamAccountName,Enabled
Любое изменение сначала проходит инвентаризацию зависимостей, тест в ограниченной области, наблюдение за журналами и план отката. Удобство разовой настройки не равно безопасности жизненного цикла. В production фиксируют дату ревизии, владельца и доказательство проверки, а не только саму команду.
Проверь себя. Что произойдёт при компрометации этого объекта? Какие системы перестанут работать при ротации секрета или отзыве доступа? Кто заметит отказ и за какое время? Ответы превращают набор технических параметров в эксплуатируемый сервис. Если на эти вопросы нет ответа, решение ещё не готово к масштабированию.
Для tiering это означает: любой новый сервер, account, путь администрирования классифицируйте до выдачи доступа а не после инцидента.
ЭтапДоказательство качества
ПроектированиеОбоснование, владелец, граница доступа и rollback
ВнедрениеPilot, журнал изменений и контрольный тест
ЭксплуатацияМониторинг, review прав и актуальная документация
ИнцидентПонятный runbook, контакты и безопасный путь восстановления

Настройки

Цветовая схема

Тема