Внедрение обязательной MFA и переход на Passkeys: лучшие практики

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

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

1. Каковы скрытые операционные издержки и ловушки для пользовательского опыта при массовом внедрении MFA?

2. Если предоставить пользователям выбор, какие методы MFA они на самом деле выбирают и какие риски безопасности это создает?

3. Как восстановление аккаунта становится главной проблемой в среде с обязательной MFA и какие компромиссы приходится искать для ее решения?

4. Почему Passkeys — это стратегическое решение проблем, созданных обязательной MFA, а не просто еще один вариант?

5. Каков практический пошаговый план для успешного перехода от обязательной устаревшей MFA к превосходной безопасности и удобству Passkeys?

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

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

Эволюция аутентификации — это прямой ответ на внутреннюю слабость ее самой базовой формы.

• Однофакторная аутентификация (SFA): Знакомая комбинация имени пользователя и пароля. Она основана на одном факторе «знания» — том, что пользователь знает. Ее уязвимость к фишингу, атакам с подстановкой учетных данных и брутфорс-атакам является основной причиной для внедрения более надежных методов.

• Двухэтапная проверка (2SV): Часто используемый как синоним MFA, 2SV — это отдельный и более слабый процесс. Он требует двух шагов проверки, но может использовать два фактора из одной и той же категории. Распространенный пример — пароль, за которым следует секретный вопрос; оба являются факторами «знания». Хотя это лучше, чем SFA, это не соответствует критериям настоящей многофакторной безопасности.

• Многофакторная аутентификация (MFA): Золотой стандарт безопасности, MFA требует подтверждения как минимум из двух разных категорий факторов аутентификации. Три основные категории:

  • Знание: Что-то, что пользователь знает (например, пароль, PIN-код).

  • Владение: Что-то, что у пользователя есть (например, мобильный телефон, получающий код, аппаратный ключ безопасности).

  • Свойство: Что-то, чем пользователь является (например, отпечаток пальца, распознавание лица).

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

Этот сдвиг был ускорен регуляторными катализаторами, в первую очередь второй Платежной директивой Европы (PSD2) и ее требованием строгой аутентификации клиентов (SCA). Этот регламент коренным образом изменил европейский ландшафт платежей, сделав MFA обязательной для большинства онлайн-транзакций. Заставив финансовые учреждения внедрить открытые API и более надежную безопасность, PSD2 предоставила нам масштабный реальный пример принудительной аутентификации.

Основной целью SCA было снижение мошенничества за счет требования двух независимых факторов аутентификации для электронных платежей. Однако первоначальное внедрение создало значительные трудности: некоторые европейские продавцы теряли почти 40% транзакций из-за путаницы пользователей и брошенных корзин. Со временем экосистема адаптировалась, и отчет Европейского центрального банка от августа 2024 года подтвердил, что транзакции, аутентифицированные с помощью SCA, теперь имеют значительно более низкие показатели мошенничества. Это демонстрирует долгосрочную выгоду для безопасности, но также подчеркивает критическую необходимость сбалансировать безопасность и пользовательский опыт.

Хотя эти требования изначально создают трудности, они также формируют среду для непроизвольного массового обучения. Когда миллионы пользователей вынуждены по требованию своих банков подтверждать транзакцию отпечатком пальца или кодом, они привыкают к концепции второго фактора. Эта нормализация, обусловленная регулированием, парадоксальным образом облегчает путь для других организаций. Диалог может сместиться с «Что такое MFA и зачем она мне нужна?» на «Вот наш новый, более простой способ выполнить тот шаг безопасности, с которым вы уже знакомы». Это создает идеальную основу для внедрения превосходного опыта, такого как Passkeys.

Если вы хотите узнать больше о специфике этих правил и их связи с Passkeys, вы можете изучить эти ресурсы:

• Анализ требований PSD2 и SCA

• Что требования SCA означают для Passkeys

• PSD2 и Passkeys: устойчивая к фишингу MFA, соответствующая PSD2

• Последствия PSD3 / PSR для Passkeys

• Делегированная аутентификация и Passkeys в рамках PSD3 / PSR

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

Когда регистрация обязательна, плохой пользовательский опыт — это уже не просто досадная мелочь, а прямое препятствие для бизнес-операций. Организации обычно выбирают между двумя стратегиями: принудительная регистрация, которая требует настройки MFA при следующем входе в систему, или постепенная регистрация, которая со временем предлагает пользователям это сделать. Хотя принудительная регистрация позволяет быстрее достичь соответствия требованиям, она рискует вызвать большее разочарование у пользователей и привести к их оттоку, если процесс не будет безупречным. Успех зависит от соблюдения лучших практик UX, таких как предложение нескольких методов аутентификации, предоставление кристально четких инструкций и обеспечение доступности для всех пользователей, например, путем предоставления текстового секретного ключа вместе с QR-кодом для приложений-аутентификаторов.

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

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

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

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

