Двухфакторная аутентификация: 2FA, MFA и выбор второго фактора

Что бизнес получает от второго фактора

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

• Почта: сложнее войти только по скомпрометированному паролю сотрудника.
• VPN: проверка удалённого доступа может учитывать дополнительный фактор.
• Администрирование: для критичных учётных записей задаётся более сильный способ подтверждения.
• Подрядчики: личные методы, срок допуска и понятный порядок отзыва.

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

Аутентификация, авторизация, 2FA и MFA

Правильный термин — двухфакторная аутентификация: подтверждение личности. В поиске часто пишут «двухфакторная авторизация», но авторизация отвечает на другой вопрос — какие действия и ресурсы разрешены уже известной личности.

2FA означает два разных фактора. MFA — более общее название многофакторной проверки. Два окна, два шага или два введённых секрета ещё не доказывают наличие двух разных факторов.

Успешная MFA также не выдаёт автоматически административные права. После подтверждения личности сервис применяет собственную политику доступа. Например, сотрудник может успешно войти в почту, но не иметь доступа к панели управления облаком.

Что считается разными факторами

• Знание: пароль или другой запоминаемый секрет.
• Владение: контроль аутентификатора — например, ключа или устройства с нужным секретом.
• Свойство пользователя: биометрия, используемая в поддерживаемом механизме.

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

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

Коды TOTP: удобно, но не защита от любого фишинга

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

Секрет регистрации, часто представленный QR-кодом, чувствителен: скопировав его, другой участник может генерировать те же коды. Скриншот QR в заявке или общей папке превращает второй фактор в общий секрет. Секреты не входят в учебный архив к статье.

Google Authenticator и другие совместимые приложения — примеры программ для кодов. Поддержку конкретного метода, перенос и синхронизацию проверяют по выбранному продукту. Восстановление после смены телефона планируют до его потери.

Код можно выманить и передать дальше в коротком окне действия. Поэтому пароль плюс TOTP может быть MFA, но сам по себе TOTP не является phishing-resistant методом. При отказе проверяют правильный аккаунт и часы, а не расширяют окно приёма бесконтрольно.

Push: подтверждение должно быть осознанным

Push предлагает подтвердить попытку входа в приложении. Пользователь должен понимать, какой вход он инициировал. Неожиданный запрос нужно отклонить и сообщить о нём, а не нажимать «разрешить», чтобы уведомления прекратились.

Частые запросы могут быть частью MFA fatigue — попытки добиться случайного согласия. Number matching, дополнительные сведения о входе и ограничения помогают сделать подтверждение осмысленнее. Microsoft Authenticator — пример реализации с сопоставлением числа в поддерживаемом процессе.

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

SMS и звонок: учитывать ограничения

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

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

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

FIDO2 и аппаратные ключи: проверка связана с сервисом

В FIDO/WebAuthn используются ключи, привязанные к контексту сервиса. При корректной реализации злоумышленнику недостаточно попросить пользователя переписать одноразовый код для другого сайта. Важны проверка подписи, RP ID, Origin и требуемого пользовательского подтверждения.

Аппаратные FIDO2-ключи, например соответствующие модели YubiKey или Security Key, — один вариант аутентификатора. Перед покупкой сверяют модель, интерфейсы USB/NFC, браузер, устройство и поддержку конкретного сервиса. Не каждый USB-ключ с сертификатом или функцией OTP является FIDO2-ключом.

Касание ключа может подтверждать присутствие пользователя, но не обязательно его локальную проверку, UV. Для многофакторного криптографического входа важны требуемый и реально выполненный PIN/биометрический механизм и политика сервиса. Одно внешне простое действие может включать несколько факторов; два внешних окна могут их не включать.

Passkeys: без пароля не означает без проверки

Passkey — учётные данные на основе FIDO-механизмов. Вход может использовать ключ устройства и локальную разблокировку PIN или биометрией вместо ввода пароля сайта. Сервис должен правильно проверять результат и требовать необходимый уровень подтверждения.

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

Passkeys встречаются в экосистемах Google, Apple и Microsoft, а также на совместимых аппаратных ключах. Возможность синхронизации, корпоративные ограничения и способы удаления проверяют по конкретному сервису и аутентификатору. Нельзя обещать переносимость любого ключа между всеми платформами.

Важно различать пользовательское присутствие, UV и фактическую политику. Не каждая надпись «passkey» автоматически доказывает выполнение требований компании или конкретного уровня NIST AAL. Уровень уверенности оценивается по всей реализации, а не названию кнопки.

Два пароля и пароль плюс фактор — разница на схеме

Сравнивайте методы по задаче: устойчивость к фишингу, поддержка сервиса, удобство, управляемость, потеря устройства и восстановление. Удобный метод, который не работает в нужном VPN-клиенте, не решает задачу. Сильный основной метод со слабым восстановлением может оставить удобный путь обхода.

От каких атак MFA помогает, а где нужны другие меры

