CyberLaka

Во многих организациях Active Directory воспринимается как последний рубеж обороны.

Логика простая: если защитили Domain Admin, значит защитили всё предприятие.

На практике это опасная иллюзия.

Если злоумышленник уже закрепился во внутренней сети, получил доступ к рабочим станциям, нашёл сервисные учётные записи и начал перемещаться между серверами, компрометация домена часто становится лишь вопросом времени.

Поэтому главный вопрос должен звучать не так:

Как сделать так, чтобы Domain Admin никогда не взломали?

А так:

Что останется у организации, если Domain Admin уже скомпрометирован?

Domain Admin не должен означать доступ ко всему

Администратор домена нужен для управления Active Directory.

Но во многих инфраструктурах эта учётная запись также позволяет:

• входить на серверы;
• управлять гипервизорами;
• отключать средства защиты;
• получать доступ к сетевому оборудованию;
• удалять резервные копии;
• подключаться к системам хранения;
• администрировать базы данных;
• входить в критичные информационные системы.

В результате компрометация одной учётной записи автоматически означает компрометацию всего предприятия.

Это не проблема конкретного пароля.

Это проблема архитектуры.

Резервная копия, которую может удалить Domain Admin, — не резервная копия

Представим типичную ситуацию.

Сервер резервного копирования введён в домен. Агент резервного копирования работает под доменной учётной записью. Хранилище доступно из основной сети. Администраторы подключаются к серверу резервного копирования со своих обычных рабочих станций.

Злоумышленник получает права администратора домена.

После этого он может:

• войти на сервер резервного копирования;
• отключить задания;
• удалить точки восстановления;
• зашифровать хранилище;
• изменить политики хранения;
• получить доступ к копиям критичных систем.

В такой архитектуре резервные копии существуют только до тех пор, пока злоумышленник не решил их удалить.

Поэтому серверы резервного копирования не должны зависеть от основного домена. Для них нужны отдельные учётные записи, отдельный контур управления и изолированное хранилище.

Как минимум часть копий должна быть недоступна для изменения из основной инфраструктуры.

Резервная копия, которую может удалить Domain Admin, — это не резервная копия.

Это ещё один файл в домене.

Гипервизор не должен доверять домену безоговорочно

На одном гипервизоре могут одновременно работать:

• контроллеры домена;
• серверы 1С;
• базы данных;
• файловые серверы;
• почтовые системы;
• средства защиты;
• внутренние приложения.

Если Domain Admin может войти в систему управления виртуализацией, злоумышленнику уже необязательно взламывать каждый сервер отдельно.

Он может:

• подключиться к консоли виртуальной машины;
• скопировать виртуальный диск;
• создать снимок;
• изменить сетевые настройки;
• остановить сервер;
• удалить виртуальную машину;
• зашифровать хранилище.

Защита внутри гостевой операционной системы при этом может вообще ничего не увидеть.

Поэтому учётные записи администраторов виртуализации должны быть отделены от доменных администраторов. Сеть управления гипервизорами должна быть изолирована, а доступ к ней — выполняться только с выделенных рабочих мест.

Компрометация Active Directory не должна автоматически открывать доступ к гипервизору.

Средства защиты также не должны зависеть от Domain Admin

Ещё одна распространённая ошибка — управление всей защитой через тот же домен, который эта защита должна контролировать.

Антивирус, EDR, SIEM, почтовый шлюз, межсетевой экран и другие средства защиты нередко администрируются доменными учётными записями.

В результате злоумышленник получает Domain Admin и сразу может:

• отключить защиту;
• изменить политики;
• удалить агенты;
• добавить исключения;
• отключить сбор событий;
• удалить или изменить журналы;
• создать собственную административную учётную запись.

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

Для критичных средств защиты нужны отдельные административные учётные записи, отдельная многофакторная аутентификация и отдельный контроль доступа.

Domain Admin не должен иметь возможность единолично отключить защиту всей организации.

Сетевое оборудование должно быть отдельной зоной доверия

Компрометация домена не должна означать получение доступа к коммутаторам, маршрутизаторам, VPN-шлюзам и межсетевым экранам.

Если сетевое оборудование использует те же доменные учётные записи и доступно из обычной серверной сети, злоумышленник может:

• изменить маршрутизацию;
• открыть доступ между сегментами;
• отключить фильтрацию;
• создать новый VPN-доступ;
• перехватывать трафик;
• удалить журналы;
• заблокировать работу сети.

Администрирование сетевого оборудования должно выполняться из отдельного сегмента управления.

Учётные записи также должны быть отдельными. Доступ необходимо ограничивать по источнику, использовать MFA и централизованно регистрировать все административные действия.