• Восстановление по email/SMS: Это самый распространенный метод из-за его низкой стоимости и привычности для пользователей. Однако это также критическая уязвимость в безопасности. Если злоумышленник уже скомпрометировал почтовый ящик пользователя — что часто предшествует другим атакам — он может легко перехватить код восстановления и полностью обойти MFA. Этот метод фактически сводит на нет преимущества безопасности, ради которых вводилась обязательная MFA.

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

• Верификация по селфи с документом: Этот метод с высокой степенью уверенности требует, чтобы пользователь сделал селфи в реальном времени и сфотографировал удостоверение личности государственного образца (например, водительские права или паспорт). Системы на базе ИИ затем сверяют лицо с документом для подтверждения личности. Хотя это распространено в банковской сфере и финансовых услугах, где личность проверяется при онбординге, это вызывает опасения по поводу конфиденциальности у некоторых пользователей и требует, чтобы у них был при себе физический документ.

• Цифровые учетные данные и кошельки: Новый, перспективный вариант — использование верифицируемых цифровых учетных данных, хранящихся в цифровом кошельке. Пользователь может предъявить учетные данные от доверенного эмитента (например, правительства или банка), чтобы подтвердить свою личность, не проходя через специфический для сервиса процесс восстановления. Этот метод все еще находится на ранней стадии, но указывает на будущее более портативной и контролируемой пользователем верификации личности.

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

• SMS: Этот метод относительно портативен, так как номер телефона можно перенести на новое устройство с помощью новой SIM-карты. Однако именно этот процесс является вектором атаки, используемым в SIM-своппинге, когда мошенник убеждает мобильного оператора перенести номер жертвы на контролируемую им SIM-карту.

• Приложения-аутентификаторы (TOTP): Это основной источник трудностей для пользователей. Если пользователь заранее не включил функцию облачного резервного копирования в своем приложении-аутентификаторе (эта функция не является универсальной и не всегда используется), секретные ключи, генерирующие коды, теряются вместе со старым устройством. Это вынуждает пользователя проходить полный и часто болезненный процесс восстановления аккаунта для каждого сервиса, который он защитил.

• Push-уведомления: Подобно приложениям TOTP, MFA на основе push-уведомлений привязана к конкретной установке приложения на зарегистрированном устройстве. Новый телефон требует новой регистрации, что вызывает те же проблемы с восстановлением.

Когда организация вводит обязательную MFA и предлагает выбор методов, возникает предсказуемая картина: более 95% пользователей тяготеют к тому, что наиболее знакомо и воспринимается как самое простое, а это часто одноразовые пароли (OTP) на основе SMS. Такое поведение создает парадокс. Директор по информационной безопасности может ввести обязательную MFA для повышения безопасности. Однако, если многие пользователи продолжают полагаться на фишинговый метод, такой как SMS, организация может достичь 100% соответствия требованиям, не улучшив существенно свою защиту от сложных атак. Понимая это, платформы, такие как Microsoft, ввели «предпочтительную системную MFA», которая активно подталкивает пользователей к более безопасным вариантам, таким как приложения-аутентификаторы, вместо SMS или голосовых вызовов. Это подчеркивает критический урок: простого введения обязательной MFA недостаточно. Тип MFA имеет огромное значение, и организации должны активно направлять пользователей от более слабых, уязвимых для фишинга факторов.

Решение о введении обязательной MFA имеет прямое и измеримое влияние на операционные ресурсы. Оно неизбежно вызывает всплеск обращений в службу поддержки, связанных с проблемами регистрации, утерянными аутентификаторами и запросами на восстановление. Исследование Gartner показывает, что 30-50% всех звонков в IT-поддержку уже связаны с проблемами паролей; обязательная MFA, особенно в сочетании с громоздкими процессами восстановления, значительно усугубляет эту нагрузку. Это выливается в прямые затраты, которые технические директора и менеджеры проектов должны предвидеть. Более того, сама служба поддержки становится главной мишенью для атак социальной инженерии, когда злоумышленники выдают себя за разочарованных, заблокированных пользователей, чтобы обманом заставить агентов поддержки сбросить для них факторы MFA.

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

