TLS propriu, redirecționare SSH sau VPN pentru un singur serviciu cloud

Întrebarea este rareori dacă să criptați ceva între două mașini cloud; este ce interfață criptați și cine verifică identitatea cui. Încep aceste conversații de la serviciu, nu de la diagrama rețelei, pentru că serviciul știe deja de ce are nevoie. Trei limite acoperă majoritatea cazurilor: TLS-ul propriu al aplicației, un singur port TCP redirecționat prin SSH și un strat suprapus rutat care dă fiecărui participant o adresă. Nu sunt ordonate după putere, ci după cât din problemă acoperă.

Începeți cu serviciul, nu cu rețeaua

Mergeți de la proces spre exterior. Ce protocol vorbește, ce nume va verifica clientul și cine are voie să deschidă o conexiune? Aceste trei răspunsuri elimină opțiuni mai repede decât orice tabel comparativ, iar configurația proprie a serviciului le răspunde de obicei în câteva minute.

Luați un API intern mic care servește deja HTTPS pe portul 8443 cu un certificat pentru api.internal.example. ss -ltnp pe gazdă arată la ce se leagă, iar openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example arată dacă certificatul este valid pentru numele pe care clientul îl va folosi efectiv. Dacă ambele sunt sănătoase, serviciul își poate proteja propriul flux și rămâne doar accesibilitatea. Este o problemă mult mai mică decât construirea unei rețele.

Pasul 1: serviciul se protejează singur?

Aceasta este opțiunea de ales când se potrivește, și se potrivește mai des decât presupun echipele. Criptarea serviciului acoperă întreaga cale dintre client și server, inclusiv fiecare salt dintre ele, ceea ce niciun tunel în jurul mijlocului nu îmbunătățește. Configurați numele așteptat și încrederea explicit, în loc să vă bazați pe ce conține din întâmplare depozitul implicit al clientului.

Criptarea și accesibilitatea rămân controale separate, iar fuziunea lor este locul unde această opțiune greșește. Un serviciu TLS pe un ascultător public nerestricționat acceptă în continuare încercări de conectare de la oricine, așa că ascultătorul și regulile de rețea trebuie delimitate independent de faptul că încărcătura este protejată. Apoi verificați dependențele, pentru că un API peste TLS nu spune nimic despre punctul de descoperire, portul de administrare sau canalul de transfer în bloc de lângă. Fiecare are nevoie de propriul răspuns, iar un singur frate neprotejat este suficient pentru a face întreaga limită o ficțiune.

Pasul 2: un singur port TCP este întreaga cerință?

Când cerința este într-adevăr un singur port TCP, o redirecționare este cel mai mic lucru care funcționează. O redirecționare locală SSH transportă acel port printr-o conexiune autentificată care există deja.

Forma este ssh -N -L 8443:127.0.0.1:8443 [email protected], iar detaliul care contează este adresa țintă: 127.0.0.1 este rezolvată pe partea îndepărtată, așa că conexiunea la serviciu este deschisă din bastion, nu de pe laptopul dumneavoastră. Legați ascultătorul local îngust ca -L 127.0.0.1:8443:... ca să nu publicați serviciul pe propria rețea locală din greșeală. Pe partea de server, limitați ce poate contul să redirecționeze în loc să vă bazați pe comportamentul bun al clientului. PermitOpen, AllowTcpForwarding local și un GatewayPorts no implicit sunt cele trei setări care transformă un releu general într-un canal anume.

Contractul este îngust în ambele direcții. SSH își protejează propriul canal, iar un salt suplimentar de la bastion la altă aplicație are nevoie de propria protecție. Un serviciu care ascultă doar pe loopback-ul bastionului are o expunere complet diferită de unul accesat prin altă rețea, iar redirecționarea nu schimbă asta. Păstrați autentificarea și verificările TLS ale aplicației în loc să tratați tunelul ca înlocuitor al lor.

Aceasta funcționează bine pentru o conexiune cu un singur proprietar. La scară devine un sistem: conflicte de porturi locale, supraveghere, rotația cheilor și întrebarea cine repornește redirecționarea după o repornire.

Pasul 3: rutarea este cerința reală?

Acea listă este costul onest al celei mai mici opțiuni, și de aceea echipele ajung să înlocuiască o mână de comenzi de fundal uitate cu ceva administrat. Înlocuirea nu este automat un VPN. Dacă cerința este încă un singur port TCP, o redirecționare supravegheată cu un proprietar documentat este mai ieftin de operat decât un strat suprapus și eșuează în moduri pe care le vedeți. Măsurați proprietatea operațională înainte de a măsura eleganța.

Rutarea devine răspunsul corect când rutarea este cerința. Mai multe aplicații care au nevoie de conectivitate IP obișnuită, protocoale pe care o redirecționare TCP nu le poate transporta sau servicii care se mută între gazde indică toate în aceeași direcție.

Un strat suprapus dă participanților o adresă și o rută, apoi începe munca reală: intervale care nu se suprapun, proprietatea rutelor, DNS, înregistrarea, revocarea și ce se întâmplă când un partener dispare. Nimic din toate acestea nu vine cu adresa. Un partener admis în stratul suprapus nu este nici automat autorizat pentru fiecare operație la destinație, așa că autentificarea la nivel de serviciu rămâne.

Ce dețineți după aceea

Două lucruri aparțin înregistrării pe care o lăsați. Primul este identitatea pe care clientul trebuie să o verifice, pentru că fiecare dintre aceste limite se degradează în tăcere de îndată ce o verificare a numelui este relaxată pentru ca ceva să funcționeze. Al doilea este pasul de eliminare: ce cheie, ce regulă sau ce rută dispare când accesul se termină, și cine îl execută.

Parcursul se termină unde a început, la serviciu. Alegeți limita care acoperă traficul real și verifică partenerii pe care intenționați să îi verificați, apoi notați cum accesul este actualizat, monitorizat și eliminat. referința OpenSSH este locul unde confirmați opțiunile de redirecționare înainte de a promite un contract îngust. Dacă nu puteți descrie pasul de eliminare într-o singură propoziție, limita este mai mare decât problema.