Дополнительная защита перед существующим веб-приложением
MFA Proxy CTRL — программный продукт SoftTech для сценариев, где веб-приложение уже работает, но вход по одному логину и паролю больше не соответствует требованиям к доступу.
Продукт размещается перед защищаемым веб-приложением. Пользователь сначала проходит проверку в MFA Proxy CTRL и только после этого получает доступ к целевой системе. Само приложение для добавления этого рубежа менять не требуется.
Такой подход применим для административных панелей, vCenter, почтовых веб-интерфейсов, CRM, камер, внутренних порталов и других веб-систем, у которых нет собственной подходящей двухфакторной защиты.
Как проходит доступ
Базовая цепочка выглядит так:
пользователь → MFA Proxy CTRL → проверка доступа → защищаемое веб-приложение.
Для сотрудника адрес сервиса может оставаться прежним. Прокси принимает обращение, проверяет необходимые условия и только после успешной аутентификации передаёт запрос приложению.
Поддерживаются два практических сценария:
- MFA Proxy CTRL проверяет TOTP и пароль до передачи запроса;
- MFA Proxy CTRL проверяет TOTP, а собственный логин и пароль пользователь вводит уже в защищаемом приложении.
Это позволяет добавить дополнительный фактор, не перенося обязательно всю штатную аутентификацию приложения в proxy.
Несколько сервисов в одном контуре
Через один MFA Proxy CTRL можно защищать несколько веб-сервисов.
Для каждого сервиса задаются собственное имя, адрес назначения, разрешённые пользователи и параметры сессии. Сотруднику можно предоставить доступ только к необходимым системам, а не ко всему опубликованному контуру.
Пользователей можно объединять в группы и назначать группу на нужный сервис.
TOTP как второй фактор
В текущей реализации MFA Proxy CTRL использует одноразовые коды TOTP из приложения-аутентификатора.
Код действует ограниченное время. Поэтому знания постоянного пароля недостаточно для обычного прохождения защищённого входа: требуется действующий одноразовый код.
TOTP существенно усиливает сценарий, в котором приложение иначе защищено только постоянным паролем, но не следует считать его абсолютной защитой от фишинга. Требования к способу аутентификации должны соответствовать риску конкретной системы.
Сессии и изменение IP-адреса
Администратор видит активные сессии, адрес, с которого они открыты, и может завершить выбранную сессию.
Сессия привязывается к IP-адресу. Если запрос с той же cookie приходит с другого адреса, MFA Proxy CTRL требует повторную проверку кода. При этом действующая сессия пользователя на исходном адресе не должна автоматически завершаться.
Срок жизни сессии задаётся отдельно для каждого защищаемого сервиса.
Ограничение попыток и IP-правила
После заданного количества последовательных ошибочных попыток вход может быть временно заблокирован.
Дополнительно используются:
- белый список IP-адресов для разрешённых сетей;
- чёрный список IP-адресов для блокировки известных источников;
- индивидуальные правила доступа к защищаемым сервисам.
Эти механизмы дополняют MFA, но не заменяют сетевую сегментацию и межсетевой экран.
Журналирование
MFA Proxy CTRL ведёт журнал входов, отказов и административных действий.
Это позволяет видеть, кто обращался к защищаемому сервису, был ли доступ разрешён и какие действия выполнялись в административном контуре proxy.
Журнал MFA Proxy CTRL не заменяет журналы самого приложения, операционной системы, межсетевого экрана или централизованной SIEM.
Сертификаты
Сертификаты защищаемых сайтов управляются в MFA Proxy CTRL.
Поддерживаются:
- собственный сертификат;
- сертификат Let’s Encrypt;
- сертификат, подписанный общим корневым сертификатом proxy.
Конкретная схема TLS должна соответствовать внутренней PKI и требованиям инфраструктуры заказчика.
Администрирование
Веб-консоль объединяет управление:
- пользователями;
- группами;
- защищаемыми сайтами;
- активными сессиями;
- журналом;
- параметрами блокировки.
Административная панель вынесена на отдельный порт и по умолчанию слушает локальный интерфейс сервера, а не публикуется рядом с защищаемыми сайтами.
Развёртывание и данные
MFA Proxy CTRL устанавливается на Linux-системы Ubuntu, Debian, AlmaLinux или CentOS.
Данные хранятся в локальной базе, поэтому отдельный сервер СУБД для продукта не требуется. Настройки выносятся в файл окружения, а состояние можно сохранить и восстановить из резервной копии.
Секреты TOTP в базе хранятся в зашифрованном виде.
Критичное условие: приложение нельзя оставлять в обход proxy
Установка MFA Proxy CTRL перед приложением имеет смысл только тогда, когда пользователь не может обратиться к серверной части защищаемого приложения напрямую и обойти дополнительную проверку.
Поэтому внедрение включает не только настройку MFA. Необходимо определить сетевой маршрут, DNS/TLS, правила межсетевого доступа и доступность исходного приложения так, чтобы пользовательский трафик проходил через предусмотренную точку входа.
Если старый прямой адрес приложения остаётся доступным той же аудитории, наличие proxy само по себе не закрывает этот путь.
Что MFA Proxy CTRL не заменяет
Продукт решает конкретную задачу контроля доступа к веб-приложению. Он не является автоматически:
- межсетевым экраном;
- антивирусом или EDR;
- универсальной IAM/IdP-платформой;
- заменой SSO;
- VPN;
- SIEM;
- гарантией защиты от фишинга;
- заменой безопасной настройки самого приложения и операционной системы.
Если приложение уже корректно интегрировано с корпоративным Identity Provider и поддерживает требуемую MFA, дополнительный proxy может быть не нужен.
Когда MFA Proxy CTRL подходит
Продукт имеет смысл рассматривать, когда:
- веб-приложение поддерживает только логин и пароль;
- изменить его код нельзя или нецелесообразно;
- это сторонний или устаревший продукт;
- требуется быстро добавить дополнительный рубеж аутентификации;
- несколько веб-сервисов нужно собрать под единые правила доступа;
- доступ к серверной части приложения можно технически закрыть в обход proxy.
Если задача начинается с выбора архитектуры, а не конкретного продукта, сначала полезно разобрать как добавить MFA к веб-приложению, которое её не поддерживает.
Обсудить защищаемый контур
Для первого разбора достаточно списка веб-сервисов, текущей схемы доступа и ответа на несколько вопросов: кто должен входить, откуда разрешён доступ, какая аутентификация используется сейчас и можно ли исключить прямое обращение к серверной части приложения.
По этим данным можно определить, подходит ли MFA Proxy CTRL или правильнее использовать встроенную MFA, корпоративный Identity Provider либо другой механизм доступа.
