MFA для старых веб-сервисов: как закрыть доступ без переписывания

Инженеры К2 описали схему, которая добавляет MFA (от англ. multi-factor authentication — многофакторная аутентификация) к веб-сервису без доработки его кода. Такой подход нужен компаниям, где до сих пор работают старые внутренние системы: они не поддерживают современные протоколы входа, но хранят важные данные.

Речь не о модной надстройке, а о практичной защите периметра. Если приложение нельзя быстро переписать, проверку пользователя выносят перед ним — на уровень Nginx, OAuth2 Proxy и провайдера идентификации.

Почему старым системам нужен внешний контроль

Современные веб-приложения обычно умеют работать с SAML (Security Assertion Markup Language — язык обмена данными об аутентификации) или OIDC (OpenID Connect — протокол входа поверх OAuth 2.0). В такой модели второй фактор включают на стороне Identity Provider — провайдера идентификации, а приложение получает уже подтверждённого пользователя.

С legacy-системами сложнее. Это старые монолитные сервисы, самописные панели и внутренние порталы, которые годами поддерживали по принципу «не трогать, пока работает». Они могут не знать ни SAML, ни OIDC, а любое вмешательство в код грозит простоем или новыми ошибками.

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

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

Как работает предаутентификация

В схеме из разбора К2 перед защищаемым сервисом стоит Nginx. Он принимает запрос пользователя и с помощью штатного модуля auth_request отправляет внутреннюю проверку в OAuth2 Proxy. Это отдельный компонент, который отвечает за сессию, куки и обмен с провайдером идентификации.

Если у пользователя уже есть валидная сессионная кука, OAuth2 Proxy возвращает Nginx успешный ответ. Nginx пропускает запрос дальше — к старому приложению. Оно получает запрос так, будто пользователь уже прошёл обычный вход.

Если куки нет или срок сессии истёк, OAuth2 Proxy отдаёт отказ. Nginx перенаправляет браузер на страницу входа провайдера идентификации. Там пользователь вводит пароль и проходит второй фактор, например код из приложения-аутентификатора.

Если у пользователя нет нужной роли, запрос обрывается. Это важная деталь: MFA не заменяет права доступа, а дополняет их.

Почему выбрали Nginx и OAuth2 Proxy

Nginx сам по себе не умеет в SSO (single sign-on — единый вход) и не разбирает OIDC. Но у него есть auth_request — штатный механизм для обращения к внешнему сервису перед тем, как пустить запрос к приложению.

Разработчики схемы не стали собирать Nginx с нестандартным модулем OIDC. У такого решения выше риски сопровождения: нужно следить за сборкой, обновлениями, совместимостью и цепочкой поставок. Вместо этого логику входа вынесли в OAuth2 Proxy.

Провайдером идентификации в проекте выбрали Indeed AM. По описанию авторов, решающими стали интеграция с внутренним корпоративным контуром, единая точка управления политиками и поддержка поставщика.

На практике связка выглядит так: Nginx стоит на входе, OAuth2 Proxy проверяет сессию и общается с Identity Provider, а старый сервис остаётся без изменений. Это снижает риск поломать приложение, которое давно никто не развивает.

Где схема может дать сбой

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

В рабочей среде такие послабления недопустимы. Куки должны передаваться только по защищённому соединению и быть недоступными для скриптов в браузере. Сертификаты нужно проверять, а секреты клиента хранить так, чтобы их не увидели администраторы без нужных прав.

Ещё один риск — доверие к заголовкам. Если старое приложение принимает имя пользователя или email из HTTP-заголовка, эти поля должны приходить только от внутреннего прокси. Прямой доступ к бэкенду нужно закрыть сетевыми правилами.

Логи тоже требуют внимания. Система мониторинга SIEM (Security Information and Event Management — сбор и анализ событий безопасности) полезна, если фиксирует не только успешные входы, но и частые отказы, подозрительные роли и попытки зайти к закрытым разделам.

Не путать с обычными проблемами доступа

Пользовательские запросы вроде «почему не работает Telegram через мобильный интернет» или «что делать если не работает Discord» обычно относятся к связи, настройкам устройства, сбоям приложения или ограничениям на стороне сети. Предаутентификация решает другую задачу: она намеренно не пускает непроверенного пользователя к корпоративному ресурсу.

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

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

Что сделать сейчас: чек-лист для компании

• Найдите внутренние веб-сервисы, которые не поддерживают SAML или OIDC, но доступны сотрудникам через браузер.
• Проверьте, можно ли закрыть прямой доступ к таким приложениям и пускать трафик только через реверс-прокси.
• Включите MFA на стороне провайдера идентификации, а не внутри старого приложения.
• Убедитесь, что сессионные куки защищены: только по HTTPS, без доступа из JavaScript, с разумным сроком жизни.
• Уберите отладочные параметры перед запуском в работу: не отключайте проверку сертификатов и не выводите данные сессии в заголовки.
• Настройте роли: второй фактор подтверждает личность, но не должен давать лишние права.
• Передайте события входа, отказов и ошибок в SIEM или другой журнал безопасности.
• Проведите тест с обычным пользователем: он должен понимать, где вход, где отказ по правам, а где реальная техническая неполадка.