Kailangan mo pa ba ng site VPN kapag gumagamit ng mTLS at SSO ang app?
Lakbayin ang mga channel na hindi kailanman saklaw ng login ng iyong app, pagkatapos magpasya kung ang pag-access sa pribadong network ay sobra o ito pa rin ang tanging daan patungo sa host.
Nag-sign in ka sa mTLS, naglo-load ang dashboard, at ang pahayag na ang site VPN ay sobra na ngayon ay mukhang makatwiran hanggang sa kailanganin mong i-restore ang isang database sa alas-dos ng madaling araw. Ang TLS na hangganan ng app ay naglalarawan ng isang channel lamang. Ang host, ang database, ang target ng backup at ang cloud account ay may kani-kaniyang landas ng pagpasok, kani-kaniyang pagkakakilanlan at kani-kaniyang nagpapatunay, at wala sa mga ito ang nasusubok ng matagumpay na pag-sign in.
Maglakad palabas mula sa screen ng login
Mag-sign in tulad ng isang ordinaryong user at isulat ang bawat hakbang na hinahawakan ng kahilingan: browser, gilid, tagapakinig ng app, imbakan ng session, backend API. Bawat hakbang ay may may-ari at desisyon sa pagpapatotoo. Ngayon ulitin ang paglalakbay para sa taong naglalagay ng patch sa host, at para sa trabahong nagsusulat ng backup sa gabi. Ang mga paglalakbay na iyon ay karaniwang naghihiwalay na sa unang hakbang.
Ang paghihiwalay na iyon ang tanong na dapat sagutin. Ang site VPN ay sobra lamang kapag ang bawat channel sa ikalawang paglalakbay ay may patakaran sa pagpasok at pahintulot na nakatayo sa sarili nito.
Limang channel na hindi kailanman saklaw ng login ng app
Ang talahanayan sa ibaba ay isang template ng imbentaryo, hindi checklist ng deploy. Punan ang ikalawang hanay ng aktuwal na ipinapatupad ng iyong kapaligiran ngayon.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
Ang pagbabahagi ng isang identity provider ay hindi nagsasama ng mga pahintulot na ito. Ang user na maaaring magpadala ng API request ay hindi dahil doon awtorisadong palitan ang VM disk o i-restore ang database gamit ang mga kredensyal ng app. Sa buod ng arkitekturang zero trust ng NIST, iniihiwalay nito ang pagpapatotoo at pahintulot ng resources mula sa lokasyon sa network dahil mismo sa dahilang ito.
Ang support engineer na nakakabasa ng ticket ay hindi dahil doon awtorisadong magbukas ng console sa host sa likod nito.
Totoo lamang ang landas kung nakasara ang alternatibo
Ang paghihigpit ng maaabot sa pribadong administrative listener ay lehitimong kapalit ng site VPN, sa kondisyon na ipinatutupad ang paghihigpit at hindi lamang iginuhit. Ang karaniwang pagkabigo ay isang alternatibong listener na walang naalala: isang serbisyong nakatali pa sa lahat ng interface, isang panuntunan ng security group na binuksan para sa isang kontratista, isang management port na maaabot mula sa internet.
Suriin ang mga listener, hindi ang mga diagram. Sa host, ilista ang aktuwal na nakatali gamit ang ss -ltnp at kumpirmahin na ang administrative ports ay nasa pribadong address. Sa cloud console, basahin ang inbound rules para sa workload subnet at maghanap ng 0.0.0.0/0 sa anumang administrative. Pagkatapos subukan ang koneksyon mula sa labas ng pribadong landas, dahil ang pagsubok na iyon ang sumasagot sa tanong.
Isang tuntuning bukas sa mundo sa SSH ang nagpapawalang-bisa sa bawat argumento ng disenyo ng tunnel.
Isulat ang mapa bago ihambing ang mga disenyo
Para sa bawat hilera ng imbentaryo, itala kung sino ang nag-aapruba ng mga pagkakakilanlan, sino ang nag-a-update ng mga patakaran sa pag-access, sino ang nag-aalis ng mga kredensyal kapag may umalis, at sino ang humahawak ng pagbangon kapag ang landas mismo ay nasira. Apat na pangalan bawat hilera ang sapat upang ilantad ang mga hilerang ang sagot ay isang shared account at isang wiki page na tatlong taon na.
Pagkatapos patunayan ang isang pahintulot at isang pagtanggi bawat channel. Ang pahintulot ay nagpapatunay na ang inilaan na pagkakakilanlan ay makakaabot sa resource sa inilaang landas. Ang pagtanggi ay nagpapatunay na ang katulad na pagkakakilanlan ay hindi makakaabot, at ito ang pagsubok na nilalaktawan ng mga tao, kaya nakakaligtas ang mga alternatibong listener sa mga audit. Ihambing ang iminungkahing disenyo sa mga resultang ito, hindi sa TLS configuration ng app, na hindi kailanman nagsubok ng alinman sa mga ito.
Kung saan pa nakakamit ng site VPN ang lugar nito
Ang tunnel o makitid na gateway ang tamang sagot kapag ang isang resource ay walang sariling pagpapatotoo sa bawat kahilingan: mga port ng maintenance ng database, mga target ng backup, mga console ng hypervisor, pamamahala sa labas ng banda. Ang mga listener na iyon ay nagtitiwala sa network, kaya ang network ang dapat magpatotoo sa tumatawag.
Hindi ito ang tanging sagot. Ang gateway na nagtatapos ng pahintulot bawat resource ay maaaring makitid pa kaysa sa tunnel sa buong subnet at nag-iiwan ng mas magandang audit trail kaysa sa shared jump host.
Pagkakasunod-sunod ng trabaho: tapusin ang imbentaryo, isara ang mga alternatibo, patunayan ang isang pagtanggi bawat hilera, at pagkatapos lamang alisin ang tunnel. Kung ang isang hilera ay hindi makagawa ng pagtanggi, panatilihin ang pribadong landas hanggang kaya nito.