FortiGate VPN MFA: token lokalny, RADIUS czy SAML?

Każdy projekt FortiGate VPN MFA najpierw odpowiada na jedno pytanie: kto weryfikuje drugi czynnik? Sama brama może to zrobić tokenem lokalnym lub kodem wysłanym e-mailem, backend RADIUS może to wymusić i zwrócić wyzwanie, a dostawca tożsamości SAML może przejąć całą ceremonię w przeglądarce. Każdy z nich daje inną sekwencję logowania, inny podpis awarii i inną procedurę odzyskiwania, a skopiowanie bloku poleceń między nimi daje konfigurację, która wygląda wiarygodnie i nikogo nie uwierzytelnia. To artykuł o mechanizmie: co każdy projekt naprawdę robi podczas logowania i gdzie się łamie.

Ceremonia logowania decyduje, kto posiada czynnik

W dwóch pierwszych projektach FortiGate jest stroną ufającą. Zbiera poświadczenia, decyduje, czy potrzebny jest drugi czynnik, i weryfikuje go lokalnie lub przez wyzwanie. W trzecim projekcie brama przestaje być weryfikatorem i staje się przekaźnikiem: przekierowuje klienta do dostawcy tożsamości, odbiera asercję i mapuje potwierdzoną tożsamość na użytkownika i grupę. W projekcie RADIUS stoi pośrodku i prowadzi wymianę żądanie-odpowiedź z backendem, który trzyma politykę.

Ta różnica decyduje o tym, jakie dowody można zebrać. Gdy brama weryfikuje, jej własne wyjście debugowania mówi, co się stało. Gdy weryfikuje dostawca tożsamości, brama wie tylko, że dotarła asercja, a odpowiedź na pytanie „czy MFA było naprawdę wymagane” znajduje się w logach dostawcy, nie w logach firewalla. Czytanie niewłaściwego logu to najczęstszy sposób błędnego diagnozowania wdrożenia, które zachowuje się dokładnie tak, jak zaprojektowano. Sama usługa również ogranicza ceremonię: FortiOS 7.6.3 usuwa tryb tunelu SSL VPN na rzecz IPsec, podczas gdy tryb web kontynuuje jako Agentless VPN na obsługiwanych modelach, więc ceremonia udowodniona na jednej usłudze nie jest automatycznie dostępna na innej.

Weryfikacja lokalna: tokeny i kody e-mail

Czynniki zarządzane przez FortiGate są przypisane do obiektu użytkownika. FortiToken lub udokumentowana integracja tokenu wymaga rejestracji, obsługiwanej ceremonii weryfikacji, licencjonowania tam, gdzie ma zastosowanie, oraz procedury wymiany. Kod wysłany e-mailem wymaga działającej ścieżki SMTP i skrzynki, do której użytkownik dotrze, zanim tunel istnieje; to zależność, która nie ma nic wspólnego z kryptografią, a wszystko z tym, czy ktokolwiek może się zalogować.

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

Dostarczanie poczty jest częścią dostępności uwierzytelniania. Skrzynka osiągalna tylko przez VPN tworzy pętlę, która dla nikogo nie rozwiązuje się sama, a opóźnienie dostarczenia, ważność kodu i limit czasu zdalnego uwierzytelniania to trzy osobne ograniczenia. Podniesienie jednego nie naprawia nieosiągalnej skrzynki, a projekt, który nigdy nie przetestował pętli, odkryje ją przy pierwszym resecie hasła po urlopie.

Wymagania dotyczące zapewnienia też tu należą, przed wyborem produktu. NIST SP 800-63B uznaje e-mail za nieakceptowalny do uwierzytelniania poza pasmem, więc wdrożenie deklarujące zgodność nie może użyć kodu e-mail jako drugiego czynnika, niezależnie od wygody. Istnienie funkcji na urządzeniu nie jest stwierdzeniem, że funkcja spełnia dany standard.

RADIUS: brama pyta, backend decyduje

Z RADIUSEM FortiGate wysyła poświadczenia do backendu, który posiada politykę czynników. Wymiana może być prostym akceptowaniem lub odrzuceniem albo obejmować wyzwanie, na które klient musi odpowiedzieć, co oznacza, że zarówno usługa VPN, jak i klient muszą obsługiwać taki kształt wyzwania. Backend wymuszający zatwierdzenie push i klient, który umie tylko dopisać sześciocyfrowy kod do hasła, nie spotkają się w połowie drogi.

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>

Przetestuj backend niezależnie, zanim obwinisz tunel. Jeśli test authserver się powiedzie, a logowanie VPN nie, różnica leży w obsłudze wyzwania, a nie w poświadczeniach, i debug demona uwierzytelniania bramy jest miejscem, gdzie to widać:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: przeglądarka opuszcza bramę

W projekcie SAML klient jest przekierowywany do dostawcy tożsamości, uwierzytelnia się tam i wraca z asercją, którą brama waliduje wobec relacji zaufania i mapowania grup. Brama nigdy nie widzi hasła ani drugiego czynnika, co jest jednocześnie poprawą bezpieczeństwa i komplikacją operacyjną: awaria zdarza się teraz w sesji przeglądarki, której firewall nie może sprawdzić.

Zaakceptowanie asercji nie dowodzi, że dostawca wymagał MFA dla tego logowania. Polityka dostawcy, która stosuje MFA do niektórych aplikacji, a do innych nie, da dokładnie to logowanie, o które prosiłeś, i nic z zapewnienia, które zakładałeś. Sprawdź politykę dostawcy dla tej konkretnej aplikacji i sprawdź, czy mapowanie roszczeń grupowych na grupy FortiGate nadal się zgadza po wszelkiej zmianie nazw po którejkolwiek stronie.

Wsparcie klienta ma tu większe znaczenie niż gdziekolwiek indziej. Niektóre klienty VPN obsługują przekazanie do przeglądarki natywnie, inne otwierają przeglądarkę systemową, a klienty bez interfejsu lub wiersza poleceń mogą w ogóle nie ukończyć przepływu. Przetestuj z klientem, którego użytkownicy naprawdę używają, na platformach, których naprawdę używają, zanim opublikujesz profil.

Odzyskiwanie jest częścią mechanizmu

Każdy z powyższych projektów ma zależność, która może zawieść dla jednego użytkownika naraz: nieosiągalna skrzynka, utracony token, backend odrzucający wyzwanie, zablokowane konto u dostawcy tożsamości. Zdecyduj teraz, kto może przywrócić dostęp, jaką obsługiwaną procedurą i z jaką weryfikacją osoby proszącej. Awaryjne lokalne konto administratora trzymane osobno od ścieżki VPN jest kontrolą; a niewyjaśnione obejście oparte tylko na haśle jest incydentem czekającym na odkrycie.

Następnie przetestuj trzy logowania przed wdrożeniem: normalne, odrzucony lub wygasły czynnik oraz zatwierdzone odzyskanie utraconego authenticatora. Zanotuj, w którym logu pojawia się każde. To właśnie ten zapis zamienia „MFA jest włączone” w projekt, którym może zarządzać ktoś inny.