“Многофакторная аутентификация стала мантрой в сфере ИБ. Но часто её внедряют с пробелами, закрывая самые очевидные двери и оставляя открытыми служебные люксы. Последствия этого — не абстрактные риски, а реальные инциденты, где злоумышленник обходит дорогие системы защиты по самому простому пути.”
Что такое MFA и почему её «частичного» внедрения недостаточно
MFA, или многофакторная аутентификация,, это требование при логине использовать не только пароль, но и дополнительный проверяемый фактор. Классически это что-то, что у вас есть (токен, телефон), или что вы есть (отпечаток, лицо).
Цель MFA — резко повысить сложность компрометации учётной записи. Злоумышленнику недостаточно украсть или подобрать пароль, нужно ещё завладеть вторым фактором. Однако эффективность MFA не абсолютна. Она работает как надёжный замок на крепкой двери. Если же в стене зияет дыра, замок на двери становится бессмысленным украшением. Именно это и происходит при избирательном, «точечном» внедрении MFA.
Типичная ошибка: внедрить MFA только для доступа сотрудников во внутренние корпоративные системы, такие как CRM или бухгалтерия, но оставить без защиты точки входа в инфраструктуру управления — панели администрирования серверов, порталы облачных провайдеров, интерфейсы систем мониторинга. Атака часто начинается именно с них, потому что через них можно получить контроль над всей средой.
Критические точки, где MFA игнорируют чаще всего
Практика показывает, что существуют целые категории систем и доступов, которые по умолчанию считаются «техническими» или «внутренними», и MFA на них не настраивают. Это создаёт уязвимости, которые сводят на нет защиту других участков.
Административные доступы к инфраструктуре
- Консоли управления облачными платформами. Доступ к аккаунту облачного провайдера с правами администратора, это ключи от королевства. Часто на root-аккаунт или учётные записи с полными правами MFA не включают, считая их «служебными». Это позволяет злоумышленнику, укравшему логин и пароль, за несколько минут развернуть вредоносные ресурсы, заблокировать легитимные или похитить все данные.
- Интерфейсы удалённого управления серверами. SSH-ключи для доступа на Linux-серверы или RDP-сессии для Windows-серверов часто защищены только паролями или статичными ключами. Внедрение MFA для этих протоколов (например, через интеграцию с PAM-системами или использование OTP для SSH) технически возможно, но редко реализуется.
- Панели управления сетевым оборудованием. Веб-интерфейсы и CLI коммутаторов, маршрутизаторов, межсетевых экранов. Компрометация такого доступа позволяет перенаправить трафик, отключить сегменты сети или внедрить правила для обхода защиты.
Сервисные и системные учётные записи
Это учётки, от имени которых работают автоматизированные процессы, скрипты, приложения и службы (например, для доступа к базам данных или API). По своей природе они не могут использовать push-уведомления или вводить код из приложения. Из-за этого MFA для них часто отключают, оставляя защиту на уровне длинного и сложного пароля (который, впрочем, может храниться в конфигурационных файлах). Уязвимость таких аккаунтов крайне опасна, так как они обычно имеют широкие привилегии. Решением является переход на аутентификацию на основе сертификатов или использование механизмов временных токенов (например, в связке с HashiCorp Vault), которые эмулируют принцип MFA, не требуя ручного ввода.
Внешние корпоративные порталы и VPN
MFA для доступа к корпоративной сети через VPN стала уже стандартом. Однако часто забывают о менее очевидных точках: порталах для партнёров, клиентов, порталах самообслуживания. Если через такой портал можно получить доступ к документам, тикетам или даже ограниченным API, его компрометация становится началом цепочки атаки.
Как злоумышленники находят и используют эти бреши
Атака редко выглядит как лобовой штурм защищённого MFA входа. Сценарий часто иной.
- Разведка. С помощью открытых источников (OSINT), утечек данных или фишинга злоумышленник получает набор учётных данных — логины и пароли. Это может быть база утекших паролей, где сотрудники использовали служебные пароли и для личных аккаунтов.
- Проверка и картографирование. Автоматизированные инструменты (сканеры) проверяют эти связки на разных публичных интерфейсах компании: почтовых сервисах, VPN-шлюзах, порталах. Цель — найти, где MFA нет. Чаще всего это оказывается какая-нибудь старая система мониторинга, вынесенная в интернет с паролем по умолчанию, или консоль управления облаком.
- Вход и закрепление. Попав в систему без MFA, атакующий не обязательно сразу что-то крадёт. Его цель — закрепиться: создать себе дополнительные учётные записи, сгенерировать постоянные токены API, установить бэкдоры, получить доступ к внутренним сегментам сети, откуда уже можно атаковать системы с MFA изнутри, минуя её.
MFA на основных пользовательских порталах выполняет роль фильтра, который отсеивает массовые атаки. Но целевая атака ищет обходной путь через незащищённый административный или сервисный интерфейс.
Практические шаги по закрытию пробелов
Чтобы избежать ситуации «MFA есть, но не там, где надо», необходим системный подход.
1. Составление полной карты точек входа
Невозможно защитить то, о чём вы не знаете. Необходимо выявить все интерфейсы, требующие аутентификации:
- Все публичные IP-адреса и домены компании.
- Все веб-приложения, включая унаследованные и административные.
- Все протоколы удалённого доступа (SSH, RDP, VPN, FTP/SFTP).
- Все облачные аккаунты и подписки.
- Все API с внешним доступом.
Эту задачу можно частично автоматизировать с помощью сканирования сети и анализа трафика.
2. Приоритизация и политика «MFA по умолчанию»
Установите правило: любая новая система, сервис или точка входа, выносимая в интернет или доступная из критичных сегментов сети, должна поддерживать и иметь включённую MFA. Для существующих систем составьте матрицу рисков. Высший приоритет — у всего, что даёт административные права или доступ к критичным данным.
| Категория доступа | Примеры систем | Уровень риска | Требование MFA |
|---|---|---|---|
| Административный доступ к инфраструктуре | Консоли облаков, vCenter, панели сетевого оборудования | Критический | Обязательно, без исключений |
| Доступ сотрудников к корпоративным данным | Почта, CRM, ERP, файловые хранилища | Высокий | Обязательно |
| Сервисные и машинные учётные записи | Учётные записи для CI/CD, баз данных, бэкенд-сервисов | Высокий | MFA или аутентификация на основе сертификатов/токенов |
| Внешние порталы для партнёров/клиентов | Портал для загрузки документов, тикет-система | Средний/Высокий | Обязательно, если доступны чувствительные данные |
| Внутренние неадминистративные системы | Вики, внутренний портал | Низкий/Средний | Рекомендуется, может быть опционально |
3. Техническая реализация для «сложных» случаев
- Для сервисных аккаунтов: Откажитесь от статичных паролей. Используйте OAuth 2.0 client credentials, JWT-токены с ограниченным временем жизни или механизмы динамических секретов из систем управления. Это аналог MFA для машин.
- Для SSH/RDP: Внедрите решение для управления привилегированным доступом (PAM), которое выступает в роли прокси и требует MFA для получения сессии. Альтернатива — использование SSH-ключей, хранящихся на аппаратных токенах (например, YubiKey), что является формой фактора «то, что у вас есть».
- Для унаследованных систем, не поддерживающих современные протоколы: Изолируйте их в отдельный сегмент сети с жёстким контролем доступа. Сам доступ к этому сегменту организуйте через шлюз (jump host, bastion host), на котором как раз и будет включена строгая MFA.
4. Непрерывный контроль и аудит
Внедрение MFA — не разовое мероприятие. Необходимо настроить мониторинг и алертирование на попытки входа без MFA там, где она должна быть принудительно включена. Регулярно (раз в квартал или полгода) проводите ревизию всех учётных записей и точек доступа, проверяя соответствие политике. Особое внимание — к вновь созданным аккаунтам и сервисам в облаке, которые могли появиться в обход процессов.
Итог: MFA, это про архитектуру безопасности, а не про галочку
История «мы внедрили MFA не везде», это история о полумерах. Она показывает разрыв между формальным выполнением требования (например, «защитить доступ сотрудников») и реальным построением устойчивой к компрометации архитектуры. Угроза редко приходит с фронтальной атаки на самую сильную защиту. Она обходит её с фланга, через забытую, незначительную на первый взгляд дверцу.
Настоящая ценность MFA раскрывается только тогда, когда она становится не отдельной функцией на нескольких системах, а системным, бесшовным слоем защиты, интегрированным в процессы управления доступом и идентификацией. Это требует больше усилий, чем просто включить опцию в Active Directory, но именно этот подход предотвращает инциденты, а не создаёт иллюзию безопасности.