AWS Client VPN-verifikasie: IAM-toestemmings is nie ’n aanmeldmetode nie
Konsoltoestemmings verifieer nie ’n tonnel nie. Vergelyk sertifikaat-, AD- en SAML-metodes, en kyk dan wanneer SSM-poortaanstuur by een private databasis pas.
Om ’n gebruiker toestemming te gee om ’n AWS Client VPN-eindpunt te skep of te beskryf, laat daardie gebruiker nie toe om daaraan te koppel nie. Dit is twee verskillende soorte identiteit: IAM beheer AWS API-oproepe, en die eindpunt aanvaar net die kliëntverifikasiemetodes wat daarop ingestel is. ’n Gebruiker kan dus wye konsolregte hê en steeds niks hê wat die VPN-kliënt kan voorlê nie. Besluit watter metode die eindpunt vertrou, en besluit dan of ’n volle tonnel die regte vorm is vir die toegang wat jy gee.
’n API-identiteit is nie ’n tonnelidentiteit nie
Wanneer iemand sê “die IAM-rol is geheg, hoekom faal die VPN steeds”, is die antwoord gewoonlik dat geen stap in die verbindingsvloei ooit daardie rol lees nie. Die kliënt lê ’n sertifikaat, ’n AD-gebruikersnaam en -wagwoord, of ’n SAML-bewering voor. Die eindpunt valideer een daarvan en wys dan ’n adres toe.
IAM maak steeds saak, net later en elders: om die eindpunt te skep, subnetwerke te assosieer, roetes te publiseer en magtigingsreëls te skryf, is API-aksies. Hou daardie toestemmings beperk tot die operateurs wat dit nodig het, in plaas daarvan om elke gebruiker die vermoë te gee om die eindpunt se toegangsreëls te herskryf.
Kies uit die metodes wat die eindpunt ondersteun
AWS Client VPN aanvaar sertifikaatgebaseerde wedersydse verifikasie, Active Directory-verifikasie en SAML-gebaseerde gefedereerde verifikasie. ’n Bediener-sertifikaat is nodig maak nie saak watter kliëntmetode jy kies nie, en ’n konfigurasie wat metodes kombineer, vereis dat albei moet slaag, nie een nie.
| 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 |
Sertifikate is die goedkoopste om op te stel en die maklikste om op skaal verkeerd te kry, want elke gebruiker het ’n geloofsbrief nodig en elke vertrek vereis ’n intrekking. Gidsverifikasie skuif daardie lewensiklus na ’n bestaande stelsel. Federasie skuif dit na ’n identiteitsverskaffer en voeg ’n blaaierstap by die kliënt.
Lees die eindpunt se eie konfigurasie voordat jy die kliënt ontfout. As wedersydse verifikasie saam met ’n gebruikergebaseerde metode geaktiveer is, sal ’n kliënt met ’n geldige sertifikaat maar geen gidsrekening steeds misluk, en die fout lyk gewoonlik soos ’n generiese handskudprobleem.
Federasie is nie die deurgee van toegangsleutels nie
’n SAML-opstelling voer nie IAM-toegangsleutels of ’n aangenome-rol-token in die tonnel in nie. Die identiteitsverskaffer verifieer die persoon, gee ’n bewering terug, en die eindpunt aanvaar dit onder die vertroue wat jy opgestel het. Die sessie wat daaruit volg, is ’n VPN-sessie, nie ’n AWS API-sessie nie.
Daardie onderskeid bepaal wie wat kan oplos. IdP-probleme wys as ’n blaaier- of kliëntfout voordat enige tonnel bestaan, terwyl tonnelprobleme ná ’n suksesvolle bewering wys. Vra watter van die twee jy voor jou het voordat jy enige konsol oopmaak.
Ná aanmelding besluit roetes en magtiging steeds
Verifikasie gee ’n sessie ’n adres; dit gee die sessie nie ’n bestemming nie. Eindpuntroetes sê vir die kliënt watter subnetwerke om na te stuur, magtigingsreëls besluit watter gebruikers watter van daardie subnetwerke mag bereik, en sekuriteitsgroepe plus die teiken se eie toestemmings besluit die res.
Dit is hoekom ’n gebruiker wat suksesvol verifieer steeds kan misluk om ’n databasis te bereik. Kontroleer die roetetabel-assosiasie vir die subnet, die magtigingsreël vir die gebruiker se groep en die sekuriteitsgroep op die teiken in daardie volgorde, want elkeen lewer ’n ander soort tydsverloop.
Vir een private databasis, vergelyk met poortaanstuur
As die werklike taak een goedgekeurde verbinding na een private databasis is, is ’n volledige netwerktonnel ’n keuse eerder as ’n vereiste. AWS Systems Manager Session Manager kan ’n poortaanstur-sessie na ’n bestuurde node deur IAM oopmaak, en daardie node bereik die databasis op die private netwerk. Die gebruiker kry nooit ’n VPC-adres nie. Die bestuurde node word die enigste gasheer wat die databasispoort kan bereik, wat gewoonlik is wat die sekuriteitsoudit gevra het. Gebruikers het dan ’n plaaslike kliënt en ’n sessieopdrag nodig eerder as ’n VPN-profiel.
Die ruil is omvang teenoor voorvereistes. Poortaanstuur benodig die SSM-agent op die bestuurde node, netwerkbereikbaarheid van daardie node na die databasis, die Session Manager-inprop op die gebruiker se masjien en toestemming om daardie spesifieke sessie te begin. Dit is nie ’n roete in elke subnet nie, en dit sal nie arbitrêre protokolle dra soos ’n tonnel nie.
Hou die databasis se eie identiteit in elk geval in plek. TLS-verifikasie en databasisverifikasie verdwyn nie omdat die pad deur IAM gemagtig is nie, en ’n goedgekeurde sessie sê niks oor watter tabelle die gebruiker mag lees nie.
Kies op grond van omvang en lewensiklus: ’n tonnel wanneer baie gebruikers baie bestemmings nodig het en jy sertifikaat- of gidslewensiklus kan bestuur, ’n aanstursessie wanneer ’n handjievol mense een diens nodig het en jy liewer nie netwerkadresse uitdeel nie. Noteer in elk geval die verifikasiemetode, die magtigingsreël en die databasis-aanmelding as drie afsonderlike feite, want hulle faal afsonderlik.