Аудит прав в Active Directory: 12 лишних Domain Admins и методика их нахождения

Несколько месяцев назад мы писали про Flame и вектора атак через сертификаты - сложные угрозы, которые требуют изощрённой защиты. На этой неделе история попроще и, честно говоря, куда более типичная: аудит прав в Active Directory у производственного клиента, который закончился фразой «мы и не знали, что их так много».

Инсайдерские инциденты в этом году заметно участились - это фиксируют и отраслевые отчёты, и наш собственный опыт разборов. Большинство из них не про хитрые техники обхода защиты. Они про то, что у бывшего системного администратора, ушедшего два года назад, в AD до сих пор активная учётная запись с правами Domain Admin.

С чего начинается такой аудит

Мы пришли к клиенту с конкретным запросом: проверить, кто реально имеет административные права и нужны ли они. Задача кажется тривиальной ровно до момента, когда открываешь список группы Domain Admins и видишь там людей, которые «вообще-то уже не работают» или «ну, им добавили когда-то на время».

Первый шаг - выгрузка членства во всех привилегированных группах. В AD к таким относятся не только Domain Admins, но и Enterprise Admins, Schema Admins, Administrators (встроенная), Account Operators, Backup Operators, Server Operators. Каждая из них - потенциальный вектор компрометации домена.

Для сбора данных использовали PowerShell - хватает стандартного модуля ActiveDirectory, который входит в состав RSAT:

$privilegedGroups = @(
    "Domain Admins",
    "Enterprise Admins",
    "Schema Admins",
    "Administrators",
    "Account Operators",
    "Backup Operators",
    "Server Operators"
)

foreach ($group in $privilegedGroups) {
    $members = Get-ADGroupMember -Identity $group -Recursive |
        Get-ADUser -Properties Enabled, LastLogonDate, Description |
        Select-Object Name, SamAccountName, Enabled, LastLogonDate, Description
    $members | Export-Csv "C:\audit\$group.csv" -Encoding UTF8 -NoTypeInformation
}

Рекурсивный обход обязателен: вложенные группы - классическое место, где прячутся лишние права. Один из технических специалистов клиента сказал, что «смотрел Domain Admins», но смотрел он только прямых членов. Вложенная группа «IT_Old_Stuff» с пятью учётными записями при этом спокойно наследовала права домен-админа.

Что нашли

Итог первого прохода: 12 учётных записей в Domain Admins, которым эти права не нужны. Разбивка примерно такая:

• Бывшие сотрудники - учётки отключены в HR-системе, но в AD не деактивированы и не удалены. Две из них последний раз использовались больше года назад, три - никогда не логинились вообще. Учётка без входа с правами домен-админа - это либо ошибка при создании, либо намеренно оставленный запасной доступ. В обоих случаях это не то, что нужно оставлять как есть.
• Разработчики и аналитики, которым «временно» добавили права для настройки чего-то конкретного. «Временно» случилось полтора года назад.
• Сервисные учётки с интерактивными правами - несколько служб работали под учётками, добавленными в Domain Admins «чтобы точно хватало прав». Это отдельная боль: сервисные учётки должны работать под принципом наименьших привилегий особенно строго, потому что пароли к ним часто не меняются месяцами.

AD Audit Plus - где PowerShell не хватает

PowerShell хорошо работает для выгрузки текущего состояния. Но он не даёт ответа на вопрос «кто и когда добавил этого пользователя в группу». Для истории изменений мы подключили ManageEngine AD Audit Plus - коммерческий продукт, который агрегирует события из Security Event Log контроллеров домена и строит по ним читаемые отчёты.

Что он показал в данном конкретном случае: большинство добавлений в Domain Admins происходило в промежутке между 18:00 и 21:00 в пятницу или субботу. Классика - кто-то чинил проблему в нерабочее время, временно поднял права, забыл убрать. Это не злой умысел, это операционная культура без контрольных точек.

Полезные отчёты из AD Audit Plus, которые мы использовали:

• Group Membership Changes - все добавления/удаления из привилегированных групп за последние N дней с именем кого добавил и временем
• Inactive User Accounts - учётки без входа дольше заданного периода (мы смотрели 60 и 90 дней)
• Logon Activity - фактическая активность по учёткам из привилегированных групп

Что дальше

Формально аудит - это диагностика. По его итогам мы составили список из трёх категорий действий.

Немедленно: деактивировать учётки бывших сотрудников, убрать прямое членство в Domain Admins для всех, кому это не нужно по должностным обязанностям. Сервисные учётки - отдельно: перевести на управляемые сервисные учётные записи (Managed Service Accounts) там, где это применимо, либо зафиксировать минимально необходимые права.

В течение месяца: настроить мониторинг изменений в привилегированных группах с алертингом. Событие 4728 в Security Log (добавление в группу безопасности) должно генерировать уведомление на почту ответственного за безопасность.

Системно: ввести процедуру ревизии привилегий раз в квартал. Никакой экзотики - просто выгрузка того же скрипта и сверка с актуальным списком сотрудников. Можно автоматизировать.

Клиент воспринял итоги нормально. Реакция «мы и не знали» здесь честная: без инструментов это действительно сложно отследить вручную в инфраструктуре на несколько сотен объектов. Инструменты есть, методика несложная - дело за регулярностью.

Если у вас тоже есть ощущение, что Domain Admins «как-то многовато», это хороший повод сделать аудит прав доступа до того, как ощущение подтвердится инцидентом.