A ju nevojitet ende një VPN nëse përdorni Identity-Aware Proxy?

Supozimi është ky: sapo një proxy që e njeh identitetin të vendoset përpara aplikacioneve të brendshme, VPN-i është thjesht dekor dhe klienti mund të largohet. Kjo vlen për një rast të ngushtë, një aplikacion HTTPS interaktiv që një person e përdor në shfletues, dhe dështon në heshtje kudo tjetër. Një proxy autorizon një kërkesë ndaj një burimi; një VPN pranon një klient në një fushë rrjeti, dhe këto dy kufij rrallë përputhen. Përpara se të hiqni një tunel, krahasoni veprimet që njerëzit tuaj kryejnë vërtet, jo etiketat e produktit në diagram.

Dy porta autorizojnë gjëra të ndryshme

Porta e aplikacionit vendos nëse kjo kërkesë, nga ky identitet, mund të arrijë këtë burim të mbrojtur. Përmbledhja e Identity-Aware Proxy nga Google përshkruan pikërisht këtë formë: një shtresë qendrore autorizimi përpara aplikacioneve HTTPS, e drejtuar nga një rol IAM. Kufiri është burimi, dhe njësia e aksesit është kërkesa. Një VPN i rrugëzuar bën diçka më të trashë dhe më të gjerë: pranon një klient në një fushë rrjeti të përcaktuar, pas së cilës aplikacioni ende vendos çfarë mund të bëjë ai klient.

Asnjëri model nuk e nënkupton tjetrin. Kalimi i portës nuk thotë asgjë për leximin e një regjistrimi të caktuar, dhe të qenit në rrjet nuk thotë asgjë për lejen për të vepruar.

Çfarë proxy nuk mbulon, dhe VPN mbulon

Sesionet SSH, klientët e bazave të dhënave, ndërmjetësit e mesazheve dhe emrat e brendshëm të hosteve që asnjë shfletues nuk i hap kurrë nuk bëhen të arritshëm vetëm sepse ekziston një proxy web. Secili flet protokollin e vet, dhe secili ka nevojë ose për rrugën e vet të vërtetuar ose për një rrjet që e mbart. Ky është hendeku që njerëzit e zbulojnë ditën e parë të migrimit, zakonisht nga një inxhinier i gatishmërisë me një laptop që nuk arrin më të zgjidhë një emër hosti.

Hendeku i kundërt është po aq real. Një VPN që pranon një klient në një nënrrjet nuk e vërteton personin brenda tij, dhe një pajisje e komprometuar në atë nënrrjet trashëgon atë që rrjeti lejon. Nëse kërkesa është autorizim për çdo kërkesë me një identitet të auditueshëm, vetëm rrugëzimi nuk mund ta prodhojë atë. Shumica e organizatave përfundojnë duke i drejtuar të dyja, dhe pyetja interesante është se cilat burime secili mund të qëndrojë përpara.

Rrjedha e punës së klientit vendos më shumë se diagrami i arkitekturës

Hyrja në shfletues me ridrejtim dhe një sfidë MFA të rastësishme është një përvojë e mirë për një person që klikon një faqerojtës. Një punë cron, një CLI ose një agjent ndërtimi nuk ka shfletues dhe nuk mund t'i përgjigjet një kërkese interaktive, ndaj i duhet një rrugë jointeraktive e dokumentuar ose tuneli. Zbulimi i asaj kërkese zakonisht ndodh pasi dizajni miratohet.

Numëroni klientët para se të numëroni aplikacionet. Një panel mund t'u shërbejë njëqind njerëzve; një port bazë të dhënash mund të bllokojë një ekip të tërë.

Gjendja e pajisjes nuk është veti e asnjërës portë

Instalimi i një klienti VPN nuk është kontroll përputhshmërie, dhe një dizajn i bazuar në shfletues nuk është automatikisht i paaftë të respektojë politikën për pajisje të menaxhuara. Të dyja mund të integrohen me sinjale gjendjeje, dhe të dyja mund të vendosen pa to. Pyetni çfarë zbatimi ekziston, kujt i përket politika dhe çfarë ndodh me një pajisje që e shkel atë, në vend që ta nxirrni nga forma e produktit.

E njëjta kujdes vlen edhe për heqjen e aksesit. Fshirja e anëtarësisë në një grup në proxy dhe revokimi i një certifikate për tunelin janë veprime të ndryshme me vonesa të ndryshme, dhe njëra prej tyre zakonisht harrohet gjatë largimit.

Gjeni rrugët alternative përpara se të hiqni diçka

Një origjinë e pambrojtur pas proxy, një emër i dytë hosti që e anashkalon, ose një rrugë e gjerë private e mbetur nga një dizajn i mëparshëm do të vendosin cila portë është në fuqi. Testoni një veprim të lejuar dhe një të refuzuar përmes klientit të vërtetë, jo përmes konsolës, dhe testojini ato nga një pajisje që nuk është regjistruar kurrë. Rasti i refuzuar është ai që ju tregon nëse porta po bën diçka.

Pastaj shkruani dorëzimin: regjistrimi, përditësimet, heqja e aksesit dhe rruga e rikuperimit për dikë të kyçur jashtë në orën 2 të mëngjesit. Heqja e një kërkese ose e një aplikacioni klienti e zhvendos përgjegjësinë mes ekipeve; nuk e fshin përgjegjësinë.

Nëse vendosni këtë javë, filloni me një listë veprimesh në vend të një liste produktesh, shënoni cilat mund t'i kryejë një shfletues, dhe lërini të tjerat të justifikojnë atë akses rrjeti që mbijeton.