Jepuni përdoruesve të VPN akses te një shërbim, jo te nënrrjeti

Një kontraktor i duhet një aplikacion i brendshëm web dhe asgjë tjetër, dhe përgjigjja e lehtë është t'i jepet një tunel në nënrrjetin e serverit. Kjo funksionon deri në ditën kur ai e skanon. Dizajni më i ngushtë kërkon më shumë mendim, sepse arritshmëria, rrugëtimi dhe leja e aplikacionit janë tre kontrolle të ndara që duhet të pajtohen.

Shkruajeni kërkesën si shërbim, jo si nënrrjet

Filloni me hostin e destinacionit, protokollin dhe portin, pastaj shtoni grupin e përdoruesve ose pajisjeve që duhet ta arrijë. Përfshini zonën private DNS vetëm nëse aplikacioni zgjidh një emër, dhe përfshini një ofrues identiteti vetëm nëse fluksi i hyrjes ka nevojë për një. Çdo gjë tjetër është një varësi që nuk e keni justifikuar ende.

Nënrrjeti është një detaj implementimi i ekipit të rrjetit, ndërsa shërbimi është ajo që kërkoi biznesi dhe njësia që mund të rishikohet dhe të tërhiqet.

Nëse lista e varësive kalon mbi tre zëra, aplikacioni ndoshta ka nevojë për bisedën e vet të dizajnit.

Rrugëtojeni ngushtë, por zbatojeni diku tjetër

Një rrugë ose përzgjedhës i ngushtë i thotë tunelit cilat paketa të mbajë; kjo nuk është politikë autorizimi. Filtri i portës, muri i zjarrit i hostit të destinacionit dhe modeli i vetë lejeve i aplikacionit janë vendet ku vendoset aksesi. Një rrugë që mbulon një adresë është një fillim i mirë, dhe nuk është kontrolli që ndalon një përdorues të vendosur. Pikërisht ky ndarje ju lejon të ndryshoni filtrin pa ridizajnuar tunelin.

Në të kundërt, një rrugë e gjerë me filtër të rreptë mund të jetë legjitime, por vetëm nëse të gjithë të përfshirët e dinë cili prej tyre bën zbatimin.

Dokumentoni shprehimisht pikën e zbatimit, përndryshe ndryshimi i radhës do ta zhvendosë atë aksidentalisht.

Kontrolloni burimin që shërbimi sheh në të vërtetë

Destinacioni sheh ose adresën e pishinës së klientit ose adresën e portës, në varësi të faktit nëse përktheni. Rregullat e murit të zjarrit të hostit dhe regjistrat duhet të përputhen me burimin real. Nëse disa përdorues ndajnë një burim të përkthyer, asnjë rregull për përdorues në atë host nuk mund t'i dallojë ata, dhe ky është një kufizim dizajni, jo një gabim.

Zgjidhni përkthimin me qëllim: ai thjeshton rrugëtimin dhe shkatërron identitetin e burimit, gjë që ka rëndësi për auditimin dhe për rregullat për përdorues.

Shkruani cilin nga të dy zgjidhët, pranë rregullit që varet prej tij.

Autorizimi i aplikacionit nuk është opsional

Arritja e një porti nuk jep një rol. Aplikacioni ka ende nevojë për hyrjen dhe lejet e veta, sepse shtresa e rrjetit nuk mund të shprehë cilat regjistrime mund të modifikojë një përdorues. Një shërbim që i beson çdo kërkese nga nënrrjeti i brendshëm e kthen një tunel të ngushtë në akses të plotë për një kredencial të komprometuar. Tuneli vendos kush mund të hapë soketin, dhe aplikacioni vendos çfarë mund të bëhet me të.

Këtu dizajni i ngushtë shpërblehet dyfish, sepse më pak hoste të arritshme do të thotë më pak vende ku një gabim në nivel aplikacioni mund të shfrytëzohet.

Mbajini rregullin e rrjetit dhe rolin e aplikacionit në sisteme të ndara, dhe tërhiqini ato veçmas.

Provoni si rrugën e lejuar ashtu edhe atë të refuzuar

Lidhuni si përdoruesi i autorizuar dhe kryeni një operacion përfaqësues të padëmshëm, pastaj provoni një destinacion që duhet të jetë i paarritshëm. Një dizajn që teston vetëm gjysmën e parë nuk është testuar, dhe testi i refuzimit është ai që provon dizajnin. Testoni një sesion të ri pas çdo ndryshimi rregulli, dhe shikoni rrugën e kthimit nëse kërkesat vijnë por përgjigjet jo.

Mos i çaktivizoni filtrat e përcjelljes për të kaluar testin e pranimit, sepse kjo ndryshon gjënë që po testohet.

Kur përdoruesi nuk e ka më nevojë shërbimin, tërhiqni identitetin në distancë dhe rolin e aplikacionit në sistemet e tyre përkatëse, dhe regjistroni të dyja. Udhëzuesi i përcjelljes i strongSwan mbulon anën e portës së rrugës.