Partner-VPN-Zugriff zentralisieren, ohne Partner zusammenzulegen

Der Vorschlag ist vernünftig: fünf Partnertunnel verteilt auf ein Dutzend Laptops, fünf Sätze Client-Versionen, fünf Helpdesk-Skripte und ein Ingenieur, der weiß, wie sie zusammenpassen. Sie auf eine kontrollierte Zugriffsebene zu heben, behebt die Ausbreitung der Endpunkte. Es schafft auch ein neues Objekt in Ihrer Architektur, einen gemeinsamen Zugriffsdienst, der nun sein eigenes Autorisierungsmodell braucht, und der Fehler, den alle unterschätzen, ist ein zentrales Gerät mit allen aktivierten Tunneln, das still zu einem Transitnetz zwischen Organisationen wird, die nie zugestimmt haben, Nachbarn zu sein. Dieses Risiko ist eine Designentscheidung, nicht etwas, das die Hardware von selbst tut. Die Arbeit unten zeigt, wie ich den Komfort behalte, ohne den versehentlichen Nebeneffekt zu akzeptieren.

Beginnen Sie mit dem Vertrag, den jeder Partner bereits unterschrieben hat

Bestätigen Sie vor jeder Konfiguration, dass der Partner überhaupt ein gemeinsames Gateway oder eine Standortverbindung erlaubt. Ein persönliches Fernzugriffskonto, eine Geräte-Posture-Anforderung oder ein interaktiver MFA-Ablauf lässt sich möglicherweise nicht auf einen unbeaufsichtigten gemeinsamen Tunnel übertragen, und Mitarbeiter hinter einer kopierten Client-Identität zu bündeln ist die Art Abkürzung, die überlebt, bis der Partner seine Protokolle prüft. Halten Sie für jede erlaubte Verbindung Zielbereiche, private DNS-Domänen, autorisierte interne Quellen, den Authentifizierungsverantwortlichen und das Verhalten bei Tunnelausfall fest. Bitten Sie den Partner, die gemeinsame Verbindung schriftlich zu bestätigen, einschließlich der Quellbereiche, die er akzeptiert. Eine mündliche Zustimmung ändert ihre Bedeutung meist in der Woche, in der das Sicherheitsteam rotiert.

Dieses Verzeichnis ist das Ergebnis. Können Sie es für einen Partner nicht schreiben, ist dieser Partner nicht bereit, zentralisiert zu werden.

Routen Sie nach Kontext, nicht nur nach Ziel

Zwei Partner werden irgendwann denselben privaten Bereich nutzen, weil jede Organisation aus demselben RFC 1918-Raum wählt. Eine einzelne gewöhnliche Routing-Tabelle kann den richtigen Partner nicht allein anhand einer Zieladresse wählen, deshalb brauchen überlappende Bereiche getrennte Routing-Kontexte oder ein anderes vereinbartes Design. Das Forwarding-Domain-Modell in RFC 4364 beschreibt, warum diese Trennung wichtig ist, und eine Bereitstellung muss kein MPLS betreiben, um dieselbe Eigenschaft von ihrer Gateway-Plattform zu verlangen.

Stellen Sie der Plattform eine direkte Frage: Können zwei Partner dasselbe Zielpräfix teilen und sich trotzdem danach unterscheiden, aus welchem Mitarbeiterkontext die Sitzung kam? Ist die Antwort nein, prägt diese Einschränkung das Design stärker als jede Funktionsliste eines Anbieters.

Wo die Antwort ja lautet, wird der Routing-Kontext zu dem, was Sie dokumentieren und testen, weil er in einem traceroute unsichtbar ist.

Entscheiden Sie, was der Mitarbeiter eingibt und was der Partner protokolliert

Manche Partnerarbeit passt zu einem Anwendungsproxy oder einem entfernten Arbeitsbereich, der im Kontext dieses Partners geöffnet wird. Andere Arbeit braucht gerouteten Netzzugriff aus einem freigegebenen Mitarbeitersegment, und beides erzeugt am fernen Ende unterschiedliche Quelladressen und unterschiedliche Prüfpfade. Eine gemeinsame übersetzte Quelladresse kann eine Allowlist erfüllen und dabei verbergen, welches Gerät was getan hat, also bewahren Sie eine verlässliche Zuordnung von Mitarbeiter zu Sitzung und lassen Sie die Anwendungsauthentifizierung bestehen, statt eine Gateway-Adresse als Identität zu behandeln, was so lange bequem ist, bis der Partner fragt, wer es war.

Gehen Sie dann eine echte Aufgabe aus Mitarbeitersicht durch: was sie anklicken, wonach sie gefragt werden und was der Partner sähe, wenn er einen Protokolleintrag anforderte. Ist dieser Durchlauf nicht reproduzierbar, ist das Design nicht fertig.

Verweigern Sie Partner-zu-Partner-Transit ausdrücklich

Gemeinsame Hardware darf niemals gemeinsames Vertrauen bedeuten. Fügen Sie die Verweigerung als bewusste Regel mit einem benannten Verantwortlichen hinzu, nicht als Zufall fehlender Konfiguration, und testen Sie sie in beide Richtungen mit einer Anfrage, die sonst erfolgreich wäre. Der Test ist wichtig, weil eine nur fehlende Erlaubnis vom nächsten Ingenieur wiederhergestellt werden kann, der eine Route hinzufügt, um eine unabhängige Beschwerde zu lösen.

Schreiben Sie die Verweigerung neben die Erlaubnisse in das Partnerverzeichnis, damit die Absicht Personalwechsel übersteht.

Betreiben Sie es als gemeinsamen Dienst, nicht als größeren Laptop

Tunnelerneuerung, Rotation von Anmeldedaten, Kapazität und Gateway-Austausch werden nun alle zu Änderungen am gemeinsamen Dienst, was bedeutet, dass sie einen Zeitplan und einen Kommunikationsweg brauchen, den einzelne Laptops nie erforderten. Ein Partnerzertifikat, das an einem Samstag abläuft, ist nicht mehr der Ausfall eines Nutzers; es sind alle Sitzungen dieses Partners auf einmal.

Akzeptieren Sie die Ebene erst, wenn eine verweigerte partnerübergreifende Anfrage genau wie beabsichtigt scheitert und eine erlaubte Mitarbeiteranfrage das richtige Ziel mit der richtigen Quelle erreicht. Laptop-Konflikte zu beseitigen und dabei die Grenze jedes Partners intakt zu lassen, ist der ganze Punkt; ein Design, in dem jedes entfernte Präfix von jedem Schreibtisch erreichbar ist, hat das Problem nur verschoben.

Führen Sie eine kleine Tabelle mit Partner, Kontext, erlaubten Bereichen und Verantwortlichem. Sie wird das Erste sein, wonach bei einem Vorfall jemand fragt.