Autentificare în AWS Client VPN: permisiunile IAM nu sunt o metodă de conectare
Permisiunile din consolă nu autentifică un tunel. Comparați metodele cu certificat, AD și SAML, apoi vedeți când redirecționarea porturilor prin SSM se potrivește pentru o singură bază de date privată.
A acorda unui utilizator permisiunea de a crea sau de a descrie un endpoint AWS Client VPN nu îi permite să se conecteze la acesta. Sunt două tipuri diferite de identitate: IAM guvernează apelurile AWS API, iar endpointul acceptă doar metodele de autentificare a clientului configurate pe el. Prin urmare, un utilizator poate avea drepturi largi în consolă și totuși să nu aibă nimic ce clientul VPN poate prezenta. Decideți în ce metodă are încredere endpointul, apoi decideți dacă un tunel complet este forma potrivită pentru accesul pe care îl acordați.
O identitate API nu este o identitate de tunel
Când cineva spune „rolul IAM este atașat, de ce eșuează totuși VPN-ul”, răspunsul este de obicei că niciun pas din fluxul de conectare nu citește vreodată acel rol. Clientul prezintă un certificat, un nume de utilizator și o parolă AD, sau o aserțiune SAML. Endpointul validează una dintre ele și apoi atribuie o adresă.
IAM contează în continuare, doar mai târziu și în altă parte: crearea endpointului, asocierea subrețelelor, publicarea rutelor și scrierea regulilor de autorizare sunt acțiuni API. Păstrați aceste permisiuni limitate la operatorii care le necesită, în loc să dați fiecărui utilizator posibilitatea de a rescrie regulile de acces ale endpointului.
Alegeți dintre metodele pe care le acceptă endpointul
AWS Client VPN acceptă autentificare mutuală bazată pe certificat, autentificare Active Directory și autentificare federată bazată pe SAML. Un certificat de server este necesar indiferent de metoda de client aleasă, iar o configurație care combină metode cere succesul ambelor, nu al uneia.
| 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 |
Certificatele sunt cele mai ieftine de instalat și cele mai ușor de greșit la scară, pentru că fiecare utilizator are nevoie de o acreditare și fiecare plecare necesită o revocare. Autentificarea prin director mută acel ciclu de viață într-un sistem existent. Federația îl mută la un furnizor de identitate și adaugă un pas de browser la client.
Citiți configurația endpointului însuși înainte de a depana clientul. Dacă autentificarea mutuală este activată alături de o metodă bazată pe utilizator, un client cu certificat valid dar fără cont de director va eșua în continuare, iar eroarea arată de obicei ca o problemă generică de handshake.
Federația nu este transmiterea cheilor de acces
O configurație SAML nu introduce chei de acces IAM sau un token de rol asumat în tunel. Furnizorul de identitate autentifică persoana, returnează o aserțiune, iar endpointul o acceptă în cadrul încrederii pe care ați configurat-o. Sesiunea rezultată este o sesiune VPN, nu o sesiune AWS API.
Această distincție decide cine poate diagnostica ce. Problemele IdP apar ca o eroare de browser sau de client înainte de a exista vreun tunel, în timp ce problemele de tunel apar după o aserțiune reușită. Întrebați care dintre cele două este în fața dumneavoastră înainte de a deschide oricare dintre console.
După conectare, rutele și autorizarea decid în continuare
Autentificarea oferă sesiunii o adresă; nu îi oferă sesiunii o destinație. Rutele endpointului spun clientului către ce subrețele să trimită, regulile de autorizare decid ce utilizatori pot ajunge la care dintre acele subrețele, iar grupurile de securitate plus permisiunile țintei decid restul.
De aceea un utilizator care se autentifică cu succes poate totuși să nu ajungă la o bază de date. Verificați asocierea tabelului de rute pentru subrețea, regula de autorizare pentru grupul utilizatorului și grupul de securitate de pe țintă în această ordine, pentru că fiecare produce un alt tip de expirare.
Pentru o singură bază de date privată, comparați cu redirecționarea porturilor
Dacă sarcina reală este o singură conexiune aprobată la o singură bază de date privată, un tunel de rețea complet este o alegere și nu o cerință. AWS Systems Manager Session Manager poate deschide prin IAM o sesiune de redirecționare a portului către un nod administrat, iar acel nod ajunge la baza de date din rețeaua privată. Utilizatorul nu primește niciodată o adresă VPC. Nodul administrat devine singurul gazdă care poate ajunge la portul bazei de date, ceea ce este de obicei exact ce a cerut revizuirea de securitate. Utilizatorii au nevoie atunci de un client local și de o comandă de sesiune în locul unui profil VPN.
Compromisul este amploare contra prerechizite. Redirecționarea porturilor necesită agentul SSM pe nodul administrat, accesibilitate de rețea de la acel nod la baza de date, pluginul Session Manager pe mașina utilizatorului și permisiunea de a porni exact acea sesiune. Nu este o rută către fiecare subrețea și nu transportă protocoale arbitrare așa cum face un tunel.
În orice caz, păstrați identitatea proprie a bazei de date. Verificarea TLS și autentificarea bazei de date nu dispar pentru că traseul a fost autorizat de IAM, iar o sesiune aprobată nu spune nimic despre ce tabele poate citi utilizatorul.
Alegeți după amploare și ciclu de viață: un tunel când mulți utilizatori au nevoie de multe destinații și puteți opera ciclul de viață al certificatelor sau al directorului; o sesiune de redirecționare când câțiva oameni au nevoie de un singur serviciu și preferați să nu distribuiți adrese de rețea. În orice caz, înregistrați metoda de autentificare, regula de autorizare și conectarea la baza de date ca trei fapte separate, pentru că eșuează separat.