Registracija uporabnika VPN: najprej poiščite lastnika identitete

Nekdo prosi za dostop do VPN, in prvi instinkt je zagnati adduser na strežniku. Ta instinkt je pravilen le v ozkem naboru namestitev. Preden karkoli ustvarite, odprite konfiguracijo strežnika in ugotovite, kateri izdelek tam deluje in kje preverja poverilnice, ker lahko račun živi v podatkovni bazi izdelka, pri ponudniku identitete ali v lastnem skladu za preverjanje pristnosti gostitelja. Ustvarjanje napačne vrste računa pusti osebo z delujočo prijavo in brez tunela.

Profil odjemalca, ki navaja OpenVPN, opisuje protokol, ne sistema identitete za njim.

Začnite s strežnikom, ne z adduser

Najprej prepoznajte izdelek. Community OpenVPN je demon plus vsaka avtentikacija, ki ste jo povezali z njim, medtem ko je Access Server izdelek z lastno uporabniško plastjo. Zahtevajte konfiguracijo, ime enote in seznam paketov ter preverite, ali obstaja spletni vmesnik za upravljanje uporabnikov. Nato poglejte, kako nameščeni profil pričakuje, da bodo odjemalci dokazali, kdo so: s potrdilom, z uporabniškim imenom in geslom ali z obojim. Ta odgovor poimenuje sistem, ki ima račun v lasti.

Šele nato ima besedna zveza ustvarjanje uporabnika pomen. V namestitvi samo s potrdili to pomeni izdajo identitete naprave po odobrenem postopku, prijava Unix pa ne spremeni ničesar. V namestitvi z geslom to pomeni backend, ki geslo resnično preverja.

Štirje backendi, štiri mesta za ustvarjanje računa

Lokalna avtentikacija Access Serverja hrani račune v svoji podatkovni bazi, zato vmesnik za njihovo ustvarjanje pripada izdelku, ne gostitelju. PAM preverjanje prepusti skladu operacijskega sistema, zato je lahko lokalni račun Unix del registracije, ko je storitev izbrala prav ta sklad. LDAP, RADIUS in SAML preverjanje premaknejo v zunanjo storitev, kjer živijo priprava, politika gesel in MFA. Access Server lahko v vseh štirih primerih še vedno hrani potrdila in dovoljenja na uporabnika, in prav to naredi delitev zmedeno.

Preverite učinkovito metodo za tega konkretnega uporabnika, ne globalne privzete vrednosti. Access Server 2.10 in novejši lahko uporabijo različne metode avtentikacije na skupino ali uporabnika, zato lokalna privzeta vrednost ne dokazuje, da se račun pred vami preverja lokalno.

Pravica je ločena odločitev

Avtentikacija odgovarja, kdo je oseba; pravica odgovarja, do kam lahko seže. Držite ju kot dva koraka, ker uspešna prijava ni podelitev. Namerno dodelite predvidene poti, dovoljenja za vire in upravljavske pravice ter potrdite, da nepovezan dostop ostane zavrnjen. Kjer namestitev podpira posamezne identitete, izdajte eno na osebo, namesto da posredujete profil nekoga drugega, ker skupnega profila ni mogoče preklicati za eno osebo.

Tudi gradivo odjemalca je pomembno. Profil z samodejno prijavo in interaktivna uporabniška prijava predstavljata različna razmerja avtentikacije, zamenjava enega z drugim pa spremeni, kaj strežnik v resnici preveri.

Preklic dostopa je del registracije

Zapišite tri lastnike, medtem ko se uporabnik ustvarja: kdo preverja račun, kdo odobri dostop do VPN in katera naprava ali profil predstavlja povezavo. To so lahko trije različni sistemi, in načrt preklica, ki imenuje le enega od njih, pusti pot odprto. Ko oseba odide, odstranite pravico pri njenem lastniku in prekličite vsako izdano poverilnico pri njenem lastniku. Brisanje prenesene datoteke ni preklic, in tudi brisanje lokalnega vnosa ne, če se zunanja identiteta še vedno preverja.

Nato registracijo preizkusite tako, kot bi jo izvedel napadalec: povežite se enkrat z novo identiteto, potrdite dostop do predvidenega vira in potrdite, da nepovezan vir še vedno zavrača. Prva delujoča povezava in negativni test skupaj pomenita dokončano registracijo.

Zapis hranite skupaj s profilom, ki mu pripada. Naslednji revizor bo vprašal, kdo se je lahko povezal v določenem mesecu, in odgovor je pri tistih treh lastnikih.