Авторизующий reverse proxy: доступ к приложению, а не к сети
Цикл «Не светим лишнего». Выпуск 10.
Basic Auth хорош, пока пользователей трое. Потом нужен четвёртый, один увольняется, другой забывает пароль, руководитель просит TOTP, а безопасник — журнал по именам. В этот момент лучше перестать улучшать htpasswd.
Авторизующий reverse proxy отправляет пользователя к нормальному провайдеру идентичности: Keycloak, Authentik, Authelia, Entra ID или другому OIDC-совместимому сервису. После входа прокси получает подтверждённую личность и решает, можно ли пропустить запрос к конкретному приложению.
Несколько новых слов
IdP, Identity Provider — система, которая аутентифицирует пользователя и сообщает другим сервисам, кто это.
OIDC, OpenID Connect — распространённый протокол входа поверх OAuth 2.0. Пользователь логинится у IdP, а приложение получает подписанные данные о его личности.
SSO — единый вход. Один раз прошли корпоративную авторизацию и используем несколько разрешённых приложений без отдельных паролей.
Identity-aware proxy — прокси, который принимает решение не только по IP, но и по пользователю, группе, MFA и другим признакам.
Как идёт запрос
Пользователь открывает внутренний hostname. Proxy видит, что действующей сессии нет, и отправляет его на страницу IdP. После пароля, passkey или TOTP пользователь возвращается с подтверждением. Proxy создаёт защищённую cookie и пропускает запрос к backend.
Внутреннее приложение может само ничего не знать про OIDC. Если ему нужна личность, proxy передаёт проверенные заголовки вроде X-User или X-Email.
Плюсы
- одна корпоративная учётная запись;
- MFA и passkey без переделки каждого приложения;
- доступ по группам;
- отзыв пользователя в одном месте;
- приложение не получает сетевой доступ ко всей подсети;
- понятный аудит входов;
- удобно публиковать старые веб-интерфейсы.
Минусы
- применимо в первую очередь к HTTP/HTTPS;
- IdP и proxy становятся критичными компонентами;
- не все приложения корректно работают за внешней авторизацией;
- нужно управлять cookie, токенами, redirect URI и секретами клиентов;
- ошибка общей политики может открыть сразу много приложений.
Где можно больно ошибиться
Backend доверяет заголовкам от клиента. Внешний пользователь сам присылает X-User: admin. Proxy обязан удалять такие заголовки и записывать собственные. Backend должен принимать трафик только от proxy.
Неправильно определён реальный IP. OAuth2 Proxy отдельно предупреждает: X-Forwarded-* надо принимать только от доверенных адресов reverse proxy. Иначе IP можно подделать строкой заголовка.
Слишком длинная cookie. Человек ушёл с общего компьютера, а сессия живёт неделю. Нужны разумный срок, logout и повторная сильная авторизация для опасных действий.
Нет защиты origin. Если backend доступен напрямую, вся identity-aware-логика обходится одним прямым запросом.
Proxy стал единственной защитой. На самом приложении всё равно оставляем минимальные роли и обновления. Для критичной админки можно совместить IdP с IP allow-list или клиентским сертификатом.
Что этот метод не решает
Он отлично защищает веб-приложения, но не открывает обычный SSH-клиент, RDP, WinBox или подключение к базе. Для произвольных протоколов понадобится bastion, VPN или динамический firewall.
Следующая наша схема как раз про динамический firewall: пользователь вводит TOTP на портале, а его текущий IP временно попадает в нужный access-list.
Ранее в цикле
- 9. Reverse proxy и Basic Auth: быстро прикрыть внутреннюю вебку
- 1. Зачем прятать то, что всё равно должно быть доступно снаружи