Isentro ang Pag-access sa VPN ng mga Partner Nang Hindi Pinagsasama ang mga Partner

Makatwiran ang panukala: limang partner tunnel na nakakalat sa isang dosenang laptop, limang set ng bersyon ng client, limang script ng help desk, at isang inhinyero na nakakaalam kung paano sila magkakasya. Ang paglipat sa kanila sa isang kontroladong antas ng pag-access ay nag-aayos ng kalat ng endpoint. Kasabay nito, lumilikha ito ng bagong bagay sa arkitektura — isang shared na serbisyo ng pag-access na ngayon ay nangangailangan ng sarili nitong modelo ng awtorisasyon; at ang kabiguan na minamaliit ng lahat ay isang sentral na kagamitan na may lahat ng tunnel na bukas na tahimik na nagiging transit network sa pagitan ng mga organisasyong hindi kailanman pumayag na maging kapitbahay. Ang panganib na iyon ay isang pagpili sa disenyo, hindi isang bagay na ginagawa ng hardware sa sarili nito. Ang gawain sa ibaba ay kung paano ko pinapanatili ang kaginhawahan nang hindi tinatanggap ang aksidenteng epekto.

Magsimula sa kontratang pinirmahan na ng bawat partner

Bago ang anumang configuration, tiyakin na pinapayagan talaga ng partner ang isang shared gateway o site na koneksyon. Ang personal na remote-access account, kinakailangan sa kalagayan ng device, o interactive na MFA flow ay maaaring hindi mailipat sa isang walang tao na shared tunnel, at ang pagsasama-sama ng mga empleyado sa likod ng isang kinopyang pagkakakilanlan ng client ay ang uri ng shortcut na tumatagal hanggang sa i-audit ng partner ang kanilang mga log. Para sa bawat pinapayagang koneksyon, itala ang mga saklaw ng destinasyon, pribadong DNS domain, awtorisadong panloob na pinagmulan, may-ari ng authentication, at kung ano ang dapat mangyari kapag nabigo ang tunnel. Hilingin sa partner na kumpirmahin nang nakasulat ang shared na koneksyon, kasama ang mga saklaw ng pinagmulan na tatanggapin nila. Ang pasalitang pag-apruba ay karaniwang nagbabago ng kahulugan sa linggong magpalit ang kanilang security team.

Ang rekord na iyon ang deliverable. Kung hindi mo ito maisusulat para sa isang partner, hindi pa handa ang partner na iyon na isentro.

I-route ayon sa konteksto, hindi lamang sa destinasyon

Sa huli, dalawang partner ang gagamit ng parehong pribadong saklaw, dahil bawat organisasyon ay pumipili mula sa parehong RFC 1918 na espasyo. Hindi matukoy ng isang ordinaryong routing table ang tamang partner mula sa address ng destinasyon lamang, kaya ang mga saklaw na nagsasapawan ay nangangailangan ng hiwalay na routing context o iba pang napagkasunduang disenyo. Inilalarawan ng modelong forwarding-domain sa RFC 4364 kung bakit mahalaga ang paghihiwalay na ito, at ang isang deployment ay hindi kailangang magpatakbo ng MPLS para hilingin ang parehong katangian mula sa platform ng gateway nito.

Tanungin ang platform nang tuwiran: maaari bang magbahagi ng isang prefix ng destinasyon ang dalawang partner at makilala pa rin sa pamamagitan ng konteksto ng empleyado kung saan nagmula ang session? Kung ang sagot ay hindi, mas hinuhubog ng hadlang na iyon ang disenyo kaysa sa anumang listahan ng feature ng vendor.

Kung saan ang sagot ay oo, ang routing context ang nagiging bagay na idinodokumento at sinusubukan mo, dahil hindi ito nakikita sa traceroute.

Magpasya kung ano ang itinatype ng empleyado at ano ang nila-log ng partner

Ang ilang trabaho ng partner ay umaangkop sa isang application proxy o remote workspace na binuksan sa loob ng konteksto ng partner na iyon. Ang ibang trabaho ay nangangailangan ng routed network access mula sa isang aprubadong segment ng empleyado, at ang dalawa ay gumagawa ng magkaibang source address at magkaibang audit trail sa kabilang dulo. Ang isang shared na isinaling source address ay maaaring masiyahan ang isang allowlist habang itinatago kung aling device ang gumawa ng ano, kaya panatilihin ang maaasahang ugnayan ng empleyado sa session at panatilihin ang authentication ng application sa halip na ituring ang address ng gateway bilang pagkakakilanlan — na maginhawa hanggang sa sandaling itanong ng partner kung sino ang gumawa nito.

Pagkatapos, lakarin ang isang tunay na gawain mula sa panig ng empleyado: ano ang kinlick nila, ano ang hinihingi sa kanila, at ano ang makikita ng partner kung humingi sila ng entry sa log. Kung ang paglalakad na iyon ay hindi maulit, hindi pa tapos ang disenyo.

Tahasang tanggihan ang transit ng partner-sa-partner

Ang shared na hardware ay hindi dapat kailanman magpahiwatig ng shared na tiwala. Idagdag ang pagtanggi bilang sinadyang panuntunan na may pinangalanang may-ari, hindi bilang aksidente ng kulang na configuration, at subukan ito mula sa magkabilang direksyon gamit ang isang kahilingang kung hindi ay magtatagumpay. Mahalaga ang pagsubok dahil ang isang permiso na wala lamang ay maaaring ibalik ng susunod na inhinyerong nagdaragdag ng ruta para ayusin ang walang kaugnayang reklamo.

Isulat ang pagtanggi sa rekord ng partner sa tabi ng mga permiso, upang mabuhay ang layunin sa pagpapalit ng kawani.

Patakbuhin ito bilang shared na serbisyo, hindi bilang mas malaking laptop

Ang pag-renew ng tunnel, pag-ikot ng kredensyal, kapasidad at pagpapalit ng gateway ay nagiging mga pagbabago sa shared na serbisyo ngayon, ibig sabihin kailangan nila ng iskedyul at daan ng komunikasyon na hindi kailanman hiniling ng mga indibidwal na laptop. Ang certificate ng partner na mag-eexpire sa Sabado ay hindi na outage ng isang user; ito ay outage ng lahat ng session ng partner na iyon nang sabay.

Tanggapin ang antas kapag ang tinanggihang kahilingan sa pagitan ng mga partner ay nabigo nang eksakto ayon sa nilalayon at ang pinapayagang kahilingan ng empleyado ay umabot sa tamang destinasyon gamit ang tamang pinagmulan. Ang alisin ang labanan ng laptop habang nananatiling buo ang hangganan ng bawat partner ay ang buong punto; ang isang disenyong maaabot ang bawat remote prefix mula sa bawat mesa ay inilipat lamang ang problema.

Magtago ng maliit na talahanayan ng partner, konteksto, pinapayagang saklaw at may-ari. Ito ang unang hihilingin ng sinuman kapag may insidente.