AWS Client VPN-autentisering: IAM-tillatelser er ikke en påloggingsmetode
Konsolltillatelser autentiserer ikke en tunnel. Sammenlign metodene med sertifikat, AD og SAML, og se deretter når SSM-viderebefordring av porter passer for én privat database.
Når en bruker får tillatelse til å opprette eller beskrive et AWS Client VPN-endepunkt, betyr ikke det at brukeren kan koble til det. Det er to forskjellige typer identitet: IAM styrer AWS API-kall, og endepunktet godtar bare de klientautentiseringsmetodene som er konfigurert på det. En bruker kan altså ha brede konsollrettigheter og likevel ikke ha noe som VPN-klienten kan presentere. Bestem hvilken metode endepunktet stoler på, og bestem deretter om en full tunnel er riktig form for tilgangen du gir.
En API-identitet er ikke en tunnelidentitet
Når noen sier «IAM-rollen er vedlagt, hvorfor feiler VPN fortsatt», er svaret vanligvis at ingen trinn i tilkoblingsflyten noen gang leser den rollen. Klienten presenterer et sertifikat, et AD-brukernavn og passord eller en SAML-påstand. Endepunktet validerer en av dem og tildeler deretter en adresse.
IAM er fortsatt viktig, bare senere og andre steder: å opprette endepunktet, knytte til subnett, publisere ruter og skrive autorisasjonsregler er API-handlinger. Hold disse tillatelsene begrenset til operatørene som trenger dem, i stedet for å gi hver bruker mulighet til å skrive om endepunktets tilgangsregler.
Velg blant metodene endepunktet støtter
AWS Client VPN godtar sertifikatbasert gjensidig autentisering, Active Directory-autentisering og SAML-basert føderert autentisering. Et serversertifikat kreves uansett hvilken klientmetode du velger, og en konfigurasjon som kombinerer metoder krever at begge lykkes, ikke én.
| 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 |
Sertifikater er de billigste å sette opp og de letteste å gjøre feil med i stor skala, fordi hver bruker trenger en legitimasjon og hver avgang krever en tilbakekalling. Katalogautentisering flytter den livssyklusen til et eksisterende system. Føderasjon flytter den til en identitetsleverandør og legger til et nettlesertrinn på klienten.
Les endepunktets egen konfigurasjon før du feilsøker klienten. Hvis gjensidig autentisering er aktivert sammen med en brukerbasert metode, vil en klient med gyldig sertifikat, men uten katalogkonto, fortsatt feile, og feilen ser vanligvis ut som et generelt håndtrykksproblem.
Føderasjon er ikke å sende tilgangsnøkler videre
En SAML-oppsett fører ikke IAM-tilgangsnøkler eller et token for en antatt rolle inn i tunnelen. Identitetsleverandøren autentiserer personen, returnerer en påstand, og endepunktet godtar den innenfor tilliten du har konfigurert. Økten som oppstår, er en VPN-økt, ikke en AWS API-økt.
Den forskjellen avgjør hvem som kan feilsøke hva. IdP-problemer viser seg som en nettleser- eller klientfeil før det i det hele tatt finnes en tunnel, mens tunnelproblemer viser seg etter en vellykket påstand. Spør hvilken av de to du ser på før du åpner noen av konsollene.
Etter pålogging avgjør fortsatt ruter og autorisasjon
Autentisering gir en økt en adresse; den gir ikke økten en destinasjon. Endepunktets ruter forteller klienten hvilke subnett den skal sende til, autorisasjonsregler avgjør hvilke brukere som kan nå hvilke av disse subnettene, og sikkerhetsgrupper pluss målets egne tillatelser avgjør resten.
Derfor kan en bruker som autentiseres riktig, fortsatt mislykkes med å nå en database. Kontroller ruttetabellens tilknytning til subnettet, autorisasjonsregelen for brukerens gruppe og sikkerhetsgruppen på målet i den rekkefølgen, fordi hver av dem gir en annen type tidsavbrudd.
For én privat database, sammenlign med viderebefordring av porter
Hvis den egentlige oppgaven er én godkjent tilkobling til én privat database, er en full nettverkstunnel et valg og ikke et krav. AWS Systems Manager Session Manager kan åpne en økt med portviderebefordring til en administrert node via IAM, og den noden når databasen på det private nettverket. Brukeren får aldri en VPC-adresse. Den administrerte noden blir den eneste verten som kan nå databasens port, og det er vanligvis det sikkerhetsgjennomgangen ba om. Brukere trenger da en lokal klient og en øktkommando i stedet for en VPN-profil.
Avveiningen er omfang mot forutsetninger. Viderebefordring av porter krever SSM-agenten på den administrerte noden, nettverkstilgjengelighet fra den noden til databasen, Session Manager-pluginen på brukerens maskin og tillatelse til å starte akkurat den økten. Det er ikke en rute inn i hvert subnett, og det bærer ikke vilkårlige protokoller slik en tunnel gjør.
Behold databasens egen identitet på plass uansett. TLS-verifisering og databaseautentisering forsvinner ikke fordi banen ble autorisert av IAM, og en godkjent økt sier ingenting om hvilke tabeller brukeren kan lese.
Velg ut fra omfang og livssyklus: en tunnel når mange brukere trenger mange destinasjoner og du kan drive livssyklusen for sertifikater eller katalog; en økt med viderebefordring når en håndfull mennesker trenger én tjeneste og du helst vil unngå å dele ut nettverksadresser. Uansett bør du registrere autentiseringsmetoden, autorisasjonsregelen og databaseloggen som tre separate fakta, fordi de feiler hver for seg.