FortiGate VPN MFA: lokal token, RADIUS eller SAML?

Ethvert FortiGate VPN MFA-design besvarer først ét spørgsmål: hvem verificerer den anden faktor? Gatewayen selv kan gøre det med et lokalt token eller en kode sendt med e-mail, en RADIUS-backend kan håndhæve det og sende en udfordring tilbage, eller en SAML-identitetsudbyder kan overtage hele ceremonien i en browser. Hver af dem giver en anden loginsekvens, en anden fejlsignatur og en anden gendannelsesprocedure, og at kopiere en kommandoblok mellem dem giver en konfiguration, der ser plausibel ud og ikke autentificerer nogen. Dette er en mekanismeartikel: hvad hvert design faktisk gør under et login, og hvor det brækker.

Login-ceremonien afgør, hvem der ejer faktoren

I de to første designs er FortiGate den part, der stoler på. Den indsamler legitimationsoplysningen, afgør, om en anden faktor er påkrævet, og verificerer den lokalt eller ved at spørge gennem en udfordring. I det tredje design holder gatewayen op med at være verifikator og bliver en relay: den omdirigerer klienten til identitetsudbyderen, modtager en assertion og mapper den bekræftede identitet til en bruger og en gruppe. I RADIUS-designet ligger den imellem og driver en anmodning-svar-udveksling med en backend, der har politikken.

Forskellen afgør, hvilke beviser du kan indsamle. Når gatewayen verificerer, fortæller dens egen fejlretningsudskrift dig, hvad der skete. Når en identitetsudbyder verificerer, ved gatewayen kun, at en assertion ankom, og svaret på „var MFA faktisk påkrævet“ findes i udbyderens logfiler, ikke i firewallens. At læse den forkerte log er den mest almindelige måde at fejldiagnosticere en udrulning, der opfører sig præcis som designet. Tjenesten sætter også grænser for ceremonien: FortiOS 7.6.3 fjerner SSL VPN-tunneltilstand til fordel for IPsec, mens webtilstand fortsætter som Agentless VPN på understøttede modeller, så en ceremoni, der er bevist på én tjeneste, ikke automatisk er tilgængelig på en anden.

Lokal verifikation: tokens og e-mailkoder

Faktorer, der styres af FortiGate, knyttes til brugerobjektet. Et FortiToken eller en dokumenteret tokenintegration kræver tilmelding, den understøttede verifikationsceremoni, licensering hvor det gælder, og en udskiftningsprocedure. En e-mailkode kræver en fungerende SMTP-vej og en postkasse, som brugeren kan nå, før tunnelen findes, hvilket er en afhængighed uden noget med kryptografi at gøre og med alt at gøre med, om nogen kan logge ind.

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

E-maillevering er en del af autentificeringens tilgængelighed. En postkasse, der kun kan nås via VPN, skaber en løkke, som ikke løser sig selv for nogen, og leveringsforsinkelse, kodegyldighed og timeout for fjernautentificering er tre separate begrænsninger. At hæve den ene reparerer ikke en utilgængelig postkasse, og et design, der aldrig har testet løkken, vil opdage den ved den første nulstilling af adgangskoden efter en ferie.

Sikkerhedskrav hører også hjemme her, før produktvalget. NIST SP 800-63B anser e-mail for uacceptabelt til autentificering uden for båndet, så en udrulning, der hævder overensstemmelse, kan ikke bruge en e-mailkode som sin anden faktor, uanset hvor bekvemt det er. At en funktion findes på enheden er ikke en erklæring om, at funktionen opfylder en given standard.

RADIUS: gatewayen spørger, backenden bestemmer

Med RADIUS sender FortiGate legitimationsoplysningen til en backend, der ejer faktorpolitikken. Udvekslingen kan være en simpel accept eller afvisning, eller den kan indeholde en udfordring, som klienten skal svare på, hvilket betyder, at både VPN-tjenesten og klienten skal understøtte den udfordringsform. En backend, der håndhæver en push-godkendelse, og en klient, der kun kan tilføje en sekscifret kode til en adgangskode, mødes ikke på midten.

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>

Test backenden uafhængigt, før du bebrejder tunnelen. Hvis authserver-testen lykkes, og et VPN-login ikke gør, er forskellen i håndteringen af udfordringen og ikke i legitimationsoplysningen, og fejlretningen af gatewayens autentificeringsdaemon er, hvor det viser sig:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: browseren forlader gatewayen

I et SAML-design omdirigeres klienten til identitetsudbyderen, autentificerer der og vender tilbage med en assertion, som gatewayen validerer mod en tillidsrelation og en gruppemapping. Gatewayen ser aldrig adgangskoden eller den anden faktor, hvilket på samme tid er en sikkerhedsforbedring og en driftsmæssig komplikation: fejlen sker nu i en browsersession, som firewallen ikke kan inspicere.

At acceptere en assertion beviser ikke, at udbyderen krævede MFA for det login. En udbyderpolitik, der anvender MFA på nogle applikationer og ikke på andre, vil give præcis det login, du bad om, og intet af den sikkerhed, du antog. Kontroller udbyderens politik for netop denne applikation, og kontroller, at gruppepåstandene, der mapper til FortiGate-grupper, stadig matcher efter en omdøbning på en af siderne.

Klientunderstøttelse betyder mere her end noget andet sted. Nogle VPN-klienter håndterer browseroverdragelsen indbygget, andre åbner systembrowseren, og headless- eller kommandolinjeklienter fuldfører måske slet ikke flowet. Test med den klient, brugerne faktisk kører, på de platforme, de faktisk bruger, før du offentliggør profilen.

Gendannelse er en del af mekanismen

Hvert af designene ovenfor har en afhængighed, der kan fejle for én bruger ad gangen: en utilgængelig postkasse, et mistet token, en backend, der afviser en udfordring, en låst konto hos identitetsudbyderen. Beslut nu, hvem der kan gendanne adgang, gennem hvilken understøttet procedure og med hvilken verifikation af den person, der spørger. En lokal nødadministratorkonto, der holdes adskilt fra VPN-vejen, er en kontrol; og en uforklaret omgåelse med kun adgangskode er en hændelse, der venter på at blive opdaget.

Test derefter tre logins før udrulning: det normale, en afvist eller udløbet faktor og den godkendte gendannelse af en mistet autentifikator. Noter, hvilken log hver af dem optræder i. Den registrering er det, der gør „MFA er aktiveret“ til et design, som en anden kan drive.