FortiGate VPN MFA: lokal token, RADIUS eller SAML?

Hvert FortiGate VPN MFA-design svarer først på ett spørsmål: hvem verifiserer den andre faktoren? Gatewayen selv kan gjøre det med et lokalt token eller en kode sendt på e-post, en RADIUS-backend kan håndheve det og returnere en utfordring, eller en SAML-identitetsleverandør kan ta over hele seremonien i en nettleser. Hver av dem gir en annen innloggingssekvens, en annen feilsignatur og en annen gjenopprettingsprosedyre, og å kopiere en kommandoblokk mellom dem gir en konfigurasjon som ser troverdig ut og ikke autentiserer noen. Dette er en artikkel om mekanismen: hva hvert design faktisk gjør under en innlogging, og hvor det bryter sammen.

Innloggingsseremonien avgjør hvem som eier faktoren

I de to første designene er FortiGate parten som stoler på. Den samler inn legitimasjonen, avgjør om en andre faktor er nødvendig, og verifiserer den lokalt eller ved å be om en utfordring. I det tredje designet slutter gatewayen å være verifiserer og blir en videresender: den omdirigerer klienten til identitetsleverandøren, mottar en assertion og mapper den bekreftede identiteten til en bruker og en gruppe. I RADIUS-designet ligger den imellom og driver en forespørsel-svar-utveksling med en backend som har policyen.

Forskjellen avgjør hvilke bevis du kan samle inn. Når gatewayen verifiserer, forteller dens egen feilsøkingsutskrift deg hva som skjedde. Når en identitetsleverandør verifiserer, vet gatewayen bare at en assertion ankom, og svaret på «var MFA faktisk påkrevd» ligger i leverandørens logger, ikke i brannmurens. Å lese feil logg er den vanligste måten å feildiagnostisere en utrulling som oppfører seg nøyaktig som designet. Tjenesten selv begrenser også seremonien: FortiOS 7.6.3 fjerner SSL VPN-tunnelmodus til fordel for IPsec, mens webmodus fortsetter som Agentless VPN på støttede modeller, så en seremoni som er bevist på én tjeneste ikke automatisk er tilgjengelig på en annen.

Lokal verifisering: tokens og e-postkoder

Faktorer som administreres av FortiGate, er knyttet til brukerobjektet. Et FortiToken eller en dokumentert tokenintegrasjon krever registrering, den støttede verifiseringsseremonien, lisensiering der det gjelder, og en erstatningsprosedyre. En e-postkode krever en fungerende SMTP-vei og en postkasse som brukeren kan nå før tunnelen finnes, en avhengighet som ikke har noe med kryptografi å gjøre og alt med hvorvidt noen kan logge inn.

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

E-postlevering er en del av autentiseringens tilgjengelighet. En postkasse som bare er tilgjengelig via VPN, skaper en løkke som ikke løser seg selv for noen, og leveringsforsinkelse, kodegyldighet og tidsavbruddet for ekstern autentisering er tre separate begrensninger. Å heve én reparerer ikke en utilgjengelig postkasse, og et design som aldri har testet løkken, vil oppdage den ved første passordtilbakestilling etter en ferie.

Også sikkerhetskrav hører hjemme her, før produktvalget. NIST SP 800-63B anser e-post som uakseptabelt for autentisering utenfor båndet, så en utrulling som hevder samsvar, kan ikke bruke en e-postkode som sin andre faktor, uansett hvor praktisk det er. At en funksjon finnes på enheten, er ikke en erklæring om at funksjonen oppfyller en gitt standard.

RADIUS: gatewayen spør, backend-en bestemmer

Med RADIUS sender FortiGate legitimasjonen til en backend som eier faktorpolitikken. Utvekslingen kan være en enkel aksept eller avvisning, eller den kan inneholde en utfordring som klienten må svare på, noe som betyr at både VPN-tjenesten og klienten må støtte den utfordringsformen. En backend som håndhever en push-godkjenning, og en klient som bare kan legge til en sekssifret kode på et passord, møtes 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 backend-en uavhengig før du klandrer tunnelen. Hvis authserver-testen lykkes og en VPN-innlogging ikke gjør det, ligger forskjellen i håndteringen av utfordringen og ikke i legitimasjonen, og feilsøkingen av gatewayens autentiseringsdaemon er der det vises:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: nettleseren forlater gatewayen

I et SAML-design omdirigeres klienten til identitetsleverandøren, autentiserer seg der og kommer tilbake med en assertion som gatewayen validerer mot et tillitsforhold og en gruppemapping. Gatewayen ser aldri passordet eller den andre faktoren, noe som samtidig er en sikkerhetsforbedring og en driftsmessig komplikasjon: feilen skjer nå i en nettleserøkt som brannmuren ikke kan inspisere.

Å akseptere en assertion beviser ikke at leverandøren krevde MFA for den innloggingen. En leverandørpolicy som bruker MFA på noen applikasjoner og ikke på andre, vil gi nøyaktig den innloggingen du ba om og ingenting av den sikkerheten du antok. Sjekk leverandørens policy for nettopp denne applikasjonen, og sjekk at mappingen av gruppepåstander til FortiGate-grupper fortsatt stemmer etter en eventuell ny navngiving på hver side.

Klientstøtte betyr mer her enn noe annet sted. Noen VPN-klienter håndterer overleveringen til nettleseren innebygd, andre åpner systemnettleseren, og headless- eller kommandolinjeklienter fullfører kanskje ikke flyten i det hele tatt. Test med klienten brukerne faktisk kjører, på plattformene de faktisk bruker, før du publiserer profilen.

Gjenoppretting er en del av mekanismen

Hvert av designene ovenfor har en avhengighet som kan svikte for én bruker om gangen: en utilgjengelig postkasse, et tapt token, en backend som avviser en utfordring, en låst konto hos identitetsleverandøren. Bestem nå hvem som kan gjenopprette tilgang, gjennom hvilken støttet prosedyre og med hvilken verifisering av personen som ber om det. En lokal nødadministratorkonto som holdes atskilt fra VPN-veien, er en kontroll; og en uforklarlig omgåelse med bare passord er en hendelse som venter på å bli oppdaget.

Test deretter tre innlogginger før utrulling: den normale, en avvist eller utløpt faktor og den godkjente gjenopprettingen av en tapt autentiserer. Noter hvilken logg hver av dem vises i. Den registreringen er det som gjør «MFA er aktivert» til et design som noen andre kan drifte.