Lastni TLS, posredovanje SSH ali VPN za eno storitev v oblaku

Vprašanje je redko, ali šifrirati kaj med dvema strojema v oblaku; vprašanje je, kateri vmesnik šifrirate in kdo preverja čigavo identiteto. Te pogovore začnem pri storitvi, ne pri omrežni shemi, ker storitev že ve, kaj potrebuje. Tri meje pokrivajo večino primerov: lastni TLS aplikacije, ena posredovana vrata TCP prek SSH in usmerjena nadgradnja, ki vsakemu udeležencu da naslov. Niso razvrščene po moči, ampak po tem, kolikšen del problema pokrivajo.

Začnite s storitvijo, ne z omrežjem

Pojdite od procesa navzven. Kateri protokol govori, katero ime bo preveril odjemalec in kdo sploh sme odpreti povezavo? Ti trije odgovori izločijo možnosti hitreje kot katera koli primerjalna tabela, lastna konfiguracija storitve pa jih običajno poda v nekaj minutah.

Vzemite majhen notranji API, ki že streže HTTPS na vratih 8443 s potrdilom za api.internal.example. ss -ltnp na gostitelju pokaže, na kaj se veže, openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example pa pokaže, ali je potrdilo veljavno za ime, ki ga bo odjemalec dejansko uporabil. Če sta oba zdrava, lahko storitev zaščiti svoj tok in ostane le dosegljivost. To je veliko manjši problem kot gradnja omrežja.

Korak 1: ali se storitev ščiti sama?

To je možnost, ki jo izberete, ko ustreza, in ustreza pogosteje, kot ekipe predpostavljajo. Šifriranje storitve pokriva celotno pot med odjemalcem in strežnikom, vključno z vsakim skokom vmes, česar noben tunel okoli sredine ne izboljša. Nastavite pričakovano ime in zaupanje izrecno, namesto da se zanašate na to, kar ima privzeto shramba odjemalca slučajno.

Šifriranje in dosegljivost ostaneta ločeni kontroli, in prav njuno združevanje je mesto, kjer ta možnost zgreši. Storitev TLS na neomejenem javnem poslušalcu še vedno sprejema poskuse povezave od vsakogar, zato je treba poslušalca in omrežna pravila določiti neodvisno od tega, da je tovor zaščiten. Nato preverite odvisnosti, ker API prek TLS ne pove ničesar o končni točki odkrivanja, skrbniških vratih ali kanalu za množični prenos ob njem. Vsak od njih potrebuje svoj odgovor, in en nezaščiten brat zadostuje, da celotna meja postane fikcija.

Korak 2: so ena vrata TCP celotna zahteva?

Ko je zahteva res ena vrata TCP, je posredovanje najmanjša stvar, ki deluje. Lokalno posredovanje SSH nosi ta vrata skozi že obstoječo overjeno povezavo.

Oblika je ssh -N -L 8443:127.0.0.1:8443 [email protected], pomembna podrobnost pa je ciljni naslov: 127.0.0.1 se razreši na oddaljeni strani, zato se povezava do storitve odpre z bastiona in ne z vašega prenosnika. Vežite lokalnega poslušalca ozko kot -L 127.0.0.1:8443:..., da storitve ne objavite po pomoti v svojem lokalnem omrežju. Na strežniški strani omejite, kaj sme račun posredovati, namesto da zaupate dobremu vedenju odjemalca. PermitOpen, AllowTcpForwarding local in privzeti GatewayPorts no so tri nastavitve, ki splošni rele spremenijo v določen kanal.

Pogodba je ozka v obe smeri. SSH ščiti svoj kanal, nadaljnji skok z bastiona do druge aplikacije pa potrebuje lastno zaščito. Storitev, ki posluša le na loopbacku bastiona, ima povsem drugačno izpostavljenost kot tista, dosegljiva prek drugega omrežja, in posredovanje tega ne spremeni. Ohranite overjanje in preverjanja TLS aplikacije, namesto da tunel obravnavate kot njuno nadomestilo.

To dobro deluje za eno povezavo z enim lastnikom. V večjem obsegu postane sistem: lokalna nasprotja vrat, nadzor, vrtenje ključev in vprašanje, kdo po ponovnem zagonu znova zažene posredovanje.

Korak 3: je usmerjanje resnična zahteva?

Ta seznam je poštena cena najmanjše možnosti, zato ekipe sčasoma zamenjajo peščico pozabljenih ukazov v ozadju z nečim upravljanim. Zamenjava ni samodejno VPN. Če je zahteva še vedno ena vrata TCP, je nadzorovano posredovanje z dokumentiranim lastnikom cenejše za upravljanje kot nadgradnja in odpove na načine, ki jih vidite. Izmerite operativno lastništvo, preden merite eleganco.

Usmerjanje postane pravi odgovor, ko je usmerjanje zahteva. Več aplikacij, ki potrebujejo običajno povezljivost IP, protokoli, ki jih posredovanje TCP ne more nositi, ali storitve, ki se selijo med gostitelji, kažejo v isto smer.

Nadgradnja da udeležencem naslov in pot, nato se začne resnično delo: neprekrivajoči se razponi, lastništvo poti, DNS, vpis, preklic in kaj se zgodi, ko partner izgine. Nič od tega ne pride z naslovom. Partner, sprejet v nadgradnjo, tudi ni samodejno pooblaščen za vsako operacijo na cilju, zato overjanje na ravni storitve ostane.

Kaj imate pozneje

V zapis, ki ga pustite za seboj, spadata dve stvari. Prva je identiteta, ki jo mora odjemalec preveriti, ker vsaka od teh mej tiho propada, takoj ko se preverjanje imena omili, da bi kaj delovalo. Druga je korak odstranitve: kateri ključ, katero pravilo ali katera pot izgine, ko se dostop konča, in kdo to izvede.

Sprehod se konča tam, kjer se je začel, pri storitvi. Izberite mejo, ki pokriva dejanski promet in preverja partnerje, ki ste jih nameravali preveriti, nato zapišite, kako se dostop posodablja, spremlja in odstranjuje. referenca OpenSSH je mesto, kjer pred obljubo ozke pogodbe potrdite možnosti posredovanja. Če koraka odstranitve ne morete opisati v enem stavku, je meja večja od problema.