Ensin EAP-menetelmä: mitä salasanan hajautetta VPN voi käyttää
VPN todentaa salaisuuden, ei verkkohajautetta. Lue menetelmä ja tarkista sitten, mitä säilö sisältää, ennen kuin lupaat, että samat salasanat toimivat edelleen.
Monella tiimillä on verkkokirjautuminen, joka toimii, ja VPN, joka hylkää jokaisen samasta taulusta tulevan salasanan. Verkkosovellus vertaa itse laskemaansa hajautetta, kun taas tunneli pyytää asiakasta todistamaan salaisuuden hallussapitoa tavalla, jonka palvelimen on kyettävä tarkistamaan. Nämä ovat eri vaatimuksia tallennetulle materiaalille. Juuri niiden välisessä kuilussa useimmat tällaiset hankkeet pysähtyvät.
Lue menetelmä ja vasta sitten skeema
Kirjoita ylös, minkä todisteen valittu menetelmä vaatii, ennen kuin katsot mitään skeemaa. Kysymys-vastaus-menetelmä tarvitsee materiaalia, josta palvelin voi laskea odotetun vastauksen, mikä käytännössä tarkoittaa salasanaa tai yhteensopivaa johdettua muotoa. Menetelmä, joka kuljettaa salasanan suojatun tunnelin sisällä, tarvitsee salasanan itsensä todentajalle. Lue menetelmän dokumentaatiota todentajan vaatimuksen vuoksi, ei asiakkaan kokoonpanon vuoksi, koska asiakasvaatimukset ovat yleensä se helppo osa.
Nykyaikaisen verkkokehyksen tuottama suolattu hajautus ei anna kumpaakaan. Se todentaa yhden tietyn vertailun, eikä sitä voi palauttaa salaisuuteen, josta se syntyi.
Kysymys-vastaus ei voi käyttää suolattua hajautusta
MSCHAPv2 on kysymys-vastaus-vaihto, joten palvelin ei koskaan saa salasanaa eikä voi vertailla tallennettua merkkijonoa. Sen on johdettava odotettu vastaus materiaalista, joka sillä jo on, ja siksi yhteensopivat tallennetut muodot ovat niin kapeita. Bcrypt- tai Argon2-arvo käyttäjäkohtaisella suolalla on yksisuuntainen tavalla, joka sulkee vaihdon kokonaan pois. Alla oleva taulukko lähtee tallennusmuodosta eikä menetelmän nimestä, koska tallennusmuoto ratkaisee vastauksen.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
SQL-liitännäisen dokumentaatio strongSwanille määrittelee oman skeemansa kokoonpanolle ja kirjautumistiedoille, ja hanke merkitsee kyseisen liitännäisen edelleen kokeelliseksi. Mikään siinä ei mukaudu sovelluksen käyttäjätauluun eikä arvaa, mikä hajautuskaava tuotti tallennetun arvon. Realistiset vaihtoehdot ovat siis siirtyminen säilöön, jota yhdyskäytävä voi käyttää, tai todentamispalvelu nykyisen säilön edessä, joka voi suorittaa vaihdon. Kaikki muu on liitin, jonka sisällä on piilotettu oletus.
RADIUS siirtää työn, ei vaatimusta
EAP:n delegoiminen RADIUS-palvelimelle muuttaa sitä, missä todentaminen tapahtuu, ja parantaa yleensä auditointijälkeä. Se ei palauta salasanaa yksisuuntaisesta hajautuksesta, joten todentamispalvelu tarvitsee edelleen materiaalia, joka sopii menetelmään, jonka se päättää. Tiimit huomaavat tämän rakennettuaan RADIUS-reitin ja kohdattuaan saman seinän toisessa päässä.
Siellä missä RADIUS-palvelin voi lukea hakemistoa, jossa on yhteensopiva kirjautumistieto, ratkaisu toimii ja VPN-yhdyskäytävä pysyy yksinkertaisena. Siellä missä ei voi, rehellinen vastaus on rekisteröinnin muutos eikä uusi liitin. Provisiointi ja peruutus kuuluvat sille, joka omistaa identiteetin, joten kopioitu taulukko ilman tuettua synkronointiprosessia on toinen kirjautumistietojen elinkaari eikä kertakirjautuminen. Se ajautuu erilleen ensimmäisen kerran, kun joku palauttaa salasanan vain yhdessä paikassa, ja ajautuminen on äänetöntä, kunnes molemmissa järjestelmissä oleva tili käyttäytyy kummassakin eri tavalla.
Rajaa hakemistoa lukeva tili juuri siihen lukemiseen ja pidä se erillään tilistä, jota yhdyskäytävä käyttää omaan kokoonpanoonsa. Jaettu ylläpitotili muuttaa vain luku -mallin paljon laajemmaksi vaikutusalaksi.
Missä tilin pitäisi sijaita
Kun materiaalikysymys on ratkaistu, jäljelle jää kaksi arkkitehtuuria. Yhdyskäytävä voi omistaa pienen kirjautumistietosäilön, jota vain se lukee, tai delegoida todentamispalvelulle, joka seisoo yrityksen hakemiston edessä.
Ensimmäistä on helpompi pohtia ja se on käyttäjälle huonompi, koska hänelle jää toinen salasana ylläpidettäväksi. Toinen säilyttää yhden identiteetin ja lisää riippuvuuden palvelusta, jonka on nyt oltava käynnissä ennen kuin kukaan voi yhdistää. Kumpikaan ei ole väärin, mutta valinta kannattaa kirjata yhdyskäytävän kokoonpanon viereen, muuten seuraava insinööri olettaa, että valittiin toinen. Mitä ikinä valitset, kaksi alla olevaa komentoa näyttävät nykytilan ennen kuin muutat sitä.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsTilin todentaminen ei ratkaise valtuutusta. Ryhmäjäsenyys, laitteen tila ja verkkolupa tarvitsevat edelleen eksplisiittisen kartoituksen sen jälkeen, kun käyttäjä on todistanut vaaditun identiteetin. Yhteys, joka todennetaan täydellisesti eikä valtuuta mitään, on käytännön tulos eikä menetelmän vika.