AWS Client VPN-authenticatie: IAM-machtigingen zijn geen inlogmethode

Een gebruiker toestemming geven om een AWS Client VPN-endpoint te maken of te beschrijven betekent niet dat die gebruiker er verbinding mee kan maken. Het zijn twee verschillende soorten identiteit: IAM beheert AWS API-aanroepen en het endpoint accepteert alleen de clientauthenticatiemethoden die erop zijn geconfigureerd. Een gebruiker kan dus ruime consolerechten hebben en toch niets hebben wat de VPN-client kan presenteren. Bepaal welke methode het endpoint vertrouwt en bepaal daarna of een volledige tunnel de juiste vorm is voor de toegang die u verleent.

Een API-identiteit is geen tunnelidentiteit

Als iemand zegt „de IAM-rol is gekoppeld, waarom faalt de VPN dan nog”, is het antwoord meestal dat geen enkele stap in de verbindingsstroom die rol ooit leest. De client presenteert een certificaat, een AD-gebruikersnaam en wachtwoord of een SAML-bewering. Het endpoint valideert een daarvan en wijst daarna een adres toe.

IAM blijft belangrijk, alleen later en elders: het endpoint aanmaken, subnetten koppelen, routes publiceren en autorisatieregels schrijven zijn API-acties. Houd die machtigingen beperkt tot de operators die ze nodig hebben in plaats van elke gebruiker de mogelijkheid te geven de toegangsregels van het endpoint te herschrijven.

Kies uit de methoden die het endpoint ondersteunt

AWS Client VPN accepteert certificaatgebaseerde wederzijdse authenticatie, Active Directory-authenticatie en SAML-gebaseerde federatieve authenticatie. Een servercertificaat is vereist ongeacht welke clientmethode u kiest, en een configuratie die methoden combineert vereist dat beide slagen, niet één.

Certificaten zijn het goedkoopst op te zetten en het makkelijkst om op schaal fout te doen, omdat elke gebruiker een referentie nodig heeft en elk vertrek een intrekking vereist. Directory-authenticatie verplaatst die levenscyclus naar een bestaand systeem. Federatie verplaatst hem naar een identiteitsprovider en voegt een browserstap toe aan de client.

Lees de configuratie van het endpoint zelf voordat u de client debugt. Als wederzijdse authenticatie is ingeschakeld naast een gebruikersgebaseerde methode, zal een client met een geldig certificaat maar zonder directoryaccount nog steeds falen, en de fout ziet er meestal uit als een algemeen handshake-probleem.

Federatie is geen doorgeven van toegangssleutels

Een SAML-configuratie voert geen IAM-toegangssleutels of een token van een aangenomen rol in de tunnel. De identiteitsprovider authenticeert de persoon, geeft een bewering terug en het endpoint accepteert die binnen het vertrouwen dat u hebt geconfigureerd. De resulterende sessie is een VPN-sessie, geen AWS API-sessie.

Dat onderscheid bepaalt wie wat kan diagnosticeren. IdP-problemen verschijnen als een browser- of clientfout voordat er überhaupt een tunnel bestaat, terwijl tunnelproblemen pas na een geslaagde bewering verschijnen. Vraag welke van de twee u bekijkt voordat u een van beide consoles opent.

Na het inloggen beslissen routes en autorisatie nog steeds

Authenticatie geeft een sessie een adres; het geeft de sessie geen bestemming. De routes van het endpoint vertellen de client naar welke subnetten te sturen, autorisatieregels beslissen welke gebruikers welke van die subnetten mogen bereiken, en beveiligingsgroepen plus de eigen machtigingen van het doel beslissen de rest.

Daarom kan een gebruiker die zich correct authenticeert nog steeds geen database bereiken. Controleer de koppeling van de routetabel voor het subnet, de autorisatieregel voor de groep van de gebruiker en de beveiligingsgroep op het doel in die volgorde, omdat elk daarvan een ander soort time-out oplevert.

Voor één particuliere database: vergelijk met poortdoorschakeling

Als de echte taak één goedgekeurde verbinding naar één particuliere database is, is een volledige netwerktunnel een keuze en geen vereiste. AWS Systems Manager Session Manager kan via IAM een sessie met poortdoorschakeling openen naar een beheerde node, en die node bereikt de database op het particuliere netwerk. De gebruiker krijgt nooit een VPC-adres. De beheerde node wordt de enige host die de databasepoort kan bereiken, en dat is meestal wat de beveiligingsreview vroeg. Gebruikers hebben dan een lokale client en een sessieopdracht nodig in plaats van een VPN-profiel.

De afweging is omvang tegen vereisten. Poortdoorschakeling vereist de SSM-agent op de beheerde node, netwerkbereikbaarheid van die node naar de database, de Session Manager-invoegtoepassing op de machine van de gebruiker en toestemming om precies die sessie te starten. Het is geen route naar elk subnet, en het draagt geen willekeurige protocollen zoals een tunnel dat doet.

Houd de identiteit van de database zelf hoe dan ook op zijn plaats. TLS-verificatie en database-authenticatie verdwijnen niet omdat het pad door IAM is geautoriseerd, en een goedgekeurde sessie zegt niets over welke tabellen de gebruiker mag lezen.

Kies op basis van omvang en levenscyclus: een tunnel wanneer veel gebruikers veel bestemmingen nodig hebben en u de certificaat- of directorylevenscyclus kunt draaien; een doorschakelsessie wanneer een handvol mensen één dienst nodig hebben en u liever geen netwerkadressen uitgeeft. Leg in elk geval de authenticatiemethode, de autorisatieregel en de databaselogin vast als drie afzonderlijke feiten, omdat ze afzonderlijk falen.