Kažkas prašo VPN prieigos, ir pirmasis instinktas yra paleisti adduser serveryje. Šis instinktas teisingas tik siaurame diegimų rinkinyje. Prieš ką nors kurdami, atidarykite serverio konfigūraciją ir išsiaiškinkite, koks produktas ten veikia ir kur tikrina prisijungimo duomenis, nes paskyra gali būti produkto duomenų bazėje, tapatybės teikėjo sistemoje arba pačio serverio autentifikavimo saugykloje. Netinkamo tipo paskyros sukūrimas palieka žmogų su veikiančiu prisijungimu ir be tunelio.

Kliento profilis, kuriame nurodyta OpenVPN, apibūdina protokolą, o ne už jo esančią tapatybės sistemą.

Pradėkite nuo serverio, o ne nuo adduser

Pirmiausia nustatykite produktą. Community OpenVPN yra demonas ir bet kokia autentifikacija, kurią prie jo prijungėte, o Access Server yra produktas su savu vartotojų sluoksniu. Paprašykite konfigūracijos, unit pavadinimo ir paketų sąrašo, ir patikrinkite, ar yra žiniatinklio sąsaja vartotojų valdymui. Tada pažiūrėkite, kaip įdiegtas profilis tikisi, kad klientai įrodys, kas jie yra: sertifikatu, vartotojo vardu ir slaptažodžiu arba abiem. Tas atsakymas įvardija sistemą, kuriai priklauso paskyra.

Tik po to frazė sukurti vartotoją įgyja prasmę. Diegime tik su sertifikatais tai reiškia įrenginio tapatybės išdavimą patvirtintu procesu, o Unix prisijungimas nieko nekeičia. Diegime su slaptažodžiu tai reiškia backend dalį, kuri iš tikrųjų tikrina slaptažodį.

Keturi backend, keturios vietos paskyrai sukurti

Access Server vietinė autentifikacija laiko paskyras savo duomenų bazėje, todėl jų kūrimo sąsaja priklauso produktui, o ne serveriui. PAM perduoda tikrinimą operacinės sistemos saugyklai, todėl vietinė Unix paskyra gali būti registracijos dalis, kai paslauga pasirinko būtent tą saugyklą. LDAP, RADIUS ir SAML perkelia tikrinimą į išorinę paslaugą, kurioje gyvena paruošimas, slaptažodžių politika ir MFA. Access Server visais keturiais atvejais vis dar gali laikyti kiekvieno vartotojo sertifikatus ir leidimus, ir būtent tai daro atskyrimą painų.

Patikrinkite šiam konkrečiam vartotojui taikomą metodą, o ne visuotinį numatytąjį. Access Server 2.10 ir naujesnės versijos gali taikyti skirtingus autentifikavimo metodus grupei ar vartotojui, todėl vietinis numatytasis nustatymas neįrodo, kad priešais esanti paskyra tikrinama vietoje.

Teisė yra atskiras sprendimas

Autentifikavimas atsako, kas yra žmogus; teisė atsako, ko jis gali pasiekti. Laikykite juos dviem žingsniais, nes sėkmingas prisijungimas nėra suteikimas. Sąmoningai priskirkite numatytus maršrutus, išteklių leidimus ir administravimo teises bei patvirtinkite, kad nesusijusi prieiga lieka atmesta. Kai diegimas palaiko individualias tapatybes, išduokite po vieną asmeniui, o ne perduokite kito žmogaus profilį, nes bendro profilio negalima panaikinti vienam asmeniui.

Kliento medžiaga taip pat svarbi. Automatinio prisijungimo profilis ir interaktyvus vartotojo prisijungimas atspindi skirtingus autentifikavimo santykius, o vieno pakeitimas kitu pakeičia tai, ką serveris iš tikrųjų tikrina.

Prieigos panaikinimas yra registracijos dalis

Užrašykite tris savininkus, kol vartotojas kuriamas: kas tikrina paskyrą, kas leidžia VPN prieigą ir kuris įrenginys ar profilis atstovauja ryšiui. Tai gali būti trys skirtingos sistemos, o panaikinimo planas, kuriame įvardijama tik viena iš jų, palieka kelią atvirą. Kai žmogus išeina, pašalinkite teisę iš jos savininko ir panaikinkite kiekvieną išduotą prisijungimo duomenį pas jo savininką. Atsisiųsto failo ištrynimas nėra panaikinimas, ir vietinio įrašo ištrynimas taip pat ne, jei išorinė tapatybė vis dar autentifikuojasi.

Tada išbandykite registraciją taip, kaip elgtųsi užpuolikas: prisijunkite vieną kartą su nauja tapatybe, patvirtinkite prieigą prie numatyto ištekliaus ir patvirtinkite, kad nesusijęs išteklius vis dar atsisako. Pirmasis veikiantis ryšys ir neigiamas testas kartu yra užbaigta registracija.

Saugokite įrašą kartu su profiliu, kuriam jis priklauso. Kitas auditorius paklaus, kas galėjo prisijungti per tam tikrą mėnesį, o atsakymas yra tuose trijuose savininkuose.

Susiję straipsniai