Aŭtentigo de AWS Client VPN: permesoj de IAM ne estas ensaluta metodo
Permesoj de la konzolo ne aŭtentigas tunelon. Komparu metodojn per atestilo, AD kaj SAML, poste vidu kiam SSM-havena plusendado taŭgas por unu privata datumbazo.
Doni al uzanto permeson krei aŭ priskribi AWS Client VPN-finpunkton ne ebligas al tiu uzanto konektiĝi al ĝi. Temas pri du malsamaj specoj de identeco: IAM regas alvokojn de AWS API, kaj la finpunkto akceptas nur la klientajn aŭtentigmetodojn agorditajn sur ĝi. Uzanto do povas havi vastajn konzolajn rajtojn kaj tamen havi nenion, kion la VPN-kliento povus prezenti. Decidu, kiun metodon la finpunkto fidas, kaj poste decidu, ĉu plena tunelo estas la ĝusta formo por la aliro, kiun vi donas.
API-identeco ne estas tunela identeco
Kiam iu diras „la IAM-rolo estas alligita, kial la VPN ankoraŭ malsukcesas“, la respondo kutime estas, ke neniu paŝo en la konekta fluo iam legas tiun rolon. La kliento prezentas atestilon, AD-uzantnomon kaj pasvorton, aŭ SAML-aserton. La finpunkto validigas unu el ili kaj poste asignas adreson.
IAM ankoraŭ gravas, nur pli poste kaj aliloke: krei la finpunkton, ligi subretojn, publikigi vojojn kaj skribi rajtigajn regulojn estas API-agoj. Tenu tiujn permesojn limigitaj al la operatoroj, kiuj bezonas ilin, anstataŭ doni al ĉiu uzanto la kapablon reskribi la alirajn regulojn de la finpunkto.
Elektu el la metodoj, kiujn la finpunkto subtenas
AWS Client VPN akceptas atestilbazan reciprokan aŭtentigon, aŭtentigon per Active Directory kaj SAML-bazan federitan aŭtentigon. Servila atestilo necesas sendepende de la klienta metodo, kiun vi elektas, kaj agordo, kiu kombinas metodojn, postulas sukceson de ambaŭ, ne de unu.
| 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 |
Atestiloj estas la plej malmultekostaj starigeblaj kaj la plej facile erarigeblaj skale, ĉar ĉiu uzanto bezonas legitimilon kaj ĉiu foriro bezonas revokon. Kataloga aŭtentigo translokas tiun vivciklon al ekzistanta sistemo. Federacio translokas ĝin al identecprovizanto kaj aldonas retumilan paŝon al la kliento.
Legi la agordon de la finpunkto mem antaŭ ol sencimigi la klienton. Se reciproka aŭtentigo estas ŝaltita apud uzantbaza metodo, kliento kun valida atestilo sed sen kataloga konto ankoraŭ malsukcesos, kaj la eraro kutime aspektas kiel ĝenerala manprema problemo.
Federacio ne estas transdono de alirŝlosiloj
SAML-agordo ne enkondukas IAM-alirŝlosilojn aŭ ĵetonon de prenita rolo en la tunelon. La identecprovizanto aŭtentigas la personon, redonas aserton, kaj la finpunkto akceptas ĝin sub la fido, kiun vi agordis. La rezulta seanco estas VPN-seanco, ne AWS API-seanco.
Tiu distingo decidas, kiu povas diagnozi kion. IdP-problemoj montriĝas kiel retumila aŭ klienta eraro antaŭ ol ekzistas iu tunelo, dum tunelaj problemoj montriĝas post sukcesa aserto. Demandu, kiun el la du vi rigardas, antaŭ ol malfermi iun ajn el la du konzoloj.
Post ensaluto, vojoj kaj rajtigo ankoraŭ decidas
Aŭtentigo donas al seanco adreson; ĝi ne donas al la seanco celon. La vojoj de la finpunkto diras al la kliento, al kiuj subretoj ĝi sendu, rajtigaj reguloj decidas, kiuj uzantoj povas atingi kiujn el tiuj subretoj, kaj sekurecaj grupoj plus la propraj permesoj de la celo decidas la reston.
Tial uzanto, kiu sukcese aŭtentiĝas, ankoraŭ povas malsukcesi atingi datumbazon. Kontrolu la ligon de la vojtablo por la subreto, la rajtigan regulon por la grupo de la uzanto kaj la sekurecan grupon sur la celo en tiu ordo, ĉar ĉiu el ili produktas alian specon de tempolimo.
Por unu privata datumbazo, komparu kun havengplusendado
Se la reala tasko estas unu aprobita konekto al unu privata datumbazo, plena reta tunelo estas elekto, ne postulo. AWS Systems Manager Session Manager povas malfermi seancon de havengplusendado al administrata nodo per IAM, kaj tiu nodo atingas la datumbazon en la privata reto. La uzanto neniam ricevas VPC-adreson. La administrata nodo fariĝas la sola gastiganto, kiu povas atingi la datumbazan havenon, kio kutime estas tio, kion la sekureca revizio postulis. Uzantoj tiam bezonas lokan klienton kaj seancomandon anstataŭ VPN-profilon.
La interŝanĝo estas amplekso kontraŭ antaŭkondiĉoj. Havengplusendado bezonas la SSM-agenton sur la administrata nodo, retan atingeblon de tiu nodo al la datumbazo, la Session Manager-kromprogramon sur la maŝino de la uzanto kaj permeson komenci ĝuste tiun seancon. Ĝi ne estas vojo en ĉiun subreton, kaj ĝi ne portos arbitrajn protokolojn kiel tunelo.
En ĉiu kazo tenu la propran identecon de la datumbazo. TLS-kontrolo kaj datumbaza aŭtentigo ne malaperas ĉar la vojo estis rajtigita de IAM, kaj aprobita seanco diras nenion pri tio, kiujn tabelojn la uzanto rajtas legi.
Elektu laŭ amplekso kaj vivciklo: tunelo, kiam multaj uzantoj bezonas multajn celojn kaj vi povas administri atestilan aŭ katalogan vivciklon; plusenda seanco, kiam kelkaj homoj bezonas unu servon kaj vi preferas ne disdoni retajn adresojn. En ĉiu kazo, registru la aŭtentigmetodon, la rajtigan regulon kaj la datumbazan ensaluton kiel tri apartajn faktojn, ĉar ili malsukcesas aparte.