AWS Client VPN-Authentifizierung: IAM-Berechtigungen sind keine Anmeldemethode

Wer einem Benutzer die Berechtigung erteilt, einen AWS Client VPN-Endpunkt zu erstellen oder zu beschreiben, erlaubt diesem Benutzer damit nicht, sich mit ihm zu verbinden. Es handelt sich um zwei verschiedene Arten von Identität: IAM steuert AWS API-Aufrufe, und der Endpunkt akzeptiert nur die auf ihm konfigurierten Client-Authentifizierungsmethoden. Ein Benutzer kann also weitreichende Konsolenrechte besitzen und trotzdem nichts vorweisen, was der VPN-Client präsentieren kann. Entscheiden Sie, welcher Methode der Endpunkt vertraut, und entscheiden Sie dann, ob ein vollständiger Tunnel die richtige Form für den Zugriff ist, den Sie gewähren.

Eine API-Identität ist keine Tunnel-Identität

Wenn jemand sagt „die IAM-Rolle ist angehängt, warum schlägt die VPN-Verbindung trotzdem fehl“, lautet die Antwort meist, dass kein Schritt im Verbindungsablauf diese Rolle jemals liest. Der Client präsentiert ein Zertifikat, einen AD-Benutzernamen mit Kennwort oder eine SAML-Assertion. Der Endpunkt validiert eines davon und weist dann eine Adresse zu.

IAM bleibt wichtig, nur später und an anderer Stelle: das Erstellen des Endpunkts, das Zuordnen von Subnetzen, das Veröffentlichen von Routen und das Schreiben von Autorisierungsregeln sind API-Aktionen. Halten Sie diese Berechtigungen auf die Operatoren beschränkt, die sie benötigen, statt jedem Benutzer die Möglichkeit zu geben, die Zugriffsregeln des Endpunkts umzuschreiben.

Wählen Sie aus den Methoden, die der Endpunkt unterstützt

AWS Client VPN akzeptiert zertifikatsbasierte gegenseitige Authentifizierung, Active Directory-Authentifizierung und SAML-basierte föderierte Authentifizierung. Ein Serverzertifikat ist erforderlich, unabhängig davon, welche Client-Methode Sie wählen, und eine Konfiguration, die Methoden kombiniert, verlangt, dass beide erfolgreich sind, nicht eine.

Zertifikate sind am günstigsten aufzusetzen und im großen Maßstab am leichtesten falsch zu machen, weil jeder Benutzer einen Nachweis braucht und jeder Abgang eine Sperrung erfordert. Die Verzeichnisauthentifizierung verlagert diesen Lebenszyklus in ein bestehendes System. Die Föderation verlagert ihn zu einem Identitätsanbieter und fügt dem Client einen Browserschritt hinzu.

Lesen Sie die Konfiguration des Endpunkts selbst, bevor Sie den Client debuggen. Ist gegenseitige Authentifizierung neben einer benutzerbasierten Methode aktiviert, scheitert ein Client mit gültigem Zertifikat, aber ohne Verzeichniskonto weiterhin, und der Fehler sieht meist wie ein allgemeines Handshake-Problem aus.

Föderation ist keine Weitergabe von Zugriffsschlüsseln

Ein SAML-Setup speist weder IAM-Zugriffsschlüssel noch ein Token einer angenommenen Rolle in den Tunnel. Der Identitätsanbieter authentifiziert die Person, gibt eine Assertion zurück, und der Endpunkt akzeptiert sie im Rahmen des von Ihnen konfigurierten Vertrauens. Die daraus entstehende Sitzung ist eine VPN-Sitzung, keine AWS API-Sitzung.

Diese Unterscheidung entscheidet, wer was diagnostizieren kann. IdP-Probleme zeigen sich als Browser- oder Clientfehler, bevor überhaupt ein Tunnel existiert, während Tunnelprobleme erst nach einer erfolgreichen Assertion auftreten. Fragen Sie, welches der beiden Sie gerade sehen, bevor Sie eine der beiden Konsolen öffnen.

Nach der Anmeldung entscheiden weiterhin Routen und Autorisierung

Authentifizierung verschafft einer Sitzung eine Adresse; sie verschafft der Sitzung kein Ziel. Endpunkt-Routen sagen dem Client, an welche Subnetze er senden soll, Autorisierungsregeln entscheiden, welche Benutzer welche dieser Subnetze erreichen dürfen, und Sicherheitsgruppen sowie die eigenen Berechtigungen des Ziels entscheiden über den Rest.

Deshalb kann ein Benutzer, der sich erfolgreich authentifiziert, trotzdem keine Datenbank erreichen. Prüfen Sie die Routentabellenzuordnung für das Subnetz, die Autorisierungsregel für die Gruppe des Benutzers und die Sicherheitsgruppe am Ziel in dieser Reihenfolge, denn jede erzeugt eine andere Art von Zeitüberschreitung.

Für eine einzelne private Datenbank: Vergleich mit Portweiterleitung

Wenn die eigentliche Aufgabe eine genehmigte Verbindung zu einer einzelnen privaten Datenbank ist, ist ein vollständiger Netzwerktunnel eine Wahl und keine Voraussetzung. AWS Systems Manager Session Manager kann über IAM eine Sitzung mit Portweiterleitung zu einem verwalteten Knoten öffnen, und dieser Knoten erreicht die Datenbank im privaten Netz. Der Benutzer erhält nie eine VPC-Adresse. Der verwaltete Knoten wird zum einzigen Host, der den Datenbankport erreichen kann, was meist genau das war, was die Sicherheitsprüfung verlangt hat. Benutzer brauchen dann einen lokalen Client und einen Sitzungsbefehl statt eines VPN-Profils.

Der Kompromiss heißt Umfang gegen Voraussetzungen. Portweiterleitung erfordert den SSM-Agenten auf dem verwalteten Knoten, Netzwerkerreichbarkeit von diesem Knoten zur Datenbank, das Session Manager-Plugin auf dem Rechner des Benutzers und die Berechtigung, genau diese Sitzung zu starten. Sie ist kein Weg in jedes Subnetz und überträgt keine beliebigen Protokolle wie ein Tunnel.

Belassen Sie die eigene Identität der Datenbank in jedem Fall. TLS-Verifikation und Datenbankauthentifizierung verschwinden nicht, weil der Pfad durch IAM autorisiert wurde, und eine genehmigte Sitzung sagt nichts darüber aus, welche Tabellen der Benutzer lesen darf.

Entscheiden Sie nach Umfang und Lebenszyklus: ein Tunnel, wenn viele Benutzer viele Ziele brauchen und Sie den Zertifikats- oder Verzeichnislebenszyklus betreiben können; eine Weiterleitungssitzung, wenn eine Handvoll Personen einen Dienst brauchen und Sie lieber keine Netzwerkadressen verteilen. Halten Sie in jedem Fall die Authentifizierungsmethode, die Autorisierungsregel und die Datenbankanmeldung als drei getrennte Fakten fest, denn sie scheitern getrennt.