Pagpaparehistro ng VPN User: Hanapin Muna ang May-ari ng Pagkakakilanlan

May humihingi ng access sa VPN, at ang unang instinct ay magpatakbo ng adduser sa server. Tama lamang ang instinct na iyon sa makitid na hanay ng mga deployment. Bago gumawa ng anuman, buksan ang configuration ng server at alamin kung aling produkto ang tumatakbo doon at saan nito vinavalidate ang mga kredensyal, dahil ang account ay maaaring nasa database ng produkto, sa identity provider o sa sariling authentication stack ng host. Ang paggawa ng maling uri ng account ay nag-iiwan sa tao na may gumaganang login at walang tunnel.

Ang client profile na nagsasabing OpenVPN ay naglalarawan ng protocol, hindi ang sistema ng pagkakakilanlan sa likod nito.

Magsimula sa server, hindi sa adduser

Tukuyin muna ang produkto. Ang Community OpenVPN ay ang daemon at anumang authentication na ikinabit mo rito, samantalang ang Access Server ay produkto na may sariling user layer. Humingi ng configuration, pangalan ng unit at listahan ng package, at tingnan kung may web interface para sa pamamahala ng user. Pagkatapos tingnan kung paano inaasahan ng naka-deploy na profile na patunayan ng mga client kung sino sila: certificate, username at password, o pareho. Pinapangalanan ng sagot na iyon ang sistemang nagmamay-ari ng account.

Pagkatapos lamang niyon nagkakaroon ng kahulugan ang pariralang paggawa ng user. Sa deployment na certificate lamang, nangangahulugan ito ng pag-isyu ng device identity sa pamamagitan ng aprubadong proseso, at walang binabago ang Unix login. Sa deployment na may password, nangangahulugan ito ng backend na tunay na nagpapatunay ng password.

Apat na backend, apat na lugar para gumawa ng account

Ang lokal na authentication ng Access Server ay nag-iingat ng account sa sarili nitong database, kaya ang interface para gawin ang mga ito ay pag-aari ng produkto, hindi ng host. Ang PAM ay nagtatalaga ng validation sa stack ng operating system, kaya ang lokal na Unix account ay maaaring maging bahagi ng enrollment kapag iyon ang stack na pinili ng serbisyo. Ang LDAP, RADIUS at SAML ay naglilipat ng validation sa panlabas na serbisyo, kung saan naroon ang provisioning, patakaran sa password at MFA. Maaari pa ring mag-imbak ang Access Server ng mga certificate at permiso sa bawat user sa lahat ng apat na kaso, at iyon ang dahilan kung bakit nakakalito ang paghahati.

Suriin ang epektibong paraan para sa partikular na user na ito, hindi ang pandaigdigang default. Ang Access Server 2.10 at mas bago ay maaaring maglapat ng iba't ibang paraan ng authentication bawat grupo o bawat user, kaya hindi pinapatunayan ng lokal na default na ang account sa harap mo ay lokal na vinavalidate.

Ang karapatan ay hiwalay na desisyon

Ang authentication ay sumasagot kung sino ang tao; ang karapatan ay sumasagot kung saan siya maaaring makarating. Panatilihin ang mga ito bilang dalawang hakbang, dahil ang matagumpay na login ay hindi pagbibigay. Sadyang itakda ang mga inaasahang ruta, permiso sa resource at karapatang administratibo, at tiyakin na ang walang kaugnayang access ay nananatiling tinatanggihan. Kung saan sinusuportahan ng deployment ang indibidwal na pagkakakilanlan, mag-isyu ng isa sa bawat tao sa halip na ipasa ang profile ng iba, dahil ang pinagsasaluhang profile ay hindi maaaring bawiin para sa isang tao lamang.

Mahalaga rin ang materyal ng client. Ang auto-login profile at interactive na login ng user ay kumakatawan sa magkaibang ugnayan ng authentication, at ang pagpapalit ng isa sa iba ay nagbabago sa aktwal na vineverify ng server.

Ang pagbawi ng access ay bahagi ng enrollment

Isulat ang tatlong may-ari habang ginagawa ang user: sino ang nagpapatunay ng account, sino ang nagpapahintulot ng access sa VPN, at aling device o profile ang kumakatawan sa koneksyon. Maaaring tatlong magkaibang sistema ang mga ito, at ang planong pagbawi na nagpapangalan lamang ng isa ay nag-iiwan ng bukas na landas. Kapag umalis ang tao, alisin ang karapatan mula sa may-ari nito at bawiin ang bawat isyung kredensyal sa may-ari nito. Ang pagtanggal ng na-download na file ay hindi pagbawi, at gayon din ang pagtanggal ng lokal na entry kung ang panlabas na pagkakakilanlan ay nag-aauthenticate pa rin.

Pagkatapos subukan ang enrollment gaya ng gagawin ng isang attacker: kumonekta isang beses gamit ang bagong pagkakakilanlan, kumpirmahin ang access sa inaasahang resource, at kumpirmahin na ang walang kaugnayang resource ay tumatanggi pa rin. Ang unang gumaganang koneksyon at negatibong test ay isang kumpletong enrollment.

Itago ang rekord kasama ng profile na kinabibilangan nito. Itatanong ng susunod na auditor kung sino ang makakakonekta sa isang partikular na buwan, at ang sagot ay nasa tatlong may-ari na iyon.