Когда на RDP или VPN одновременно приходит несколько тысяч запросов авторизации, 2FA перестает быть просто удобным способом безопасного входа. Это становится чисто инженерной задачей: как выдержать нагрузку, не потерять запросы на авторизацию и не превратить безопасность в точку отказа.

Мы в МУЛЬТИФАКТОР несколько лет решаем именно этот вопрос — строим систему двухфакторной аутентификации, которая работает в больших и маленьких корпоративных сетях, поддерживает все основные протоколы и при этом не зависит от зарубежных сервисов. В этой статье расскажем о том, как устроена система MULTIFACTOR: архитектура, взаимодействие компонентов и инженерные решения, которые позволяют системе быть стабильной при любой нагрузке.

Архитектура
MULTIFACTOR — это решение для двухфакторной аутентификации и централизованного контроля доступа, спроектированное как распределённая отказоустойчивая система, работающая в облачной модели (SaaS).
Основная идея архитектуры решения — отделить ядро аутентификации и политики безопасности от точек интеграции, чтобы обеспечить гибкость подключения любых систем: от VPN и RDP до облачных приложений и кастомных корпоративных решений.
Система состоит из нескольких основных уровней:
AuthCore — движок аутентификации и проверки факторов.
Gateway Layer — набор адаптеров (RADIUS, LDAP, SAML, OIDC, API), принимающих запросы извне.
Storage Layer — отказоустойчивое хранилище пользовательских данных и токенов.
Push Broker — собственный сервис доставки уведомлений.
Audit & Telemetry — система логирования и аналитики.
Ядро работает в мультиоблачной конфигурации. Сервера расположены в Москве в трех дата-центрах (DataLine, Selectel, Linx Cloud). Отказ одного из них не повлияет на доступность сервиса: балансировщики на входе перенаправят трафик на активный узел.
Как это работает на практике
Рассмотрим пример интеграции системы двухфакторной аутентификации MULTIFACTOR с сайтом или приложением.
Пользователь вводит логин и пароль на вашем сайте.
Сайт проверяет корректность введённых данных в своей системе.
Если учётные данные верны, сайт обращается к API MULTIFACTOR для создания запроса доступа.
В ответе API возвращается уникальный адрес страницы, на которую нужно перенаправить пользователя для прохождения второго фактора.
Сайт перенаправляет пользователя на страницу MULTIFACTOR.
Пользователю предлагается подтвердить вход с помощью второго фактора — например, push-уведомления или одноразового пароля (OTP).
После успешного подтверждения MULTIFACTOR формирует токен доступа (JWT) и возвращает пользователя обратно на сайт.
Сайт проверяет подлинность токена и, если всё корректно, авторизует пользователя.
Таким образом, MULTIFACTOR полностью берёт на себя второй фактор аутентификации и выдает сайту или приложению проверенный токен доступа, не храня при этом пароли ваших пользователей.
Как передается подтверждение
Взаимодействие между сайтом и MULTIFACTOR основано на JSON Web Token (JWT) — современном стандарте обмена аутентификационной информацией.
При всей сложности названия, JWT имеет простую структуру и его очень удобно использовать. Он компактен, легко проверяется и безопасно передается по HTTP благодаря кодировке base64-url.
Структура JWT
Токен состоит из трех частей, разделённых точками, например: xxx.yyy.zzz
Заголовок описывает формат токена:
{
"typ": "JWT", //тип : JWT
"alg": "HS256" //алгоритм подписи: HMAC с использованием SHA-256
}
Во втором блоке передаются сведения о пользователе или аутентификации:
{
"iss": "https://access.multifactor.ru", //кто выдал
"aud": "rs_1a913e4ea690ac12ea163331dd60d", //кому выдан (ApiKey)
"sub": "user@example.com", //имя пользователя
"jti": "RxMEyo9", //id токена
"iat": 1571684399, //когда выдан
"exp": 1571684699, //срок действия
"returnUrl": "/", //произвольный ключ
"rememberMe": "False", //произвольный ключ
"createdAt": "10/21/19 6:59:55 PM" //произвольный ключ
}
Второй блок содержит обязательные и необязательные ключи. Необязательные поля — это любые дополнительные данные, переданные в API (например, роли, метки безопасности, returnUrl и др.). Обязательные ключи зарезервированы системой MULTIFACTOR и всегда присутствуют в токене. Пример таких ключей:
Ключ |
Название |
Описание |
Значение |
iss |
Issuer |
Сторона, где был выдал токен |
|
aud |
Audience |
Кому предназначен токен |
ApiKey из настроек в личном кабинете |
sub |
Subject |
Идентификатор пользователя |
Из параметра 'Identity' API |
jti |
JWT ID |
Идентификатор токена |
Совпадает с идентификатором запроса доступа |
iat |
Issued At |
Дата/время выдачи |
в формате UNIX time |
exp |
Expiration Time |
Дата/время окончания действия |
в формате UNIX time |
Подпись токена
MULTIFACTOR поддерживает два алгоритма подписи:
HS256 — HMAC-SHA256 с использованием вашего секретного ключа (API Secret);
RS256 — подпись закрытым ключом MULTIFACTOR, проверяется открытым ключом: https://api.multifactor.ru/.well-known/jwks.json.
RS256 предпочтителен, так как полностью исключает возможность подделки токена внутри организации.
Проверка токена и авторизация пользователя
После успешного прохождения второго фактора пользователь возвращается на ваш сайт по адресу, указанному при создании запроса.
В параметре accessToken передаётся JWT, который необходимо проверить:
Проверить дату выдачи и срок действия (iat, exp);
Проверить аудиторию (aud) — должен совпадать с вашим ApiKey;
Проверить подпись токена.
Если все проверки пройдены, пользователь авторизуется, и вашему сайту можно выдать сессионную куку.
MULTIFACTOR поддерживает все основные протоколы корпоративной интеграции:
RADIUS — для VPN, Wi-Fi, сетевых шлюзов и NPS.
LDAP — для прямых обращений приложений и сервисов.
SAML / OIDC — для реализации SSO и интеграции с SaaS-платформами.
REST API — для кастомных сценариев и внутренней автоматизации.

