Centraliseer partnertoegang via VPN zonder de partners samen te voegen

Het voorstel is redelijk: vijf partnertunnels verspreid over een dozijn laptops, vijf sets clientversies, vijf helpdeskscripts en één engineer die weet hoe ze in elkaar passen. Ze naar een gecontroleerde toegangslagen verplaatsen lost de verspreiding van endpoints op. Tegelijk creëert het een nieuw object in je architectuur — een gedeelde toegangsdienst die nu een eigen autorisatiemodel nodig heeft; en de fout die iedereen onderschat is een centraal apparaat met alle tunnels ingeschakeld dat stilletjes een transitnetwerk wordt tussen organisaties die nooit hebben ingestemd om buren te zijn. Dat risico is een ontwerpkeuze, niet iets wat de hardware zelf doet. Het werk hieronder laat zien hoe ik het gemak behoud zonder het onbedoelde neveneffect te accepteren.

Begin bij het contract dat elke partner al heeft ondertekend

Bevestig vóór enige configuratie dat de partner een gedeelde gateway- of siteverbinding überhaupt toestaat. Een persoonlijk remote-accessaccount, een eis aan de apparaatpostuur of een interactieve MFA-stroom is mogelijk niet overdraagbaar naar een onbeheerde gedeelde tunnel, en werknemers achter één gekopieerde clientidentiteit bundelen is het soort snelkoppeling dat standhoudt tot de partner hun logs controleert. Leg voor elke toegestane verbinding de bestemmingsbereiken, private DNS-domeinen, geautoriseerde interne bronnen, de eigenaar van de authenticatie en wat er moet gebeuren als de tunnel faalt vast. Vraag de partner de gedeelde verbinding schriftelijk te bevestigen, inclusief de bronbereiken die zij accepteren. Mondelinge goedkeuring verandert meestal van betekenis in de week dat hun securityteam wisselt.

Dat record is de oplevering. Kun je het voor één partner niet schrijven, dan is die partner niet klaar om te worden gecentraliseerd.

Routeer op context, niet alleen op bestemming

Twee partners zullen uiteindelijk hetzelfde privébereik gebruiken, omdat elke organisatie uit dezelfde RFC 1918-ruimte kiest. Eén gewone routetabel kan niet op basis van alleen een bestemmingsadres de juiste partner kiezen, dus overlappende bereiken hebben aparte routingcontexten of een ander overeengekomen ontwerp nodig. Het forwarding-domeinmodel in RFC 4364 beschrijft waarom die scheiding belangrijk is, en een implementatie hoeft geen MPLS te draaien om dezelfde eigenschap van zijn gatewayplatform te eisen.

Stel het platform een directe vraag: kunnen twee partners hetzelfde bestemmingsprefix delen en toch worden onderscheiden op basis van de werknemerscontext waaruit de sessie kwam? Is het antwoord nee, dan bepaalt die beperking het ontwerp meer dan welke leveranciersfunctielijst dan ook.

Waar het antwoord ja is, wordt de routingcontext het ding dat je documenteert en test, omdat het onzichtbaar is in een traceroute.

Bepaal wat de werknemer typt en wat de partner logt

Sommig partnerwerk past bij een applicatieproxy of een externe werkruimte die binnen de context van die partner wordt geopend. Ander werk vereist gerouteerde netwerktoegang vanaf een goedgekeurd werknemerssegment, en beide produceren andere bronadressen en andere auditsporen aan de andere kant. Een gedeeld vertaald bronadres kan aan een allowlist voldoen terwijl het verbergt welk apparaat wat deed, dus houd een betrouwbare koppeling tussen werknemer en sessie bij en laat applicatieauthenticatie staan in plaats van een gatewayadres als identiteit te behandelen — wat handig is tot precies het moment waarop de partner vraagt wie het deed.

Loop daarna één echte taak door vanaf de kant van de werknemer: waar ze op klikken, waarom ze worden gevraagd en wat de partner zou zien als die om een logregel vroeg. Is die doorloop niet reproduceerbaar, dan is het ontwerp niet af.

Weiger partner-naar-partnertransit expliciet

Gedeelde hardware mag nooit gedeeld vertrouwen impliceren. Voeg de weigering toe als een bewuste regel met een genoemde eigenaar, niet als een ongeluk van ontbrekende configuratie, en test hem in beide richtingen met een verzoek dat anders zou slagen. De test is belangrijk omdat een permit die alleen ontbreekt kan worden hersteld door de volgende engineer die een route toevoegt om een losstaande klacht op te lossen.

Schrijf de weigering in het partnerrecord naast de permits, zodat de bedoeling personeelswisselingen overleeft.

Beheer het als een gedeelde dienst, niet als een grotere laptop

Tunnelvernieuwing, rotatie van inloggegevens, capaciteit en vervanging van de gateway worden nu allemaal wijzigingen in een gedeelde dienst, wat betekent dat ze een planning en een communicatiepad nodig hebben die individuele laptops nooit vereisten. Een partnercertificaat dat op zaterdag verloopt is niet langer de storing van één gebruiker; het is elke sessie van die partner tegelijk.

Accepteer de laag alleen wanneer een geweigerd verzoek tussen partners precies faalt zoals bedoeld en een toegestaan werknemersverzoek de juiste bestemming met de juiste bron bereikt. Laptopconflicten wegnemen terwijl de grens van elke partner intact blijft is het hele punt; een ontwerp waarin elk extern prefix vanaf elk bureau bereikbaar is, heeft het probleem alleen verplaatst.

Houd een kleine tabel bij van partner, context, toegestane bereiken en eigenaar. Het is het eerste waar iedereen tijdens een incident om vraagt.