• Первоначальные трудности неизбежны, но управляемы: Внедрение SCA в Европе показало, что принудительное изменение поведения пользователей, даже ради безопасности, поначалу негативно скажется на коэффициентах конверсии. Однако это также показало, что с усовершенствованием процессов и привыканием пользователей эти негативные эффекты можно со временем смягчить. Ключ в том, чтобы предвидеть эти трудности и с самого начала разработать максимально оптимизированный и удобный для пользователя процесс.

• Выбор пользователя — палка о двух концах: Когда пользователям предоставляют выбор, они последовательно выбирают путь наименьшего сопротивления, что часто означает выбор знакомых, но менее безопасных методов MFA, таких как SMS. Это приводит к состоянию «театра соответствия», когда организация выполняет букву требования, но не его дух, оставаясь уязвимой для фишинга. Успешная стратегия должна активно направлять пользователей к более сильным, устойчивым к фишингу вариантам.

• Восстановление доступа становится ахиллесовой пятой: В мире обязательного внедрения восстановление аккаунта превращается из крайнего случая в основную операционную нагрузку и критическую уязвимость безопасности. Опора на электронную почту или SMS для восстановления подрывает всю модель безопасности, в то время как восстановление через службу поддержки финансово нежизнеспособно. Надежный, безопасный и удобный процесс восстановления — это не второстепенная задача, а основное требование для любого успешного внедрения.

• Поэтапное внедрение значительно снижает риски: Попытка внедрения «большим взрывом» для всей пользовательской базы — это стратегия высокого риска. Более разумный подход, проверенный в крупных корпоративных развертываниях, — сначала пилотировать новую систему на небольших, некритичных группах пользователей. Это позволяет команде проекта выявлять и устранять ошибки, совершенствовать пользовательский опыт и собирать обратную связь в контролируемой среде перед полномасштабным развертыванием.

• Централизованная платформа для управления идентификацией — мощный инструмент: Организации, у которых уже есть централизованная платформа управления идентификацией и доступом (IAM) или система единого входа (SSO), находятся в гораздо лучшем положении для плавного внедрения. Центральная система идентификации позволяет быстро и последовательно применять новые политики аутентификации к сотням или тысячам приложений, значительно снижая сложность и стоимость проекта.

Passkeys, созданные на основе стандарта WebAuthn от FIDO Alliance, — это не просто постепенное улучшение по сравнению с устаревшей MFA. Их базовая архитектура, основанная на криптографии с открытым ключом, специально разработана для решения самых болезненных и постоянных проблем, создаваемых обязательным внедрением MFA.

• Решение кошмара с восстановлением: Самая большая проблема обязательной MFA — это восстановление аккаунта. Passkeys решают ее в корне. Passkey — это криптографические учетные данные, которые могут синхронизироваться между устройствами пользователя через его платформенную экосистему (например, iCloud Keychain от Apple или Google Password Manager). Если пользователь теряет телефон, passkey все еще доступен на его ноутбуке или планшете. Это значительно снижает частоту блокировок и уменьшает зависимость от небезопасных каналов восстановления, таких как электронная почта или дорогостоящие обращения в службу поддержки.

• Решение проблемы жизненного цикла устройств: Поскольку Passkeys синхронизируются, получение нового устройства превращается из момента больших трудностей в плавный переход. Когда пользователь входит в свою учетную запись Google или Apple на новом телефоне, его Passkeys автоматически восстанавливаются и готовы к использованию. Это устраняет болезненный процесс повторной регистрации для каждого приложения, который требуется для традиционных, привязанных к устройству приложений-аутентификаторов.

• Решение парадокса пользовательских предпочтений: Passkeys разрешают классический компромисс между безопасностью и удобством. Самый безопасный доступный метод аутентификации — устойчивая к фишингу криптография с открытым ключом — также является самым быстрым и простым для пользователя. Достаточно одного биометрического жеста или PIN-кода устройства. У пользователя нет стимула выбирать более слабый, менее безопасный вариант, потому что самый сильный вариант также является самым удобным.

• Решение проблемы уязвимости к фишингу: Passkeys устойчивы к фишингу по своей конструкции. Пара криптографических ключей, созданная при регистрации, привязана к конкретному источнику веб-сайта или приложения (например, corbado.com). Пользователя нельзя обманом заставить использовать свой passkey на поддельном фишинговом сайте (например, corbado.scam.com), потому что браузер и операционная система распознают несоответствие источника и откажутся выполнять аутентификацию. Это обеспечивает фундаментальную гарантию безопасности, которую не может предложить ни один метод, основанный на общих секретах (таких как пароли или OTP).

