VPN lietotāja reģistrēšana: vispirms atrodiet identitātes īpašnieku

Kāds lūdz VPN piekļuvi, un pirmā reakcija ir palaist adduser serverī. Šī reakcija ir pareiza tikai šaurā izvietojumu kopā. Pirms kaut ko veidot, atveriet servera konfigurāciju un noskaidrojiet, kurš produkts tur darbojas un kur tas pārbauda akreditācijas datus, jo konts var atrasties produkta datubāzē, identitātes pakalpojumu sniedzējā vai paša resursdatora autentifikācijas steikā. Nepareiza veida konta izveide atstāj cilvēku ar strādājošu pieteikšanos un bez tunela.

Klienta profils, kurā norādīts OpenVPN, apraksta protokolu, nevis identitātes sistēmu aiz tā.

Sāciet ar serveri, nevis ar adduser

Vispirms identificējiet produktu. Community OpenVPN ir dēmons plus jebkura autentifikācija, ko tam pievienojāt, savukārt Access Server ir produkts ar savu lietotāju slāni. Pieprasiet konfigurāciju, vienības nosaukumu un pakotņu sarakstu, un pārbaudiet, vai lietotāju pārvaldībai ir tīmekļa saskarne. Pēc tam apskatiet, kā izvietotais profils sagaida, ka klienti pierādīs, kas viņi ir: ar sertifikātu, lietotājvārdu un paroli vai abiem. Šī atbilde nosauc sistēmu, kurai pieder konts.

Tikai pēc tam frāzei izveidot lietotāju ir nozīme. Izvietojumā tikai ar sertifikātiem tas nozīmē ierīces identitātes izsniegšanu apstiprinātajā procesā, un Unix pieteikšanās neko nemaina. Izvietojumā ar paroli tas nozīmē backend, kas patiešām pārbauda paroli.

Četri backend, četras vietas, kur izveidot kontu

Access Server vietējā autentifikācija glabā kontus savā datubāzē, tāpēc to izveides saskarne pieder produktam, nevis resursdatoram. PAM deleģē pārbaudi operētājsistēmas steikam, tāpēc vietējais Unix konts var būt reģistrācijas daļa, ja pakalpojums ir izvēlējies tieši šo steiku. LDAP, RADIUS un SAML pārvieto pārbaudi uz ārēju pakalpojumu, kur dzīvo nodrošināšana, paroļu politika un MFA. Access Server visos četros gadījumos joprojām var glabāt katra lietotāja sertifikātus un atļaujas, un tieši tas padara sadalījumu mulsinošu.

Pārbaudiet šim konkrētajam lietotājam piemēroto metodi, nevis globālo noklusējumu. Access Server 2.10 un jaunākas versijas var piemērot dažādas autentifikācijas metodes grupai vai lietotājam, tāpēc vietējs noklusējums nepierāda, ka priekšā esošais konts tiek pārbaudīts vietēji.

Tiesības ir atsevišķs lēmums

Autentifikācija atbild, kas ir cilvēks; tiesības atbild, ko viņš var sasniegt. Turiet tos kā divus soļus, jo veiksmīga pieteikšanās nav piešķiršana. Apzināti piešķiriet paredzētos maršrutus, resursu atļaujas un administratīvās tiesības un apstipriniet, ka nesaistīta piekļuve paliek liegta. Kur izvietojums atbalsta individuālas identitātes, izsniedziet vienu uz cilvēku, nevis pārsūtiet kāda cita profilu, jo kopīgu profilu nevar atņemt vienam cilvēkam.

Klienta materiāls arī ir svarīgs. Automātiskās pieteikšanās profils un interaktīva lietotāja pieteikšanās atspoguļo atšķirīgas autentifikācijas attiecības, un viena aizstāšana ar otru maina to, ko serveris patiešām pārbauda.

Piekļuves atņemšana ir reģistrācijas daļa

Pierakstiet trīs īpašniekus, kamēr lietotājs tiek veidots: kas pārbauda kontu, kas atļauj VPN piekļuvi un kura ierīce vai profils pārstāv savienojumu. Tie var būt trīs dažādas sistēmas, un atņemšanas plāns, kas nosauc tikai vienu no tiem, atstāj ceļu vaļā. Kad cilvēks aiziet, noņemiet tiesības no to īpašnieka un atsauc visus izsniegtos akreditācijas datus pie to īpašnieka. Lejupielādēta faila dzēšana nav atsaukšana, un arī lokāla ieraksta dzēšana nav, ja ārēja identitāte joprojām autentificējas.

Pēc tam pārbaudiet reģistrāciju tā, kā rīkotos uzbrucējs: pievienojieties vienu reizi ar jauno identitāti, apstipriniet piekļuvi paredzētajam resursam un apstipriniet, ka nesaistīts resurs joprojām atsakās. Pirmais strādājošais savienojums plus negatīvs tests ir pabeigta reģistrācija.

Glabājiet ierakstu kopā ar profilu, kuram tas pieder. Nākamais auditors jautās, kas varēja pieslēgties noteiktā mēnesī, un atbilde ir tajos trijos īpašniekos.