Вступление
Приветствую сообщество Хабра!
Служба каталогов Active Directory, к сожалению, достаточно часто недооценивается бизнесом или ИТ‑персоналом с точки зрения её критичности.
Она представляет из себя не просто базу данных пользователей — а целый набор информационных систем, предоставляющих возможности централизованной идентификации, прозрачной аутентификации и авторизации, в том числе на основе инфраструктуры открытых ключей (PKI) и технологии единого входа (SSO) и управлении конечными устройствами на основе групповых политик (GPO).
Компрометация таких важных инфраструктурных служб даёт злоумышленникам полный контроль над всеми сервисами, интегрированными в доменную среду (файловые и веб‑сервера, СУБД, среды управления виртуализацией, резервным копированием, сетевым оборудованием и так далее), позволяя беспрепятственно повышать привилегии и осуществлять горизонтальное перемещение в корпоративной сети.
Именно поэтому я, как специалист по информационной безопасности — хотел бы агрегировать для сообщества релевантную информацию по харденингу AD DS в данной статье.
Дисклеймер: в рамках статьи не будут упоминаться базовые меры по обеспечения безопасности корпоративных сетей, такие как «не класть все яйца в одну корзину» (увы.. плоские сети всё ещё встречаются в так называемых Horns&Hooves LTD, поэтому вспоминаем концепции безопасной сетевой сегментации и демилитаризованной зоны), не включать УЗ секретаря, уборщицы или бухгалтерши в Domain Admins (это только кажется мраком, но и такое бывало), создавать регулярные бэкапы сервисов, хотя бы по методологии 3-2-1 и тому подобное
TL;DR — Таймлайн уровней функциональных лесов
Функциональные уровни леса — это механизм, который Microsoft использует для контроля доступных возможностей Active Directory Domain Services (AD DS) на уровне всего леса.
Каждый уровень определяет минимальную версию Windows Server, которая может выполнять роль контроллера домена во всех доменах леса, а также набор функций, доступных на уровне леса.
На текущий момент существует 8 основных уровней леса AD DS, но не все из них привносят существенный вклад в части обеспечения ИБ:
Функциональный уровень леса | Реализованные функции |
Windows 2000 | Является базовым уровнем леса, не содержит в себе дополнительных функций сверх стандартных возможностей AD DS. |
Windows Server 2003 | Лесные доверительные отношения (Forest Trusts) Контроллер домена только для чтения (RODC) |
Windows Server 2008 | Поддержка AES 128 и AES 256 в протоколе Kerberos Детальная политика паролей и блокировки учётных записей (Fine‑Grained Password and Account Lockout Policy) |
Windows Server 2008 R2 | Корзина AD (Active Directory Recycle Bin) Управляемые сервисные учетные записи (Managed Service Accounts) Подтверждение механизма аутентификации (Authentication Mechanism Assurance) |
Windows Server 2012 | Аутентификация на основе утверждений (Claims‑based authentication) Составная аутентификация (Compound Authentication) Динамический контроль доступа (Dynamic Access Control) |
Windows Server 2012 R2 | Глобальная группа безопасности Защищённые пользователи (Protected Users) Политики и силосы аутентификации (Authentication Policies и Authentication Policy Silos) |
Windows Server 2016 | Предоставление доступа «точно в срок» (Just‑In‑Time) Управление привилегированным доступом (Privileged Access Management) с использованием Microsoft Identity Manager (MIM) Автоматическая ротация NTLM‑секретов для УЗ с требованием PKI‑аутентификации (Smart card required for interactive logon) |
Windows Server 2025 | Не привносит существенных функций в части ИБ |
Если рассматривать суть наиболее интересных из них — то мы увидим следующую картину:
Forest Trusts — это механизм, позволяющий установить отношения доверия между корневыми доменами лесов Active Directory разной степени направленности (по умолчанию являются транзитивными).
Именно с этой функции начинается сегментация доменной инфраструктуры по географическому или функциональному признаку; По факту, она заложила фундамент для реализации бастионных (привилегированных) лесов спустя 13 лет.RODC — специализированный тип контроллера домена, содержащий реплику базы данных Active Directory (NTDS.dit), которая работает в режиме «только для чтения» (работает в режиме входящей репликации, не поддерживая протокол отправки изменений на RWDC; аналогично и сам RWDC теперь имеют механизмы запрета репликации с неавторитетных источников, которым RODC и является).
В своё время она не только дала возможность оптимизировать сетевую нагрузку за счёт локализации аутентификации, но существенно сократило поверхность атаки в удалённых филиалах, хоть и не без нюансов.FGPP — технология создавшая фундамент для разделения требований к парольной политике для разных типов учётных записей за счёт создания нового типа объектов — Password Settings Object (PSO), который напрямую маппится к учётным записям или глобальным группам безопасности и имеет приоритет над соответствующими настройками GPO.
В последствии подход с раздельной парольной политикой для обычных и привилегированных учётных записей (а позже и для сервисных/технологических) попал в большинство системообразующих международных стандартов ИБ (NIST SP 800–63B, PCI DSS 4.0 и ISO/IEC 27001:2022).MSA — это новый вид учётных записей домена, которые предназначены специально для запуска служб, приложений и задач планировщика. Они решают проблему ручного управления секретами путём делегирования этой операции службе распределения ключей (KDS).
В последствии помимо sMSA (standalone‑версия, работающая только на одном сервере) появились gMSA (групповая, которая может использоваться на нескольких серверах, в кластерах или ферме), а начиная с Windows Server 2025 и dMSA (созданные специально для миграции с классических учётных записей служб), которые, к сожалению, имеют достаточно неприятную EoP‑уязвимость.AMA — функция подтверждения механизма аутентификации, которая работает за счёт возможности динамического добавления идентификаторов групп безопасности в билеты Kerberos при прохождении аутентификации с использованием определённых шаблонов сертификатов (проверяется по наличию OID в свойствах выданного сертификата по заранее сконфигурированному шаблону).
DAC — как раз таки функция динамического контроля доступа, упомянутая в пункте выше.
Позволяет настраивать доступ к данным на основе множества факторов — свойств (атрибутов) учётных записей, типа устройства и способов аутентификации.
Используя DAC, например, можно настроить доступ к данным на основе степени их критичности или секретности внутри предприятия.Protected Users — это специализированная глобальная группа безопасности созданная специально для защиты высоко‑привилегированных учётных записей от техник кражи учётных данных.
Включение учётных записей в данную группу триггерит в службе каталогов встроенную защиту для предотвращения кеширования учётных данных.
Членство в данной группе вводит следующие важные ограничения:
— Невозможность прохождения NTLM‑аутентификации (можно считать серебряной пулей в плане защиты от Pass‑the‑Hash);
— Невозможность использования устаревших типов шифрования в пре‑аутентификации Kerberos (DES или RC4), что существенно минимизирует риск успешной Kerberoasting‑атаки;
— Невозможность продления TGT вне их TTL (по умолчанию 4 часа), что уменьшает риски закрепления в системе при успешной компрометации билета;
— Clear‑text пароли учётных записей более не кэшируются с использованием встроенных механизмов CredSSP, WDigest, NTLM и DCC.Authentication Policies и Silos — представляют из себя взаимосвязанные сущности, которые можно использовать для гранулярного управления параметрами Kerberos‑аутентификации и ограничения горизонтального перемещения в сети за счёт объединения учётных записей, компьютеров и сервисных аккаунтов в логические контейнеры — силосы, с которым применяются отдельные политики аутентификации. В случае если произвольный объект (например, tier 0 учётная запись администратора) пытается аутентифицироваться на устройстве (например, tier 1 веб‑сервере), не входящем в тот же силос, в который входит он — то такой запрос будет отклонён на уровне KDC при аутентификации.
JIT — переводится как Just In Time, является механизмом предоставления временного привилегированного доступа по требованию.
В AD DS она реализована путём включения соответствующей функциональности на уровне леса, что добавляет возможность указания атрибута-MemberTimeToLiveпри вызове командлетаAdd-ADGroupMember, создания PAM‑запросов через командлетNew-PAMRequestили взаимодействие с REST API службы Microsoft Identity Management (MIM), в случае развёртывания среды AD по новой архитектурной модели для полноценной реализации концепции управления привилегированным доступом (PAM).MIM — система управления идентичностью, которая позволяет в полной мере реализовать как управление жизненным циклом учётных записей, в том числе с использованием кадровых систем, так и концепцию защищённого привилегированного доступа.
При её использовании концепция PAM строится на выделении изолированного бастионного леса (Bastion Environment) с односторонним входящим доверием от продуктивных лесов, где привилегии предоставляются не постоянно, а через JIT‑активацию на защищённой рабочей станции (PAW), подробнее про её компоненты тут.
Все ранее озвученные нововведения позволяют в полной мере реализовать концепцию нулевого доверия (Zero Trust) в AD DS.
Рассвет уязвимостей экосистемы Windows
Эволюция функций Active Directory неразрывно связана с историей атак на корпоративные сети. Каждое значимое нововведение в функциональных уровнях леса часто появлялось как ответ на уже реализованные угрозы или как превентивная мера против зарождающихся техник.
В этом разделе мы проследим, как уязвимости, их эксплуатация в «дикой среде», а также выявленные мисконфигурации стимулировали развитие встроенных механизмов защиты как самой AD DS, так и клиентских и серверных систем.
Эпоха до Windows Server 2012 R2
Долгое время основными векторами компрометации доменных сред были атаки на учётные данные и слабые места устаревших протоколов. До появления функционального уровня леса Windows Server 2008 в Kerberos использовались только чрезвычайно не‑криптостойкие алгоритмы шифрования RC4 и DES, что давало злоумышленникам прекрасную возможность по офлайн‑подбору паролей сервисных учётных записей через Kerberoasting — технику, активно применяемую и по сей день за счёт низкого уровня шума. Аналогично, повсеместное использование NTLM создавало благодатную почву для атак Pass‑the‑Hash: злоумышленнику достаточно было получить хэш пароля администратора (например, через Mimikatz), чтобы аутентифицироваться на других системах без знания самого пароля.
Эти проблемы усугублялись отсутствием в SMB‑сегменте бизнеса минимального уровня ИТ‑гигиены (как на уровне инфраструктуры, в виде сетевой сегментации, строгого контроля доступа и наличию средств антивирусной защиты, так и на уровне устойчивости персонала к техникам социальной инженерии). Классическая атака Golden Ticket, основанная на краже ключа krbtgt, позволяла создавать легитимные TGT на десятилетия вперёд, а DCSync — выгружать базу NTDS.dit, получив права репликации каталога. Все эти техники не требовали эксплуатации каких‑то конкретных уязвимостей — они использовали штатные механизмы AD, что делало их особенно опасными.
Ответ Microsoft: Protected Users, Authentication Policies и Silos и PPL
Реакцией на волну утечек учётных данных стало появление глобальной группы Protected Users при повышении функционального уровня леса до версии Windows Server 2012 R2.
Как ранее уже описывалось, членство в этой группе накладывает жёсткие ограничения в части запрета NTLM‑аутентификации, использования DES и RC4 в Kerberos, ограничения времени жизни TGT и запрета кэширования паролей в конечных системах. Эти меры напрямую закрыли большинство классических векторов атак: Pass‑the‑Hash, Overpass‑the‑Hash и Kerberoasting.
Одновременно были введены Authentication Policies и Authentication Policy Silos, позволяющие ограничить горизонтальное перемещение в сети. Теперь администратор домена, включённый в силос tier 0, не сможет аутентифицироваться на сервере в силосе tier 1 — KDC попросту отклонит запрос. Эта функциональность стала краеугольным камнем для реализации модели tiered administration, ещё когда концепция бастионов не была мейнстримом.
И ещё одной весомой защитной мерой от кражи учётных данных стал новый режим RunAsPPL (Protected Proccess Light) для процесса локальной подсистемы безопасности (так всем известный lsass.exe, отвечающий за работу с учётными данными и проверку подлинности), который появился с выходом ОС Windows 8.1, что позволяло ограничить доступ на чтение к памяти данного процесса только подписанными драйверами с аналогичным или более высоким внутренним флагом доверия.
Хотя, панацеей он, к сожалению, не стал, поскольку данный параметр а) должен был быть включен администраторами вручную, через редактирование ветки реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa и б) исследователи смогли, хоть и спустя некоторое время — создать отдельный подписанный драйвер mimidrv.sys для уже знакомой утилиты, а потом и вовсе адаптировать технику BYOVD для обхода этих ограничений, как, например, получилось с легаси‑драйвером MSI Afterburner RTCore64.sys (CVE-2019-16098), и с весьма замысловатой цепочкой эксплуатации через DLL Hijacking и созданием PoC в виде PPLDump, который «прикрыли» только через год после его выхода.
И лишь спустя время, с выходом Windows 10 v1607 появилась функция контроля целостности на основе компонентов встроенной виртуализации для защиты от уязвимых и неподписанных драйверов, к осени 2018 началось освещение методов детектирования упомянутых техник, к концу 2020 года стала популяризироваться тематика защитных мер AD в массовом SysOps‑сообществе, а в Windows 11 22H2 RunAsPPL и HVCI (как и остальные компоненты Credential Guard) стали включаться в системе по умолчанию.
Несмотря на эти улучшения, настоящим испытанием для корпоративных сетей стали события 2017 года.
Глобальное распространение шифровальщиков, и при чём здесь АНБ
Спустя пять лет после выхода функционального уровня леса Windows Server 2012 R2, сначала в мае, а потом и в июне 2017 года стали глобально известны два компьютерных червя‑шифровальщика, заразившие множество предприятий в сфере промышленности, здравоохранения, телекоммуникации и даже некоторые федеральные органы власти и государственные образования — WannaCry от Lazarus Group (которая, по многим исследованиям Threat Intelligence, имеет прямое отношение к разведывательному управлению генштаба КНДР) и Petya, создателей которого эксперты не смогли достоверно определить и по сей день.
Хоть их механизмы работы во многом отличались — остаётся неизменным факт использования обоими критической уязвимости протокола SMBv1 под названием EternalBlue (также известной как MS17-010 или CVE-2017-0144) совместно с бэкдором DoublePulsar для распространения в незащищённых сетях и закрепления на уязвимых устройствах.
Как раз таки данная уязвимость в протоколе SMB была впервые обнаружена группировкой Equation Group, которая впоследствии разработала для неё данный бэкдор. По многим косвенным факторам её связывают с Агентством Национальной Безопасности США, которое, возможно, использовало её в собственных целях, пока в марте 2017 года само исследование и бэкдор не были украдены и выложены в общий доступ группировкой The Shadow Brokers, что по факту спровоцировало появление данных червей.
При этом ВПО семейства Petya, в отличии от WannaCry, было больше заточено под сети корпоративного класса, так как не только имело функционал шифрования файлов и распространения через ранее описанную цепочку эксплуатации, но и мог красть учётные данные, сохранённые в памяти процесса lsass.exe через уже знакомую утилиту Mimikatz, и использовать их для горизонтального перемещения в сети через интерфейсы WMI и утилиту PsExec, что прямо вело к компрометации AD DS.
Эти инциденты окончательно убедили отрасль в том, что постоянные привилегии и плоские сети — главный враг безопасности, и подтолкнули Microsoft к разработке принципиально новых механизмов и архитектуры управления доступом.
Ответ Microsoft: JIT, MIM и PAM
Им стали две взаимосвязанные технологии на новом функциональном уровне леса Windows Server 2016:
JIT, который как и обсуждалось ранее, позволяет администратору добавлять членов в группы безопасности с ограниченным сроком действия, после которого членство в ней будет автоматически аннулировано.
Это радикально сокращает окно возможностей для злоумышленника: даже если он успеет украсть учётные данные, они будут бесполезны уже через короткое время.MIM PAM — полноценная архитектурная модель, построенная на изоляции привилегированного доступа.
Административные учётные записи не существуют постоянно в продуктивной среде — они временно проецируются через механизм теневых групп и JIT‑активацию с помощью MIM.
Это позволяет реализовать принципы нулевого доверия: даже если продуктивный лес полностью скомпрометирован — злоумышленник не получит доступ к бастионному лесу и не сможет повысить свои привилегии.
Помимо этого была улучшена существующая функция безопасности учётных записей, у которых установлен флаг Smart card is required for interactive logon — теперь её NT‑хэш автоматически ротируется, а не просто задаётся хэшем случайного 128-битного числа при установке флага (что убрало необходимость в создании костылей для ротации этих секретов и снизило риск использования данного хэша в техниках Pass‑the‑Hash или оффлайн‑брутфорса).
Эти меры в совокупности закрывают ключевые пробелы, которыми ранее пользовались злоумышленники:
Постоянные привилегии заменяются временными, что снижает риск компрометации учётной записи;
Кража NT‑хэшей у высоко‑привилегированных пользователей становится бесполезной из‑за автоматической ротации секретов;
Горизонтальное перемещение ограничивается бастионной моделью и ранее введёнными силосами аутентификации.
Таким образом, функциональный уровень леса Windows Server 2016 стал ключевым рубежом, после которого Microsoft наконец предоставила встроенные инструменты для построения достаточно устойчивой к атакам среды AD DS, но остаётся вопрос — как грамотно объединить их между собой для обеспечения эффективной и безопасной архитектуры Active Directory?
«Чёрный заслон» на уровне лесов
Харденинг учётных записей и активов
В первую очередь меня заинтересовала наиболее давняя концепция разделения учётных записей. Ранее для повседневных, административных и технологических задач использовалась единственная учётная запись, что, естественно, создаёт множество рисков её компрометации и быстрой эскалации привилегий в 0 шагов.
Теперь же практически в каждой организации можно встретить следующие типы учётных записей:
Пользовательские
Используются для повседневных рабочих задач (почтовая переписка, доступ к корпоративному порталу и в прочие корпоративные сервисы (ServiceDesk, RDS, КЭДО и тому подобное)).Технологические
Используется для автоматизации задач встроенными средствами операционных систем и сервисов (запуск служб, регламентных заданий, проверка работоспособности встроенных систем и др.).Административные
Используются, исходя из названия, для сопровождения различных систем (начиная от АРМ, и заканчивая СХД и сетевым оборудованием).
Тип УЗ жёстко ограничивает область её применения путём изоляции сред и не даёт возможности реализации рисков перекрёстных утечек секретов (например, при компрометации почтового ящика у злоумышленника внезапно не появится административный доступ до внутреннего портала или сервера).
Как раз таки по типам УЗ логичнее всего составить и требования к парольной политике за счёт FGPP и маппинга PSO к глобальным группам безопасности, например, таким образом:
Для пользовательских УЗ (в абстрактной группе _all_usr) — минимальная длина 12 символов;
Для технологических УЗ (в абстрактной группе _all_svc) — минимальная длина 20 символов;
Для административных УЗ (в абстрактной группе _all_adm) — минимальная длина 16 символов;
Естественно не стоит и забывать помимо этого требованиях к комплексности пароля (это применимо ко всем УЗ), к несовпадению с n‑ным количеством предыдущих паролей, сроке действия и политике блокировки УЗ, например, таким образом:
Для всех УЗ (в абстрактной группе _all) — должен быть установлен комплексный пароль и требование к несовпадению с предыдущими 12 паролями;
Для пользовательских и административных УЗ — должен быть установлен срок действия пароля 1 год и блокировка после 10 попыток неудачного входа;
Следующим шагом в этом направлении является разветвление учётных записей администраторов на различные тиры, поскольку каждая современная инфраструктура имеет множество уровней, каждый из которых имеет собственный уровень защищённости и подход к обеспечению безопасности.
Данный методологический вопрос уже неплохо проработан Microsoft, благодаря которому появилось следующее разделение административных УЗ на основе типов активов:
Тир административной УЗ | Тип ИТ‑активов |
Тир 0 | Контроллеры домена, SSO и PKI (AD DS, AD FS и AD CS) |
Тир 1 | Серверы и сервисы предприятия (Exhcange, MSSQL и прочие LOB‑приложения) |
Тир 2 | Устройства конечных пользователей (компьютеры и ноутбуки) |
Единственным нюансом, который удалось увидеть в данной схеме — размытый Tier 0.
Помимо упомянутых систем контроля идентичности и проверки подлинности в него так же входят все системы, на которых они работают, благодаря которым они работают или которые ими управляют, а под это определение подходит существенный пласт всей низкоуровневой ИТ‑инфраструктуры (гипервизоры, системы хранения данных, коммутаторы, маршрутизаторы, межсетевые экраны, средства защиты информации, оркестраторы, балансировщики и др.), к которым применимы совершенно другие меры по ИБ, ввиду требований к совместимости (например, не в каждом сервисе возможно настроить обязательную аутентификацию на основе сертификатов, не все поддерживают kerberos‑аутентификацию и тому подобное).
Именно поэтому я предлагаю внести некоторые корректировки в эту схему:
Благодаря этому у нас появляется возможность применения необходимых мер безопасности без ущерба совместимости и работоспособности инфраструктуры.
Что же касается самих мер:
Актив | Мера защиты |
Администраторы Тир 0 | — Установка флага «Smart card is required for interactive logon»; |
Активы Тир 0 | — Добавление в аутентификационный силос Тир 0; |
Администраторы Тир 0.5 | — Добавление в привилегированные группы безопасности только через механизм JIT; |
Активы Тир 0.5 | — Ограничение доступа для привилегированных групп Тир 1 и 2 (из сети, в качестве пакетного задания или службы); |
Администраторы Тир 1 | — Добавление в привилегированные группы безопасности только через механизм JIT; |
Активы Тир 1 | — Ограничение доступа для привилегированных групп Тир 0.5 и 2 (из сети, в качестве пакетного задания или службы); |
Администраторы Тир 2 | — Добавление в привилегированные группы безопасности только через механизм JIT; |
Активы Тир 2 | — Ограничение доступа для привилегированных групп Тир 0.5 и 1 (из сети, в качестве пакетного задания или службы); |
Совокупность этих встроенных мер защиты обеспечивает нам следующее:
Доступ к среде управления идентичности (Тир 0) возможен только при обязательной двухфакторной аутентификации через токен (смарт‑карту);
Невозможна реализация административного доступа к активам из несоответствующего типа;
Минимизируется использование устаревшего протокола аутентификации NTLM;
Сокращение возможностей злоумышленников по закреплению в инфраструктуре (включая время закрепления) и латеральному перемещению через кражу маркеров доступа (через злоупотребление механизмами неограниченного и ограниченного делегирования Kerberos) или кражу билетов Kerberos;
Также можно применить аналогичную модель с разделением на тиры и для технологических учётных записей, таким образом, чтобы технологическая УЗ не обслуживала одновременно сервисы из разных тиров.
Помимо озвученных мер следует учесть и другие, которые могут быть применимы под индивидуальные сценарии или требуют особого подхода в реализации:
Authentication Mechanism Assurance — может быть весьма удобным в сценариях с гомогенной Windows‑инфраструктурой, но не применим в гетерогенных средах, приложения в которых не всегда поддерживают обработку OID в PAC Kerberos;
Microsoft Security Baselines — содержит в себе набор мер по усилению защищённости как серверной, так и клиентской инфраструктуры Windows, но перед их применением необходимо тщательно изучить каждую из них, чтобы внезапно не вывести из строя большую часть инфраструктуры (например, полным запретом протокола NTLM в домене);
Но теперь появляется логичные вопросы — как построить доменную архитектуру и администрировать интранет с учётом высказанных мер?
Доменная архитектура
Эффективная защита AD DS невозможна без архитектурной сегментации на несколько лесов, каждый из которых выполняет свою роль в модели нулевого доверия (это является техническим требованием для реализации MIM PAM).
Типовая современная схема включает три взаимосвязанных леса: бастионный (привилегированный), внутренний (корпоративный) и внешний (периметровый).
Бастионный лес содержит учётные записи администраторов и средства управления привилегированным доступом (MIM PAM).
Он не имеет исходящих доверительных отношений к другим лесам, а только входящие — от внутреннего и внешнего лесов, что гарантирует: компрометация любого из них не приведёт к захвату привилегированных УЗ.
Внутренний лес используется для повседневной работы пользователей (сотрудников Компании) и размещения основных корпоративных сервисов (почтовый сервер, СУБД, корпоративный портал и так далее).
Внешний лес (периметровый или демилитаризованный) содержит ресурсы, доступные из сети Интернет, и имеет строгую изоляцию от интранета, взаимодействуя с ним только через строго контролируемые сетевые политики или федерацию на уровне приложений; Так же используется для контроля УЗ подрядчиков и/или клиентов.
Привилегированные рабочие станции
Что же касается PAW — то они представляют из себя выделенные устройства, предназначенные исключительно для выполнения административных задач над соответствующими активами.
Они не должны использоваться для любой повседневной работы (включая чтение почты, сёрфинга в интернете и так далее) и должны иметь дополнительные механизмы защиты (в том числе наложенные, в виде EPP).
Согласно методологии Microsoft — для каждого типа активов должен быть выделен отдельный PAW, и логично заводить их в соответствующую доменную среду для дополнительной сегментации.
Так, например, PAW тир 0 и 0.5 будут находится под управлением бастионного леса, тогда как PAW тир 1 и 2 под управлением внутреннего леса.
При этом не обязательно чтобы они были в одной сетевой плоскости с остальными сервисами (можно выделить отдельный PAW‑сегмент с гранулированным сетевым доступом).
Подробнее про Just‑In‑Time активацию и MIM PAM
MIM PAM реализует межлесное временное предоставление привилегий через вышеописанную доменную архитектуру (с выделенным бастионным лесом).
В бастионном лесу создаются теневые субъекты (shadow principals) — группы и пользователи, которые являются отображениями привилегированных объектов продуктивного леса. Например, для группы INT\Domain Admins — в бастионном лесу создаётся соответствующая теневая группа PRIV\INT Domain Admins. Администраторы, работающие в бастионном лесу, временно добавляются в эти теневые группы, а MIM Service автоматически синхронизирует членство в соответствующие группы продуктивного леса.
Механизм синхронизации основан на добавлении в продуктивную группу Foreign Security Principal (FSP), ссылающегося на SID пользователя из бастионного леса. Для этого между лесами настраивается одностороннее входящее доверие: продуктивный лес доверяет бастионному (исходящее от INT, входящее для PRIV).
При активации роли MIM Service добавляет FSP в продуктивную группу, и Kerberos‑аутентификация пользователя из бастионного леса в продуктивном лесу проходит с использованием этого SID. По истечении заданного времени (TTL) MIM Service автоматически удаляет FSP из группы.
Важным остаётся отсутствие в продуктивных лесах постоянных членов привилегированны групп — все они будут управляться только через MIM PAM.
Это гарантирует, что даже при компрометации учётной записи администратора у злоумышленника будет очень короткое временное окно для латерального перемещения и эскалации привилегий.
Сам же процесс реализации JIT может быть реализован следующими способами, в зависимости от критичности УЗ:
Ручной (через интеграцию с ITSM‑системой через PAM REST API)
Запрос на активацию роли создаётся автоматически из системы заявок (например, Jira SD) с передачей параметров (роль, срок, обоснование).
После одобрения заявки уполномоченным лицом — MIM выполняет активацию, и администратор получает уведомление.Автоматический (на основе правил PAM)
В MIM Policy можно задать условия, при которых запрос одобряется без участия второго лица (например, если пользователь входит с доверенного устройства, запрашивает роль с низким уровнем риска и успешно прошёл двухфакторную аутентификацию).
Первый способ — наиболее релевантный для администраторов инфраструктуры которые могут внести существенные изменения в AD (тир 0 и 0.5), тогда как второй позволяет администраторам серверов и АРМ беспрепятственно выполнять свою работу при соблюдении строгих требований политики безопасности.
Главное не забыть при создании PAM‑ролей выставить в соответствующие значения атрибуты TTL, ApprovalEnabled, AvailabilityWindowEnabled (вместе с AvailableFrom и AvailableTo) и MFAEnabled в соответствии с требованиями защищённости, например:
Для тир 0 и 0.5 ролей выставить TTL 3600 (1 час), включить опции ApprovalEnabled и AvailabilityWindowEnabled и настроить AvailableFrom и AvailableTo на время начала и окончания рабочего дня соответствующих администраторов (например, «9:00» и «18:00» соответственно);
Для тир 1 и 2 ролей выставить TTL 14 400 (4 часа), включить опцию AvailabilityWindowEnabled и настроить AvailableFrom и AvailableTo на время начала и окончания рабочего дня соответствующих администраторов;
Что в итоге?
Мы прошли долгий путь от описания уязвимостей экосистемы Windows и проблемами с управлением привилегированным доступом к многоуровневой эшелонированной защите.
Active Directory больше не является «просто базой данных пользователей».
Это сложная система, требующая системного архитектурного подхода.
Помните: безопасность AD DS — это не разовый проект по настройке GPO или всех указанных мер, а непрерывный процесс обеспечения безопасности, включающий мониторинг и аудит активов, регулярный пересмотр прав доступа и обучение персонала. Буду рад если данный материал пригодится Вам как «отправная точка» в части аудита вашей текущей инфраструктуры и составления плана по усилению защищённости.
В комментариях предлагаю поделится:
Вашим опытом, который возник при организации безопасности AD DS, который возможно был бы полезен как для профессионалов, так и для тех кто только начинает задумываться о харденинге;
Подводными камнями, которые были внезапно обнаружены в ваших кейсах.
Всех благ!
