Обязательная MFA и переход на ключи доступа: лучшие практики

1. Введение: новая реальность обязательной MFA#

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

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

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

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

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

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

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

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

2. Сдвиг в безопасности: понимание контекста обязательной MFA#

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

2.1 Краткое напоминание: SFA, 2SV и настоящая MFA#

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

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

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

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

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

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

  • Биометрия (Inherence): То, кем является пользователь (например, отпечаток пальца, распознавание лица).

2.2 Почему обязательные требования меняют все#

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

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

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

Подобная регуляторная динамика нарастает и в мире. В Австралии финансовый сектор работает в рамках стандарта CPS 234 Австралийского управления пруденциального надзора (APRA), который устанавливает стандарты безопасности для финансовых учреждений. Вслед за волной атак с подстановкой учетных данных в начале 2025 года APRA направило письмо всем советам директоров пенсионных фондов, прямо ожидая от них внедрения MFA или эквивалентных мер защиты для действий с высоким риском. Регулятор отметил, что примерно 20% киберинцидентов в австралийском финансовом секторе были атаками с подстановкой учетных данных, что делает MFA критически важным средством контроля. Кроме того, телекоммуникационный сектор Австралии сталкивается с обязательной MFA для всех транзакций клиентов с высоким риском в соответствии с Определением об аутентификации личности клиентов Австралийского управления связи и СМИ (ACMA) 2022 года. Это правило обязывает операторов использовать MFA при замене SIM-карт, сбросе пароля и добавлении услуг после громких случаев мошенничества с подменой SIM-карт.

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

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

• Analysis of PSD2 & SCA Requirements

• What SCA Requirements Mean for Passkeys

• PSD2 Passkeys: Phishing-Resistant PSD2-Compliant MFA

• SD3 / PSR Implications for Passkeys

• Delegated Authentication & Passkeys under PSD3 / PSR

2.3 Когда утечки безопасности заставляют действовать: внедрение после инцидентов#

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

Сектор пенсионных фондов Австралии столкнулся с этим в жесткой форме в марте 2025 года. В ходе сложной кампании по подстановке учетных данных киберпреступники использовали украденные пары логин-пароль из сторонних утечек для систематических атак на счета пенсионных фондов. Согласно сообщениям Reuters и ABC News, AustralianSuper, крупнейший фонд страны с более чем 3 миллионами участников, подтвердил, что злоумышленники получили доступ примерно к 600 аккаунтам участников и успешно вывели 500 000 австралийских долларов со счетов четырех членов фонда, прежде чем атака была обнаружена. Инцидент затронул несколько фондов: Rest Super обнаружил подозрительную активность примерно в 20 000 аккаунтах, а Insignia Financial сообщила о попытках взлома около 100 аккаунтов.

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

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

Обязательные требования после взлома также возникают из-за фишинговых кампаний, компрометирующих корпоративные учетные данные. В марте 2020 года Service NSW, государственный портал госуслуг штата, подвергся фишинговой атаке, в результате которой произошла утечка 736 ГБ данных, поставившая под угрозу личную информацию примерно 103 000 клиентов. Расследователи установили, что отсутствие MFA на почтовых ящиках сотрудников стало ключевым фактором серьезности инцидента. В ответ Service NSW внедрила MFA во всех внешних системах электронной почты и к августу 2021 года включила ее в 95% внешних систем, при поддержке инвестиций в безопасность в размере 5 миллионов австралийских долларов. После отдельной утечки данных телекоммуникационной компании Optus в 2022 году, Service NSW расширила свои усилия, запустив пилотный проект, а затем сделав MFA обязательной для всех владельцев аккаунтов MyServiceNSW к 2026 году.

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

3. Скрытые сложности: что означает обязательная MFA на практике#

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

3.1 Барьер при регистрации: массовое подключение#

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

3.2 Кошмар восстановления: новая проблема №1 для службы поддержки#

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

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

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

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

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

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

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

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

3.3 Проблема жизненного цикла устройств: новые телефоны, потерянный доступ#

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

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

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

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

3.4 Парадокс пользовательских предпочтений: путь наименьшего сопротивления#

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

Атаки на австралийские пенсионные фонды в марте 2025 года стали ярким подтверждением этой проблемы в реальных условиях. В том инциденте отсутствие какой-либо MFA стало решающей уязвимостью. Однако более широкий урок выходит за рамки дихотомии «MFA или нет MFA» к качеству внедренной MFA. Организации, которые предлагают только MFA на базе SMS в качестве основного или единственного варианта, остаются уязвимыми для фишинга, социальной инженерии и атак с подменой SIM-карт. В австралийском случае злоумышленники воспользовались слабыми учетными данными; если бы эти аккаунты были «защищены» только SMS OTP, злоумышленники, имеющие доступ к скомпрометированным аккаунтам электронной почты, могли бы потенциально перехватить процессы сброса пароля и инициировать подмену SIM-карты, чтобы обойти и этот фактор.

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