• Решение проблемы усталости от MFA: Одно простое действие пользователя, такое как сканирование Face ID или прикосновение к датчику отпечатков пальцев, одновременно доказывает владение криптографическим ключом на устройстве («то, что у вас есть») и свойство через биометрию («то, чем вы являетесь»). Для пользователя это выглядит как один легкий шаг, но криптографически удовлетворяет требованию многофакторной аутентификации. Это позволяет организациям соответствовать строгим стандартам без добавления лишних шагов и когнитивной нагрузки, связанных с устаревшей MFA.

Переход от устаревшей MFA к стратегии, ориентированной на Passkeys, требует продуманного, многоэтапного подхода, который учитывает технологии, пользовательский опыт и бизнес-цели.

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

• Проанализируйте ваш парк устройств: Используйте существующие инструменты веб-аналитики для сбора данных об операционных системах (iOS, Android, версии Windows) и браузерах, которые предпочитают ваши пользователи.

• Внедрите инструмент проверки готовности к Passkeys: Для получения более точных данных можно интегрировать в ваш веб-сайт или приложение легкий, сохраняющий конфиденциальность инструмент, такой как Corbado Passkeys Analyzer. Он предоставляет аналитику в реальном времени о проценте ваших пользователей, чьи устройства поддерживают платформенные аутентификаторы (такие как Face ID, Touch ID и Windows Hello) и важные улучшения UX, такие как Conditional UI, который обеспечивает автозаполнение Passkey. Эти данные необходимы для построения реалистичной модели внедрения.

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

• Выберите шаблон интеграции:

  • Сначала идентификатор: Пользователь вводит свой email или имя пользователя. Затем система проверяет, зарегистрирован ли для этого идентификатора passkey, и, если да, запускает процесс входа с помощью Passkey. Если нет, она плавно переключается на пароль или другой безопасный метод. Этот подход предлагает лучший пользовательский опыт и обычно приводит к более высоким показателям внедрения.

  • Отдельная кнопка для Passkey: Кнопка «Войти с помощью passkey» размещается рядом с традиционной формой входа. Это проще в реализации, но перекладывает на пользователя обязанность выбрать новый метод, что может привести к более низкому использованию.

• Обеспечьте безопасность резервных вариантов: Ваш резервный механизм не должен подрывать ваши цели безопасности. Избегайте возврата к небезопасным методам, таким как SMS OTP. Более надежная альтернатива — использовать ограниченный по времени одноразовый код или магическую ссылку, отправленную на подтвержденный адрес электронной почты пользователя, что служит фактором владения для конкретной сессии.

Эффективная коммуникация имеет первостепенное значение для плавного внедрения. Цель — представить Passkeys не как очередную проблему с безопасностью, а как значительное улучшение пользовательского опыта.

• Сообщения, ориентированные на выгоду: Используйте ясный, простой язык, который фокусируется на преимуществах для пользователя: «Входите быстрее и безопаснее», «Забудьте о забытых паролях» и «Ваш отпечаток пальца — теперь ваш ключ». Последовательно используйте официальный значок Passkey от FIDO для повышения узнаваемости.

• Стратегия поэтапного внедрения:

  1. Начните с «добровольного» внедрения: Изначально предложите создание Passkey как опцию на странице настроек аккаунта пользователя. Это позволит ранним последователям и технически подкованным пользователям присоединиться, не мешая остальным.

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

  3. Интегрируйте в онбординг: Наконец, сделайте создание Passkey основным, рекомендуемым вариантом для всех регистраций новых пользователей.

Подход, основанный на данных, необходим для подтверждения инвестиций в Passkeys и для постоянной оптимизации опыта. Все команды должны отслеживать метрики, относящиеся к их ролям.

• Метрики внедрения и вовлеченности:

  • Коэффициент создания Passkey: Процент подходящих пользователей, которые создают passkey.

  • Коэффициент использования Passkey: Процент от общего числа входов, выполненных с помощью passkey.

  • Время до первого ключевого действия: Как быстро новые пользователи выполняют критическое действие после внедрения Passkeys.

• Бизнес и операционные метрики:

  • Сокращение обращений по сбросу пароля: Прямая мера снижения затрат на службу поддержки.

  • Сокращение затрат на SMS OTP: Ощутимая экономия средств за счет отказа от устаревшего фактора.

  • Коэффициент успешных входов: Сравнение показателя успешности входов с помощью Passkey и входов с паролем/MFA.

  • Снижение числа инцидентов по захвату аккаунтов: Конечная мера эффективности безопасности.

Следующие таблицы предоставляют краткое резюме, сравнивая методы аутентификации и напрямую сопоставляя решения Passkeys с общими бизнес-проблемами.

Как Passkeys решают проблемы обязательного внедрения MFA

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

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

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

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