Centralizujte prístup partnerov cez VPN bez spájania partnerov

Návrh je rozumný: päť partnerských tunelov roztrúsených po tucte notebookov, päť sád verzií klienta, päť skriptov help desku a jeden inžinier, ktorý vie, ako do seba zapadajú. Presun na kontrolovanú úroveň prístupu rieši rozptýlenie koncových bodov. Zároveň vytvára v architektúre nový objekt — spoločnú prístupovú službu, ktorá teraz potrebuje vlastný model autorizácie; a zlyhanie, ktoré všetci podceňujú, je centrálne zariadenie so zapnutými všetkými tunelmi, ktoré sa potichu stáva tranzitnou sieťou medzi organizáciami, ktoré nikdy nesúhlasili s tým, že budú susedmi. Toto riziko je konštrukčná voľba, nie niečo, čo hardvér robí sám od seba. Práca nižšie je spôsob, akým si zachovávam pohodlie bez toho, aby som prijal neúmyselný vedľajší účinok.

Začnite zmluvou, ktorú každý partner už podpísal

Pred akoukoľvek konfiguráciou overte, že partner vôbec povoľuje spoločnú bránu alebo pripojenie lokality. Osobný účet vzdialeného prístupu, požiadavka na stav zariadenia alebo interaktívny tok MFA nemusia byť prenositeľné na spoločný tunel bez obsluhy, a združovanie zamestnancov za jednou skopírovanou identitou klienta je ten druh skratky, ktorý vydrží, kým partner neskontroluje svoje záznamy. Pre každé povolené pripojenie zaznamenajte rozsahy cieľov, súkromné domény DNS, autorizované interné zdroje, vlastníka autentifikácie a to, čo sa má stať, keď tunel zlyhá. Požiadajte partnera, aby spoločné pripojenie potvrdil písomne, vrátane zdrojových rozsahov, ktoré prijme. Ústny súhlas zvyčajne zmení význam v týždni, keď sa im vymení bezpečnostný tím.

Ten záznam je výsledok. Ak ho pre jedného partnera nedokážete napísať, ten partner nie je pripravený na centralizáciu.

Smerujte podľa kontextu, nie len podľa cieľa

Dvaja partneri nakoniec použijú rovnaký súkromný rozsah, pretože každá organizácia vyberá z rovnakého priestoru RFC 1918. Jedna bežná smerovacia tabuľka nedokáže vybrať správneho partnera len podľa cieľovej adresy, takže prekrývajúce sa rozsahy potrebujú samostatné smerovacie kontexty alebo iný dohodnutý návrh. Model smerovacej domény v RFC 4364 opisuje, prečo je toto oddelenie dôležité, a nasadenie nemusí prevádzkovať MPLS, aby od svojej bránovej platformy vyžadovalo rovnakú vlastnosť.

Položte platforme priamu otázku: môžu dvaja partneri zdieľať rovnaký cieľový prefix a napriek tomu sa rozlišovať podľa toho, z kontextu ktorého zamestnanca relácia prišla? Ak je odpoveď nie, toto obmedzenie formuje návrh viac než akýkoľvek zoznam funkcií dodávateľa.

Tam, kde je odpoveď áno, sa smerovací kontext stáva tým, čo dokumentujete a testujete, pretože v traceroute nie je viditeľný.

Rozhodnite, čo zamestnanec zadáva a čo partner zaznamenáva

Časť partnerskej práce sa hodí k aplikačnému proxy alebo k vzdialenému pracovnému priestoru otvorenému v kontexte toho partnera. Iná práca potrebuje smerovaný sieťový prístup zo schváleného segmentu zamestnancov a obe vytvárajú na druhej strane odlišné zdrojové adresy a odlišné audítorské stopy. Zdieľaná preložená zdrojová adresa môže splniť zoznam povolení a zároveň skryť, ktoré zariadenie čo urobilo, preto si zachovajte spoľahlivý záznam medzi zamestnancom a reláciou a ponechajte autentifikáciu aplikácie, namiesto toho, aby ste adresu brány považovali za identitu — čo je pohodlné presne do chvíle, keď sa partner spýta, kto to urobil.

Potom prejdite jednu skutočnú úlohu zo strany zamestnanca: na čo klikajú, čo sa od nich žiada a čo by partner videl, keby požiadal o záznam v logu. Ak ten prechod nie je reprodukovateľný, návrh nie je dokončený.

Explicitne odmietnite tranzit medzi partnermi

Zdieľaný hardvér by nikdy nemal znamenať zdieľanú dôveru. Pridajte odmietnutie ako úmyselné pravidlo s menovaným vlastníkom, nie ako náhodu chýbajúcej konfigurácie, a otestujte ho z oboch strán požiadavkou, ktorá by inak uspela. Test je dôležitý, pretože povolenie, ktoré jednoducho chýba, môže obnoviť ďalší inžinier, ktorý pridá trasu na opravu nesúvisiacej sťažnosti.

Zapíšte odmietnutie do záznamu partnera vedľa povolení, aby zámer prežil zmeny personálu.

Prevádzkujte to ako spoločnú službu, nie ako väčší notebook

Obnova tunelov, rotácia poverení, kapacita a výmena brány sa teraz všetky stávajú zmenami spoločnej služby, čo znamená, že potrebujú harmonogram a komunikačnú cestu, aké jednotlivé notebooky nikdy nevyžadovali. Partnerský certifikát, ktorý vyprší v sobotu, už nie je výpadok jedného používateľa; je to výpadok všetkých relácií toho partnera naraz.

Prijmite úroveň len vtedy, keď odmietnutá požiadavka medzi partnermi zlyhá presne podľa zámeru a povolená požiadavka zamestnanca dosiahne správny cieľ so správnym zdrojom. Odstránenie konfliktu notebookov pri zachovaní neporušenej hranice každého partnera je celý zmysel; návrh, v ktorom je každý vzdialený prefix dosiahnuteľný z každého stola, problém len presunul.

Veďte si malú tabuľku partnera, kontextu, povolených rozsahov a vlastníka. Bude to prvá vec, o ktorú niekto počas incidentu požiada.