Как мы проектировали архитектуру сервиса MFA для миллиона пользователей

Система многофакторной аутентификации находится на критическом участке корпоративной инфраструктуры. Через нее проходят практически все сценарии доступа пользователей: подключение к VPN, вход в виртуальные рабочие столы, корпоративную почту, внутренние веб-приложения, облачные сервисы и административные панели. Если сервис аутентификации становится недоступным, сотрудники не могут начать работу независимо от того, насколько исправно функционируют остальные информационные системы.

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

За последние несколько лет нам пришлось реализовать обе модели. MULTIFACTOR используется как классическое on-premise решение внутри инфраструктуры заказчиков и одновременно существует как облачный сервис, который ежедневно обслуживает более миллиона пользователей. За это время стало очевидно, что вопрос «облако или коробка» уже не отражает реальную картину. Гораздо важнее понять, какие требования предъявляются к системе и каким образом должна быть построена ее архитектура.

Когда локальное развертывание действительно необходимо

Несмотря на развитие SaaS-модели, локальная установка остается востребованной во многих проектах.

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

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

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

Именно поэтому значительная часть коммерческих компаний сегодня предпочитает облачную модель.

Что означает облачная модель для сервиса MFA

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

На практике промышленная инфраструктура системы аутентификации значительно сложнее.

В отличие от большинства корпоративных приложений, сервис MFA практически невозможно «остановить на обслуживание». Если пользователь не получил push-уведомление или одноразовый код, он не сможет получить доступ ни к одному корпоративному сервису.

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

В результате ключевыми требованиями стали:

• отсутствие единой точки отказа;

• возможность обслуживания инфраструктуры без остановки сервиса;

• горизонтальное масштабирование;

• географическое резервирование;

• автоматическое переключение между площадками;

• минимальная задержка обработки запросов.

Как устроена облачная инфраструктура MULTIFACTOR

Сегодня облачная версия MULTIFACTOR обслуживает более 1 000 000 пользователей.

Каждый рабочий день система обрабатывает сотни тысяч операций аутентификации. Наиболее высокая нагрузка приходится на период с 09:00 до 10:00, когда пользователи одновременно начинают рабочий день, подключаются к VPN, открывают корпоративные приложения и подтверждают вход через второй фактор.

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

Поэтому промышленная инфраструктура проектировалась сразу как распределенная система.

Первый уровень отказоустойчивости — три независимых дата-центра

Основные производственные контуры MULTIFACTOR развернуты в инфраструктуре Selectel и Ростелеком. Архитектура построена сразу в трех дата-центрах, объединенных выделенными каналами Direct Connect и собственными волоконно-оптическими линиями связи.

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

Также компания арендует волоконно-оптические линии связи, чтобы обеспечивать высокую скорость передачи данных между несколькими дата-центрами. Основные мощности находятся в Санкт-Петербурге и Москве.

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

Подобная схема позволяет не только исключить единую точку отказа, но и использовать вычислительные ресурсы всех площадок одновременно. Именно такая архитектура позволяет поддерживать доступность сервиса на уровне 99,99 %, а среднее время ответа не превышает 30 мс.

Второй уровень — разделение сервисов

В облачной инфраструктуре MULTIFACTOR используется более 100 виртуальных серверов и 600 подов.

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

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

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

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

Третий уровень — отказоустойчивая база данных

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

Основная MongoDB развернута минимум на трех виртуальных машинах в каждом дата-центре.

Репликация организована по схеме Replicaset, благодаря чему отказ любого отдельного узла не приводит к остановке сервиса.

Для хранения используются SSD-диски производительностью до 25 000 IOPS при чтении и 15 000 IOPS при записи.

Журналы событий вынесены на отдельные выделенные серверы, что позволяет не создавать дополнительную нагрузку на вычислительный контур.

Для защиты от DDoS-атак команда компании МУЛЬТИФАКТОР использует NGENIX, который также играет роль балансировщика запросов между тремя дата-центрами.

Аттестованное гособлако

При разработке облачной версии MULTIFACTOR мы исходили из того, что инфраструктура заказчиков существенно различается. Одним компаниям необходима максимально производительная облачная платформа с высокой доступностью, другим — возможность размещения решения в аттестованной инфраструктуре, соответствующей требованиям ФСТЭК России.

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

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

Еще один шаг в развитии облачной версии

В июле 2026 года облачная часть MULTIFACTOR получила собственный аттестат соответствия требованиям ФСТЭК России.

Информационная система соответствует требованиям по защите информации для класса защищенности К1, уровня защищенности персональных данных УЗ1, а также требованиям приказов ФСТЭК России № 17 и № 21.

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

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