Autentisering i AWS Client VPN: IAM-behörigheter är inte en inloggningsmetod
Konsolbehörigheter autentiserar inte en tunnel. Jämför metoderna med certifikat, AD och SAML och se sedan när SSM-portvidarebefordran passar för en enda privat databas.
Att ge en användare behörighet att skapa eller beskriva en AWS Client VPN-slutpunkt gör inte att användaren kan ansluta till den. Det är två olika typer av identitet: IAM styr AWS API-anrop och slutpunkten accepterar bara de klientautentiseringsmetoder som är konfigurerade på den. En användare kan alltså ha breda konsolrättigheter och ändå inte ha något som VPN-klienten kan presentera. Bestäm vilken metod slutpunkten litar på och bestäm sedan om en full tunnel är rätt form för den åtkomst du ger.
En API-identitet är inte en tunnelidentitet
När någon säger »IAM-rollen är bifogad, varför misslyckas VPN ändå«, är svaret oftast att inget steg i anslutningsflödet någonsin läser den rollen. Klienten visar ett certifikat, ett AD-användarnamn och lösenord eller ett SAML-påstående. Slutpunkten validerar en av dem och tilldelar sedan en adress.
IAM spelar fortfarande roll, bara senare och någon annanstans: att skapa slutpunkten, associera subnät, publicera rutter och skriva auktoriseringsregler är API-åtgärder. Håll dessa behörigheter begränsade till de operatörer som behöver dem i stället för att ge varje användare möjlighet att skriva om slutpunktens åtkomstregler.
Välj bland de metoder som slutpunkten stöder
AWS Client VPN accepterar certifikatbaserad ömsesidig autentisering, Active Directory-autentisering och SAML-baserad federerad autentisering. Ett servercertifikat krävs oavsett vilken klientmetod du väljer, och en konfiguration som kombinerar metoder kräver att båda lyckas, inte en.
| Client method | What the user presents | Where the work sits |
|---|---|---|
| Mutual certificate | A client certificate the endpoint trusts | Certificate authority, issuing and revoking per user |
| Active Directory | Domain credentials | Directory reachable from the endpoint's VPC |
| SAML federation | An assertion from an identity provider | IdP application, attribute mapping, client support |
Certifikat är billigast att sätta upp och lättast att göra fel i stor skala, eftersom varje användare behöver en legitimering och varje avgång kräver en återkallning. Katalogautentisering flyttar den livscykeln till ett befintligt system. Federation flyttar den till en identitetsleverantör och lägger till ett webbläsarsteg på klienten.
Läs slutpunktens egen konfiguration innan du felsöker klienten. Om ömsesidig autentisering är aktiverad vid sidan av en användarbaserad metod kommer en klient med giltigt certifikat men utan katalogkonto fortfarande att misslyckas, och felet ser oftast ut som ett allmänt handskakningsproblem.
Federation är inte att skicka vidare åtkomstnycklar
En SAML-konfiguration för inte in IAM-åtkomstnycklar eller en token för en antagen roll i tunneln. Identitetsleverantören autentiserar personen, returnerar ett påstående och slutpunkten accepterar det inom det förtroende du har konfigurerat. Den session som uppstår är en VPN-session, inte en AWS API-session.
Den skillnaden avgör vem som kan felsöka vad. IdP-problem visar sig som ett webbläsar- eller klientfel innan det ens finns en tunnel, medan tunnelproblem visar sig efter ett lyckat påstående. Fråga vilken av de två du tittar på innan du öppnar någon av konsolerna.
Efter inloggning avgör rutter och auktorisering fortfarande
Autentisering ger en session en adress; den ger inte sessionen en destination. Slutpunktens rutter talar om för klienten vilka subnät den ska skicka till, auktoriseringsregler avgör vilka användare som kan nå vilka av dessa subnät, och säkerhetsgrupper plus målets egna behörigheter avgör resten.
Därför kan en användare som autentiseras korrekt fortfarande misslyckas med att nå en databas. Kontrollera ruttabellens koppling till subnätet, auktoriseringsregeln för användarens grupp och säkerhetsgruppen på målet i den ordningen, eftersom var och en ger en annan typ av tidsgräns.
För en enda privat databas, jämför med portvidarebefordran
Om den egentliga uppgiften är en godkänd anslutning till en enda privat databas är en full nätverkstunnel ett val och inte ett krav. AWS Systems Manager Session Manager kan via IAM öppna en session med portvidarebefordran till en hanterad nod, och den noden når databasen på det privata nätet. Användaren får aldrig en VPC-adress. Den hanterade noden blir den enda värden som kan nå databasens port, och det är oftast vad säkerhetsgranskningen bad om. Användarna behöver då en lokal klient och ett sessionskommando i stället för en VPN-profil.
Avvägningen är omfattning mot förutsättningar. Portvidarebefordran kräver SSM-agenten på den hanterade noden, nätverksåtkomst från den noden till databasen, Session Manager-tillägget på användarens maskin och behörighet att starta just den sessionen. Det är inte en väg in i varje subnät, och det bär inte godtyckliga protokoll som en tunnel gör.
Behåll databasens egen identitet på plats oavsett. TLS-verifiering och databasautentisering försvinner inte för att vägen auktoriserades av IAM, och en godkänd session säger ingenting om vilka tabeller användaren får läsa.
Välj utifrån omfattning och livscykel: en tunnel när många användare behöver många destinationer och du kan driva livscykeln för certifikat eller katalog; en vidarebefordringssession när en handfull personer behöver en enda tjänst och du helst undviker att dela ut nätverksadresser. Registrera hur som helst autentiseringsmetoden, auktoriseringsregeln och databasinloggningen som tre separata fakta, eftersom de misslyckas var för sig.