Готовые решения двухфакторной аутентификации не всегда учитывают реальные требования бизнеса и безопасности. В этом кейсе рассказываем, почему мы отказались от сторонних инструментов и разработали собственный сервис 2FA, который встроился в архитектуру портала и закрыл требования информационной безопасности.
Зачем нужна двухфакторная аутентификация (2FA)
Основная задача 2FA — обеспечить защиту конфиденциальных данных на корпоративном портале. При этом важно сохранить гибкость и удобство, чтобы решение можно было настраивать под задачи компании и не зависеть от сторонних приложений.
Помимо этого, решение должно снизить затраты на поддержку и упростить пользовательский сценарий, исключив установку дополнительных приложений и покупку лицензий.
Почему понадобилась собственная разработка 2FA
Практически на любом корпоративном портале есть функциональность с доступом к чувствительным данным, и без дополнительного уровня защиты такие данные остаются уязвимыми. В компании уже использовалось решение, которое частично ограничивало доступ к ним, но после проверки со стороны информационной безопасности стало ясно, что оно не соответствует установленным требованиям.
Ключевые проблемы были следующими:
- отсутствовало шифрование сгенерированного пин-кода
- не был ограничен срок действия кода
- решение нельзя было переиспользовать в других системах
В таком виде его невозможно было масштабировать и развивать внутри корпоративной архитектуры.
Почему не стали использовать готовое OTP-решение (One-Time Password)
Сторонние OTP-решения кажутся быстрым способом повысить безопасность, но в корпоративной среде их ограничения становятся заметны довольно быстро.
С точки зрения интеграции и гибкости:
- они рассчитаны на стандартные сценарии и не учитывают внутренние процессы
- требуют отдельной интеграции с системой авторизации
- сложно адаптируются под нестандартную бизнес-логику
С точки зрения пользовательского опыта:
- интерфейсы не совпадают с корпоративным дизайном
- система воспринимается как разрозненная
- часто требуется установка мобильного приложения
С точки зрения рисков и затрат:
- появляется зависимость от внешнего поставщика
- сохраняются риски утечки данных
- возникают дополнительные расходы, например на лицензии для push-уведомлений
В результате собственная разработка оказалась более подходящим вариантом: она позволила учесть реальные требования и встроить 2FA в существующую архитектуру без каких-либо ограничений.
Как декомпозировали задачу
После сбора требований мы поняли, что внедрение 2FA не ограничится одной доработкой. Это набор связанных изменений, поэтому задачу разделили на несколько блоков.
В основу решения лег отдельный сервис генерации и проверки пин-кодов. Он отвечает за создание, хранение, срок жизни и валидацию кодов, а также сразу учитывает требования ИБ и возможность переиспользования.
Далее мы проработали следующие пользовательские сценарии:
- первичное получение пин-кода
- повторный вход с действующим кодом
- обработка истечения срока действия
- сброс и повторная генерация
Это позволило заранее учесть возможные пограничные ситуации и корректно заложить бизнес-логику. Отдельно выделили каналы доставки и добавили SMS наряду с email. На уровне безопасности зафиксировали обязательное шифрование пин-кода на клиенте перед отправкой.
Также сразу предусмотрели возможность использования решения в других системах через единый API и реализовали онбординг, чтобы упростить переход пользователей на новую логику.
В результате получилось комплексное решение, включающее:
- сервис пин-кодов
- пользовательские сценарии
- каналы доставки
- механизмы безопасности
- интеграционный слой
- пользовательскую адаптацию
Процесс реализации и внедрения
Как уже писали выше, в основе архитектуры лежит отдельный сервис генерации и проверки пин-кодов, который можно использовать во всех системах, подключенных к платформе. Он решает три задачи:
- генерация и хранение пин-кода в зашифрованном виде
- отправка пользователю по email или SMS
- валидация введенного значения
В рамках этого подхода используется step-up аутентификация — дополнительное подтверждение личности внутри уже активной сессии, когда пользователь запрашивает доступ к операциям с повышенными требованиями к безопасности. Определением и обработкой таких запросов занимается отдельный микросервис-гейтвей, через который проходят все операции с повышенным уровнем доступа.
Сценарий работы выглядит следующим образом:
1. пользователь запрашивает ресурс с персональными данными
2. гейтвей проверяет, пройден ли второй фактор
- если аутентификация уже выполнена, доступ предоставляется
- если нет, инициируется ввод пин-кода
3. при открытии формы сервис проверяет наличие действующего пин-кода
- если код уже есть, используется он
- если нет, генерируется новый и отправляется пользователю
Данные для отправки берутся из JWT-токена, выданного SSO, что упрощает интеграцию с другими системами.
После ввода пин-кода выполняется проверка: по логину пользователя, полученному из JWT-токена, находится сохраненное значение в базе данных и сравнивается с введенным. В случае успеха система устанавливает cookie в формате JWT, поля которого заполняются данными из SSO токена. На протяжении времени жизни cookie пользователь получает доступ к ресурсам без повторного ввода пин-кода.
Поскольку cookie может быть перехвачена или использована повторно, дополнительно выполняется проверка — сравниваются выбранные поля JWT-токена пользователя и самой cookie.
Отдельно мы реализовали сценарий восстановления пин-кода для внешней системы, где он используется как пароль. В этом случае сервис пин-кодов фактически выступает как сервер авторизации, и JWT-токен в запросе отсутствует. В качестве решения внедрили персистентное хранение JWT-токенов пользователей. Это позволяет по логину найти нужный токен и отправить новый пин-код. Ограничением остается необходимость хотя бы одной авторизации пользователя в системе.
Итоговые характеристики решения:
- доступ к API осуществляется через JWT-токен
- срок жизни пин-кода и cookie настраивается в одном сервисе
- архитектура позволяет добавлять новые способы отправки пин-кода
Подведение итогов
Собственное решение позволило повысить уровень защиты корпоративных данных и при этом сохранить удобный пользовательский сценарий. Отказ от сторонних сервисов снизил затраты на поддержку и убрал зависимость от внешних поставщиков.
За счет возможности использования в других системах решение усиливает безопасность всей корпоративной архитектуры и упрощает дальнейшее развитие ИТ-ландшафта компании.