FortiGate VPN MFA: локальный токен, RADIUS или SAML?

Шлюз, бэкенд RADIUS или провайдер SAML могут проверять фактор, и каждый отказывает по-своему. Согласуйте сервис, клиент и путь восстановления.

Каждая схема FortiGate VPN MFA сначала отвечает на один вопрос: кто проверяет второй фактор? Сам шлюз может сделать это локальным токеном или кодом, отправленным по почте, бэкенд RADIUS может принудительно его применить и вернуть вызов, а провайдер идентичности SAML может взять на себя всю церемонию в браузере. Каждый из них даёт разную последовательность входа, разную подпись сбоя и разную процедуру восстановления, а копирование командного блока между ними даёт конфигурацию, которая выглядит правдоподобно и никого не аутентифицирует. Это статья о механизме: что каждая схема на самом деле делает при входе и где ломается.

Церемония входа решает, кому принадлежит фактор

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

Эта разница определяет, какие доказательства вы можете собрать. Когда шлюз проверяет, его собственный отладочный вывод говорит вам, что произошло. Когда проверяет провайдер идентичности, шлюз знает только, что пришло утверждение, а ответ на вопрос «требовался ли MFA на самом деле» живёт в журналах провайдера, а не в журналах межсетевого экрана. Чтение не того журнала — самый распространённый способ неверно диагностировать внедрение, которое ведёт себя ровно так, как задумано. Сам сервис тоже ограничивает церемонию: FortiOS 7.6.3 удаляет режим туннеля SSL VPN в пользу IPsec, тогда как веб-режим продолжается как Agentless VPN на поддерживаемых моделях, поэтому церемония, доказанная на одном сервисе, не становится автоматически доступной на другом.

Локальная проверка: токены и коды по почте

Управляемые FortiGate факторы привязаны к объекту пользователя. FortiToken или документированная интеграция токена требуют регистрации, поддерживаемой церемонии проверки, лицензирования там, где это применимо, и процедуры замены. Код, отправленный по почте, требует рабочего пути SMTP и почтового ящика, до которого пользователь может добраться до появления туннеля; это зависимость, не имеющая ничего общего с криптографией и целиком связанная с тем, может ли кто-то войти.

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

Доставка почты — часть доступности аутентификации. Ящик, доступный только через VPN, создаёт петлю, которая ни для кого не разрешается сама собой, а задержка доставки, срок действия кода и тайм-аут удалённой аутентификации — три отдельных ограничения. Повышение одного не чинит недоступный ящик, и схема, которая ни разу не проверяла петлю, обнаружит это при первом сбросе пароля после праздников.

Требования к гарантиям тоже относятся сюда, до выбора продукта. NIST SP 800-63B считает почту неприемлемой для внешней аутентификации, поэтому развёртывание, заявляющее соответствие, не может использовать почтовый код как второй фактор, как бы удобно это ни было. Наличие функции на устройстве не является заявлением о том, что функция соответствует определённому стандарту.

RADIUS: шлюз спрашивает, бэкенд решает

С RADIUS FortiGate отправляет учётные данные бэкенду, который владеет политикой факторов. Обмен может быть простым принятием или отклонением, либо включать вызов, на который клиент должен ответить, а значит, и VPN-сервис, и клиент должны поддерживать такую форму вызова. Бэкенд, требующий push-подтверждения, и клиент, умеющий только дописать шестизначный код к паролю, не встретятся посередине.

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

Проверьте бэкенд отдельно, прежде чем винить туннель. Если тест authserver успешен, а вход через VPN — нет, разница в обработке вызова, а не в учётных данных, и отладка демона аутентификации шлюза — то место, где это видно:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: браузер покидает шлюз

В схеме SAML клиент перенаправляется к провайдеру идентичности, аутентифицируется там и возвращается с утверждением, которое шлюз проверяет по отношению доверия и сопоставлению групп. Шлюз никогда не видит пароль или второй фактор, что одновременно является улучшением безопасности и операционным усложнением: сбой теперь происходит в сеансе браузера, который межсетевой экран не может проверить.

Принятие утверждения не доказывает, что провайдер требовал MFA для этого входа. Политика провайдера, применяющая MFA к одним приложениям и не применяющая к другим, даст ровно тот вход, который вы запросили, и ничего из той гарантии, которую вы предположили. Проверьте политику провайдера для этого конкретного приложения и проверьте, что сопоставление групповых утверждений с группами FortiGate по-прежнему совпадает после любого переименования на любой стороне.

Поддержка клиента здесь важнее, чем где-либо ещё. Одни VPN-клиенты обрабатывают передачу в браузер нативно, другие открывают системный браузер, а клиенты без интерфейса или командной строки могут вообще не завершить поток. Тестируйте с клиентом, который пользователи действительно запускают, на платформах, которые они действительно используют, прежде чем публиковать профиль.

Восстановление — часть механизма

У каждой схемы выше есть зависимость, которая может отказать для одного пользователя за раз: недоступный ящик, потерянный токен, бэкенд, отклоняющий вызов, заблокированная учётная запись провайдера идентичности. Решите сейчас, кто может восстановить доступ, какой поддерживаемой процедурой и с какой проверкой обращающегося. Аварийная локальная учётная запись администратора, хранимая отдельно от пути VPN, — это мера контроля; а необъяснённый обход только по паролю — инцидент, ожидающий обнаружения.

Затем проверьте три входа перед развёртыванием: обычный, отклонённый или истёкший фактор и одобренное восстановление потерянного аутентификатора. Запишите, в каком журнале появляется каждый. Именно эта запись превращает «MFA включён» в схему, которой может управлять кто-то другой.

Похожие статьи