FortiGate VPN MFA: paikallinen token, RADIUS vai SAML?

Yhdyskäytävä, RADIUS-tausta tai SAML-tarjoaja voivat kukin vahvistaa tekijän, ja jokainen epäonnistuu eri tavalla. Sovita palvelu, asiakasohjelma ja palautuspolku yhteen.

Jokainen FortiGate VPN MFA -suunnittelu vastaa ensin yhteen kysymykseen: kuka vahvistaa toisen tekijän? Yhdyskäytävä itse voi tehdä sen paikallisella tokenilla tai sähköpostitse lähetettävällä koodilla, RADIUS-tausta voi pakottaa sen ja palauttaa haasteen, tai SAML-identiteettitarjoaja voi ottaa koko seremonian haltuunsa selaimessa. Jokainen näistä tuottaa erilaisen kirjautumisjakson, erilaisen vikaantumisjäljen ja erilaisen palautusmenettelyn, ja komentolohkon kopioiminen niiden välillä tuottaa kokoonpanon, joka näyttää uskottavalta eikä todista ketään. Tämä on mekanismiartikkeli: mitä kukin suunnittelu kirjautumisen aikana oikeasti tekee ja mihin se hajoaa.

Kirjautumisseremonia päättää, kuka omistaa tekijän

Kahdessa ensimmäisessä suunnittelussa FortiGate on luottava osapuoli. Se kerää tunnistetiedon, päättää tarvitaanko toinen tekijä ja vahvistaa sen paikallisesti tai haasteen kautta. Kolmannessa suunnittelussa yhdyskäytävä lakkaa olemasta vahvistaja ja muuttuu välittäjäksi: se ohjaa asiakasohjelman identiteettitarjoajalle, vastaanottaa väitteen ja yhdistää vahvistetun identiteetin käyttäjään ja ryhmään. RADIUS-suunnittelussa se on niiden välissä ja ajaa pyyntö-vastaus-vaihtoa taustan kanssa, jolla on käytäntö.

Tämä ero päättää, mitä todisteita voit kerätä. Kun yhdyskäytävä vahvistaa, sen oma virheenkorjaustuloste kertoo, mitä tapahtui. Kun identiteettitarjoaja vahvistaa, yhdyskäytävä tietää vain, että väite saapui, ja vastaus kysymykseen „vaadittiinko MFA todella“ on tarjoajan lokeissa, ei palomuurin lokeissa. Väärän lokin lukeminen on yleisin tapa diagnosoida väärin käyttöönotto, joka käyttäytyy täsmälleen suunnitellusti. Myös palvelu rajaa seremoniaa: FortiOS 7.6.3 poistaa SSL VPN -tunnelitilan IPsecin hyväksi, kun taas verkkotila jatkuu Agentless VPN:nä tuetuilla malleilla, joten yhdessä palvelussa todistettu seremonia ei ole automaattisesti saatavilla toisessa.

Paikallinen vahvistus: tokenit ja sähköpostikoodit

FortiGaten hallitsemat tekijät liittyvät käyttäjäobjektiin. FortiToken tai dokumentoitu token-integraatio vaatii rekisteröinnin, tuetun vahvistusseremonian, lisensoinnin missä se koskee ja korvausmenettelyn. Sähköpostikoodi vaatii toimivan SMTP-polun ja postilaatikon, johon käyttäjä pääsee ennen kuin tunneli on olemassa; se on riippuvuus, jolla ei ole mitään tekemistä kryptografian kanssa ja kaikki tekemistä sen kanssa, voiko kukaan kirjautua sisään.

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

Sähköpostin toimitus on osa todennuksen käytettävyyttä. Vain VPN:n kautta saavutettava postilaatikko luo silmukan, joka ei ratkea kenellekään itsestään, ja toimitusviive, koodin voimassaolo ja etätodennuksen aikakatkaisu ovat kolme erillistä rajoitusta. Yhden nostaminen ei korjaa saavuttamatonta postilaatikkoa, ja suunnittelu, joka ei ole koskaan testannut silmukkaa, löytää sen ensimmäisessä salasanan palautuksessa loman jälkeen.

