У вас есть MFA, но она не работает: как защитить айдентити от атак
О том, почему MFA не всегда защищает от атак и как снизить риски компрометации айдентити, Лев Овчинников, руководитель продукта Indeed ITDR, рассказывает в статье для РБК.
В современном ландшафте киберугроз становится все меньше места для хактивизма и киберхулиганства, и все чаще действуют организованные группы. Они используют уязвимости цифровых систем не только ради прибыли, но и как инструмент политической и бизнес-борьбы.
По данным ГК «Солар», промышленный шпионаж уже составляет 61% атак, тогда как атаки ради привлечения внимания снизились до 11%. Компрометация айдентити как начальный этап атаки сократилась по сравнению с 2024 годом до 27,6%, но остается вторым по распространенности сценарием.
Айдентити по-прежнему остается одной из ключевых целей злоумышленников. Получив доступ к легитимным учетным данным, они могут действовать от имени пользователя и незаметно продвигаться к критическим системам. При этом инфраструктура айдентити, которую необходимо защищать, стремительно усложняется. Главная причина — цифровизация: переход в онлайн и автоматизация все большего числа бизнес-процессов приводят к тому, что каждый процесс обслуживается отдельным приложением.
Зарубежные аналитики утверждают, что при цифровизации одного процесса часто используются сразу несколько приложений с пересекающимся функционалом, например Microsoft 365 и Google Workspace одновременно. Благодаря SaaS и облачным решениям подключение новых сервисов стало максимально простым, поэтому в крупных компаниях в среднем используется около 230 приложений. Многие из них становятся частью инфраструктуры айдентити: идентифицируют пользователей, выполняют аутентификацию и управляют доступом. Однако защита в таких приложениях часто развита слабо, что приводит к появлению уязвимостей. В результате формируется эффект «расползания айдентити» (identity sprawl), который становится одной из ключевых причин компрометации инфраструктуры.
Злоумышленник с конкретной целью не будет атаковать хорошо защищенный периметр. Он найдет слабое место и проникнет через него. Если внутренняя защита слабая, одного такого входа достаточно, чтобы получить доступ ко всей инфраструктуре.
Показательный пример — инцидент с американским гигантом медицинского страхования Change Healthcare. Один украденный пароль дал доступ к удаленному рабочему столу через веб-приложение Citrix, где не был включен второй фактор аутентификации. В результате был запущен шифровальщик, а общий ущерб превысил 10 миллиардов долларов. Такой инцидент часто объясняют ошибкой администраторов. И такое объяснение, как правило, исчерпывает разбор инцидента и снимает ответственность с менеджмента. Однако проблема глубже. При быстром росте числа приложений подобные ошибки становятся системными и практически неизбежными.
В итоге под угрозой оказывается сам подход к защите. Возникает классическая асимметрия: атакующему достаточно найти одну уязвимость, тогда как защищающая сторона должна закрыть все возможные риски. Поэтому внедрение MFA как отдельной меры и формальное соблюдение политик безопасности не дают необходимого уровня и реальной защиты.
Почему MFA не справляется со своей задачей
Эксперты международной компании JumpCloud, специализирующейся на решениях по защите айдентити в облачной среде, отмечают, что MFA внедрена более чем в 87% компаний с численностью свыше 10 000 сотрудников и более чем в 78% компаний с численностью свыше 1 000. При этом треть успешных атак по-прежнему связана с компрометацией учетных данных.
Существуют специфические техники обхода MFA: компрометация мобильных устройств, бомбардировка запросами (MFA bombing), методы социальной инженерии, вынуждающие пользователя подтвердить ошибочный запрос. Однако на практике злоумышленникам часто даже не требуется использовать эти подходы. В типичных инфраструктурах остается достаточно обходных путей.
Одна из ключевых причин заключается в том, что многие приложения не поддерживают MFA в стандартной конфигурации. Они используют локальную аутентификацию или традиционные протоколы, такие как Kerberos и LDAP. При этом именно эти наиболее зрелые и важные компоненты инфраструктуры чаще всего являются критичными для бизнеса.
Так возникает перекос: MFA внедряется в новых и второстепенных системах, например, в корпоративных приложениях для командировок или AI-инструментах, тогда как административный доступ к критически важным ресурсам может оставаться без дополнительной защиты. Даже когда интеграция с MFA возможна, ее откладывают. Причины — ошибки администраторов, разрыв между ИТ и ИБ, а также процессы слияний и поглощений, где новые системы вводятся в эксплуатацию быстрее, чем успевают быть защищены.
При этом традиционные решения MFA не видят таких пробелов. Они контролируют только подключенные системы, создавая иллюзию полной защищенности. Для выявления «белых пятен» требуется корреляция данных из разных источников: между журналами MFA, приложений и контроллеров домена, что является сложной задачей. Дополнительное ограничение связано с агентной моделью. Многие решения MFA основаны на модификации клиентских приложений или рабочих станций через агенты. Такая защита может быть обойдена с использованием неподконтрольных устройств или отключением самого агента. Они есть почти в любой крупной компании: например, личный компьютер подрядчика или нестандартное устройство топ-менеджера. Кроме того, пользователь с правами администратора может отключить агент самостоятельно, и злоумышленник сможет сделать то же самое, получив его доступ.
В результате там, где последствия несанкционированного доступа наиболее высоки, внедрить и поддерживать MFA оказывается сложнее всего.
Повышение защиты через устранение недостатков
Главная проблема избирательного внедрения MFA в том, что злоумышленнику достаточно одного слабого места. Одного доступного приложения и пароля достаточно для компрометации. Это значит, что постепенное внедрение MFA в отдельные системы приводит к постоянному накоплению незакрытых рисков. Бэклог интеграции растет быстрее, чем его удается закрывать. Идеальный сценарий — полное покрытие систем и приложений MFA. Однако на практике это сложно реализовать из-за технических ограничений и сопротивления пользователей.
Поэтому при поэтапном внедрении важно начинать с наиболее критичных систем: административных доступов, баз данных, сетевой инфраструктуры. Для этого необходима прозрачность: располагать качественным процессом управления активами и системным аудитом. Нужно понимание, какие учетные записи имеют доступ к ключевым ресурсам и с каким уровнем привилегий. Это позволяет избежать ситуации, когда решение внедрено, но не защищает действительно важные активы. Администраторы вынуждены мириться с недостатками приобретенного продукта, компенсируя их внедрением MFA во второстепенных системах.
В этом контексте прокси-подход к MFA дает существенные преимущества. Он позволяет контролировать все попытки аутентификации независимо от приложения и устраняет проблему точечной интеграции. Дополнительно появляется возможность видеть все обращения к ресурсам, включая те, где MFA еще не внедрена. Это помогает выявлять неучтенные системы, обнаруживать «забытые» приложения и закрывать пробелы. Сочетание качественной интеграции с процессами управления доступом дает возможность своевременно выявлять привилегированные учетные записи и внедрять MFA, а не следовать техническим ограничениям конкретного продукта.
Прокси-подход устойчив к обходу через сторонние устройства и не зависит от установки агентов: он защищает запросы доступа с некорпоративных устройств и устойчив к компрометации самого агента. Однако он требует аккуратного внедрения и управления рисками, так как влияет на критические процессы аутентификации. Прокси-архитектура ограничена отдельными протоколами, а ее сбой приводит к отказу инфраструктуры айдентити и отсутствию возможности у пользователей получить доступ к приложениям.
Когда все приложения и пользователи уже охвачены MFA, важно учитывать и устойчивость самих факторов аутентификации к распространенным атакам. SMS и звонки уязвимы к перехвату, push-уведомления подвержены ошибочным подтверждениям. Поэтому можно использовать более современные методы: number matching, защита от MFA fatigue, FIDO и passkey.
Будущее защиты айдентити — MFA или
Традиционный подход к MFA неизбежно будет пересмотрен. Несмотря на то что технология уже широко распространена, сегодня она обеспечивает защиту в первую очередь от массовых и случайных атак, но этого уже недостаточно.
Ключевая проблема — отсутствие целостного подхода. MFA обычно защищает отдельные приложения или сценарии доступа. Однако точечная защита оставляет уязвимости в других частях инфраструктуры и снижает общий уровень безопасности. На практике даже небольшое повышение общей защищенности инфраструктуры снижает риски эффективнее, чем сильная, но локальная защита отдельных компонентов.
При этом цифровизация продолжает ускоряться, и злоумышленники активно ищут даже минимальные слабые места. Разрыв между развитием ИТ и уровнем защиты увеличивается. Поэтому развитие защиты должно идти к тому, чтобы MFA стала частью базовых элементов инфраструктуры айдентити — локальных доменов, систем управления доступом, облачных провайдеров айдентити, шлюзов API.
Быстро перейти на современные решения по управлению доступом (например, облачные) невозможно: устаревшие компоненты все равно остаются в зоне риска и продолжают воспроизводить описанный парадокс MFA. Решение требует фокуса на защите критичных компонентов и отказа от формального внедрения ради показателей.
ITDR — новый класс в системе защиты айдентити
На практике MFA стоит рассматривать не как расширение отдельных приложений, а как часть базовой инфраструктуры аутентификации и контроля доступа: контроллеров домена и облачных провайдеров айдентити. Через нее проходит большинство запросов, поэтому такой подход позволяет выявлять сценарии, где MFA еще не применяется, и быстрее расширять покрытие защиты. В результате организация получает основу для комплексной защиты, при которой уязвимости выявляются до инцидента, а не после него.
Здесь появляются системы класса ITDR (Identity Threat Detection and Response), которые обеспечивают более целостную защиту айдентити. В рамках ITDR-продукта разработчики объединяют различные технологии, которые работают на уровне инфраструктуры айдентити: анализируют сценарии аутентификации, находят обходные пути MFA, выявляют «белые пятна» и обеспечивают контроль доступа. Это позволяет перейти от формального внедрения MFA к управляемой защите: когда важно не наличие технологии, а снижение риска компрометации.
В ежегодном опросе компании Quest 92% респондентов скзали, что внедрение ITDR позволило эффективнее обнаруживать уязвимости в инфраструктуре и повысить уровень ее защищенности.
Тем не менее, несмотря на появление продуктов нового поколения, их внедрение, особенно в отечественных инфраструктурах, идет медленно. Такие решения требуют серьезной перестройки процессов, сопоставимой с внедрением систем управления учетными записями IDM/IGA. Кроме этого, отдельные компоненты ITDR нередко уступают специализированным продуктам при прямом сравнении с альтернативными решениями, специализирующимися только на одной технологии, например только MFA или только защите от сетевых атак.
