AWS Client VPN autentifikavimas: IAM leidimai nėra prisijungimo būdas
Konsolės leidimai neautentifikuoja tunelio. Palyginkite sertifikato, AD ir SAML metodus, tada pažiūrėkite, kada SSM prievado peradresavimas tinka vienai privačiai duomenų bazei.
Suteikus naudotojui leidimą kurti ar aprašyti AWS Client VPN galinį tašką, jis dar negauna galimybės prie jo prisijungti. Tai du skirtingi tapatybės tipai: IAM valdo AWS API iškvietimus, o galinis taškas priima tik jame sukonfigūruotus kliento autentifikavimo metodus. Taigi naudotojas gali turėti plačias konsolės teises ir vis tiek neturėti nieko, ką VPN klientas galėtų pateikti. Nuspręskite, kuriuo metodu pasitiki galinis taškas, o tada nuspręskite, ar pilnas tunelis yra tinkama forma suteikiamai prieigai.
API tapatybė nėra tunelio tapatybė
Kai kas nors sako „IAM vaidmuo pridėtas, kodėl VPN vis tiek nepavyksta“, atsakymas paprastai būna toks, kad nė vienas prisijungimo eigos žingsnis niekada neskaito to vaidmens. Klientas pateikia sertifikatą, AD naudotojo vardą ir slaptažodį arba SAML teiginį. Galinis taškas patikrina vieną iš jų ir tada priskiria adresą.
IAM vis dar svarbus, tik vėliau ir kitur: galinio taško kūrimas, potinklių susiejimas, maršrutų skelbimas ir autorizacijos taisyklių rašymas yra API veiksmai. Laikykite šiuos leidimus apribotus operatoriams, kuriems jų reikia, o ne suteikite kiekvienam naudotojui galimybę perrašyti galinio taško prieigos taisykles.
Rinkitės iš metodų, kuriuos palaiko galinis taškas
AWS Client VPN priima sertifikatu pagrįstą abipusę autentifikaciją, Active Directory autentifikaciją ir SAML pagrįstą federuotą autentifikaciją. Serverio sertifikatas reikalingas nepriklausomai nuo pasirinkto kliento metodo, o konfigūracija, kuri derina metodus, reikalauja, kad pavyktų abu, o ne vienas.
| 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 |
Sertifikatai pigiausiai įdiegiami ir lengviausiai supainiojami dideliu mastu, nes kiekvienam naudotojui reikia kredencialo, o kiekvienam išėjimui reikia atšaukimo. Katalogo autentifikacija perkelia tą gyvavimo ciklą į esamą sistemą. Federacija perkelia jį pas tapatybės teikėją ir prideda naršyklės žingsnį klientui.
Perskaitykite paties galinio taško konfigūraciją prieš derindami klientą. Jei abipusė autentifikacija įjungta kartu su naudotoju pagrįstu metodu, klientas su galiojančiu sertifikatu, bet be katalogo paskyros vis tiek nepavyks, o klaida paprastai atrodo kaip bendra rankos paspaudimo problema.
Federacija nėra prieigos raktų perdavimas
SAML sąranka neįleidžia į tunelį IAM prieigos raktų ar prisiimto vaidmens žetono. Tapatybės teikėjas autentifikuoja asmenį, grąžina teiginį, o galinis taškas jį priima pagal jūsų sukonfigūruotą pasitikėjimą. Gauta sesija yra VPN sesija, o ne AWS API sesija.
Šis skirtumas lemia, kas ką gali diagnozuoti. IdP problemos pasirodo kaip naršyklės ar kliento klaida dar prieš atsirandant bet kokiam tuneliui, o tunelio problemos pasirodo po sėkmingo teiginio. Paklauskite, kurią iš šių dviejų matote, prieš atidarydami bet kurią konsolę.
Prisijungus maršrutai ir autorizacija vis tiek sprendžia
Autentifikacija suteikia sesijai adresą; ji nesuteikia sesijai tikslo. Galinio taško maršrutai pasako klientui, į kuriuos potinklius siųsti, autorizacijos taisyklės nusprendžia, kurie naudotojai gali pasiekti kuriuos iš tų potinklių, o saugos grupės ir paties taikinio leidimai nusprendžia likusią dalį.
Štai kodėl naudotojas, kuris sėkmingai autentifikuojasi, vis tiek gali nepasiekti duomenų bazės. Patikrinkite potinklio maršrutų lentelės susiejimą, naudotojo grupės autorizacijos taisyklę ir taikinio saugos grupę šia tvarka, nes kiekviena jų sukuria kitokio tipo skirtąjį laiką.
Vienai privačiai duomenų bazei palyginkite su prievado peradresavimu
Jei tikroji užduotis yra vienas patvirtintas ryšys su viena privačia duomenų baze, pilnas tinklo tunelis yra pasirinkimas, o ne reikalavimas. AWS Systems Manager Session Manager gali per IAM atidaryti prievado peradresavimo sesiją į valdomą mazgą, ir tas mazgas pasiekia duomenų bazę privačiame tinkle. Naudotojas niekada negauna VPC adreso. Valdomas mazgas tampa vieninteliu hostu, galinčiu pasiekti duomenų bazės prievadą, ir paprastai tai ir buvo tai, ko prašė saugos peržiūra. Tada naudotojams reikia vietinio kliento ir sesijos komandos, o ne VPN profilio.
Mainai yra apimtis prieš prielaidas. Prievado peradresavimui reikia SSM agento valdomame mazge, tinklo pasiekiamumo iš to mazgo į duomenų bazę, Session Manager papildinio naudotojo kompiuteryje ir leidimo paleisti būtent tą sesiją. Tai ne kelias į kiekvieną potinklį ir neperduoda savavališkų protokolų taip, kaip tunelis.
Bet kuriuo atveju palikite pačios duomenų bazės tapatybę savo vietoje. TLS tikrinimas ir duomenų bazės autentifikavimas neišnyksta todėl, kad kelią autorizavo IAM, o patvirtinta sesija nieko nesako apie tai, kurias lenteles naudotojas gali skaityti.
Rinkitės pagal apimtį ir gyvavimo ciklą: tunelį, kai daug naudotojų reikia daug tikslų ir galite valdyti sertifikatų ar katalogo gyvavimo ciklą; peradresavimo sesiją, kai keliems žmonėms reikia vienos paslaugos ir norite nedalinti tinklo adresų. Bet kuriuo atveju užregistruokite autentifikavimo metodą, autorizacijos taisyklę ir prisijungimą prie duomenų bazės kaip tris atskirus faktus, nes jie nepavyksta atskirai.