• Украден пароль: дополнительный фактор способен остановить новый вход.
• Поддельная форма с кодом: OTP может быть передан атакующему; нужен более устойчивый метод и обучение.
• Неожиданный push: не подтверждать, проверить учётную запись и события.
• Украдена действующая сессия: может потребоваться отдельный отзыв токенов и расследование.
• Заражено рабочее устройство: MFA не заменяет защиту конечной точки и обновления.

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

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

Как внедрять MFA поэтапно

1. Инвентаризировать сервисы и все способы входа: веб, мобильные клиенты, VPN, административные панели и интеграции.
2. Определить критичные роли и допустимую силу аутентификации.
3. Сверить совместимость, лицензии, устройства, методы и порядок восстановления.
4. Провести пилот с основным и резервным методом.
5. Включать требование по группам, контролируя отказы и исключения.
6. Проверить реальную операцию и закрыть ненужные слабые пути.

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

В сервисах вроде Microsoft Entra можно задавать требования к допустимым комбинациям методов. Наличие конкретного элемента управления и лицензии сверяют перед проектом; одинакового «включателя MFA везде» нет.

Регистрация второго фактора — тоже операция безопасности

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

• Проверять личность и основание выдачи в контролируемом процессе.
• Регистрировать основной и согласованный резервный способ.
• Уведомлять владельца об изменении методов.
• Учитывать выданные аппаратные ключи и корпоративные устройства.
• Проверять, что разрешённые методы соответствуют роли пользователя.

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

Телефон потерян: восстановить доступ без простого обхода

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

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

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

Аварийный доступ администраторов

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

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

В Microsoft Entra есть отдельные рекомендации по emergency access. Для VPN, гипервизора и другой панели порядок может отличаться. Проверку выполняют заранее в согласованном окне, а не после того, как все администраторы потеряли доступ.

VPN, AD, почта и старые приложения

MFA на веб-портале не обязательно защищает IMAP/SMTP, старый VPN-клиент, RDP, сервисную учётную запись или прямой административный интерфейс. Составьте карту реальных способов доступа, включая интеграции и машинные сценарии.

В RADIUS/VPN-интеграции проверяют поддержку метода, challenge и таймеры. Сам RADIUS не добавляет MFA автоматически. Для AD DS также нет одного флажка, превращающего каждый Kerberos/LDAP-вызов в интерактивный второй фактор.

Для приложений без нужной поддержки рассматривают совместимую точку входа, модернизацию или ограниченное исключение с компенсационными мерами. Машинные идентичности и API-ключи управляются отдельно: нельзя просто заставить фоновую задачу отвечать на push пользователя.

Сессии, токены и отзыв доступа

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

При увольнении или инциденте проверяют учётную запись, факторы, активные сессии, доверенные устройства, VPN, токены приложений и API-секреты. Действия должны соответствовать реальному сервису, а результат — подтверждаться конкретным подключением.

Это причина сочетать MFA с журналами и контролем устройств. В расследовании сопоставляют входы, выдачу сессий, регистрацию нового фактора и операции, а не делают вывод только по надписи «MFA включена».

Как принять внедрение: положительный и отрицательный тест

• Пользователь с разрешённым методом входит и выполняет рабочую операцию.
• Неверный или отсутствующий фактор не обходится слабым fallback.
• Новый метод нельзя бесконтрольно добавить по украденному паролю.
• Потеря телефона или ключа отрабатывается по проверенному сценарию.
• Аварийный вход доступен уполномоченным и сопровождается уведомлением.
• Старые клиенты и протоколы имеют явный проверенный статус.
• Отзыв методов и активных сессий проверен отдельно.

Фиксируйте сервис, пользователя, тип клиента, время, версию, ожидаемую политику и фактический результат. Не публикуйте рабочие QR, токены и recovery-коды как «скриншот подтверждения».

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

Учебная модель: число факторов и требование политики

В ZIP находится небольшая офлайн-модель. Она различает два секрета знания, пароль плюс TOTP и корректно проверяемый FIDO/WebAuthn с обязательным UV. Для условного критичного ресурса дополнительно требуется phishing-resistant способ.

# Windows, после распаковки ZIP
py -3 mfa-policy-model.py
# Linux: соответствующая команда вместо Windows-варианта
python3 mfa-policy-model.py

PASS_OFFLINE_FACTOR_MODEL означает 12 проверок таксономии и объявленной политики. verified_inputs — заданный флаг, а не результат реальной проверки пароля, OTP, UV, подписи или Origin. Модель не выдаёт NIST AAL и не проверяет независимость ваших устройств.

Первичные источники: NIST SP 800-63B-4, WebAuthn, FIDO passkeys, TOTP, требования к силе аутентификации Entra. Проверены 14 ноября 2026 года; живые методы, сервисы и восстановление при подготовке не испытывались.

Скачать план и карточку приёмки

Архив не содержит секретов, seed, QR, активных токенов и резервных кодов. Это планирование, а не готовый сервер аутентификации.

Поможем организовать доступ и сопровождать сервисы

Вопросы и ответы