Isipin ang pagbabago mula sa panig ng user. May nag-click sa isang bookmark, umaasa sa pamilyar na pahina ng pag-login, at sa halip ay nakakakuha ng error sa koneksyon dahil ang hostname ay sumasagot na lamang sa loob ng tunnel. Ang nag-iisang sandaling iyon ay naglalaman ng lahat ng dapat gawin nang tama ng plano sa migration: ang pangalan, ang landas, ang sertipiko, ang account at ang operasyong nasa likod nito. Sundan ang mga hakbang sa ibaba sa ganoong pagkakasunod-sunod at hindi na magiging paglundag ang paglipat.

Hakbang 1: isulat kung ano ang ginagawa ng mga user ngayon

Magsimula sa hostname sa address bar, sa port, sa mga operasyong ginagawa ng mga tao at sa mga account na ginagamit nila. Kung hindi mo maipangalan ang tatlong pangunahing operasyon, hindi ka pa handa na isara ang pampublikong pasukan, dahil hindi mo makikilala ang isang sira sa panahon ng pagtanggap.

Pagkatapos ay magpasya kung sino ang pribadong madla. Ang mga empleyado sa corporate VPN ay simula, hindi sagot. Ang mga kontratista, kawani ng suporta at pangkat sa pananalapi ay maaaring lahat mangailangan ng app at maaaring hindi lahat nakaupo sa likod ng parehong gateway.

Hakbang 2: paghiwalayin ang tunnel sa pag-login

Kapag naabot ng user ang app sa pamamagitan ng VPN, binubuksan pa rin ng browser ang isang TLS na koneksyon sa sariling endpoint ng app. Dapat tumugma ang sertipiko sa pangalang iyon, at ginagawa pa rin ng app ang pagpapatunay ng account. Walang anuman sa tunnel ang pumapalit sa alinman sa dalawa.

Dito tahimik na nagkakamali ang mga migration. May nagpasya na hindi na kailangan ng pribadong address ang wastong sertipiko, natututo ang mga user na i-click sa isang babala, at ipinagpalit ng organisasyon ang pampublikong paglantad sa isang programang pagsasanay sa pagwawalang-bahala sa mga babala sa seguridad. Kung talagang kailangan ng app ang panloob na sertipiko, maglabas ng isa mula sa panloob na awtoridad at ipamahagi nang tama ang pagtitiwala. Iyon ay kontroladong pagbabago; ang pahina ng babala ay hindi.

Panatilihin ang awtorisasyon kung nasaan na ito. Ang buod ng zero-trust architecture ng NIST ay direktang nagsasabi: ang lokasyon sa network ay hindi dahilan upang magbigay ng sensitibong operasyon. Ang pagiging nasa loob ng tunnel ay hindi dapat gawing administrator ang isang read-only na account.

Hakbang 3: hanapin ang mga tumatawag na hindi empleyado

Buksan ang configuration ng app at ilista ang lahat ng nakikipag-usap dito: ang callback URL ng identity provider, ang webhook ng payment provider, isang naka-iskedyul na import, isang monitoring probe, ang API client ng partner. Bawat isa ay dependency na may may-ari, at bawat isa ay masisira sa ibang sandali.

Magpasya ng sinusuportahang landas para sa bawat isa na dapat manatili. Ang isang webhook provider ay hindi maaaring sumali sa iyong employee VPN, kaya alinman ay ilantad ang isang makitid na integration endpoint na may sariling authentication, o baguhin ang modelo ng integration. Ang iwanang pampubliko ang buong app dahil may isang callback ay isang pagpipilian, at kadalasan ang mali.

Isulat ang bawat pagbubukod kasama ang destinasyon, pinapayagang operasyon, authentication at may-ari. Ang isang generic na VPN account na ibinigay sa isang integration ay ang paraan ng pagiging permanente ng isang pagbubukod. Suriin ang listahan sa susunod na pagsusuri ng access, dahil ang mga integration ay nabubuhay nang mas matagal kaysa sa mga proyektong nagdagdag sa kanila. Ang pagbubukod na walang petsa ng pag-expire ay isang permanenteng desisyon sa disenyo na walang gumawa.

Hakbang 4: alisin ang pampublikong ruta, hindi lamang ang DNS record

Lakarin ang chain ng pag-publish: DNS, mga listener ng load balancer, mga patakaran ng reverse proxy, firewall ng host at anumang alternatibong pangalan na tumuturo pa rin sa lumang address. Suriin ang parehong pamilya ng address. Ang pagbabago ng pangunahing A record ay halos walang pinatutunayan kung ang mas lumang CNAME o isang IPv6 listener ay nagsisilbi pa rin sa app.

Kasabay nito, tiyakin na ang pribadong pangalan ay nare-resolve sa loob ng tunnel at ang sertipiko ay sumasaklaw sa pangalang ita-type ng mga user. Ang user na kailangang mag-paste ng numeric na address ay nakahanap ng sintomas, hindi ng solusyon.

Limitahan ang madla ng VPN sa landas ng app. Ang malawak na access sa opisina network ay nagpapalit ng isang desisyon sa paglantad para sa isang mas malaki, at ang mga administrative interface ay nangangailangan ng sarili nilang pinapayagang source sa halip na magmana ng user rule.

Hakbang 5: gawin mo mismo ang pagtanggap

Kumonekta bilang aprubadong user, buksan ang bookmark, suriin ang sertipiko, mag-login at magsagawa ng isang tunay na operasyon. Pagkatapos ay subukan ang isang account na hindi dapat magkaroon ng operasyong iyon at tiyaking tinatanggihan ito. Pagkatapos ay subukan mula sa isang device sa labas ng VPN at tiyaking hindi maabot ang app.

Ulitin para sa bawat pinanatiling integration, at basahin ang delivery log ng provider sa halip na ipagpalagay na ang 200 mula sa sarili mong test tool ay pareho. Ang matagumpay na pag-login sa VPN ay hindi ebidensya para sa alinman sa mga resultang ito.

Hakbang 6: sanayin ang masamang araw

Magpasya kung ano ang mangyayari kapag nagkaaberya ang tunnel: humihinto ang trabaho, o may ibang aprubadong paraan ng access na pumapalit. Anuman ang piliin mo, isulat ito at subukan nang isang beses, dahil ang emergency na pampublikong muling pagbubukas bilang hindi dokumentadong mekanismo ng pagbawi ay gagawin sa huli ng isang taong nasa ilalim ng pressure.

Panatilihin ang recovery access para sa mga administrator na nagpapanatili ng gateway at app, may may-ari at petsa ng pag-alis. Itala ang pagbabago at ang mga kondisyon ng pagbabalik nito sa parehong lugar, upang ang isang nabigong migration ay hindi mag-lock out sa mga taong mag-aayos nito.

Pagkatapos ng paglipat, ang pag-patch, lifecycle ng account, awtorisasyon ng app at auditing ay sa iyo pa rin. Pinaliit ng tunnel ang pasukan; hindi nito kinuha ang alinman sa mga gawaing iyon.

Kaugnay na mga artikulo