После историй с недоступными SMS многие компании внезапно вспомнили неприятную вещь: если второй фактор завязан только на SMS, то в момент сбоя у вас ломается не “удобство”. У вас ломается доступ.

Особенно больно это выглядит в корпоративной инфраструктуре: VPN, админки, CRM, ERP, складские системы, кассы, подрядчики, техподдержка.

И дальше начинается любимая развилка корпоративной ИБ:

  • не пускаем сотрудников – бизнес страдает;
  • отключаем второй фактор – безопасность страдает;
  • придумываем обходной процесс в момент аварии – страдают вообще все.

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

Ниже – инженерный набор, с чего можно начинать.

1. TOTP: самый простой первый шаг вместо SMS

TOTP – это одноразовый код из приложения-аутентификатора. Он не требует мобильного интернета и SMS. Телефон может быть в авиарежиме, а код все равно будет генерироваться локально.

Это не идеальная защита от современного фишинга, особенно от атак через прокси, но как замена SMS для массового корпоративного доступа – это уже большой шаг вперед.

Что использовать на телефонах

Aegis Authenticator

Хороший вариант для Android: открытый код, шифрование хранилища, поддержка TOTP/HOTP и резервных копий. Репозиторий есть на GitHub, приложение также доступно через F-Droid. (GitHub)

Где уместно:

  • сотрудники;
  • администраторы как временный этап;
  • подрядчики;
  • резервный фактор вместо SMS.

Минус:

  • только Android;
  • TOTP всё еще можно выманить фишингом.

Ente Auth

Интересен тем, что это открытый кроссплатформенный аутентификатор с end-to-end encrypted backup и синхронизацией между устройствами. Подходит, если нужно не потерять токены при замене телефона. (GitHub)

Где уместно:

  • сотрудники с несколькими устройствами;
  • небольшие команды;
  • резервный сценарий при потере телефона.

Минус:

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

FreeOTP

Простой open-source аутентификатор от Red Hat для одноразовых паролей. Поддерживает стандартные OTP-сценарии и добавление токенов через QR-код. (GitHub)

Где уместно:

  • базовый корпоративный rollout;
  • пилот TOTP вместо SMS;
  • ситуации, где нужен максимально простой аутентификатор.

Минус:

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

2. PrivacyIDEA: когда нужен MFA-сервер, а не просто приложение на телефоне

Если нужно не просто сказать сотрудникам “поставьте приложение”, а централизованно управлять токенами, пользователями, политиками и интеграциями, стоит смотреть в сторону privacyIDEA.

Это open-source MFA-платформа, которая позволяет управлять OTP-токенами и встраивать второй фактор в существующие приложения и инфраструктуру. Репозиторий проекта доступен на GitHub. (GitHub)

Где полезно:

  • VPN;
  • SSH;
  • веб-порталы;
  • интеграции через RADIUS/PAM/API;
  • централизованное управление токенами.

Типовая схема для VPN

Самый рабочий корпоративный сценарий:

VPN → RADIUS/PAM → privacyIDEA → AD/LDAP

Пользователь вводит логин, пароль и одноразовый код. VPN передает проверку во внешний контур, а privacyIDEA уже решает, валидный фактор или нет.

У privacyIDEA есть документация по интеграции с OpenVPN: можно использовать PAM-модуль privacyIDEA, прямую интеграцию через RADIUS или PAM-модуль RADIUS в OpenVPN. (GitHub)

Пример логики:

  1. Пользователь подключается к VPN.
  2. VPN спрашивает логин, пароль и OTP.
  3. OpenVPN передает запрос в RADIUS/privacyIDEA.
  4. privacyIDEA проверяет пароль через LDAP/AD и OTP-токен.
  5. VPN принимает или отклоняет подключение.

Это уже сильно лучше, чем “VPN + SMS, а если SMS нет – отключите второй фактор”.

3. Keycloak: SSO, TOTP, recovery codes и WebAuthn

Если у вас уже есть или планируется единый вход, то Keycloak – один из самых популярных open-source вариантов.

Keycloak дает единый вход, управление пользователями, федерацию с внешними каталогами и сильную аутентификацию. Репозиторий проекта открыт на GitHub, а в официальной документации указана поддержка passkey, recovery codes, TOTP/HOTP через Google Authenticator или FreeOTP. (GitHub)

Где уместно:

  • внутренние веб-приложения;
  • порталы;
  • админки;
  • DevOps-сервисы;
  • приложения с OIDC/SAML;
  • постепенный переход к WebAuthn/passkeys.

Минимальный сценарий

Приложение → OIDC/SAML → Keycloak → AD/LDAP + MFA

Для современного приложения это обычно выглядит так:

  1. Включаем Keycloak как поставщика идентификации.
  2. Подключаем AD/LDAP.
  3. Для пользователей включаем обязательный второй фактор.
  4. Для обычных сотрудников – TOTP.
  5. Для администраторов – WebAuthn/FIDO2 или passkeys.
  6. Для аварийных случаев – recovery codes и отдельный процесс восстановления.

