Központosítsa a partner VPN-hozzáférést a partnerek egyesítése nélkül

A javaslat ésszerű: öt partnertunnel egy tucat laptopon elosztva, öt kliensverzió-készlet, öt ügyfélszolgálati szkript és egy mérnök, aki tudja, hogyan illeszkednek össze. Ellenőrzött hozzáférési szintre emelésük megoldja a végpontok szétszóródását. Új objektumot is teremt az architektúrában, egy közös hozzáférési szolgáltatást, amelynek most saját jogosultsági modellre van szüksége, és a mindenki által alulértékelt hiba az a központi eszköz, amelyen minden tunnel engedélyezve van, és amely csendben tranzithálózattá válik olyan szervezetek között, amelyek soha nem egyeztek bele, hogy szomszédok legyenek. Ez a kockázat tervezési döntés, nem valami, amit a hardver magától tesz. Az alábbi munka azt mutatja, hogyan tartom meg a kényelmet anélkül, hogy elfogadnám a véletlen mellékhatást.

Kezdje azzal a szerződéssel, amelyet minden partner már aláírt

Minden konfiguráció előtt erősítse meg, hogy a partner egyáltalán engedélyez közös átjárót vagy telephelyi kapcsolatot. Egy személyes távoli hozzáférési fiók, eszközpostúra-követelmény vagy interaktív MFA-folyamat lehet, hogy nem vihető át felügyelet nélküli közös tunnelre, és az alkalmazottak egyetlen másolt kliensidentitás mögé tömörítése az a rövidítés, amely addig él, amíg a partner nem auditálja a naplóit. Minden engedélyezett kapcsolatnál rögzítse a célcím-tartományokat, a privát DNS-tartományokat, az engedélyezett belső forrásokat, a hitelesítés tulajdonosát és azt, hogy mi történjen a tunnel meghibásodásakor. Kérje meg a partnert, hogy írásban erősítse meg a közös kapcsolatot, beleértve az általa elfogadott forrástartományokat. A szóbeli jóváhagyás jelentése általában abban a héten változik meg, amikor a biztonsági csapatuk vált.

Ez a nyilvántartás az eredmény. Ha egy partner számára nem tudja megírni, az a partner nincs készen a központosításra.

Kontextus szerint irányítson, ne csak cél szerint

Két partner végül ugyanazt a privát tartományt fogja használni, mert minden szervezet ugyanabból az RFC 1918 térből választ. Egyetlen közönséges útválasztási tábla nem tudja kiválasztani a helyes partnert pusztán egy célcímből, ezért az átfedő tartományok külön útválasztási kontextusokat vagy más egyeztetett tervezést igényelnek. A továbbítási tartomány modellje az RFC 4364 dokumentumban elmagyarázza, miért fontos ez az elkülönítés, és egy telepítésnek nem kell MPLS-t futtatnia ahhoz, hogy ugyanezt a tulajdonságot megkövetelje az átjáróplatformjától.

Kérdezze meg egyenesen a platformot: megoszthat-e két partner egy célprefixet, és mégis megkülönböztethető-e aszerint, melyik alkalmazotti kontextusból jött a munkamenet? Ha a válasz nem, ez a korlát jobban formálja a tervezést, mint bármely szállítói funkciólista.

Ahol a válasz igen, az útválasztási kontextus lesz az, amit dokumentál és tesztel, mert egy traceroute-ban láthatatlan.

Döntse el, mit ír be az alkalmazott és mit naplóz a partner

A partneri munka egy része alkalmazásproxyhoz vagy a partner kontextusában megnyitott távoli munkaterülethez illik. Más munka engedélyezett alkalmazotti szegmensből származó irányított hálózati hozzáférést igényel, és a kettő eltérő forrásmimet és eltérő auditnyomot ad a távoli végén. A közös, lefordított forráscím kielégíthet egy engedélyezési listát, miközben elrejti, melyik eszköz mit tett, ezért őrizzen megbízható nyilvántartást az alkalmazott és a munkamenet között, és tartsa meg az alkalmazás hitelesítését, ahelyett hogy az átjáró címét identitásnak tekintené, ami egészen addig kényelmes, amíg a partner meg nem kérdezi, ki tette.

Azután járjon végig egy valódi feladatot az alkalmazott oldaláról: mire kattintanak, mit kérnek tőlük, és mit látna a partner, ha naplóbejegyzést kérne. Ha ez a végigjárás nem ismételhető, a tervezés nincs kész.

Tiltsa meg kifejezetten a partnerek közötti tranzitot

A megosztott hardver soha nem jelenthet megosztott bizalmat. Adja hozzá a tiltást szándékos szabályként, névvel ellátott tulajdonossal, nem hiányzó konfiguráció baleseteként, és tesztelje mindkét irányból egy olyan kéréssel, amely egyébként sikerülne. A teszt azért fontos, mert a csak hiányzó engedélyt a következő mérnök visszaállíthatja, aki egy útvonalat ad hozzá egy független panasz megoldásához.

Írja a tiltást a partner nyilvántartásába az engedélyek mellé, hogy a szándék túlélje a személyi változásokat.

Közös szolgáltatásként működtesse, ne nagyobb laptopként

A tunnelfrissítés, a hitelesítő adatok rotációja, a kapacitás és az átjáró cseréje most mind közös szolgáltatás változásaivá válnak, ami azt jelenti, hogy olyan ütemtervre és kommunikációs útra van szükségük, amilyet az egyedi laptopok soha nem igényeltek. A szombaton lejáró partneri tanúsítvány már nem egy felhasználó kiesése; az az adott partner összes munkamenete egyszerre.

Csak akkor fogadja el a szintet, ha egy megtagadott partnerközi kérés pontosan a szándék szerint meghiúsul, és egy engedélyezett alkalmazotti kérés a helyes forrással éri el a helyes célt. A laptopkonfliktus megszüntetése minden partner határának sértetlenül hagyásával az egész lényeg; az a tervezés, amelyben minden távoli prefix minden asztalról elérhető, csak elmozdította a problémát.

Tartson egy kis táblázatot a partnerről, kontextusról, engedélyezett tartományokról és tulajdonosról. Egy incidens során ezt fogja először kérni bárki.