AWS Client VPN-en autentifikazioa: IAM baimenak ez dira saio-hasteko metodo bat
Kontsolaren baimenek ez dute tunel bat autentifikatzen. Konparatu ziurtagiri, AD eta SAML metodoak, eta gero ikusi noiz datorren bat SSM ataka-birbidalketa datu-base pribatu bakar baterako.
Erabiltzaile bati AWS Client VPN endpoint bat sortzeko edo deskribatzeko baimena emateak ez dio erabiltzaile horri hara konektatzeko aukerarik ematen. Identitate mota bi desberdin dira: IAMek AWS API deiak gobernatzen ditu, eta endpointak beran konfiguratuta dauden bezero-autentifikazio metodoak soilik onartzen ditu. Beraz, erabiltzaile batek kontsolako eskubide zabalak izan ditzake eta, hala ere, VPN bezeroak aurkez dezakeen ezer ez izan. Erabaki endpointak zein metodori konfiantza ematen dion, eta gero erabaki tunel osoa den zuzena ematen ari zaren sarbidearentzat.
API identitatea ez da tunel identitatea
Norbaitek «IAM rola lotuta dago, orduan zergatik egiten du VPNak huts» esaten duenean, erantzuna izan ohi da konexio-fluxuko urrats batek ere ez duela rol hori irakurtzen. Bezeroak ziurtagiri bat, AD erabiltzaile-izena eta pasahitza, edo SAML adierazpen bat aurkezten du. Endpointak horietako bat baliozkotzen du eta gero helbide bat esleitzen dio.
IAMek oraindik garrantzia du, baina geroago eta beste leku batean: endpointa sortzea, azpisareak elkartzea, ibilbideak argitaratzea eta baimen-arauak idaztea API ekintzak dira. Mantendu baimen horiek behar dituzten operadoreetara mugatuta, erabiltzaile bakoitzari endpointaren sarbide-arauak berridazteko gaitasuna eman beharrean.
Aukeratu endpointak onartzen dituen metodoen artean
AWS Client VPNek ziurtagiri bidezko elkarrekiko autentifikazioa, Active Directory autentifikazioa eta SAML bidezko autentifikazio federatua onartzen ditu. Zerbitzari-ziurtagiri bat beharrezkoa da bezero-metodo edozein aukeratuta ere, eta metodoak konbinatzen dituen konfigurazio batek biak arrakastatsuak izatea eskatzen du, bat ez.
| 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 |
Ziurtagiriak dira merkeenak martxan jartzen eta eskalan okerrena egiteko errazenak, erabiltzaile bakoitzak kredentzial bat behar duelako eta irteera bakoitzak ezeztatze bat behar duelako. Direktorio-autentifikazioak bizi-ziklo hori lehendik dagoen sistema batera eramaten du. Federazioak identitate-hornitzaile batera eramaten du eta nabigatzaile-urrats bat gehitzen dio bezeroari.
Irakurri endpointaren beraren konfigurazioa bezeroa araztu aurretik. Elkarrekiko autentifikazioa erabiltzailean oinarritutako metodo baten ondoan gaituta badago, ziurtagiri balioduna baina direktorio-konturik ez duen bezero batek huts egiten jarraituko du, eta erroreak esku-emate arazo orokor baten itxura izaten du.
Federazioa ez da sarbide-gakoak pasatzea
SAML konfigurazio batek ez du IAM sarbide-gakorik ez ustezko rol-tokenik tunelean sartzen. Identitate-hornitzaileak pertsona autentifikatzen du, adierazpen bat itzultzen du, eta endpointak konfiguratu duzun konfiantzaren arabera onartzen du. Emaitzazko saioa VPN saioa da, ez AWS API saioa.
Bereizketa horrek erabakitzen du nork zer diagnostika dezakeen. IdP arazoak nabigatzaile edo bezero erro gisa agertzen dira tunelik egon aurretik, eta tunel arazoak adierazpen arrakastatsu baten ondoren agertzen dira. Galdetu bi horietako zein ari zaren begiratzen bi kontsoletako edozein ireki aurretik.
Saioa hasi ondoren, ibilbideek eta baimenek oraindik erabakitzen dute
Autentifikazioak helbide bat ematen dio saioari; ez dio helmugarik ematen saioari. Endpointaren ibilbideek bezeroari esaten diote zein azpisareetara bidali, baimen-arauak erabakitzen dute zein erabiltzailek irits daitezkeen azpisare horietako zeinetara, eta segurtasun-taldeek eta helburuaren beraren baimenek gainerakoa erabakitzen dute.
Horregatik, behar bezala autentifikatzen den erabiltzaile batek huts egin dezake datu-base batera iristean. Egiaztatu azpisarearen ibilbide-taularen elkartzea, erabiltzailearen taldearen baimen-araua eta helburuko segurtasun-taldea ordena horretan, bakoitzak itxaronaldi mota desberdin bat sortzen duelako.
Datu-base pribatu batentzat, konparatu ataka-birbidalketarekin
Benetako zeregina datu-base pribatu bakar baterako konexio onartu bat bada, sare-tunel osoa aukera bat da, ez baldintza. AWS Systems Manager Session Managerrek IAM bidez ataka-birbidalketa saio bat ireki dezake kudeatutako nodo batera, eta nodo horrek sare pribatuko datu-basera iristen da. Erabiltzaileak ez du inoiz VPC helbiderik jasotzen. Kudeatutako nodoa datu-basearen atakara irits daitekeen ostalari bakarra bihurtzen da, eta hori izaten da segurtasun-berrikusketak eskatzen zuena. Ondoren, erabiltzaileek bezero lokal bat eta saio-komando bat behar dituzte, VPN profil bat beharrean.
Trukea irismena eta aurrebaldintzak dira. Ataka-birbidalketak SSM agentea behar du kudeatutako nodoan, nodo horretatik datu-basera sareko irisgarritasuna, Session Manager plugina erabiltzailearen makinan eta saio zehatz hori hasteko baimena. Ez da azpisare guztietarako bidea, eta ez ditu protokolo arbitrarioak eramango tunel batek bezala.
Edozein kasutan, mantendu datu-basearen beraren identitatea. TLS egiaztapena eta datu-basearen autentifikazioa ez dira desagertzen bidea IAMek baimendu duelako, eta onartutako saio batek ez du ezer esaten erabiltzaileak zein taula irakur ditzakeen.
Aukeratu irismenaren eta bizi-zikloaren arabera: tunel bat erabiltzaile askok helmuga asko behar dituztenean eta ziurtagiri edo direktorioaren bizi-zikloa kudea dezakezunean; birbidalketa saio bat pertsona gutxi batzuek zerbitzu bat behar dutenean eta sare-helbideak banatu nahi ez dituzunean. Edozein kasutan, erregistratu autentifikazio-metodoa, baimen-araua eta datu-baseko saio-hasiera hiru gertakari bereizi gisa, bereiz huts egiten dutelako.