MFA для корпоративных сервисов: TOTP для всех, FIDO2-ключи для привилегированных учёток

Клиент из финансового сектора пришёл с запросом, который мы слышим всё чаще: «хотим MFA на все корпоративные сервисы, но у нас 200+ человек, разный уровень технической грамотности, и нельзя всё положить на две недели онбординга». Добавить сюда требования к привилегированным учёткам - администраторы инфраструктуры, доступ к боевым БД, финансовые системы - и задача становится достаточно нетривиальной, чтобы не решать её «ну поставили Google Authenticator, и ладно».

Работаем в рамках managed-сопровождения, поэтому нам же досталось и проектирование схемы, и раскатка, и сопровождение онбординга.

Почему два разных метода

Первое решение, которое нужно было принять: один метод для всех или разные для разных групп. Остановились на двух треках.

TOTP (Time-based One-Time Password) - для основной массы сотрудников. Приложение на телефоне (Google Authenticator, Microsoft Authenticator, Aegis на Android), генерирует шестизначный код раз в 30 секунд. Метод понятный, работает без интернета, приложений на выбор достаточно. Основной минус - уязвим к фишингу: если сотрудник введёт код на поддельном сайте, атакующий успеет использовать его за те же 30 секунд. Для основного офисного персонала этот риск принят как приемлемый при наличии нормального антифишинга.

FIDO2/WebAuthn с аппаратными ключами - для привилегированных учёток. Администраторы серверов, DBA, доступ к production-среде, финансовые системы. Аппаратный ключ (в нашем случае YubiKey 5) принципиально не уязвим к фишингу: протокол привязывает аутентификацию к origin конкретного домена, и поддельный сайт просто не получит валидного ответа. Ключ физически присутствует при аутентификации - украсть учётку удалённо, зная только пароль, недостаточно.

W3C в прошлом году принял WebAuthn как рекомендацию, и это важно: поддержка появилась в Chrome, Firefox, Edge - браузерный сценарий работает без дополнительных плагинов. Windows Hello for Business тоже работает на той же FIDO2-основе, что упрощает интеграцию для Windows-окружений.

Что именно защищаем

До начала работ провели инвентаризацию сервисов - без неё непонятно, к чему подключать MFA. Список получился разнородным:

• VPN-шлюз (корпоративный периметр, все сотрудники) - самый критичный вход, сюда идут в первую очередь
• Корпоративный GitLab и CI/CD - разработчики и DevOps
• Внутренние панели управления - несколько веб-приложений на NGINX+приложение
• Windows Remote Desktop / RD Gateway - уже частично закрыто MFA после прошлого аудита
• Финансовые ERP-системы - ограниченный круг пользователей
• SSH-доступ к серверам - только администраторы

Последние два пункта и SSH сразу попали в категорию «FIDO2 обязателен».

Инфраструктура аутентификации

Центральный узел - FreeRADIUS плюс связка с существующим Active Directory клиента. TOTP-часть реализовали через FreeRADIUS с модулем rlm_totp, учётки в AD остаются основным источником истины, RADIUS добавляет проверку второго фактора.

Для FIDO2 в части SSH - libpam-u2f с поддержкой YubiKey на уровне PAM. Для веб-сервисов, где есть OIDC/SAML - интеграция через Keycloak, который умеет FIDO2 из коробки начиная с версии 8.0. У клиента Keycloak уже стоял как IdP, что упростило задачу.

VPN подключили к RADIUS с двухфакторной цепочкой: пароль AD + TOTP-код (или YubiKey OTP для привилегированных учёток). YubiKey 5 поддерживает и FIDO2, и OTP - один ключ закрывает оба сценария.

Онбординг: где было сложно

Теоретически всё красиво. На практике онбординг 200+ человек за разумное время - это отдельный проект внутри проекта.

Первое - разрыв между «зарегистрировал» и «пользуется». Мы подняли портал самообслуживания: сотрудник логинится под своей AD-учёткой, сканирует QR-код в приложении, подтверждает - готово. Казалось бы просто. Реальность: часть людей делала это правильно, но потом удаляла приложение (очищала телефон, переустанавливала) и не понимала, почему перестало работать. Резервные коды при регистрации стали обязательными, и мы добавили явный экран с объяснением что это такое.

Второе - телефоны у части сотрудников корпоративные, у части личные. Политика клиента допускает личный телефон для TOTP, но это означало что поддержка «у меня не работает код» могла прийти в любое время. Часть проблем оказалась банальной: неправильное системное время на телефоне, TOTP чувствителен к расхождению - окно допуска мы настроили в ±1 интервал (30 секунд в каждую сторону), но телефоны с дрейфующими часами иногда вылетали за пределы.

Третье - YubiKey для привилегированных учёток. Здесь онбординг оказался проще: меньше людей, выше мотивация, понятнее зачем. Основная мука - регистрация ключа в нескольких системах (Keycloak, SSH PAM, VPN). Написали инструкцию на четыре страницы с картинками, провели живую сессию с каждым администратором. Трудоёмко, но ключи зарегистрированы правильно с первого раза.

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

Где сейчас

TOTP раскатан на основную часть сотрудников, VPN и GitLab закрыты. SSH и финансовые системы на FIDO2 работают у всех администраторов. Остался хвост из нескольких внутренних приложений со специфической аутентификацией - там либо доработка приложения, либо проксирование через Keycloak, сейчас на стадии оценки трудозатрат.

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