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

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

Начинать нужно с критичности доступа

У корпоративного портала или внутреннего приложения иногда есть окно для обслуживания. У MFA его почти нет: задержка push-уведомления или одноразового кода останавливает вход во все системы, связанные со вторым фактором. Отказ одного компонента быстро превращается в проблему для сотрудников, поддержки и ИТ-службы.

Поэтому в требованиях к сервису полезно зафиксировать несколько сценариев: что произойдёт при недоступности дата-центра, канала связи, балансировщика, базы данных и самого внешнего провайдера. Для каждого сценария нужны допустимое время простоя, порядок переключения и ответственный за проверку. Формулировка «высокая доступность» без этих параметров мало помогает при проектировании.

Нагрузка тоже требует конкретики. В описанной архитектуре облачного MFA-сервиса свыше миллиона пользователей, а самый плотный период приходится на 09:00–10:00: люди одновременно начинают смену, подключаются к VPN и подтверждают вход. Пиковая нагрузка измеряется не только числом учётных записей, но и синхронностью действий. Компания с несколькими тысячами сотрудников может столкнуться с похожим паттерном утром после длинных выходных или при массовом переходе на удалённую работу.

Локальный контур приносит ответственность за каждый слой

On-premise-развёртывание обосновано там, где данные и компоненты нельзя выводить за периметр: в изолированных сегментах, критической инфраструктуре, части финансовых и государственных организаций. Такой контур позволяет самостоятельно управлять обновлениями, резервным копированием, мониторингом и правилами сетевого доступа. Он сохраняет работоспособность при отсутствии внешнего канала, если все необходимые зависимости находятся внутри сети.

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

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

Облако проверяют по схеме переключения

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

При отключении одной площадки трафик направляется на другую; третий контур подключается при недоступности основного кластера. Балансировка происходит на стороне адаптеров, поэтому переключение не требует действия пользователя. Такая схема исключает единственную точку отказа и помогает поддерживать заявленную доступность 99,99 % при среднем времени ответа до 30 мс. Эти цифры сами по себе не служат универсальной нормой, зато показывают, какие метрики поставщик должен раскрыть для проверки.

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

База данных и журналы требуют отдельных решений

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

В рассмотренной инфраструктуре MongoDB развёрнута минимум на трёх виртуальных машинах в каждом дата-центре, а репликация использует Replicaset. Для чтения применяются SSD с производительностью до 25 000 IOPS, для записи — до 15 000 IOPS. Журналы вынесены на выделенные серверы, чтобы поток событий безопасности не перегружал вычислительный контур аутентификации.

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

Регуляторные требования задают тип площадки

Выбор локального решения часто связывают с требованиями регуляторов. На практике возможен ещё один вариант — аттестованный облачный сегмент. В июле 2026 года облачная часть MULTIFACTOR получила аттестат соответствия требованиям ФСТЭК России для класса защищённости К1 и уровня защищённости персональных данных УЗ1; также заявлено соответствие приказам ФСТЭК № 17 и № 21.

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

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

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

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