Что важно не забыть

Keycloak хорош как центр аутентификации, но сам становится критичным активом. Если он лежит, пользователи не входят. Если он скомпрометирован, последствия неприятные.

Поэтому:

  • кластеризация;
  • резервная база;
  • резервное копирование;
  • отдельные админские роли;
  • аудит изменений;
  • отдельный break-glass процесс;
  • тест восстановления.

Иначе вы просто перенесли хаос из 15 приложений в одну очень важную точку.

4. FIDO2 / WebAuthn / passkeys: для админов и критичных ролей

TOTP хорош как быстрый отход от SMS. Но для администраторов, владельцев критичных систем и сотрудников с доступом к чувствительным данным лучше идти в сторону FIDO2/WebAuthn.

Почему?

Потому что FIDO2/WebAuthn устойчивее к фишингу. Пользователь не переписывает код руками, а браузер и ключ/устройство участвуют в криптографической проверке привязки к домену.

Keycloak поддерживает passkeys/WebAuthn, но эта возможность должна быть включена и настроена в политиках WebAuthn Passwordless Policy. (Keycloak)

Где применять первым

Не надо начинать с лозунга “завтра всем FIDO2”.

Начинать лучше с групп высокого риска:

  • администраторы домена;
  • администраторы VPN/NGFW;
  • DevOps;
  • владельцы CI/CD;
  • доступ к облакам;
  • финансы;
  • руководители с доступом к чувствительным данным;
  • учетные записи для удаленного администрирования.

Что использовать

Аппаратные ключи

YubiKey, Рутокен, другие FIDO2-совместимые ключи – нормальный путь для админов и критичных ролей.

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

Passkeys

Passkeys удобнее для массового внедрения, потому что могут использовать встроенные механизмы устройства: Windows Hello, Touch ID, Face ID, платформенные ключи.

Но в корпорации надо заранее решить:

  • разрешены ли синхронизируемые passkeys;
  • можно ли использовать личные устройства;
  • как происходит отзыв доступа;
  • что делать при потере устройства;
  • как проходит восстановление.

5. Linux/SSH: TOTP и FIDO2 через PAM

Для серверов и SSH есть два понятных класса решений.

Вариант 1. TOTP через google-authenticator-libpam

Google Authenticator PAM module – открытый PAM-модуль для двухфакторной аутентификации при входе на серверы через SSH, OpenVPN и другие сервисы. Проект находится на GitHub. (GitHub)

Условный минимальный сценарий для SSH:

**sudo **apt install libpam-google-authenticator google-authenticator

Дальше пользователь сканирует QR-код в TOTP-приложении, а в PAM/SSH включается проверка второго фактора.

Схематично:

SSH login → password → TOTP code → access

Важно:

  • не включать сразу на всех серверах без теста;
  • сначала проверить на одном узле;
  • оставить резервный доступ;
  • не закрыть самому себе аварийный вход;
  • задокументировать восстановление доступа.

Вариант 2. FIDO2/U2F через pam-u2f

Для более сильной модели можно использовать pam-u2f от Yubico. Он реализует PAM поверх U2F/FIDO2 и позволяет встраивать YubiKey или другие совместимые FIDO2-ключи в существующую инфраструктуру. (GitHub)

Плюс рядом полезен libfido2 – библиотека и набор командных инструментов для работы с FIDO2-устройствами по USB/NFC. Она поддерживает FIDO U2F/CTAP1 и FIDO2/CTAP2. (GitHub)

Минимальная логика:

Пользователь → SSH/PAM → pam-u2f → FIDO2-ключ → доступ

Тут особенно важно:

  • заранее зарегистрировать ключи пользователей;
  • иметь резервные ключи для админов;
  • не строить всю модель на одном физическом ключе;
  • не забыть аварийный доступ через консоль/ILO/гипервизор;
  • хранить mapping-файлы и конфигурацию с правильными правами.

Это уже не “удобный код из приложения”. Это нормальная защита админского доступа.

6. Legacy Web: Authelia и OAuth2 Proxy

Отдельная боль – старые внутренние веб-приложения, которые ничего не знают про OIDC, SAML и современную MFA.

Тут часто работает паттерн: не переписывать древнюю админку, а поставить перед ней слой аутентификации.

Authelia

Authelia – open-source сервер аутентификации и авторизации с SSO и MFA, который работает как защитный слой перед приложениями через reverse proxy. В репозитории проекта указана поддержка SSO и 2FA для приложений через веб-портал. (GitHub)

Где уместно:

  • self-hosted приложения;
  • внутренние панели;
  • домашние/лабораторные и небольшие корпоративные контуры;
  • приложения за NGINX/Traefik.

Authelia поддерживает TOTP, а в документации отдельно описана настройка TOTP. (Authelia)

Схема:

