VPN-kasutaja registreerimine: leidke esmalt identiteedi omanik

Keegi palub VPN-i juurdepääsu ja esimene instinkt on serveris adduser käivitada. See instinkt on õige ainult kitsas hulgas paigaldustes. Enne millegi loomist avage serveri konfiguratsioon ja tehke kindlaks, milline toode seal töötab ja kus see mandaate valideerib, sest konto võib asuda toote andmebaasis, identiteedipakkujas või hosti enda autentimispinus. Vale tüüpi konto loomine jätab inimese töötava sisselogimisega ja tunnelita.

Kliendiprofiil, milles on kirjas OpenVPN, kirjeldab protokolli, mitte selle taga olevat identiteedisüsteemi.

Alustage serverist, mitte adduser-käsust

Tehke esmalt kindlaks toode. Community OpenVPN on deemon pluss mis tahes autentimine, mille te sellega ühendasite, samas kui Access Server on toode, millel on oma kasutajakiht. Küsige konfiguratsiooni, uniti nime ja paketiloendi ning kontrollige, kas kasutajate haldamiseks on veebiliides. Seejärel vaadake, kuidas juurutatud profiil eeldab, et kliendid tõestavad, kes nad on: sertifikaadi, kasutajanime ja parooliga või mõlemaga. See vastus nimetab süsteemi, millele konto kuulub.

Alles pärast seda omab fraas kasutaja loomine tähendust. Ainult sertifikaatidega paigalduses tähendab see seadme identiteedi väljastamist kinnitatud protsessi kaudu ja Unixi sisselogimine ei muuda midagi. Parooliga paigalduses tähendab see backendi, mis parooli tegelikult valideerib.

Neli backendi, neli kohta konto loomiseks

Access Serveri kohalik autentimine hoiab kontosid oma andmebaasis, seega kuulub nende loomise liides tootele, mitte hostile. PAM delegeerib valideerimise operatsioonisüsteemi pinule, mistõttu võib kohalik Unixi konto olla registreerimise osa, kui teenus valis just selle pinu. LDAP, RADIUS ja SAML viivad valideerimise välisesse teenusesse, kus elavad provisioneerimine, paroolipoliitika ja MFA. Access Server võib kõigil neljal juhul siiski hoida kasutajapõhiseid sertifikaate ja õigusi ning just see teeb jaotuse segadust tekitavaks.

Kontrollige selle konkreetse kasutaja tegelikku meetodit, mitte üldist vaikeväärtust. Access Server 2.10 ja hilisemad võivad rakendada erinevaid autentimismeetodeid grupi või kasutaja kaupa, seega kohalik vaikeväärtus ei tõenda, et teie ees olev konto valideeritakse kohapeal.

Õigus on eraldi otsus

Autentimine vastab, kes inimene on; õigus vastab, milleni ta võib jõuda. Hoidke neid kahe sammuna, sest edukas sisselogimine ei ole luba. Määrake kavandatud marsruudid, ressursiõigused ja haldusõigused teadlikult ning kinnitage, et mitteseotud juurdepääs jääb keelatuks. Kus paigaldus toetab individuaalseid identiteete, väljastage üks inimese kohta, selle asemel et edastada kellegi teise profiili, sest jagatud profiili ei saa ühe inimese jaoks tagasi võtta.

Kliendi materjal on samuti oluline. Automaatse sisselogimise profiil ja interaktiivne kasutaja sisselogimine esindavad erinevaid autentimissuhteid ning ühe vahetamine teise vastu muudab seda, mida server tegelikult kontrollib.

Juurdepääsu tühistamine on registreerimise osa

Kirjutage kasutaja loomise ajal üles kolm omanikku: kes kontot valideerib, kes VPN-i juurdepääsu autoriseerib ja milline seade või profiil ühendust esindab. Need võivad olla kolm erinevat süsteemi ja tühistamisplaan, mis nimetab ainult ühte neist, jätab tee avatuks. Kui inimene lahkub, eemaldage õigus selle omanikult ja tühistage iga väljastatud mandaat selle omaniku juures. Allalaaditud faili kustutamine ei ole tühistamine ja seda ei ole ka kohaliku kirje kustutamine, kui väline identiteet autendib endiselt.

Seejärel testige registreerimist nii, nagu ründaja seda teeks: ühenduge korra uue identiteediga, kinnitage juurdepääs kavandatud ressursile ja kinnitage, et mitteseotud ressurss keeldub endiselt. Esimene töötav ühendus pluss negatiivne test on lõpetatud registreerimine.

Hoidke kirje selle profiili juures, millele see kuulub. Järgmine audiitor küsib, kes sai antud kuul ühenduda, ja vastus peitub neis kolmes omanikus.