3.5 Операционные потери: служба поддержки в осаде#

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

4. Ключевые уроки масштабных внедрений обязательной MFA#

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

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

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

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

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

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

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

5. Неизбежный следующий шаг: почему ключи доступа решают проблему обязательной MFA#

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

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

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

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

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

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

6. Стратегический поворот: план перехода к обязательным ключам доступа#

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

6.1 Шаг 1: Аудит готовности устройств#

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

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

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

6.2 Шаг 2: Проектирование гибридной резервной архитектуры#

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

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

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

  • Специальная кнопка для ключей доступа: Кнопка «Войти с помощью ключа доступа» (Sign in with a passkey) размещается рядом с традиционной формой входа. Это проще реализовать, но возлагает на пользователя ответственность за выбор нового метода, что может привести к более редкому использованию.

• Убедитесь, что резервные варианты безопасны: Ваш резервный механизм не должен подрывать ваши цели безопасности. Избегайте использования небезопасных методов, таких как SMS OTP. Более надежной альтернативой является использование одноразового кода или магической ссылки (magic link), отправляемой на подтвержденный email пользователя, что служит фактором владения для конкретной сессии.

6.3 Шаг 3: Разработка ориентированного на пользователя плана обучения и внедрения#

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

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

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

  1. Начните с самостоятельного внедрения (Pull Adoption): Первоначально предложите создание ключа доступа в качестве опции на странице настроек аккаунта пользователя. Это позволит ранним последователям и технически подкованным пользователям подключиться по желанию, не нарушая процесс для всех остальных.

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

  3. Интеграция в процесс регистрации (Onboarding): Наконец, сделайте создание ключа доступа основным, рекомендуемым вариантом для всех новых регистраций.

6.4 Шаг 4: Мониторинг, измерение и итерации#

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

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

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

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

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

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

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

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

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

  • Снижение числа инцидентов со взломом аккаунтов (Account Takeover): Конечный показатель эффективности безопасности.

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

Как ключи доступа решают проблемы обязательной MFA

Заключение: превращение комплаенса в конкурентное преимущество#

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

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

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

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

О Corbado

Corbado — это Authentication Intelligence Platform для CIAM-команд, обеспечивающих аутентификацию пользователей в крупных масштабах. Мы показываем то, что не видят логи IDP и общие инструменты аналитики: какие устройства, версии ОС, браузеры и менеджеры учётных данных поддерживают passkey, почему регистрации не превращаются в логины, где сбоит WebAuthn-поток и когда обновление ОС или браузера тихо ломает вход — всё это без замены Okta, Auth0, Ping, Cognito или вашего собственного IDP. Два продукта: Corbado Observe добавляет наблюдаемость для passkey и любых других способов входа. Corbado Connect даёт managed passkey со встроенной аналитикой (рядом с вашим IDP). VicRoads использует passkey для более чем 5 млн пользователей с Corbado (+80 % активации passkey). Поговорить с экспертом по passkey →

Часто задаваемые вопросы#

Как работает восстановление аккаунта, когда MFA обязательна для всех пользователей?#

Обязательная MFA делает восстановление аккаунтов главной операционной проблемой. Существует четыре основных варианта: проверка через службу поддержки (безопасно, но дорого), восстановление по email или SMS (дешево, но уязвимо при компрометации email), заранее созданные резервные коды (пользователи часто их теряют) и верификация по селфи и удостоверению личности (selfie-ID). Каждый вариант — это компромисс между безопасностью, стоимостью и масштабируемостью.

Почему обязательная MFA по SMS по-прежнему оставляет организации уязвимыми для фишинга?#

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

Что произошло во время атаки с подстановкой учетных данных на австралийские пенсионные фонды в 2025 году и что это доказывает в отношении MFA?#

В марте 2025 года злоумышленники использовали украденные учетные данные для доступа к примерно 600 аккаунтам AustralianSuper и вывели 500 000 австралийских долларов со счетов четырех участников. HostPlus, который уже внедрил MFA, не сообщил о финансовых потерях в результате той же кампании. Впоследствии APRA направило письмо всем председателям советов директоров пенсионных фондов, сделав внедрение MFA срочным нормативным обязательством, а не планом на будущее.

Чем регистрация нового устройства для ключей доступа отличается от приложений-аутентификаторов TOTP?#

Ключи доступа (passkeys) синхронизируются через экосистемы платформ, такие как Apple iCloud Keychain и Google Password Manager, и автоматически восстанавливаются на новом устройстве без повторной регистрации для каждого сервиса. Приложения-аутентификаторы TOTP теряют все секретные ключи при замене устройства (если резервное копирование в облако не было включено вручную), что делает замену устройства главной причиной обращений в службу поддержки и блокировок аккаунтов при обязательной MFA.

Какова рекомендуемая стратегия поэтапного развертывания при переходе пользователей от устаревшей MFA к ключам доступа?#

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