TLS vendas, përcjellje SSH ose VPN për një shërbim cloud

Pyetja rrallë është nëse duhet kriptuar diçka mes dy makinave cloud; është cilën ndërfaqe kriptoni dhe kush verifikon identitetin e kujt. I filloj këto biseda nga shërbimi dhe jo nga diagrami i rrjetit, sepse shërbimi tashmë e di çfarë i nevojitet. Tre kufij mbulojnë shumicën e rasteve: TLS i vetë aplikacionit, një portë TCP e përcjellë përmes SSH dhe një shtresë e rrugëtuar që i jep secilit pjesëmarrës një adresë. Nuk renditen sipas forcës, por sipas asaj se sa nga problemi mbulojnë.

Filloni me shërbimin, jo me rrjetin

Shkoni nga procesi jashtë. Çfarë protokolli flet, çfarë emri do të verifikojë klienti dhe kush lejohet të hapë një lidhje? Këto tre përgjigje i eliminojnë opsionet më shpejt se çdo tabelë krahasimi, dhe konfigurimi i vetë shërbimit zakonisht u përgjigjet në pak minuta.

Merrni një API të brendshme të vogël që tashmë shërben HTTPS në portën 8443 me një certifikatë për api.internal.example. ss -ltnp në host tregon se me çfarë lidhet, dhe openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example tregon nëse certifikata është e vlefshme për emrin që klienti do të përdorë vërtet. Nëse të dyja janë të shëndetshme, shërbimi mund të mbrojë rrjedhën e vet dhe mbetet vetëm arritshmëria. Ky është një problem shumë më i vogël sesa ndërtimi i një rrjeti.

Hapi 1: a e mbron shërbimi veten?

Ky është opsioni që merret kur përshtatet, dhe përshtatet më shpesh sesa supozojnë ekipet. Kriptimi i shërbimit mbulon të gjithë rrugën mes klientit dhe serverit, duke përfshirë çdo kërcim në mes, të cilin asnjë tunel rreth mesit nuk e përmirëson. Vendosni emrin e pritur dhe besimin në mënyrë eksplicite në vend që të mbështeteni në atë që përmban rastësisht depoja e paracaktuar e klientit.

Kriptimi dhe arritshmëria mbeten kontrolle të veçanta, dhe pikërisht bashkimi i tyre është vendi ku ky opsion gabon. Një shërbim TLS në një dëgjues publik të pakufizuar ende pranon përpjekje lidhjeje nga kushdo, prandaj dëgjuesi dhe rregullat e rrjetit duhet të përcaktohen pavarësisht nga fakti që ngarkesa është e mbrojtur. Më pas kontrolloni varësitë, sepse një API mbi TLS nuk thotë asgjë për pikën e zbulimit, portën e administratorit ose kanalin e transferimit masiv pranë tij. Secili prej tyre ka nevojë për përgjigjen e vet, dhe një vëlla i pambrojtur mjafton për ta kthyer të gjithë kufirin në trillim.

Hapi 2: a është një portë TCP e gjithë kërkesa?

Kur kërkesa është vërtet një portë TCP, përcjellja është gjëja më e vogël që funksionon. Një përcjellje lokale SSH e transporton atë portë përmes një lidhjeje tashmë ekzistuese të vërtetuar.

Forma është ssh -N -L 8443:127.0.0.1:8443 [email protected], dhe detaji që ka rëndësi është adresa e synimit: 127.0.0.1 zgjidhet në anën e largët, prandaj lidhja me shërbimin hapet nga bastioni dhe jo nga laptopi juaj. Lidhni dëgjuesin lokal ngushtë si -L 127.0.0.1:8443:... që të mos e publikoni shërbimin aksidentalisht në rrjetin tuaj lokal. Në anën e serverit, kufizoni çfarë llogaria mund të përcjellë në vend që të besoni sjelljen e mirë të klientit. PermitOpen, AllowTcpForwarding local dhe GatewayPorts no i paracaktuar janë tre cilësimet që e kthejnë një rele të përgjithshme në një kanal të caktuar.

Kontrata është e ngushtë në të dy drejtimet. SSH mbron kanalin e vet, dhe një kërcim i mëtejshëm nga bastioni në një aplikacion tjetër kërkon mbrojtjen e vet. Një shërbim që dëgjon vetëm në loopback-un e bastionit ka një ekspozim krejt të ndryshëm nga ai që arrihet përmes një rrjeti tjetër, dhe përcjellja nuk e ndryshon këtë. Mbani vërtetimin dhe kontrollet TLS të aplikacionit në vend të trajtimit të tunelit si zëvendësuesin e tyre.

Kjo funksionon mirë për një lidhje me një pronar. Në shkallë të gjerë bëhet një sistem: konflikte portash lokale, mbikëqyrje, rrotullim çelësash dhe pyetja se kush e rinis përcjelljen pas një rinisjeje.

Hapi 3: a është rrugëtimi kërkesa e vërtetë?

Ai listë është kostoja e ndershme e opsionit më të vogël, dhe për këtë arsye ekipet përfundimisht zëvendësojnë një grusht komandash të harruara në sfond me diçka të menaxhuar. Zëvendësimi nuk është automatikisht një VPN. Nëse kërkesa është ende një portë TCP, një përcjellje e mbikëqyrur me pronar të dokumentuar është më e lirë për t'u operuar sesa një shtresë dhe dështon në mënyra që mund t'i shihni. Matni pronësinë operacionale përpara se të matni elegancën.

Rrugëtimi bëhet përgjigja e duhur kur rrugëtimi është kërkesa. Disa aplikacione që kanë nevojë për lidhshmëri IP të zakonshme, protokolle që një përcjellje TCP nuk mund t'i mbajë, ose shërbime që lëvizin mes hostesh tregojnë të gjitha në të njëjtin drejtim.

Një shtresë u jep pjesëmarrësve një adresë dhe një rrugë, dhe pastaj fillon puna e vërtetë: intervalet që nuk mbivendosen, pronësia e rrugëve, DNS, regjistrimi, revokimi dhe çfarë ndodh kur një palë zhduket. Asgjë nga kjo nuk vjen me adresën. Një palë e pranuar në shtresë gjithashtu nuk është automatikisht e autorizuar për çdo operacion në destinacion, prandaj vërtetimi në nivel shërbimi mbetet.

Çfarë zotëroni më pas

Dy gjëra i përkasin regjistrit që lini pas. E para është identiteti që klienti pritet të verifikojë, sepse secili prej këtyre kufijve përkeqësohet në heshtje sapo një kontroll emri lehtësohet për të bërë diçka të funksionojë. E dyta është hapi i heqjes: cili çelës, cili rregull ose cila rrugë zhduket kur aksesi përfundon, dhe kush e kryen atë.

Shëtitja përfundon aty ku filloi, te shërbimi. Zgjidhni kufirin që mbulon trafikun aktual dhe verifikon palët që kishit ndërmend të verifikoni, më pas shkruani si përditësohet, monitorohet dhe hiqet aksesi. referenca OpenSSH është vendi për të konfirmuar opsionet e përcjelljes përpara se të premtoni një kontratë të ngushtë. Nëse nuk mund ta përshkruani hapin e heqjes në një fjali, kufiri është më i madh se problemi.