Пользователь → NGINX/Traefik → Authelia → LDAP/File backend + MFA → Legacy App

OAuth2 Proxy

OAuth2 Proxy – открытый reverse proxy / middleware, который перенаправляет пользователей к OAuth2/OIDC-провайдеру и защищает приложения за прокси. Проект доступен на GitHub. (GitHub)

Схема:

Пользователь → OAuth2 Proxy → Keycloak → Legacy App

Это хороший вариант, если:

  • приложение само не умеет OIDC;
  • вы уже используете Keycloak;
  • хотите закрыть доступ единым входом;
  • надо быстро добавить MFA перед старым сервисом.

7. Что выбрать: простая матрица

Если нужно быстро уйти от SMS для сотрудников

TOTP-приложение + централизованная политика

ПО:

  • Aegis;
  • Ente Auth;
  • FreeOTP;
  • privacyIDEA для централизованного управления.

Если нужно защитить VPN

VPN → RADIUS/PAM → privacyIDEA → AD/LDAP + TOTP

Это практичный старт. Потом можно добавлять сертификаты устройств, условный доступ, контроль доверенных устройств и отдельные правила для подрядчиков.

Если нужно защитить веб-приложения

Keycloak + OIDC/SAML + TOTP/WebAuthn

Для legacy:

OAuth2 Proxy / Authelia перед приложением

Если нужно защитить админов

FIDO2/WebAuthn/passkeys + резервный ключ + break-glass процесс

Для Linux/SSH:

pam-u2f или TOTP через PAM

Если нужно защитить массовых пользователей

TOTP как базовый фактор FIDO2/passkeys для критичных ролей SMS только как временный или резервный канал, если без него нельзя

8. Чего не делать

Самые частые ошибки:

  1. Оставить SMS единственным фактором

Это работает ровно до первого сбоя связи, блокировки, SIM-swap или массовой проблемы с доставкой кодов.

8.1 Включить TOTP без восстановления доступа

Потерянный телефон без резервного сценария быстро превращается в проблему ServiceDesk.

8.2. Выдать FIDO2-ключи без второго ключа

Один ключ – это не зрелость. Это новая единая точка отказа.

8.3. Поставить Keycloak и забыть про его отказоустойчивость

SSO, который лежит, превращается в единую точку остановки бизнеса.

8.4. Включить MFA только на VPN

VPN – важный вход, но не единственный. Админки, почта, Git, облака, CI/CD и внутренние панели тоже надо смотреть.

8.5. Не описать аварийный процесс

Самая плохая инструкция в момент сбоя: “пишите в чат, разберемся”.

8.6. Использовать личные учетки админов для интеграций

Сервисные сценарии должны жить на сервисных учетках с минимальными правами.

9. Минимальный план внедрения на месяц

Неделя 1. Инвентаризация

Собрать:

  • какие системы используют SMS;
  • где SMS – второй фактор;
  • где SMS – способ восстановления пароля;
  • где SMS фактически основной вход;
  • какие группы пользователей критичны;
  • какие системы нельзя оставить без доступа.

Результат:

Реестр систем и сценариев аутентификации

Неделя 2. Пилот TOTP

Выбрать:

  • одну VPN-группу;
  • одну группу админов;
  • одну внутреннюю систему.

Подключить:

  • Aegis/FreeOTP/Ente Auth на стороне пользователя;
  • privacyIDEA или встроенный TOTP в вашей IAM/SSO-системе;
  • ServiceDesk-процесс восстановления.

Результат:

SMS уже не единственный способ входа

Неделя 3. FIDO2 для критичных ролей

Выдать аппаратные ключи:

  • доменным администраторам;
  • сетевым администраторам;
  • администраторам безопасности;
  • владельцам критичных облаков/CI/CD.

Обязательно:

  • основной ключ;
  • резервный ключ;
  • правила хранения;
  • отзыв при увольнении;
  • аварийный доступ.

Результат:

Самые опасные роли уходят от SMS и TOTP к phishing-resistant MFA

Неделя 4. Аварийный режим

Описать:

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

Результат:

Компания не придумывает безопасность в момент аварии

Мой личный вывод

SMS как единственный второй фактор для корпоративного доступа – плохая опора.

Но еще хуже – не иметь плана, что делать, когда эта опора исчезает.

Нормальная архитектура доступа должна быть многослойной:

обычные сотрудники → TOTP / push / passkeys администраторы → FIDO2 / passkeys / аппаратные ключи VPN → RADIUS/PAM + MFA-сервер веб-приложения → SSO + MFA legacy → proxy-слой аварийный доступ → заранее описанный процесс

И главное: не надо пытаться внедрить все сразу.

Первый взрослый шаг – убрать SMS как единственную точку отказа хотя бы для VPN, админов и восстановления пароля.

Потому что “SMS не пришла, отключите пока второй фактор” – это не аварийный процесс.

Это признание, что аварийного процесса у вас не было.