Vërtetimi në AWS Client VPN: lejet e IAM nuk janë metodë hyrjeje

T'i japësh një përdoruesi leje për të krijuar ose përshkruar një pikë fundore AWS Client VPN nuk e lejon atë të lidhet me të. Këto janë dy lloje të ndryshme identiteti: IAM drejton thirrjet e AWS API, dhe pika fundore pranon vetëm metodat e vërtetimit të klientit të konfiguruara mbi të. Prandaj një përdorues mund të ketë të drejta të gjera në konsolë dhe gjithsesi të mos ketë asgjë që klienti VPN mund të paraqesë. Vendosni se cilës metodë i beson pika fundore, pastaj vendosni nëse një tunel i plotë është forma e duhur për aksesin që po jepni.

Një identitet API nuk është identitet tuneli

Kur dikush thotë «roli IAM është bashkangjitur, pse VPN vazhdon të dështojë», përgjigjja zakonisht është se asnjë hap në rrjedhën e lidhjes nuk e lexon kurrë atë rol. Klienti paraqet një certifikatë, një emër përdoruesi dhe fjalëkalim AD, ose një pretendim SAML. Pika fundore vërteton njërën prej tyre dhe më pas cakton një adresë.

IAM vazhdon të ketë rëndësi, vetëm më vonë dhe diku tjetër: krijimi i pikës fundore, shoqërimi i nënrrjetave, publikimi i rrugëve dhe shkrimi i rregullave të autorizimit janë veprime API. Mbani ato leje të kufizuara tek operatorët që u nevojiten, në vend që t'i jepni çdo përdoruesi aftësinë për të rishkruar rregullat e aksesit të pikës fundore.

Zgjidhni nga metodat që mbështet pika fundore

AWS Client VPN pranon vërtetim reciprok të bazuar në certifikatë, vërtetim përmes Active Directory dhe vërtetim federativ të bazuar në SAML. Një certifikatë serveri kërkohet pavarësisht nga metoda e klientit që zgjidhni, dhe një konfigurim që kombinon metoda kërkon që të dyja të kenë sukses, jo njëra.

Certifikatat janë më të lirat për t'u ngritur dhe më të lehtat për t'u gabuar në shkallë të gjerë, sepse çdo përdorues ka nevojë për një kredencial dhe çdo largim kërkon një revokim. Vërtetimi me drejtori e zhvendos atë cikël jetësor në një sistem ekzistues. Federacioni e zhvendos tek një ofrues identiteti dhe i shton klientit një hap në shfletues.

Lexoni konfigurimin e vetë pikës fundore përpara se të korrigjoni klientin. Nëse vërtetimi reciprok është aktivizuar krahas një metode të bazuar në përdorues, një klient me certifikatë të vlefshme por pa llogari drejtorie do të dështojë gjithsesi, dhe gabimi zakonisht duket si një problem i përgjithshëm shtrëngimi duarsh.

Federacioni nuk është kalimi i çelësave të aksesit

Një konfigurim SAML nuk fut çelësa aksesi IAM ose një token roli të supozuar në tunel. Ofruesi i identitetit vërteton personin, kthen një pretendim, dhe pika fundore e pranon atë nën besimin që keni konfiguruar. Sesioni që rezulton është një sesion VPN, jo një sesion AWS API.

Ky dallim përcakton se kush mund të diagnostikojë çfarë. Problemet e IdP shfaqen si gabim shfletuesi ose klienti përpara se të ekzistojë ndonjë tunel, ndërsa problemet e tunelit shfaqen pas një pretendimi të suksesshëm. Pyetni se cilin nga të dy po shikoni përpara se të hapni ndonjë nga konsolat.

Pas hyrjes, rrugët dhe autorizimi vazhdojnë të vendosin

Vërtetimi i jep një sesioni një adresë; nuk i jep sesionit një destinacion. Rrugët e pikës fundore i thonë klientit në cilat nënrrjeta të dërgojë, rregullat e autorizimit vendosin se cilët përdorues mund të arrijnë në cilat nga ato nënrrjeta, dhe grupet e sigurisë plus lejet e vetë objektivit vendosin pjesën tjetër.

Kjo është arsyeja pse një përdorues që vërtetohet me sukses mund të dështojë gjithsesi të arrijë një bazë të dhënash. Kontrolloni shoqërimin e tabelës së rrugëve për nënrrjetin, rregullin e autorizimit për grupin e përdoruesit dhe grupin e sigurisë në objektiv në atë rend, sepse secili prodhon një lloj tjetër skadimi.

Për një bazë të dhënash private, krahasoni me përcjelljen e portës

Nëse detyra e vërtetë është një lidhje e miratuar me një bazë të dhënash private, një tunel i plotë rrjeti është zgjedhje dhe jo kërkesë. AWS Systems Manager Session Manager mund të hapë një sesion përcjelljeje porte drejt një nyje të menaxhuar përmes IAM, dhe ajo nyje arrin bazën e të dhënave në rrjetin privat. Përdoruesi nuk merr kurrë një adresë VPC. Nyja e menaxhuar bëhet i vetmi host që mund të arrijë portën e bazës së të dhënave, dhe zakonisht kjo është ajo që kërkonte rishikimi i sigurisë. Përdoruesve u duhet atëherë një klient lokal dhe një komandë sesioni në vend të një profili VPN.

Shkëmbimi është shtrirje kundrejt parakushteve. Përcjellja e portës kërkon agjentin SSM në nyjen e menaxhuar, arritshmëri rrjeti nga ajo nyje deri te baza e të dhënave, shtojcën Session Manager në makinën e përdoruesit dhe leje për të nisur pikërisht atë sesion. Nuk është një rrugë në çdo nënrrjet, dhe nuk mbart protokolle arbitrare siç bën një tunel.

Në çdo rast mbani identitetin e vetë bazës së të dhënave në vendin e tij. Verifikimi TLS dhe vërtetimi i bazës së të dhënave nuk zhduken sepse rruga u autorizua nga IAM, dhe një sesion i miratuar nuk thotë asgjë për tabelat që përdoruesi mund të lexojë.

Zgjidhni sipas shtrirjes dhe ciklit jetësor: një tunel kur shumë përdorues kanë nevojë për shumë destinacione dhe mund të drejtoni ciklin jetësor të certifikatave ose të drejtorisë; një sesion përcjelljeje kur disa njerëz kanë nevojë për një shërbim të vetëm dhe preferoni të mos shpërndani adresa rrjeti. Në çdo rast, regjistroni metodën e vërtetimit, rregullin e autorizimit dhe hyrjen në bazën e të dhënave si tre fakte të veçanta, sepse dështojnë veçmas.