AWS ClientVPN SAML-basierte Authentifizierung über Tools4ever HelloID

Es gibt eine umfangreiche Dokumentation für die Implementierung der SAML-basierten Authentifizierung für AWS Client VPN über IDPs wie Okta und Azure AD, aber wenn Sie oder Ihre Kunden zufällig einen anderen IDP verwenden, ist die Dokumentation schwer zu bekommen. Kombinieren Sie dies mit der Tatsache, dass die meisten AWS Managed / Professional Services-Teams keinen Zugriff auf die IDP eines Kunden haben - die Implementierung wird oft schwierig. In diesem Blog gebe ich eine schrittweise Anleitung zur Konfiguration Ihrer SAML-Anwendung in Tools4ever's IDP-Produkt - HelloID.

Gegen Ende dieses Artikels werfen wir einen Blick auf die Autorisierungsregeln, wie sie von AWS Client VPN implementiert werden. Wir sehen uns an, wie Sie dies in einem Szenario umsetzen können, in dem Sie mehrere externe Einheiten/Lieferanten haben, die sich über AWS Client VPN mit Ihrem Netzwerk verbinden. Vielleicht möchten Sie externen Unternehmen einen granularen Zugriff gewähren und gleichzeitig weniger restriktive Regeln für Ihr technisches Personal, das diese Unternehmen unterstützt, beibehalten. Autorisierungsregeln sind die erste Anlaufstelle für jeden authentifizierten VPN-Benutzer. Netzwerk-ACLs und Sicherheitsgruppen legen genau fest, was diese Benutzer mit diesem Zugang tun können, und bestimmen ihre Netzwerkreichweite.

• AWS Client VPN SAML-basierte Implementierung Okta
• AWS Client VPN SAML-basierte Implementierung AzureAD:
• AWS Client VPN-Dokumentation für SAML-basierte Authentifizierung
• SAML Tracer: Nützliches Tool für die SAML-Fehlersuche

Überblick über die Lösung

 

In der obigen Lösung wurde der clientVPN-Endpunkt im Transit-Gateway-Konto konfiguriert. Dies ist keineswegs erforderlich, aber unser bevorzugter Ansatz bei der Konfiguration externer Konnektivität zur AWS-Umgebung eines Kunden.

Generische SAML-App in HelloID konfigurieren

Beginnen Sie mit der Erstellung eines selbstsignierten Zertifikats zur Verwendung durch die SAML-Anwendung:

 

 

Erstellen Sie eine neue SAML-Anwendung

 

 

Allgemeine Konfiguration

 

Einzelanmeldung

 

Wenn Sie nicht vorhaben, die Selbstbedienungsfunktion zu nutzen, können Sie die Option "ACS-Anfrage-URL validieren und verwenden" deaktivieren und die ACS-Validierungsliste leer lassen. Die einzige Anforderung in diesem Fall ist die Endpunkt/ACS-URL, die http://127.0.0.1:35001 sein muss (beachten Sie http, nicht https).

 

Name ID-Format	Emailadresse
Endpunkt/ACS URL	http://127.0.0.1:35001
ACS-Anfrage-URL validieren und verwenden	Aktiviert
ACS Validierungsliste	http://127.0.0.1:35001 https://self-service.clientvpn.amazonaws.com/api/auth/sso/saml
Bindung	HTTP-Redirect
Signieren Sie Assertion	Aktiviert
Antwort unterschreiben	Aktiviert
X509-Zertifikat	Wählen Sie das in Schritt 1 erstellte selbstsignierte Zertifikat
Publikum überschreiben	Aktiviert
Extra Zielgruppen	urn:amazon:webservices:clientvpn
Attribut Gruppenmitgliedschaft senden	Aktiviert
Name des Attributs Gruppenmitgliedschaft	memberOf (Groß-/Kleinschreibung beachten)

 

Aufgaben nach der Anwendungserstellung Anwendungsgruppenmitgliedschaft

 

 

Fügen Sie die erforderlichen Gruppen hinzu, die von dieser Anwendung verwendet werden sollen.

 

Karte erforderlich Attribute

 

 

 

Klicken Sie auf "Mappings ändern".

Attribute LastName, FirstName hinzufügen

SAML-Metadaten-Dokument exportieren / herunterladen

 

Klicken Sie auf Metadaten herunterladen oben rechts auf dem Bildschirm und speichern Sie die Datei auf Ihrem lokalen Computer. Der Inhalt dieser xml-Datei wird für die Konfiguration des Identitätsanbieters in AWS IAM für den AWS ClientVPN-Endpunkt verwendet.

AWS Client VPN Autorisierungsregeln

Das Attribut memberOf der SAML-Antwort gibt alle Gruppen zurück, in denen der authentifizierte Benutzer Mitglied ist. Damit können wir granulare Autorisierungsregeln für jede Gruppe implementieren, d.h. allen Mitgliedern einer bestimmten Gruppe den Zugriff auf z.B. eine einzelne IP (z.B. 192.168.1.24/32) oder einen Bereich von IPs/Subnetzen (192.168.1.0/24) erlauben. AWS implementiert dies anhand der längsten Präfix-Übereinstimmung für die Ziel-IP (Bereich) - was in Ordnung ist, wenn Sie nicht viele VPN-Benutzer/Gruppen mit unterschiedlichen/überlappenden Zugangsanforderungen haben.

Wenn eine bestimmte Gruppe Zugriff auf eine bestimmte IP / einen bestimmten Bereich hat, ist dieser Bereich für andere Gruppen nicht mehr zugänglich, selbst wenn eine Autorisierungsregel, die einer der anderen Gruppen zugewiesen wurde, einen noch breiteren IP-Bereich umfasst.

Zum Beispiel:

 

In diesem Szenario hat Anbieter2 keinen Zugriff auf 192.168.1.24/32, da Anbieter1 die längste Präfixübereinstimmung hat. Die Gruppe AdminsGroup hat keinen Zugriff auf 192.168.1.24/32 oder 192.168.1.0/24.

Um dies zu umgehen, könnten wir einfach weitere Autorisierungsregeln hinzufügen...

 

Das wird funktionieren - ABER Sie sehen, wie schnell dies zu einem administrativen Alptraum werden kann - insbesondere für Gruppen, die Zugang zu einer größeren Anzahl von IPs/Subnetzen benötigen - da Sie für diese Benutzer effektiv jede einzelne IP-Adresse (oder jeden Bereich) aus den anderen Gruppen hinzufügen müssten.

Wie können wir das also lösen?

Die Lösung ist eigentlich ganz einfach - halten Sie die Autorisierungsregeln für die Lieferantengruppe so granular wie möglich, d.h. pflegen Sie die Autorisierungsregeln für jeden Lieferanten so spezifisch wie möglich - auch wenn sich diese Regeln überschneiden.

Für Ihre Admin-Benutzer - machen Sie einfach die Gruppe admins zu einem Mitglied aller Lieferantengruppen in Ihrer IDP. Sie würden dann etwa so aussehen:

 

Ein letzter Tipp: Wenn Sie internes DNS hosten, erstellen Sie Autorisierungsregeln, die allen Benutzern den Zugriff auf diese Dienste erlauben. So können Ihre VPN-Clients über Hostnamen statt über IP-Adressen auf Ressourcen in Ihrem Netzwerk zugreifen. WICHTIG: Stellen Sie sicher, dass Sie nur den Zugriff auf Port 53 von den mit Ihrem ClientVPN-Endpunkt verbundenen Subnetzen auf Ihre DNS-Server erlauben.