AWS Client VPN-godkendelse: IAM-tilladelser er ikke en loginmetode
Konsoltilladelser godkender ikke en tunnel. Sammenlign metoderne med certifikat, AD og SAML, og se derefter, hvornår SSM-viderebefordring af porte passer til én privat database.
Når en bruger får tilladelse til at oprette eller beskrive et AWS Client VPN-endpoint, betyder det ikke, at brugeren kan oprette forbindelse til det. Det er to forskellige slags identitet: IAM styrer AWS API-kald, og endpointet accepterer kun de klientgodkendelsesmetoder, der er konfigureret på det. En bruger kan altså have brede konsolrettigheder og stadig ikke have noget, som VPN-klienten kan fremvise. Afgør, hvilken metode endpointet stoler på, og afgør derefter, om en fuld tunnel er den rigtige form for den adgang, du giver.
En API-identitet er ikke en tunnelidentitet
Når nogen siger »IAM-rollen er vedhæftet, hvorfor fejler VPN så stadig«, er svaret normalt, at intet trin i forbindelsesforløbet nogensinde læser den rolle. Klienten fremviser et certifikat, et AD-brugernavn og en adgangskode eller en SAML-erklæring. Endpointet validerer en af dem og tildeler derefter en adresse.
IAM er stadig vigtigt, bare senere og andre steder: at oprette endpointet, tilknytte undernet, offentliggøre ruter og skrive autorisationsregler er API-handlinger. Hold disse tilladelser begrænset til de operatører, der har brug for dem, i stedet for at give enhver bruger mulighed for at omskrive endpointets adgangsregler.
Vælg blandt de metoder, endpointet understøtter
AWS Client VPN accepterer certifikatbaseret gensidig godkendelse, Active Directory-godkendelse og SAML-baseret fødereret godkendelse. Der kræves et servercertifikat, uanset hvilken klientmetode du vælger, og en konfiguration, der kombinerer metoder, kræver, 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 |
Certifikater er de billigste at opsætte og de letteste at få galt i stor skala, fordi hver bruger har brug for en legitimationsoplysning, og hver afgang kræver en tilbagekaldelse. Mappegodkendelse flytter den livscyklus til et eksisterende system. Føderation flytter den til en identitetsudbyder og tilføjer et browsertrin til klienten.
Læs endpointets egen konfiguration, før du fejlretter klienten. Hvis gensidig godkendelse er aktiveret sammen med en brugerbaseret metode, vil en klient med et gyldigt certifikat, men uden mappekonto, stadig fejle, og fejlen ligner normalt et generisk håndtryksproblem.
Føderation er ikke at sende adgangsnøgler videre
En SAML-opsætning fører ikke IAM-adgangsnøgler eller et token for en antaget rolle ind i tunnelen. Identitetsudbyderen godkender personen, returnerer en erklæring, og endpointet accepterer den under den tillid, du har konfigureret. Den resulterende session er en VPN-session, ikke en AWS API-session.
Den forskel afgør, hvem der kan fejlfinde hvad. IdP-problemer viser sig som en browser- eller klientfejl, før der overhovedet findes en tunnel, mens tunnelproblemer viser sig efter en vellykket erklæring. Spørg, hvilken af de to du ser på, før du åbner en af konsollerne.
Efter login afgør ruter og autorisation stadig
Godkendelse giver en session en adresse; den giver ikke sessionen en destination. Endpointets ruter fortæller klienten, hvilke undernet der skal sendes til, autorisationsregler afgør, hvilke brugere der kan nå hvilke af disse undernet, og sikkerhedsgrupper plus målets egne tilladelser afgør resten.
Derfor kan en bruger, der godkendes korrekt, stadig mislykkes med at nå en database. Kontrollér ruttetabellens tilknytning til undernettet, autorisationsreglen for brugerens gruppe og sikkerhedsgruppen på målet i den rækkefølge, fordi hver af dem giver en anden slags timeout.
For én privat database, sammenlign med viderebefordring af porte
Hvis den egentlige opgave er én godkendt forbindelse til én privat database, er en fuld netværkstunnel et valg snarere end et krav. AWS Systems Manager Session Manager kan via IAM åbne en session med portvideresendelse til en administreret node, og den node når databasen på det private netværk. Brugeren får aldrig en VPC-adresse. Den administrerede node bliver den eneste vært, der kan nå databasens port, hvilket normalt er det, sikkerhedsgennemgangen bad om. Brugere har derefter brug for en lokal klient og en sessionskommando i stedet for en VPN-profil.
Afvejningen er omfang mod forudsætninger. Viderebefordring af porte kræver SSM-agenten på den administrerede node, netværksadgang fra den node til databasen, Session Manager-pluginet på brugerens maskine og tilladelse til at starte netop den session. Det er ikke en rute ind i hvert undernet, og det bærer ikke vilkårlige protokoller, som en tunnel gør.
Behold under alle omstændigheder databasens egen identitet. TLS-verifikation og databasegodkendelse forsvinder ikke, fordi stien blev autoriseret af IAM, og en godkendt session siger intet om, hvilke tabeller brugeren må læse.
Vælg ud fra omfang og livscyklus: en tunnel, når mange brugere har brug for mange destinationer, og du kan køre certifikat- eller mappelivscyklus; en session med viderebefordring, når en håndfuld mennesker har brug for én tjeneste, og du hellere vil undgå at uddele netværksadresser. Under alle omstændigheder skal du registrere godkendelsesmetoden, autorisationsreglen og databaselogin som tre separate fakta, fordi de fejler hver for sig.