Centralizo aksesin VPN të partnerëve pa i bashkuar partnerët

Propozimi është i arsyeshëm: pesë tunele partnerësh të shpërndara në një duzinë laptopësh, pesë grupe versionesh klienti, pesë skripte help-desk dhe një inxhinier që e di si përshtaten. Kalimi i tyre në një nivel aksesi të kontrolluar e rregullon shpërndarjen e pikave fundore. Njëkohësisht krijon një objekt të ri në arkitekturën tuaj — një shërbim aksesi të përbashkët që tani kërkon modelin e vet të autorizimit; dhe dështimi që të gjithë e nënvlerësojnë është një pajisje qendrore me të gjitha tunelet aktive që heshtazi bëhet një rrjet transit midis organizatave që nuk janë marrë kurrë vesh të jenë fqinjë. Ai rrezik është një zgjedhje projektimi, jo diçka që hardueri e bën vetë. Puna më poshtë është mënyra se si e mbaj komoditetin pa pranuar efektin anësor të rastësishëm.

Filloni nga kontrata që çdo partner ka nënshkruar tashmë

Përpara çdo konfigurimi, konfirmoni që partneri lejon fare një gateway ose lidhje site të përbashkët. Një llogari personale aksesi në distancë, një kërkesë për gjendjen e pajisjes ose një fluks interaktiv MFA mund të mos jenë të transferueshme në një tunel të përbashkët pa mbikëqyrje, dhe grumbullimi i punonjësve pas një identiteti klienti të kopjuar është ai shkurtore që zgjat derisa partneri të kontrollojë regjistrat e tij. Për çdo lidhje të lejuar, regjistroni intervalet e destinacionit, domenet private DNS, burimet e brendshme të autorizuara, pronarin e autentikimit dhe çfarë duhet të ndodhë kur tuneli dështon. Kërkoni nga partneri të konfirmojë me shkrim lidhjen e përbashkët, duke përfshirë intervalet e burimit që do të pranojë. Miratimi verbal zakonisht ndryshon kuptim në javën kur ekipi i tyre i sigurisë ndryshon.

Ai regjistër është rezultati. Nëse nuk mund ta shkruani për një partner, ai partner nuk është gati të centralizohet.

Rutoni sipas kontekstit, jo vetëm sipas destinacionit

Dy partnerë përfundimisht do të përdorin të njëjtin interval privat, sepse çdo organizatë zgjedh nga i njëjti hapësirë RFC 1918. Një tabelë e zakonshme routing-u nuk mund të zgjedhë partnerin e duhur vetëm nga adresa e destinacionit, prandaj intervalet që mbivendosen kërkojnë kontekste të veçanta routing-u ose një dizajn tjetër të rënë dakord. Modeli i domenit të përcjelljes në RFC 4364 përshkruan pse kjo ndarje ka rëndësi, dhe një vendosje nuk ka nevojë të ekzekutojë MPLS për të kërkuar të njëjtën veti nga platforma e saj e gateway-t.

Bëjini platformës një pyetje të drejtpërdrejtë: a mund dy partnerë të ndajnë të njëjtin prefiks destinacioni dhe gjithsesi të dallohen nga konteksti i punonjësit prej nga erdhi sesioni? Nëse përgjigja është jo, ai kufizim e formëson dizajnin më shumë se çdo listë veçorish e furnizuesit.

Aty ku përgjigja është po, konteksti i routing-ut bëhet ai që dokumentoni dhe testoni, sepse është i padukshëm në traceroute.

Vendosni çfarë shkruan punonjësi dhe çfarë regjistron partneri

Një pjesë e punës së partnerit përshtatet me një proxy aplikacioni ose një hapësirë pune në distancë të hapur në kontekstin e atij partneri. Punë tjetër kërkon akses rrjeti të rutuar nga një segment punonjësish i miratuar, dhe të dyja prodhojnë adresa burimi të ndryshme dhe gjurmë auditimi të ndryshme në skajin tjetër. Një adresë burimi e përkthyer e përbashkët mund të plotësojë një listë lejimesh duke fshehur njëkohësisht se cila pajisje bëri çfarë, prandaj ruani një lidhje të besueshme punonjës-sesion dhe mbani autentikimin e aplikacionit, në vend që ta trajtoni adresën e gateway-t si identitet — gjë që është e përshtatshme deri në momentin kur partneri pyet kush e bëri.

Pastaj ecni një detyrë reale nga ana e punonjësit: çfarë klikojnë, çfarë u kërkohet dhe çfarë do të shihte partneri nëse kërkon një zë regjistri. Nëse ai ecje nuk është e riprodhueshme, dizajni nuk është përfunduar.

Refuzoni shprehimisht transit-in partner-me-partner

Hardueri i përbashkët nuk duhet të nënkuptojë kurrë besim të përbashkët. Shtoni refuzimin si rregull të qëllimshëm me një pronar të emërtuar, jo si aksident i konfigurimit që mungon, dhe testojeni nga të dy drejtimet me një kërkesë që përndryshe do të kishte sukses. Testi ka rëndësi sepse një leje që thjesht mungon mund të rivendoset nga inxhinieri i radhës që shton një rrugë për të rregulluar një ankesë të palidhur.

Shkruani refuzimin në regjistrin e partnerit pranë lejeve, që qëllimi t'i mbijetojë ndryshimeve të stafit.

Drejtojeni si shërbim i përbashkët, jo si laptop më i madh

Rinovimi i tuneleve, rotacioni i kredencialeve, kapaciteti dhe zëvendësimi i gateway-t tani të gjitha bëhen ndryshime të shërbimit të përbashkët, që do të thotë se kanë nevojë për një plan dhe një rrugë komunikimi që laptopët individualë nuk i kërkuan kurrë. Një certifikatë partneri që skadon të shtunën nuk është më ndërprerja e një përdoruesi; është ndërprerja e të gjitha sesioneve të atij partneri njëherësh.

Pranojeni nivelin vetëm kur një kërkesë e refuzuar midis partnerëve dështon saktësisht siç është menduar dhe një kërkesë e lejuar e punonjësit arrin destinacionin e duhur me burimin e duhur. Heqja e konfliktit të laptopëve duke mbajtur të paprekur kufirin e secilit partner është e gjithë pika; një dizajn ku çdo prefiks në distancë është i arritshëm nga çdo tavolinë e ka thjesht zhvendosur problemin.

Mbani një tabelë të vogël me partnerin, kontekstin, intervalet e lejuara dhe pronarin. Do të jetë gjëja e parë që dikush kërkon gjatë një incidenti.