Teie VPN-parool on sama privaatne kui selle kontrollija

Mõelge läbi neli küsimust iga VPN-sisselogimise kohta: mis kaitseb parooli edastamise ajal, milline komponent selle vastu võtab, mida see komponent sellega teeb ja mida hiljem salvestatakse. Iga vastus on erinev kontroll, ja tugev vastus ühele ei ütle teiste kohta midagi. Viga on käsitleda tunneli krüpteerimist nii, nagu kataks see kõik neli. See katab esimese ja ainult esimese.

Küsige, kes sessiooni lõpetab, mitte kas sessioon on krüpteeritud.

Krüpteeritud kelle eest, täpsemalt?

TLS kaitseb parooli kliendi ja ühenduse lõpetaja vahel. Kui see lõpp-punkt on VPN-lüüs, näeb lüüsi autentimiskood parooli lihttekstina, valideerib selle ja edastab edasi kas selle või tuletatud väärtuse. See on kavandatud lahendus, mitte leke. Võrguvaatleja teel ei õpi midagi kasulikku, ja kontrolli tegev komponent õpib kõik, mida ta vajab.

OpenVPN kogukond dokumenteerib seda selgesõnaliselt: auth-user-pass-verify annab esitatud volitused üle kontrolliskriptile või pistikprogrammile. See on komponentide vaheline tahtlik üleandmine ja kuulub usaldusmudelisse nimetatud osapoolena.

Kontrollija näeb parooli

Kui komponent on parooli kontrollimiseks kätte saanud, otsustavad selle juurdepääsukontrollid, logimine ja koodi kvaliteet, kas saladus jääb suletuks. Skript, mis kirjutab volitused logisse, või pistikprogramm, mis need vahemällu salvestab, tekitab palju suurema avatuse kui protokoll. Juurdepääs sõltub arhitektuurist ja rollidest, mitte tunnelist, mistõttu kuulub hindamisse teenuse omanik, kes kontrollijat juhib.

Erinevad meetodid paljastavad erinevat materjali. Sertifikaadi autentimine tõestab privaatvõtit ilma seda saatmata, ja föderatsioonivoog võib jätta parooli identiteediteenuse pakkuja juurde, väljastades VPN-ile piiratud väite. Need lahendused kitsendavad ringi; ükski neist ei kõrvalda kõiki usaldatud osapooli.

Salvestatud räsid kaitsevad teist etappi

NISTi juhised eristavad kaitstud edastust vastupidavast kontrollija salvestusest. Soolamine ja kulukas räsisherm käsitlevad salvestatud kontrollija ohtu, mis on see, mis juhtub tagantjärele, kui andmebaas lekib. Nad ei tee midagi jooksva komponendi heaks, mis peab sisendi võrdlemiseks vastu võtma. Juhiste lugemine nii, nagu lubaksid need jooksuaegset salastatust, on kategooriaviga.

Hästi räsitud paroolihoidla ja avatud kontrolliskript võivad seega ühes tootes vastuoluta kõrvuti eksisteerida.

Valida meetod, mis kitsendab ringi

Kui nõue on, et lüüs ei saaks kunagi korduvkasutatavat parooli, valige meetod, mis seda tõesti tagab; andmesalastuse vahetamine ei loo seda omadust. VPN-serveri sertifikaadi kontrollimine ütleb teile, millise partnerini jõudsite; see ei ütle midagi selle kohta, kuidas see partner hiljem volitusi käsitleb. Jätke serverikontroll alles, kasutage iga teenuse jaoks eraldi volitusi ja järgige organisatsiooni toetatud identiteedivoogu.

Kirjutage üles osapool, kes parooli saab, osapool, kes selle valideerib, ja vorm, milles seda säilitatakse. Need kolm vastust kuuluvad ühendusprofiili kõrvale, sest need elavad üle iga konkreetse tunneli.

Kasulik küsimus ei ole, kas parool on krüpteeritud, vaid kelle eest see peidetakse, milline komponent selle saab ja milline vorm hiljem püsib.