Двухфакторная аутентификация давно стала стандартом защиты корпоративных систем. Но для работы с персональными данными и другими критичными операциями проверки только при входе в систему может быть недостаточно. В этой статье разберем, чем Step-Up Authentication отличается от классической 2FA, в каких сценариях она применяется и как мы реализовали этот механизм в одном из наших проектов.
Почему обычной 2FA недостаточно
Двухфакторная аутентификация (2FA) подтверждает личность пользователя в момент входа в систему. После успешной проверки создается доверенная сессия, и до ее завершения пользователь получает доступ к разрешенным ресурсам без повторной аутентификации.
В качестве второго фактора чаще всего используются:
- SMS или Email OTP (One-Time Password) - одноразовый код, который пользователь получает по SMS или электронной почте после ввода пароля.
- TOTP (Time-based One-Time Password) - одноразовый код из приложения-аутентификатора, например, Яндекс Ключ, Google Authenticator, Microsoft Authenticator или Authy. Код генерируется локально на устройстве пользователя и обновляется через определенный интервал времени.
Этот подход хорошо защищает процесс входа в систему, но не всегда подходит для работы с чувствительными данными. Кроме того, современные атаки все чаще направлены на компрометацию уже активных пользовательских сессий. Поэтому однократной проверки личности при авторизации уже недостаточно – для критичных операций требуется дополнительное подтверждение.
Именно эту задачу решает Step-Up Authentication (аутентификация с повышением уровня доверия).
Что такое Step-Up Authentication и когда она необходима
В отличие от классической двухфакторной аутентификации (2FA), Step-Up Authentication запрашивает дополнительное подтверждение личности не в момент входа в систему, а при попытке выполнить действие, требующее повышенного уровня доверия.
Например:
- пользователь работает с общего устройства, и открытую сессию может использовать другой человек
- сессия остается активной длительное время, поэтому перед выполнением чувствительной операции требуется повторное подтверждение личности
- пользователь вошел в систему с одним уровнем доверия, но пытается получить доступ к ресурсу, который требует более строгой аутентификации
Именно последний сценарий реализовывался в нашем проекте: усиленная аутентификация требовалась при доступе к данным о заработной плате. Дополнительную проверку необходимо было выполнять только при обращении к определенным API, не меняя общий процесс авторизации пользователя.
Технически такой механизм обычно реализуется через ACR (Authentication Context Class Reference) - значение в токене, которое отражает контекст и уровень выполненной аутентификации: например, вход только по паролю или с дополнительным OTP. При обращении к защищенному ресурсу приложение проверяет значение ACR и принимает решение: предоставить доступ или запросить дополнительную аутентификацию.
Почему стандартных возможностей тоже недостаточно
Большинство современных Identity Provider поддерживают Step-Up Authentication. Например, в Keycloak этот механизм можно реализовать через ACR. Разработчик задает, какие ресурсы требуют повышенного ACR, а приложение проверяет это значение в токене и при необходимости перенаправляет пользователя на дополнительную аутентификацию.
В нашем проекте в качестве Identity Provider использовался WSO2. Платформа также поддерживает несколько вариантов второго фактора «из коробки»: SMS OTP, Email OTP, Passkey и Magic Link.
Однако этих возможностей оказалось недостаточно из-за особенностей бизнес-логики:
- PIN-код должен оставаться действительным в течение шести месяцев
- внешние системы используют этот PIN-код как пароль пользователя
- дополнительная проверка должна выполняться на уровне отдельного gateway, независимо от Identity Provider
Реализовать такие требования средствами WSO2 без существенной кастомизации было невозможно. Поэтому мы выбрали другой подход – разработали отдельный сервис PIN-кодов, который отвечает за Step-Up Authentication независимо от механизма основной аутентификации.
Архитектура решения
Вместо того чтобы выполнять дополнительную проверку непосредственно в Identity Provider, мы вынесли Step-Up Authentication в отдельный gateway-микросервис (gateway-2fa). Через него проходят только запросы к API, для которых требуется повышенный уровень доверия. Все остальные запросы продолжают обрабатываться по обычному маршруту. Это позволило отделить механизм дополнительной аутентификации от основной схемы авторизации и применять его только там, где это было нужно.
Работа решения выглядит следующим образом:
- Изначально веб-приложение направляет пользователя в сервис PIN-кодов для его генерации. Сервис генерирует PIN-код, сохраняет его в базе данных в зашифрованном виде и отправляет пользователю по электронной почте и SMS.
- После успешного ввода PIN-кода сервис формирует и подписывает cookie с заданным временем жизни (TTL), подтверждающую прохождение Step-Up Authentication.
- При последующих обращениях к защищенным API gateway-2fa проверяет наличие этой cookie. Если она отсутствует или не содержит подтверждения второго фактора, доступ к ресурсу отклоняется, а пользователю предлагается повторно пройти дополнительную аутентификацию.
Для защиты от повторного использования или подмены cookie выполняется дополнительная проверка: gateway сравнивает ключевые поля JWT-токена пользователя с содержимым cookie. Если данные не совпадают, запрос отклоняется.
Как Step-Up Authentication выглядит для пользователя
Для пользователя механизм дополнительной аутентификации остается практически незаметным и срабатывает только при обращении к защищенным данным.
На примере нашего приложения сценарий выглядит следующим образом.
- Пользователь запрашивает персональные данные Поскольку подтверждение Step-Up Authentication отсутствует, приложение получает ответ 401 Unauthorized и предлагает пользователю ввести PIN-код.
- Пользователь вводит PIN-код После успешной проверки сервис формирует подписанную cookie, подтверждающую прохождение дополнительной аутентификации.
- Пользователь получает доступ к данным До окончания времени жизни cookie повторный ввод PIN-кода не требуется - пользователь может работать с защищенными ресурсами без дополнительных действий.
- Ошибка при вводе PIN-кода Если PIN-код введен неверно, дополнительная аутентификация не считается пройденной, а доступ к защищенному ресурсу остается закрытым.
Что получилось
Разработанный механизм Step-Up Authentication уже используется в проекте для защиты чувствительных операций. Дополнительная аутентификация запрашивается только при обращении к определенным API, поэтому не влияет на привычный сценарий работы пользователя и не усложняет процесс входа в систему.
Для мониторинга работы решения мы собираем статистику использования в Matomo и технические метрики в ELK. Это позволяет отслеживать количество запросов на создание и проверку PIN-кодов, анализировать нагрузку на сервис и выявлять возможные проблемы на ранних этапах.
(метрики из Matomo)
(график из ELK)
Почему Step-Up Authentication становится стандартом
Сегодня Step-Up Authentication рассматривается не как опциональное улучшение, а как архитектурный стандарт. Во многом это связано с развитием концепции Zero Trust, согласно которой доверие к пользователю не должно сохраняться автоматически после успешного входа в систему. Каждая операция, связанная с чувствительными данными или критичными действиями, должна оцениваться с учетом текущего контекста и уровня доверия.
Еще одна причина - изменение характера современных угроз. Если раньше основной задачей было защитить процесс входа в систему, то сегодня злоумышленники все чаще пытаются использовать уже существующие пользовательские сессии. В таких сценариях дополнительная аутентификация перед выполнением критичных операций позволяет существенно снизить риски.
Что важно учесть при внедрении
При проектировании Step-Up Authentication стоит заранее определить несколько ключевых параметров.
Время жизни подтверждения (TTL). Оно должно обеспечивать баланс между безопасностью и пользовательским опытом. Слишком короткий TTL приведет к частым запросам дополнительной аутентификации, слишком длинный - снизит эффективность механизма.У нас на проекте TTL - 20 минут.
Хранение и защита PIN-кодов. Если в качестве второго фактора используются PIN-коды, необходимо использовать стойкие алгоритмы шифрования и исключить хранение чувствительных данных в открытом виде.
Нагрузочное тестирование. Перед запуском важно проверить, как дополнительный сервис аутентификации поведет себя под ожидаемой нагрузкой, поскольку он становится частью критического пользовательского сценария.
Логирование. Логи должны содержать достаточно информации для диагностики и расследования инцидентов, но при этом не раскрывать чувствительные пользовательские данные.
Заключение
Step-Up Authentication позволяет усилить защиту корпоративных систем без ухудшения пользовательского опыта. Вместо того чтобы запрашивать второй фактор при каждом входе, дополнительная аутентификация выполняется только там, где это нужно.
В нашем проекте стандартных возможностей Identity Provider оказалось недостаточно, поэтому механизм Step-Up Authentication был вынесен в отдельный сервис PIN-кодов с проверкой на уровне gateway. Это позволило нам реализовать требования бизнеса независимо от используемого IdP и гибко управлять доступом к защищенным ресурсам.