Почему MFA не срабатывает там, где должна, в средах Microsoft

By Mirko Peters · 2026-04-22

Многофакторная аутентификация (MFA) должна быть вашей страховочной сеткой в Microsoft 365 и Azure: она останавливает злоумышленников, даже если они украли пароль. Но что происходит, когда этой сетки попросту нет там, где она нужна? «Нужна» — это критические моменты: рискованные входы, вход административных учётных записей или доступ из необычных мест. Если MFA не срабатывает в таких случаях, у вас

Automatically translated with AI from the original post. Read the English original

Многофакторная аутентификация (MFA) должна быть вашей страховочной сеткой в Microsoft 365 и Azure: она останавливает злоумышленников, даже если они украли пароль. Но что происходит, когда этой сетки попросту нет там, где она нужна? «Нужна» — это критические моменты: рискованные входы, вход административных учётных записей или доступ из необычных мест. Если MFA не срабатывает в таких случаях, у вас есть уязвимость, и это очевидно.

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

Понимание и устранение этих пробелов в принудительной проверке жизненно важно для защиты данных. Если вы хотите увидеть на реальном примере, как злоумышленники используют кражу токенов и трюки с OAuth, посмотрите разбор взлома Microsoft 365: там наглядно видно, что на кону.

Где MFA не срабатывает и почему

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

Частая причина — неверно настроенные политики условного доступа. Например, VIP-пользователя исключили «для удобства» или тестовые учётные записи с широкими разрешениями живут без требования MFA. На этапе настройки такие исключения могут казаться безобидными, но они способны пробить серьёзные дыры в защите. Если политики не пересматриваются регулярно, у вас могут появиться невидимые пробелы в безопасности, о которых не предупредит ни одна панель мониторинга.

Ещё одна коварная проблема — устаревшие приложения. Такие инструменты, как Exchange ActiveSync или некоторые настольные почтовые клиенты, часто используют устаревшую аутентификацию и по умолчанию обходят современную MFA. Эти неброузерные приложения опираются на базовую аутентификацию, которая не совместима с вашей новой настройкой MFA, и в результате входы могут происходить совершенно вне вашего контроля.

И не забывайте о поведении пользователей. Некоторые создают «пароли приложений», чтобы подключить старые приложения, и такие пароли полностью обходят MFA. Другие по неосторожности выдают разрешения OAuth сторонним приложениям, соглашаясь на рискованные запросы согласия, и тем самым дают злоумышленникам заднюю дверь, которую никто не проверит через MFA. Именно здесь важно управление, ведь пользователи могут обойти MFA, даже не осознавая риска.

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

Внедрение устойчивых к фишингу методов MFA для безопасной аутентификации

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

Сопоставление чисел в приложениях-аутентификаторах — заметное улучшение. Вместо одобрения обычного push-уведомления пользователь получает код, который должен ввести, и злоумышленнику практически невозможно обмануть человека с помощью «бомбардировки» запросами. Microsoft и другие активно продвигают этот подход и включают его по умолчанию для новых настроек MFA. Он напрямую закрывает хитрые приёмы с засыпанием запросами, которые использовались в недавних громких взломах.

Физические ключи безопасности, такие как YubiKey и токены FIDO2, идут ещё дальше. Эти ключи невозможно подделать с помощью фишинга, и они не опираются на общие секреты. В особо чувствительных средах или для администраторов и руководителей это близко к «режиму блокировки»: аутентификация на аппаратном уровне эффективно блокирует большинство реальных атак.

Жертвовать удобством тоже не обязательно. Современные варианты входа без пароля и глубокая интеграция с такими платформами, как Microsoft 365 и Defender, позволяют встроить MFA, устойчивую к фишингу, прямо в существующие рабочие процессы. Примеры интеграции условного доступа с защитой от продвинутых угроз и удобным пользовательским опытом можно посмотреть в руководстве по настройкам безопасности M365 без лишних неудобств. Переход на MFA, устойчивую к фишингу, — уже не «приятный бонус», а быстро становящийся новым базовым уровнем защиты от изощрённых атакующих.

Внедрение MFA без затрат для малого бизнеса с помощью Microsoft Entra ID

Если вы управляете малым бизнесом, для эффективной MFA не нужен огромный бюджет или дорогие лицензии. Microsoft Entra ID (ранее Azure AD) предлагает значения безопасности по умолчанию, которые любая компания может включить буквально за несколько кликов.

Включите значения безопасности по умолчанию в центре администрирования Entra. Это сразу же обязательно вводит MFA для всех пользователей, без создания сложных политик и без дополнительных лицензий. Самое приятное: эти предварительно настроенные параметры работают сразу после включения, обеспечивая базовую защиту от компрометации учётных записей и блокируя устаревшие протоколы аутентификации по умолчанию.

Важно внедрять это аккуратно. Предупредите пользователей заранее, чтобы никто не оказался врасплох из-за новых запросов. Помогите тем, кто незнаком с инструментами MFA или приложениями-аутентификаторами. По возможности сначала протестируйте настройку на пилотной группе, чтобы убедиться, что не возникнет сюрпризов с важными рабочими приложениями или сервисными учётными записями.

Главное — не полагаться на принцип «настроил и забыл». Регулярно проверяйте, кто входит в значения безопасности по умолчанию, и ищите учётные записи, которые могли выпасть из защиты. Если вам понадобятся более гранулярные средства управления, добавляйте условный доступ поэтапно, но начинайте просто и безопасно. Практичный план безопасного развёртывания и идеи по закрытию невидимых пробелов в защите описаны в практическом руководстве по условному доступу: там разобраны подводные камни и стратегии, которые стоит знать.

MFA для бизнеса: лучшие практики применения политик и снижения рисков

1. Применяйте MFA ко всем без исключений — не ради удобства. Убедитесь, что MFA распространяется на все учётные записи пользователей, а не только на администраторов, включая учётные записи временных сотрудников, подрядчиков и руководителей. Исключения должны быть редкими, всегда ограниченными по времени и иметь веское деловое обоснование.
2. Защитите сервисные и нечеловеческие учётные записи современными средствами. Традиционные сервисные учётные записи нередко становятся серьёзными брешами в MFA. Модернизируйте их с помощью инструментов вроде Entra Workload Identities для управляемой аутентификации, что обеспечивает управление жизненным циклом и возможность аудита. Подробнее об этом подходе — в этом разборе риска нечеловеческих учётных записей.
3. Обучайте пользователей и обеспечивайте поддержку. Помогите пользователям настроить приложения-аутентификаторы или физические токены и объясните, зачем нужна MFA. Обеспечьте поддержку службы helpdesk во время внедрения, особенно для пользователей, которые не знакомы с новыми запросами MFA, например с сопоставлением чисел (number matching).
4. Отслеживайте попытки обхода MFA и аномальные входы. Настройте оповещения и журналы, чтобы выявлять случаи, когда MFA отсутствует в ожидаемых сценариях повышенного риска или когда устаревшие протоколы проходят незамеченными. По возможности автоматизируйте реагирование на инциденты: сброс паролей или запрос дополнительной проверки MFA при рискованных входах.
5. Регулярно проверяйте охват MFA и соответствие политикам. Не считайте, что покрытие уже настроено и больше не требует внимания. Используйте панели идентификации и отчёты как в Microsoft 365, так и на других платформах, если вы работаете в мультиоблачной среде. Оформляйте результаты в понятные отчёты, чтобы ИТ-отдел и руководство видели, где остаются риски. Эффективное управление — это больше, чем переключатели и кнопки; для более глубокого понимания изучите выводы из провалов управления в M365.

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