Виды ресурсов, которые защищает MULTIFACTOR:
Средства коммутации, аппаратные и программные межсетевые экраны (Check Point, Cisco, UserGate, Citrix Gateway и др.);
Средства облачной виртуализации (VMware vCloud, Huawei Cloud и др.);
Удаленные рабочие станции и VDI (Citrix, RDP, VMware Horizon и др.);
Облачные приложения (GSuite, Trello, SalesForce, Slack и др.);
Windows-инфраструктура (Outlook Web Access, Windows VPN, NPS, Remote Desktop Gateway и др.);

Производительность и масштабирование
Главное требование к системе 2FA — не замедлять аутентификацию. Среднее время ответа MULTIFACTOR при нагрузочных тестах (RADIUS) — около 180 мс, включая сетевые задержки и проверку факторов. На уровне адаптера один инстанс способен обрабатывать ~120 транзакций в секунду, масштабирование выполняется горизонтально без изменения конфигурации.
Для сценариев с пиковыми нагрузками (например, при начале рабочего дня) мы внедрили брокер сообщений NATS.
Хранение данных и криптография
MULTIFACTOR не хранит пароли пользователей, только хэши и временные артефакты. Для OTP используется одноразовый HMAC-SHA1/256, для пуш-подтверждений — схема ECDSA-SHA256 с асимметричными ключами клиента. Каждая операция подписывается и валидируется сервером по времени и nonce, что исключает возможность повторного воспроизведения (replay attack).
Данные в хранилище шифруются на уровне столбцов с использованием ключей AES-256, управляемых через собственный KMS-модуль. Репликация выполняется по защищенному каналу IPSec. Все события аутентификации фиксируются в аудит-логе, доступном через API и интерфейс администратора.
Self-Service Portal и мобильное приложение
Для снижения нагрузки на админов создан портал самообслуживания. Через него пользователи могут зарегистрировать новый фактор (например, приложение или токен), сбросить пароль или заново привязать устройство.
Портал написан на C# и JavaScript, общение с облаком идет по REST API. Каждое действие требует подтверждения существующего фактора или временного токена, что предотвращает злоупотребления.
Мобильное приложение MULTIFACTOR полностью разработано внутри компании. Оно использует Firebase, Apple Push Notification Service, Huawei Push Kit. Кроме того, мы построили собственный транспорт уведомлений Pushed, который доставляет пуши, если доставка через сторонние сервисы не осуществлена. Это важно для работы в закрытых или импортонезависимых инфраструктурах: приложение функционирует даже без доступа к Google Services.
Наблюдаемость и аудит
Для телеметрии используется стек Prometheus + Grafana, а для логов ElasticSearch (ELK). Каждое событие авторизации имеет собственный trace ID, что позволяет детально анализировать поведение системы и пользователей.
Внутренний дашборд показывает:
среднее время подтверждения MFA по типу фактора;
географию логинов;
процент отклонённых запросов;
SLA адаптеров и брокеров.
Эти данные помогают отлаживать систему и выявлять аномалии — например, массовые входы из нетипичных регионов или необычные отклонения во времени отклика.
Развитие сервиса
Сейчас команда продолжает углублять интеграцию со службой каталогов MULTIDIRECTORY, чтобы единая идентичность пользователя автоматически распространялась во все компоненты инфраструктуры.
Также ведется работа над расширением возможностей второго фактора. В текущей разработке подтверждение 2FA через российский мессенджер «eXpress», а в дальнейшем планируем добавить поддержку MAX.
Если хотите попробовать систему в деле, подключайтесь к нашему каналу MULTIFACTOR в Telegram — там можно узнать основные новости про систему и оставить обратную связь. Мы внимательно собираем идеи от инженеров и админов, именно из них рождаются следующие релизы.
Repredess
Как я вижу мы по чуть чуть абстрагируемся от иностранных сервисов. Последнее время часто сталкиваюсь с непонятками юридических сторон.
Как я вижу, мы постепенно отходим от иностранных сервисов — не из «патриотизма», а потому что интеграции с зарубежными SaaS становятся всё более мутными. Компании подключают такие инструменты, даже не понимая, где крутятся их данные, соответствуют ли они 152-ФЗ и что будет при первой же проверке.
Рынок пользуется, а правовой статус до конца никто не проговорил. Такое ощущение, что все надеются на «авось», хотя вопросов становится только больше. Был у кого то такой опыт?