AWS Client VPN-Regeln gehören zur Ressource, nicht zum Subnetz

Mitarbeitende müssen eine Anwendung in der VPC erreichen und dürfen den Datenbank-Listener auf derselben Instanz nicht erreichen, also fügt jemand ein zweites öffentliches Subnetz für den VPN-Endpunkt hinzu und erklärt die Anforderung für erfüllt. Die Subnetzplatzierung ändert Routing und Verfügbarkeit. Sie gewährt oder verweigert keinen einzigen Port. Die Berechtigung, die die Anforderung ausdrückt, liegt am Ziel, in der Sicherheitsgruppe der Ressource, und die VPN-Grenze liefert den Bezugspunkt, auf den diese Regel verweist.

Subnetzplatzierung ist Routing, nicht Autorisierung

Wo die Netzwerkzuordnung des Endpunkts liegt, entscheidet, welche Routentabelle den Client-Verkehr trägt und welche Verfügbarkeitszonen einen Ausfall überstehen. Sie sagt nichts darüber, welchen Port auf welcher Instanz dieser Verkehr erreichen darf. Zwei Clients, die demselben Subnetz zugeordnet sind, kommen weiterhin mit derselben Quellidentität an, und die Ressource kann sie nicht anhand des Subnetznamens unterscheiden.

Beginnen Sie stattdessen bei der Anforderung: wer aufruft, welche Ressource, welcher Dienstport und welche Richtung. Wählen Sie dann das Regelmodell, das diese vier Dinge am Ziel ausdrücken kann. Diese Betrachtung entfernt das zusätzliche Subnetz meist vollständig aus dem Entwurf.

Die Client VPN-Zuordnungsgruppe ist der Bezugspunkt

Für einen subnetzgebundenen AWS Client VPN-Endpunkt ist die dokumentierte Anordnung konkret. Wenden Sie die vorgesehene Sicherheitsgruppe auf die Zielnetz-Zuordnungen des Endpunkts an und erlauben Sie dann den erforderlichen Verkehr in der Sicherheitsgruppe der Ressource, indem Sie diese Client VPN-Gruppe als Quelle verwenden.

Konkret erlaubt die Gruppe der Anwendungsinstanz den Anwendungsport aus der Zuordnungsgruppe und sonst nichts. Das Verfahren für den Ressourcenzugriff von AWS beschreibt diese Beziehung, und es lohnt sich, dieselbe Gruppenrichtlinie in jedem Subnetz beizubehalten, dem der Endpunkt zugeordnet wird, denn eine veraltete Zuordnung mit einer anderen Gruppe erweitert die Grenze still.

Diese Regel authentifiziert niemanden. Die Anmeldung ist eine eigene Kontrolle, und der Weg zur Ressource ist eine dritte. Alle drei müssen gelten, bevor eine Anfrage ankommt. Welche versagt, entscheidet, welche Korrektur richtig ist, und eine Regeländerung ist nur für die erste die richtige Antwort.

Was eine Zuordnungsgruppe nicht unterscheiden kann

Jeder Client hinter derselben Zuordnungsgruppe erreicht die Ressource als dieselbe Sicherheitsgruppenquelle. Zwei Nutzer mit unterschiedlichen Rollen sind auf dieser Ebene nicht unterscheidbar, egal wie die Gruppe benannt oder getaggt ist. Die Autorisierung externer Gruppen bei Client VPN begrenzt den Zugriff nach Zielpräfix für eine Verzeichnis- oder SAML-Gruppe, was gröber als eine Ressourcenrolle ist und als Netzwerkgrenze statt als Identitätssystem behandelt werden sollte.

Feinere Unterscheidungen gehören zur Anwendung. Ein Datenbank-Listener, der für die meisten Mitarbeitenden geschlossen bleiben muss, ist besser geschützt, indem er unter dem erlaubten Präfix überhaupt nicht erreichbar ist, als indem man hofft, dass die Gruppenmitgliedschaft ordentlich bleibt.

Das Umbenennen der Gruppe erzeugt keine Identität, und das Vervielfältigen je Team vermehrt nur die Zuordnungen, die geprüft werden müssen.

Kopieren Sie diese Regel nicht in jedes VPN-Design

Ein selbst verwaltetes EC2 VPN-Gateway, eine geroutete Prüfappliance und verwaltetes Client VPN sind drei verschiedene Paketpfade. Stellen Sie fest, welche Quelladresse die Ressource tatsächlich erreicht, ob dazwischen übersetzt wird und welche Referenzmechanismen der Dienst auf diesem Pfad unterstützt.

Verkehr durch eine Middlebox zu leiten, erhält eine Quell-Sicherheitsgruppenreferenz nicht so, wie es direkter Instanz-zu-Instanz-Verkehr tut. AWS dokumentiert, dass solche Entwürfe statt einer Gruppenreferenz die passenden privaten Quelladressen oder CIDRs benötigen können. Das Verfahren für verwaltetes Client VPN ist kein Beleg dafür, dass die angehängte Gruppe jedes Gateways als universelles Identitätstoken für weitergeleitete Pakete funktioniert.

Ein NAT-Hop auf dem Pfad genügt, um die Annahme zu brechen, und der Fehler sieht aus wie eine Regel, die vorhanden ist, aber nie passt.

Prüfen Sie die effektive Grenze

Lesen Sie jede Sicherheitsgruppe, die an der Ressource hängt, denn Erlauben-Regeln addieren sich, und eine enge Regel hebt eine weitere auf einer anderen Gruppe nicht auf. Prüfen Sie dann die Netzwerk-ACL, die Host-Firewall und die eigene Autorisierung der Anwendung, also getrennte Schichten mit getrennten Fehlern.

Schließen Sie mit einer erlaubten und einer bewusst ausgeschlossenen Anfrage gegen dieselbe Ressource ab. Das Paar beweist die Grenze, während eine einzelne erfolgreiche Verbindung nur beweist, dass etwas offen ist. Bestätigen Sie die Route, die effektive Quelle und den vorgesehenen Dienstport statt des Subnetzes, das den Endpunkt enthält.

Reihenfolge der Arbeit: Schreiben Sie die viergeteilte Anforderung, hängen Sie die Gruppe an die Zuordnungen, begrenzen Sie die Ressourcenregel auf den Port, prüfen Sie eine Erlaubnis und eine Ablehnung, und erwägen Sie erst dann, Subnetze aus Routinggründen zu teilen.