Preverjanje pristnosti v AWS Client VPN: dovoljenja IAM niso način prijave
Dovoljenja v konzoli ne overjajo tunela. Primerjajte metode s potrdilom, AD in SAML, nato pa poglejte, kdaj preusmerjanje vrat prek SSM ustreza eni zasebni podatkovni bazi.
Če uporabniku dovolite ustvariti ali opisati končno točko AWS Client VPN, to še ne pomeni, da se lahko z njo poveže. Gre za dve različni vrsti identitete: IAM upravlja klice AWS API, končna točka pa sprejema le na njej nastavljene načine preverjanja pristnosti odjemalca. Uporabnik ima lahko torej široke pravice v konzoli in hkrati nima ničesar, kar bi odjemalec VPN lahko predložil. Odločite se, kateri metodi končna točka zaupa, nato pa se odločite, ali je polni tunel prava oblika za dostop, ki ga dajete.
Identiteta API ni identiteta tunela
Ko nekdo reče „vloga IAM je pritrjena, zakaj VPN še vedno ne deluje“, je odgovor običajno ta, da noben korak v toku povezave te vloge nikoli ne prebere. Odjemalec predloži potrdilo, uporabniško ime in geslo AD ali trditev SAML. Končna točka preveri eno od tega in nato dodeli naslov.
IAM je še vedno pomemben, le pozneje in drugje: ustvarjanje končne točke, povezovanje podomrežij, objavljanje poti in pisanje pravil avtorizacije so dejanja API. Te pravice omejite na operaterje, ki jih potrebujejo, namesto da bi vsakemu uporabniku dali možnost prepisati pravila dostopa končne točke.
Izberite med metodami, ki jih končna točka podpira
AWS Client VPN sprejema medsebojno preverjanje pristnosti s potrdilom, preverjanje pristnosti Active Directory in federirano preverjanje pristnosti na podlagi SAML. Potrdilo strežnika je potrebno ne glede na izbrano metodo odjemalca, konfiguracija, ki združuje metode, pa zahteva uspeh obeh, ne ene.
| 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 |
Potrdila so najcenejša za vzpostavitev in najlažje jih je v velikem obsegu zgrešiti, ker vsak uporabnik potrebuje poverilnico in vsak odhod zahteva preklic. Preverjanje pristnosti prek imenika premakne ta življenjski cikel v obstoječi sistem. Federacija ga premakne k ponudniku identitete in odjemalcu doda korak v brskalniku.
Pred razhroščevanjem odjemalca preberite konfiguracijo same končne točke. Če je medsebojno preverjanje pristnosti omogočeno ob metodi, ki temelji na uporabniku, bo odjemalec z veljavnim potrdilom, a brez računa v imeniku, še vedno propadel, napaka pa je običajno videti kot splošen problem rokovanja.
Federacija ni posredovanje ključev za dostop
Nastavitev SAML v tunel ne vstavi ključev za dostop IAM ali žetona prevzete vloge. Ponudnik identitete overi osebo, vrne trditev, končna točka pa jo sprejme v okviru zaupanja, ki ste ga nastavili. Nastala seja je seja VPN, ne seja AWS API.
Ta razlika določa, kdo lahko kaj diagnosticira. Težave z IdP se pokažejo kot napaka brskalnika ali odjemalca, še preden obstaja kak tunel, težave s tunelom pa po uspešni trditvi. Vprašajte, katero od tega gledate, preden odprete katero koli konzolo.
Po prijavi še vedno odločajo poti in avtorizacija
Preverjanje pristnosti seji dodeli naslov; seji ne dodeli cilja. Poti končne točke povedo odjemalcu, v katera podomrežja naj pošilja, pravila avtorizacije odločajo, kateri uporabniki lahko dosežejo katera od teh podomrežij, o ostalem pa odločajo varnostne skupine in lastna dovoljenja cilja.
Zato uporabnik, ki se uspešno overi, še vedno morda ne doseže podatkovne baze. Preverite povezavo tabele usmerjanja s podomrežjem, pravilo avtorizacije za uporabnikovo skupino in varnostno skupino na cilju v tem vrstnem redu, ker vsako od njih ustvari drugačno vrsto poteka časa.
Za eno zasebno podatkovno bazo primerjajte s preusmerjanjem vrat
Če je resnična naloga ena odobrena povezava do ene zasebne podatkovne baze, je polni omrežni tunel izbira in ne zahteva. AWS Systems Manager Session Manager lahko prek IAM odpre sejo preusmerjanja vrat do upravljanega vozlišča in to vozlišče doseže podatkovno bazo v zasebnem omrežju. Uporabnik nikoli ne prejme naslova VPC. Upravljano vozlišče postane edini gostitelj, ki lahko doseže vrata podatkovne baze, in to je običajno tisto, kar je zahteval varnostni pregled. Uporabniki nato potrebujejo lokalnega odjemalca in ukaz seje namesto profila VPN.
Kompromis je obseg proti predpogojem. Preusmerjanje vrat zahteva agenta SSM na upravljanem vozlišču, omrežno dosegljivost od tega vozlišča do podatkovne baze, vtičnik Session Manager na uporabnikovem računalniku in dovoljenje za zagon prav te seje. To ni pot v vsako podomrežje in ne prenaša poljubnih protokolov tako kot tunel.
V vsakem primeru ohranite lastno identiteto podatkovne baze. Preverjanje TLS in preverjanje pristnosti podatkovne baze ne izgineta zato, ker je pot avtoriziral IAM, odobrena seja pa ne pove ničesar o tem, katere tabele lahko uporabnik bere.
Izberite glede na obseg in življenjski cikel: tunel, ko veliko uporabnikov potrebuje veliko ciljev in lahko vodite življenjski cikel potrdil ali imenika; sejo preusmerjanja, ko nekaj ljudi potrebuje eno storitev in raje ne bi delili omrežnih naslovov. V vsakem primeru zabeležite metodo preverjanja pristnosti, pravilo avtorizacije in prijavo v podatkovno bazo kot tri ločena dejstva, ker propadejo ločeno.