Centralizujte přístup partnerů přes VPN bez slučování partnerů

Nabídka je rozumná: pět partnerských tunelů rozprostřených po tuctu notebooků, pět sad verzí klienta, pět skriptů podpory a jeden inženýr, který ví, jak do sebe zapadají. Přesun na řízenou úroveň přístupu řeší rozbujení koncových bodů. Zároveň vytváří nový objekt v architektuře, sdílenou přístupovou službu, která teď potřebuje vlastní model autorizace, a selhání, které všichni podceňují, je centrální zařízení se zapnutými všemi tunely, které se tiše stane tranzitní sítí mezi organizacemi, jež nikdy nesouhlasily, že budou sousedy. To riziko je rozhodnutí o návrhu, ne něco, co hardware dělá sám. Práce níže je o tom, jak si zachovávám pohodlí, aniž bych přijal náhodný vedlejší efekt.

Začněte smlouvou, kterou každý partner už podepsal

Před jakoukoli konfigurací potvrďte, že partner vůbec povoluje sdílenou bránu nebo spojení na lokalitu. Osobní účet vzdáleného přístupu, požadavek na stav zařízení nebo interaktivní tok MFA nemusí být přenositelné na sdílený tunel bez dohledu, a sdružování zaměstnanců za jednou zkopírovanou identitou klienta je ta zkratka, která přežije, dokud partner neprovede audit svých logů. U každého povoleného spojení zaznamenejte cílové rozsahy, privátní domény DNS, povolené interní zdroje, vlastníka autentizace a co se má stát, když tunel selže. Požádejte partnera o písemné potvrzení sdíleného spojení včetně rozsahů zdrojů, které přijme. Ústní schválení obvykle změní význam týden poté, co se jim vymění bezpečnostní tým.

Ten záznam je výstup. Pokud ho pro jednoho partnera nedokážete napsat, ten partner není na centralizaci připravený.

Směrujte podle kontextu, ne jen podle cíle

Dva partneři nakonec použijí stejný privátní rozsah, protože každá organizace vybírá ze stejného prostoru RFC 1918. Jedna běžná směrovací tabulka nedokáže vybrat správného partnera jen podle cílové adresy, takže překrývající se rozsahy potřebují samostatné směrovací kontexty nebo jiný dohodnutý návrh. Model domény přesměrování v RFC 4364 popisuje, proč na tom oddělení záleží, a nasazení nemusí provozovat MPLS, aby stejnou vlastnost vyžadovalo od své bránové platformy.

Zeptejte se platformy přímo: mohou dva partneři sdílet jeden cílový prefix a přesto se rozlišit podle toho, z jakého kontextu zaměstnance relace přišla? Pokud je odpověď ne, toto omezení utváří návrh víc než jakýkoli seznam funkcí dodavatele.

Kde je odpověď ano, směrovací kontext se stává tím, co dokumentujete a testujete, protože je v traceroute neviditelný.

Rozhodněte, co zaměstnanec zadá a co partner zaloguje

Některá partnerská práce sedí na proxy aplikací nebo vzdálenou pracovní plochu otevřenou v kontextu daného partnera. Jiná práce potřebuje směrovaný síťový přístup ze schváleného segmentu zaměstnanců a obojí na vzdáleném konci vytváří jiné zdrojové adresy a jiné auditní stopy. Sdílená přeložená zdrojová adresa může splnit allowlist a přitom skrýt, které zařízení co udělalo, takže si udržujte spolehlivý záznam o vazbě zaměstnance na relaci a ponechte autentizaci aplikace, místo abyste adresu brány považovali za identitu, což je pohodlné přesně do chvíle, kdy se partner zeptá, kdo to udělal.

Pak projděte jeden skutečný úkol ze strany zaměstnance: na co klikají, co se po nich chce a co by partner viděl, kdyby si vyžádal záznam v logu. Pokud ten průchod není opakovatelný, návrh není hotový.

Průchod mezi partnery výslovně zakažte

Sdílený hardware nikdy nesmí znamenat sdílenou důvěru. Zákaz přidejte jako záměrné pravidlo s jmenovaným vlastníkem, ne jako náhodu chybějící konfigurace, a otestujte ho v obou směrech požadavkem, který by jinak prošel. Test je důležitý, protože povolení, které jen chybí, může obnovit další inženýr, který přidá trasu k vyřešení nesouvisející stížnosti.

Zapište zákaz do záznamu partnera vedle povolení, aby záměr přežil změny personálu.

Provozujte to jako sdílenou službu, ne jako větší notebook

Obnova tunelů, rotace přihlašovacích údajů, kapacita a výměna brány se teď všechny stávají změnami sdílené služby, což znamená, že potřebují harmonogram a komunikační cestu, jaké jednotlivé notebooky nikdy nevyžadovaly. Partnerský certifikát, který vyprší v sobotu, už není výpadek jednoho uživatele; jsou to všechny relace toho partnera najednou.

Úroveň přijměte jen tehdy, když odmítnutý požadavek mezi partnery selže přesně podle záměru a povolený požadavek zaměstnance dorazí na správný cíl se správným zdrojem. Odstranit konflikt notebooků a přitom zachovat hranici každého partnera je celý smysl; návrh, v němž je každý vzdálený prefix dostupný z každého stolu, problém jen přesunul.

Veďte malou tabulku partnera, kontextu, povolených rozsahů a vlastníka. Bude to první věc, kterou při incidentu někdo vyžádá.