Centralizuokite partnerių VPN prieigą nesujungdami partnerių

Pasiūlymas pagrįstas: penki partnerių tuneliai, pasklidę per keliolika nešiojamųjų kompiuterių, penki klientų versijų rinkiniai, penki pagalbos tarnybos scenarijai ir vienas inžinierius, kuris žino, kaip jie dera. Perkėlus juos į valdomą prieigos lygį, išsprendžiamas galinių taškų išsibarstymas. Tai taip pat sukuria naują objektą architektūroje, bendrą prieigos paslaugą, kuriai dabar reikia savo autorizacijos modelio, o gedimas, kurį visi nuvertina, yra centrinis įrenginys su įjungtais visais tuneliais, kuris tyliai tampa tranzitiniu tinklu tarp organizacijų, niekada nesutikusių būti kaimynėmis. Ši rizika yra projektavimo sprendimas, o ne tai, ką aparatinė įranga daro pati. Toliau pateiktas darbas rodo, kaip išlaikau patogumą nepriimdamas atsitiktinio šalutinio poveikio.

Pradėkite nuo sutarties, kurią kiekvienas partneris jau pasirašė

Prieš bet kokią konfigūraciją patvirtinkite, kad partneris apskritai leidžia bendrą šliuzą ar svetainės ryšį. Asmeninė nuotolinės prieigos paskyra, įrenginio būsenos reikalavimas ar interaktyvus MFA srautas gali būti neperkeliami į neprižiūrimą bendrą tunelį, o darbuotojų rinkimas už vienos nukopijuotos kliento tapatybės yra ta trumpoji gudrybė, kuri išlieka tol, kol partneris nepradeda audituoti savo žurnalų. Kiekvienam leidžiamam ryšiui užrašykite paskirties diapazonus, privačius DNS domenus, autorizuotus vidinius šaltinius, autentifikavimo savininką ir tai, kas turi įvykti, kai tunelis sugenda. Paprašykite partnerio raštu patvirtinti bendrą ryšį, įskaitant šaltinio diapazonus, kuriuos jis priims. Žodinis patvirtinimas paprastai pakeičia prasmę tą savaitę, kai keičiasi jų saugumo komanda.

Tas įrašas yra rezultatas. Jei negalite jo parašyti vienam partneriui, tas partneris nėra pasirengęs centralizacijai.

Maršrutizuokite pagal kontekstą, ne tik pagal paskirtį

Du partneriai galiausiai naudos tą patį privatų diapazoną, nes kiekviena organizacija renkasi iš tos pačios RFC 1918 erdvės. Viena įprasta maršrutizavimo lentelė negali pasirinkti teisingo partnerio vien pagal paskirties adresą, todėl persidengiantiems diapazonams reikia atskirų maršrutizavimo kontekstų ar kitokio suderinto projekto. Persiuntimo domeno modelis RFC 4364 dokumente paaiškina, kodėl šis atskyrimas svarbus, o diegimui nereikia vykdyti MPLS, kad reikalautų tos pačios savybės iš savo šliuzo platformos.

Paklauskite platformos tiesiai: ar du partneriai gali dalytis tuo pačiu paskirties prefiksu ir vis tiek būti atskirti pagal tai, iš kurio darbuotojo konteksto atėjo sesija? Jei atsakymas ne, šis apribojimas formuoja projektą labiau nei bet koks tiekėjo funkcijų sąrašas.

Kai atsakymas taip, maršrutizavimo kontekstas tampa tuo, ką dokumentuojate ir testuojate, nes jis nematomas traceroute.

Nuspręskite, ką įveda darbuotojas ir ką registruoja partneris

Dalis partnerių darbo tinka programos proxy arba nuotolinei darbo erdvei, atidaromai to partnerio kontekste. Kitam darbui reikia maršrutizuotos tinklo prieigos iš patvirtinto darbuotojų segmento, ir abu sukuria skirtingus šaltinio adresus bei skirtingus audito pėdsakus tolimajame gale. Bendras išverstas šaltinio adresas gali patenkinti leidžiamų sąrašą ir kartu paslėpti, kuris įrenginys ką padarė, todėl saugokite patikimą darbuotojo ir sesijos įrašą ir palikite programos autentifikavimą, o ne traktuokite šliuzo adresą kaip tapatybę, kas patogu iki to momento, kai partneris paklausia, kas tai padarė.

Tada pereikite vieną realią užduotį darbuotojo pusėje: ką jie spaudžia, ko prašoma ir ką partneris pamatytų, jei paprašytų žurnalo įrašo. Jei tos eigos neįmanoma pakartoti, projektas nebaigtas.

Aiškiai uždrauskite tranzitą tarp partnerių

Bendra aparatinė įranga niekada neturi reikšti bendro pasitikėjimo. Pridėkite draudimą kaip sąmoningą taisyklę su įvardytu savininku, ne kaip trūkstamos konfigūracijos atsitiktinumą, ir išbandykite jį abiem kryptimis su prašymu, kuris kitu atveju pavyktų. Testas svarbus, nes vien tik trūkstamą leidimą gali atkurti kitas inžinierius, pridėjęs maršrutą nesusijusiam skundui išspręsti.

Įrašykite draudimą į partnerio įrašą šalia leidimų, kad ketinimas išliktų pasikeitus personalui.

Valdykite tai kaip bendrą paslaugą, o ne kaip didesnį nešiojamąjį kompiuterį

Tunelių atnaujinimas, kredencialų rotacija, talpa ir šliuzo pakeitimas dabar visi tampa bendros paslaugos pakeitimais, o tai reiškia, kad jiems reikia grafiko ir komunikacijos kelio, kurių atskiri nešiojamieji kompiuteriai niekada nereikalavo. Partnerio sertifikatas, kurio galiojimas baigiasi šeštadienį, nebėra vieno naudotojo sutrikimas; tai visos to partnerio sesijos vienu metu.

Priimkite lygį tik tada, kai atmestas tarpusavio partnerių prašymas nepavyksta tiksliai taip, kaip numatyta, o leidžiamas darbuotojo prašymas pasiekia tinkamą paskirties vietą su tinkamu šaltiniu. Pašalinti nešiojamųjų kompiuterių konfliktą išlaikant kiekvieno partnerio ribą nepaliestą yra visa esmė; projektas, kuriame kiekvienas nuotolinis prefiksas pasiekiamas nuo kiekvieno stalo, tik perkėlė problemą.

Laikykite mažą lentelę apie partnerį, kontekstą, leidžiamus diapazonus ir savininką. Incidento metu jos bus pirmiausia paprašyta.