Myös varmuusvaatimukset kuuluvat tähän, ennen tuotevalintaa. NIST SP 800-63B pitää sähköpostia hyväksymättömänä kaistan ulkopuoliseen todennukseen, joten yhdenmukaisuutta väittävä käyttöönotto ei voi käyttää sähköpostikoodia toisena tekijänä, oli se kuinka kätevää tahansa. Toiminnon olemassaolo laitteessa ei ole väite, että toiminto täyttää tietyn standardin.

RADIUS: yhdyskäytävä kysyy, tausta päättää

RADIUSin kanssa FortiGate lähettää tunnistetiedon taustalle, joka omistaa tekijäkäytännön. Vaihto voi olla yksinkertainen hyväksyntä tai hylkäys, tai siihen voi kuulua haaste, johon asiakasohjelman on vastattava, mikä tarkoittaa, että sekä VPN-palvelun että asiakasohjelman on tuettava sitä haasteen muotoa. Tausta, joka pakottaa push-hyväksynnän, ja asiakasohjelma, joka osaa vain liittää kuusinumeroisen koodin salasanaan, eivät kohtaa puolivälissä.

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>

Testaa tausta erikseen ennen kuin syytät tunnelia. Jos authserver-testi onnistuu eikä VPN-kirjautuminen, ero on haasteen käsittelyssä eikä tunnistetiedossa, ja yhdyskäytävän todennusdaemonin virheenkorjaus on paikka, jossa se näkyy:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: selain lähtee yhdyskäytävältä

SAML-suunnittelussa asiakasohjelma ohjataan identiteettitarjoajalle, se todentaa siellä ja palaa väitteen kanssa, jonka yhdyskäytävä validoi luottamussuhdetta ja ryhmämappausta vasten. Yhdyskäytävä ei näe koskaan salasanaa tai toista tekijää, mikä on samanaikaisesti turvallisuusparannus ja operatiivinen hankaluus: vika tapahtuu nyt selainistunnossa, jota palomuuri ei voi tarkastaa.

Väitteen hyväksyminen ei todista, että tarjoaja vaati MFA:n kyseiselle kirjautumiselle. Tarjoajan käytäntö, joka soveltaa MFA:ta joihinkin sovelluksiin eikä toisiin, tuottaa täsmälleen pyytämäsi kirjautumisen eikä mitään olettamastasi vakuudesta. Tarkista tarjoajan käytäntö juuri tälle sovellukselle ja tarkista, että ryhmäväitteiden mappaus FortiGate-ryhmiin vastaa edelleen minkä tahansa nimeämismuutoksen jälkeen kummalla puolella tahansa.

Asiakastuki merkitsee täällä enemmän kuin missään muualla. Jotkin VPN-asiakasohjelmat hoitavat selainsiirron natiivisti, jotkin avaavat järjestelmän selaimen, ja päätteettömät tai komentoriviasiakasohjelmat eivät ehkä suorita virtaa lainkaan. Testaa asiakasohjelmalla, jota käyttäjät oikeasti ajavat, alustoilla, joita he oikeasti käyttävät, ennen kuin julkaiset profiilin.

Palautus on osa mekanismia

Jokaisella yllä olevalla suunnittelulla on riippuvuus, joka voi pettää yhden käyttäjän kohdalla kerrallaan: saavuttamaton postilaatikko, kadonnut token, haasteen hylkäävä tausta, lukittu identiteettitarjoajan tili. Päätä nyt, kuka voi palauttaa pääsyn, millä tuetulla menettelyllä ja millä pyytävän henkilön vahvistuksella. VPN-polusta erillään pidettävä paikallinen hätäylläpitäjätili on valvontakeino; ja selittämätön vain salasanaan perustuva ohitus on odottava tapahtuma.

Testaa sitten kolme kirjautumista ennen käyttöönottoa: normaali, hylätty tai vanhentunut tekijä ja hyväksytty kadonneen todennuksen palautus. Kirjaa, missä lokissa kukin näkyy. Juuri se kirjaus muuttaa „MFA on käytössä“ suunnitteluksi, jota joku toinen voi ylläpitää.

Aiheeseen liittyvät artikkelit