Verschlüsselter Transit gewährt keinen Zugriff auf den Carrier

Zwei freigegebene Gateways übertragen den Verkehr eines Netzes mit geringerem Vertrauen über ein eingeschränktes Transportnetz. Die Verschlüsselung der Nutzlast hält sie für gewöhnliche Transitbeobachter unlesbar, und das ist der Teil, den man zuerst entwirft und dann nicht mehr weiterdenkt. Was Verschlüsselung nicht leistet, ist festzulegen, welche Ressourcen die Seite mit geringerem Vertrauen erreichen darf. Das Design braucht zwei Grenzen: eine um die übertragene Konversation und eine um den Zugriff auf den Carrier selbst.

Führen Sie die folgenden Schritte der Reihe nach aus und behandeln Sie einen Fehler bei jedem Schritt als Designänderung, nicht als Konfigurationsanpassung.

Legen Sie beide Grenzen fest, bevor Sie eine Konfiguration anfassen

Die erste Grenze ist die Konversation: Welche Gateway-Paare dürfen einen Tunnel aufbauen, und welcher innere Verkehr darf hindurch. Die zweite ist der Carrier: Welche Adressen und Dienste die Hosts mit geringerem Vertrauen außerhalb des Tunnels erreichen dürfen. Teams bauen meist die erste und erben die zweite von welchem Routing auch immer bereits existierte, und so wird ein eingeschränktes Design still zu einem weiten. Diese Vererbung ist die übliche Grundursache, wenn eine Prüfung einen Host mit geringerem Vertrauen findet, der mit etwas spricht, das niemand freigegeben hat.

Schreiben Sie beide als Listen von Adressen, Ports und Richtungen auf. Lässt sich eine Liste nicht schreiben, ist die Grenze noch nicht definiert.

Schritt 1: den äußeren Tunnel einschränken

Erlauben Sie auf der carrierzugewandten Schnittstelle nur, was der Tunnel braucht: IKE auf UDP 500 und 4500 zwischen den beiden Gateway-Adressen und ESP, wo kein NAT-Traversal verwendet wird. Verwerfen Sie alles andere, was auf dieser Schnittstelle ankommt, einschließlich Management-Protokollen. Die ESP-Spezifikation deckt die Schutzdienste ab; sie sagt nichts darüber, welche eigenen Dienste des Carriers die Gateways nutzen dürfen. Drücken Sie das als explizite Erlaubnisliste aus, damit ein neu veröffentlichter Carrier-Dienst nicht standardmäßig erreichbar wird.

Das ist das Regelwerk, das das Design zu einem Transitdesign macht und nicht zu einer Peering-Vereinbarung.

Prüfen Sie es von der Seite mit geringerem Vertrauen aus, nicht von der Gateway-Konsole. Ein Host dort sollte einen DNS-Server des Carriers nicht erreichen können, noch bevor der Tunnel steht.

Schritt 2: entscheiden, was das ferne Gateway liefert

Am fernen Ende muss wiederhergestellter Verkehr an einen bestimmten Ort gehen. Legen Sie fest, welche inneren Dienste erlaubt sind, aus welchen Quellbereichen, und ob Antworten symmetrisch erwartet werden. Prüfen Sie Verwaltungszugriff separat, denn dasselbe Gateway stellt oft eine administrative Schnittstelle bereit, die nie Teil des Transitplans war.

Ein Diagramm, das bei erfolgreicher Entschlüsselung endet, hat die wichtigste Entscheidung übersprungen.

Schritt 3: Zuständigkeit pro Schicht behalten

Transitausrüstung empfängt und leitet weiterhin äußere Pakete weiter, braucht also Patches und Kapazitätsplanung. Tunnelendpunkte verarbeiten das geschützte Protokoll und geben inneren Verkehr an ihren Weiterleitungspfad weiter, brauchen also eigene Regeln und eigene Überwachung. Endanwendungen verarbeiten die Nutzlast, und eine undurchsichtige Nutzlast ist kein Beweis dafür, dass ein entschlüsselter Download harmlos ist.

Weisen Sie jeder Schicht einen Verantwortlichen zu. Die Schichten ohne Verantwortlichen sind die, die abdriften.

Schritt 4: überprüfen, dann der Behörde übergeben

Überprüfen Sie den äußeren Pfad bei stehendem Tunnel und aktiven Carrier-Regeln. Versuchen Sie dann jede Ressource, die die Seite mit geringerem Vertrauen nicht erreichen sollte, und bestätigen Sie, dass das Scheitern eine Ablehnung ist und kein Timeout, das eine Route verbirgt. Prüfen Sie auch Verfügbarkeit und Ressourcengrenzen, denn auch eine verschlüsselte Verbindung kann gesättigt werden.

Für regulierte oder klassifizierte Umgebungen bringen Sie das Design zur zuständigen Sicherheitsbehörde und verwenden Sie deren freigegebene Trennungsarchitektur. Eine VPN-Konfiguration und eine konzeptionelle Erklärung begründen keine Akkreditierung. Dieser Schritt ist keine Papierarbeit; er entscheidet, ob das Design überhaupt existieren darf.