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 увімкнено» на схему, якою може керувати хтось інший.

Схожі статті