Во многих компаниях есть веб-приложения, которые годами выполняют свою задачу и используют простую схему входа: логин и пароль.
Это могут быть корпоративные порталы, CRM, административные панели, интерфейсы инфраструктурных систем или специализированное программное обеспечение.
Менять работающую систему только потому, что в ней нет многофакторной аутентификации, часто нецелесообразно. Иногда это вообще невозможно. Но оставлять критичный доступ защищённым только постоянным паролем — отдельный риск.
Почему одного пароля недостаточно
Пароль подтверждает знание секрета. Проблема возникает, когда этот секрет получает другой человек.
Пароль может попасть в утечку, использоваться повторно в нескольких системах, быть получен через фишинг или оказаться на скомпрометированном устройстве.
Если система проверяет только логин и пароль, правильной пары учётных данных достаточно для прохождения этого рубежа. Усложнение требований к паролю не меняет сам принцип.
Что меняет MFA
Многофакторная аутентификация требует дополнительного подтверждения личности.
Например, кроме постоянного пароля пользователь вводит одноразовый код из приложения-аутентификатора. Компрометации одного пароля в таком сценарии уже недостаточно для обычного входа.
При этом разные способы MFA обеспечивают разный уровень защиты. TOTP-коды полезны как дополнительный фактор, но не являются абсолютной защитой от фишинга: пользователь может передать действующий код убедительной поддельной странице.
Поэтому выбирать способ аутентификации нужно по риску конкретной системы, а не по наличию формальной отметки «MFA включена».
Почему MFA нельзя просто добавить в любое приложение
С системой собственной разработки можно изменить механизм входа или интегрировать её с корпоративным Identity Provider.
С существующими приложениями ситуация сложнее.
Исходный код может быть недоступен. Производитель может больше не поддерживать версию. Добавление MFA может потребовать крупного обновления. У стороннего продукта компания вообще не управляет механизмом аутентификации.
В таких случаях появляется другой вопрос: можно ли выполнить дополнительную проверку перед приложением, не изменяя его?
Дополнительный защитный слой перед приложением
Один из вариантов — поставить перед веб-приложением reverse proxy, который контролирует доступ.
Схема выглядит так:
пользователь → дополнительная аутентификация → proxy → веб-приложение.
Пользователь сначала проходит проверку на промежуточном слое. Только после этого запрос передаётся защищаемой системе.
Само приложение при этом можно не менять только ради появления дополнительного фактора.
Два варианта работы с паролем
Прокси-слой не обязательно должен полностью забирать штатную аутентификацию приложения.
В одном сценарии пользователь проходит на proxy проверку TOTP и пароля, после чего получает доступ к системе.
В другом proxy проверяет только дополнительный фактор, а собственный логин и пароль пользователь вводит уже на странице приложения.
Выбор зависит от архитектуры продукта и требований конкретного контура.
Где такой подход полезен
Устаревшие системы
Приложение продолжает выполнять свою функцию, но его механизм входа уже не соответствует требованиям компании. Переписывать всю систему ради MFA может быть экономически нецелесообразно.
Стороннее программное обеспечение
Компания использует систему, но не контролирует её исходный код и не может самостоятельно добавить новый механизм аутентификации.
Административные веб-интерфейсы
У инфраструктурных систем, камер, виртуализации и другого программного обеспечения могут быть собственные веб-интерфейсы. Возможности их аутентификации определяет производитель, а требования организации к доступу могут быть строже.
Несколько внутренних веб-сервисов
Отдельный входной контур позволяет централизовать дополнительную проверку и назначать пользователям доступ только к нужным сервисам.
Самое важное условие — нельзя оставлять путь в обход
Это принципиальная часть архитектуры.
Если перед приложением установлен MFA proxy, но исходная серверная часть приложения остаётся доступна пользователю напрямую, дополнительную проверку можно обойти.
Вместо одной защищённой дороги появляются две:
пользователь → MFA → приложение
и
пользователь → приложение напрямую.
Поэтому внедрение proxy — не только установка программного обеспечения. Сетевые правила должны исключать прямой пользовательский доступ к серверной части защищаемого приложения.
Нужно учитывать маршрутизацию, DNS, TLS, межсетевые правила и административный доступ.
MFA — не вся система информационной безопасности
Дополнительная аутентификация закрывает конкретный риск, но не исправляет уязвимости приложения и не заменяет остальные средства защиты.
MFA proxy не должен восприниматься как замена:
- межсетевому экрану;
- антивирусу или EDR;
- обновлению приложения;
- безопасной конфигурации сервера;
- сегментации сети;
- мониторингу событий;
- резервному копированию;
- корпоративному управлению идентификацией там, где оно необходимо.
Это один слой в общей архитектуре защиты.
Когда лучше использовать встроенную MFA или Identity Provider
Прокси-подход нужен не всегда.
Если приложение штатно поддерживает требуемую MFA, обычно сначала стоит рассмотреть эту возможность.
Если организация уже использует централизованный Identity Provider, SSO и современные протоколы федеративной аутентификации, правильным решением может быть интеграция приложения с существующим контуром.
Для систем с повышенными требованиями может потребоваться механизм аутентификации, устойчивый к фишингу, и более строгая модель доступа.
Прокси особенно полезен там, где существующее веб-приложение изменить сложно, но его сетевой доступ можно поставить под контролируемую точку входа.
Какие системы проверять в первую очередь
Начинать стоит не с перечня технологий, а с последствий компрометации учётной записи.
В первую очередь имеет смысл проверить системы, через которые можно:
- управлять IT-инфраструктурой;
- получать доступ к конфиденциальной или коммерчески значимой информации;
- изменять настройки других систем;
- выполнять операции от имени компании;
- получать удалённый доступ к внутренним ресурсам;
- управлять физическим или логическим доступом;
- использовать скомпрометированную учётную запись для дальнейшего движения по инфраструктуре.
Отдельного внимания требуют веб-системы, доступные из Интернета.
MFA Proxy CTRL
Для сценария, где дополнительную проверку необходимо поставить перед существующим веб-приложением, SoftTech разработал MFA Proxy CTRL.
Продукт поддерживает TOTP, пользователей и группы, индивидуальный доступ к сервисам, контроль активных сессий, IP-правила, блокировку после последовательных ошибочных попыток и журналирование.
Его задача конкретна: создать управляемый дополнительный рубеж аутентификации перед веб-приложением, которое сложно или нецелесообразно дорабатывать.
С чего начать
Перед выбором реализации нужно ответить на несколько вопросов:
- какое приложение защищаем;
- кто и откуда должен получать к нему доступ;
- какая аутентификация используется сейчас;
- поддерживает ли приложение собственную MFA;
- есть ли в организации Identity Provider;
- можно ли исключить прямой доступ к серверной части приложения;
- насколько критичны последствия компрометации учётной записи;
- какой способ второго фактора соответствует этому риску.
После этого можно выбирать между встроенной MFA, интеграцией с корпоративным контуром идентификации и отдельным proxy-слоем.
Главный вопрос — не «какую MFA установить», а какой доступ мы защищаем, от какого сценария атаки и что произойдёт, если одного украденного пароля окажется достаточно.