Kailangan mo pa ba ng VPN kung gumagamit ka ng Identity-Aware Proxy?

Ang palagay ay ganito: kapag nakatayo na ang isang proxy na may alam sa pagkakakilanlan sa harap ng mga panloob na aplikasyon, ang VPN ay palamuti na lang at makakaalis na ang kliyente. Totoo ito para sa isang makitid na kaso, isang interaktibong HTTPS application na ginagamit ng isang tao sa isang browser, at tahimik itong nabibigo sa lahat ng iba pang lugar. Ang proxy ay nagpapahintulot ng kahilingan laban sa isang resource; ang isang VPN ay nagpapapasok ng kliyente sa isang saklaw ng network, at ang dalawang hangganang ito ay bihirang magtugma. Bago mo i-retire ang isang tunnel, ihambing ang mga operasyong talagang ginagawa ng iyong mga tao, hindi ang mga label ng produkto sa diagram.

Dalawang pintuan ang nagpapahintulot ng magkaibang bagay

Ang pintuan ng aplikasyon ay nagpapasya kung ang kahilingang ito, mula sa pagkakakilanlang ito, ay makakaabot sa protektadong resource na ito. Ang pangkalahatang-tanaw ng Identity-Aware Proxy ng Google ay naglalarawan ng eksaktong hugis na iyon: isang sentral na sapin ng awtorisasyon sa harap ng mga HTTPS application, na pinapatakbo ng isang tungkulin ng IAM. Ang hangganan ay ang resource, at ang yunit ng pag-access ay ang kahilingan. Ang rutang VPN ay gumagawa ng mas magaspang at mas malawak: nagpapapasok ng kliyente sa isang tinukoy na saklaw ng network, at pagkatapos ay nagpapasya pa rin ang aplikasyon kung ano ang maaaring gawin ng kliyenteng iyon.

Wala sa mga modelo ang nagpapalagay ng isa pa. Ang pagdaan sa pintuan ay walang sinasabi tungkol sa pagbasa ng isang partikular na tala, at ang pagiging nasa network ay walang sinasabi tungkol sa pahintulot na kumilos.

Ang hindi sakop ng proxy, at sakop ng VPN

Ang mga sesyon ng SSH, mga kliyente ng database, mga broker ng mensahe at mga panloob na pangalan ng host na hindi kailanman binubuksan ng anumang browser ay hindi nagiging maabot dahil lang may web proxy. Bawat isa ay nagsasalita ng sarili nitong protocol, at bawat isa ay nangangailangan ng sarili nitong pinatotohanang landas o isang network na nagdadala nito. Ito ang puwang na natutuklasan ng mga tao sa unang araw ng isang paglipat, kadalasan mula sa isang on-call engineer na may laptop na hindi na maresolba ang isang pangalan ng host.

Ang kabaligtarang puwang ay kasing totoo. Ang isang VPN na nagpapapasok ng kliyente sa isang subnet ay hindi nagpapatotoo sa taong nasa loob nito, at ang isang kompromisadong device sa subnet na iyon ay nagmamana ng anumang pinapayagan ng network. Kung ang pangangailangan ay awtorisasyon sa bawat kahilingan na may naa-audit na pagkakakilanlan, ang ruta lamang ay hindi makakabuo nito. Karamihan sa mga organisasyon ay nagpapatakbo sa huli ng dalawa, at ang kawili-wiling tanong ay kung aling mga resource ang maaaring harapin ng bawat isa.

Ang daloy ng trabaho ng kliyente ay nagpapasya ng higit sa diagram ng arkitektura

Ang pag-sign in sa browser na may redirect at paminsan-minsang hamon ng MFA ay isang magandang karanasan para sa isang taong nag-click ng bookmark. Ang isang gawain ng cron, isang CLI o isang build agent ay walang browser at hindi makasagot sa isang interaktibong prompt, kaya kailangan nito ng dokumentadong di-interaktibong landas o ng tunnel. Ang pagtuklas ng pangangailangang iyon ay karaniwang nangyayari pagkatapos maaprubahan ang disenyo.

Bilangin ang mga kliyente bago bilangin ang mga aplikasyon. Ang isang dashboard ay makapaglilingkod sa isang daang tao; ang isang port ng database ay makakapigil sa isang buong pangkat.

Ang kalagayan ng device ay hindi katangian ng alinmang pintuan

Ang pag-install ng kliyente ng VPN ay hindi pagsusuri ng pagsunod, at ang disenyong nakabatay sa browser ay hindi awtomatikong walang kakayahang igalang ang patakaran para sa mga pinamamahalaang device. Pareho silang makapagsasama ng mga senyales ng kalagayan, at pareho silang maipapakilala nang wala ang mga iyon. Itanong kung anong pagpapatupad ang umiiral, kanino ang patakaran at ano ang nangyayari sa isang device na nabibigo rito, sa halip na hulaan iyon mula sa hugis ng produkto.

Ang parehong pag-iingat ay naaangkop sa pag-alis ng access. Ang pagbura ng kasapi sa isang pangkat sa proxy at ang pagbawi ng sertipiko para sa tunnel ay magkaibang operasyon na may magkaibang pagkaantala, at ang isa sa kanila ay karaniwang nakakalimutan kapag umaalis.

Hanapin ang mga alternatibong ruta bago mag-retire ng anuman

Ang isang hindi protektadong pinagmulan sa likod ng proxy, isang pangalawang pangalan ng host na lumalampas dito, o isang malawak na pribadong ruta na natira mula sa dating disenyo ang magpapasya kung aling pintuan ang talagang may bisa. Subukan ang isang pinahihintulutan at isang tinanggihang operasyon sa pamamagitan ng tunay na kliyente, hindi sa console, at subukan ang mga iyon mula sa isang device na hindi kailanman nairehistro. Ang tinanggihang kaso ang nagsasabi sa iyo kung may ginagawa ba ang pintuan.

Pagkatapos ay isulat ang paglilipat: pagpaparehistro, mga update, pag-alis ng access at ang landas ng pagbawi para sa isang taong nakakandado sa labas nang ika-2 ng madaling-araw. Ang pag-alis ng isang prompt o ng isang aplikasyon ng kliyente ay naglilipat ng pananagutan sa pagitan ng mga pangkat; hindi nito binubura ang pananagutan.

Kung magpapasya ka ngayong linggo, magsimula sa isang listahan ng mga operasyon sa halip na isang listahan ng mga produkto, markahan kung alin ang kayang gawin ng browser, at hayaang ang iba ay magbigay-katwiran sa access sa network na natitira.