Один администратор — не одна учётная запись

У администратора не должно быть одной универсальной учётной записи для всех задач.

Нормальный подход — разделение учётных записей по уровням доступа.

Например:

• обычная пользовательская учётная запись;
• учётная запись администратора рабочих станций;
• учётная запись администратора серверов;
• отдельная учётная запись для управления Active Directory;
• отдельная учётная запись для гипервизоров;
• отдельная учётная запись для резервного копирования;
• отдельная учётная запись для сетевого оборудования;
• отдельная учётная запись для средств защиты.

Да, это сложнее.

Но одна украденная учётная запись не должна открывать все двери предприятия.

Нельзя администрировать критичные системы с обычного компьютера

Если администратор читает почту, открывает документы, ходит в Интернет и одновременно с этого же компьютера управляет доменом, гипервизорами и резервным копированием, вся архитектура защиты фактически зависит от безопасности одной рабочей станции.

Достаточно:

• фишингового письма;
• вредоносного документа;
• заражённого сайта;
• уязвимого браузера;
• украденной сессии;
• программы удалённого доступа.

После этого злоумышленник получает доступ к административным учётным данным или активным сессиям.

Критичные системы нужно администрировать с выделенных защищённых рабочих мест.

На таких компьютерах не должно быть почты, обычного браузинга, мессенджеров и пользовательского программного обеспечения.

Рабочее место администратора — это часть системы безопасности, а не обычный офисный компьютер с дополнительными правами.

Постоянные привилегии — плохая практика

Domain Admin не должен использоваться для повседневной работы.

Чем чаще применяется привилегированная учётная запись, тем выше вероятность её компрометации.

Права должны выдаваться:

• только для конкретной задачи;
• только на необходимое время;
• только с доверенного рабочего места;
• с обязательной регистрацией действий;
• с многофакторной аутентификацией;
• с последующим автоматическим отзывом.

Привилегия, выданная навсегда, рано или поздно будет использована не тем человеком.

Сервисные учётные записи — отдельная проблема

Во многих доменах годами живут сервисные учётные записи:

• с бессрочным паролем;
• с широкими правами;
• с разрешённым интерактивным входом;
• используемые сразу на нескольких серверах;
• состоящие в административных группах.

Злоумышленнику достаточно получить пароль одной такой учётной записи, чтобы начать перемещение по инфраструктуре.

Для каждого сервиса должна использоваться отдельная учётная запись с минимальными правами.

Нужно запретить интерактивный вход, ограничить места использования, контролировать изменения и по возможности применять управляемые сервисные учётные записи.

Одна сервисная учётная запись не должна обслуживать половину предприятия.

Не все серверы обязаны находиться в одном домене

Иногда сервер вводят в домен просто потому, что «так принято».

Но если система не нуждается в доменной аутентификации, групповых политиках или централизованном управлении, нужно задать простой вопрос:

Зачем она вообще находится в домене?

Особенно это касается:

• серверов резервного копирования;
• систем управления виртуализацией;
• отдельных средств защиты;
• сетевых систем управления;
• технологических и производственных систем;
• изолированных критичных сегментов.

Не нужно создавать лишние доверительные связи только ради удобства администрирования.

Удобство администратора не должно быть важнее устойчивости всей инфраструктуры.

Цель — не сделать компрометацию невозможной

Полностью исключить компрометацию нельзя.

Можно установить дорогие средства защиты, настроить многофакторную аутентификацию, внедрить EDR и провести десятки аудитов. Но всегда останутся ошибки, уязвимости, человеческий фактор и новые способы атак.

Поэтому зрелая инфраструктура строится не только вокруг предотвращения атаки.

Она должна быть готова к тому, что часть систем уже скомпрометирована.

Злоумышленник получил рабочую станцию — он не должен получить серверы.

Получил сервер — не должен получить домен.

Получил домен — не должен получить гипервизоры, резервные копии, сетевое оборудование и средства защиты.

Каждый уровень должен быть отдельной границей доверия.

Компрометация домена — это серьёзный инцидент.

Но она не должна становиться смертным приговором для всей организации.

Если одна доменная учётная запись позволяет отключить защиту, удалить резервные копии, войти на гипервизоры, изменить сеть и получить доступ ко всем информационным системам, проблема не только в украденном пароле.

Проблема в том, что вся инфраструктура построена вокруг одной точки отказа.

Нормальная инфраструктура должна быть способна пережить компрометацию Active Directory.

Возможно, с ограничениями. Возможно, с остановкой части сервисов. Возможно, с трудным восстановлением.

Но она должна пережить её.