Izvorni TLS, SSH prosljeđivanje ili VPN za jednu cloud uslugu

Pitanje rijetko je treba li šta šifrirati između dva cloud računara; pitanje je koje sučelje šifrirate i ko provjerava čiji identitet. Ove razgovore počinjem od usluge, a ne od mrežnog dijagrama, jer usluga već zna šta joj treba. Tri granice pokrivaju većinu slučajeva: vlastiti TLS aplikacije, jedan proslijeđeni TCP port preko SSH-a i rutirana nadogradnja koja svakom učesniku daje adresu. One nisu rangirane po snazi, nego po tome koliko problema pokrivaju.

Počnite od usluge, ne od mreže

Idite od procesa prema van. Kojim protokolom govori, koje će ime klijent provjeriti i kome je uopće dopušteno otvoriti vezu? Ta tri odgovora brže isključuju opcije od bilo koje tabele poređenja, a vlastita konfiguracija usluge obično ih daje za nekoliko minuta.

Uzmite mali interni API koji već poslužuje HTTPS na portu 8443 sa certifikatom za api.internal.example. ss -ltnp na hostu pokazuje na šta se veže, a openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example pokazuje da li certifikat vrijedi za ime koje će klijent zaista koristiti. Ako je oboje zdravo, usluga može zaštititi vlastiti tok i ostaje samo dostupnost. To je mnogo manji problem od izgradnje mreže.

Korak 1: štiti li se usluga sama?

Ovo je opcija koju treba uzeti kada odgovara, a odgovara češće nego što timovi pretpostavljaju. Šifriranje usluge pokriva cijeli put između klijenta i servera, uključujući svaki hop između, što nijedan tunel oko sredine ne poboljšava. Postavite očekivano ime i povjerenje eksplicitno, umjesto da se oslanjate na ono što se slučajno nalazi u zadanom spremištu klijenta.

Šifriranje i dostupnost ostaju odvojene kontrole, i upravo njihovo spajanje je mjesto gdje ova opcija pogreši. TLS usluga na neograničenom javnom slušaču i dalje prihvata pokušaje veze od svakoga, pa se slušač i mrežna pravila moraju odrediti nezavisno od činjenice da je sadržaj zaštićen. Zatim provjerite zavisnosti, jer API preko TLS-a ne govori ništa o krajnjoj točki otkrivanja, administrativnom portu ili kanalu za masovni prijenos pored njega. Svaki od njih traži vlastiti odgovor, a jedan nezaštićeni brat dovoljan je da cijela granica postane fikcija.

Korak 2: je li jedan TCP port cijeli zahtjev?

Kada je zahtjev zaista jedan TCP port, prosljeđivanje je najmanja stvar koja radi. SSH lokalno prosljeđivanje nosi taj port kroz već postojeću autentificiranu vezu.

Oblik je ssh -N -L 8443:127.0.0.1:8443 [email protected], a detalj koji je važan je ciljna adresa: 127.0.0.1 se razrješava na udaljenoj strani, pa se veza prema usluzi otvara sa bastiona, a ne s vašeg laptopa. Vežite lokalni slušač usko kao -L 127.0.0.1:8443:... da slučajno ne objavite uslugu na vlastitoj lokalnoj mreži. Na strani servera ograničite šta račun smije prosljeđivati, umjesto da vjerujete klijentu da će se ponašati. PermitOpen, AllowTcpForwarding local i zadani GatewayPorts no tri su postavke koje opći relej pretvaraju u određeni kanal.

Ugovor je uzak u oba smjera. SSH štiti vlastiti kanal, a daljnji hop s bastiona na drugu aplikaciju treba vlastitu zaštitu. Usluga koja sluša samo na loopbacku bastiona ima sasvim drugačiju izloženost od one do koje se dolazi preko druge mreže, i prosljeđivanje to ne mijenja. Zadržite autentifikaciju i TLS provjere aplikacije umjesto da tunel tretirate kao njihovu zamjenu.

Ovo dobro radi za jednu vezu s jednim vlasnikom. U mjerilu to postaje sistem: lokalni sukobi portova, nadzor, rotacija ključeva i pitanje ko ponovno pokreće prosljeđivanje nakon restarta.

Korak 3: je li rutiranje stvarni zahtjev?

Taj spisak je poštena cijena najmanje opcije, i zato timovi na kraju zamijene šaku zaboravljenih pozadinskih komandi nečim upravljanim. Zamjena nije automatski VPN. Ako je zahtjev još uvijek jedan TCP port, nadzirano prosljeđivanje s dokumentiranim vlasnikom jeftinije je za rad od nadogradnje i pada na načine koje vidite. Izmjerite operativno vlasništvo prije nego što mjerite eleganciju.

Rutiranje postaje pravi odgovor kada je rutiranje zahtjev. Nekoliko aplikacija kojima treba obična IP povezanost, protokoli koje TCP prosljeđivanje ne može nositi, ili usluge koje se sele između hostova sve pokazuju u istom smjeru.

Nadogradnja daje učesnicima adresu i rutu, a zatim počinje pravi posao: rasponi koji se ne preklapaju, vlasništvo nad rutama, DNS, upis, opoziv i šta se događa kada partner nestane. Ništa od toga ne dolazi s adresom. Partner primljen u nadogradnju također nije automatski ovlašten za svaku operaciju na odredištu, pa autentifikacija na razini usluge ostaje.

Šta posjedujete poslije

Dvije stvari pripadaju u zapis koji ostavljate. Prva je identitet koji klijent treba provjeriti, jer svaka od ovih granica tiho degradira čim se provjera imena olabavi da bi nešto proradilo. Druga je korak uklanjanja: koji ključ, koje pravilo ili koja ruta nestaje kada pristup završi, i ko to izvodi.

Šetnja završava tamo gdje je počela, kod usluge. Odaberite granicu koja pokriva stvarni promet i provjerava partnere koje ste namjeravali provjeriti, zatim zapišite kako se pristup ažurira, nadzire i uklanja. OpenSSH referenca je mjesto gdje potvrđujete opcije prosljeđivanja prije nego što obećate uzak ugovor. Ako korak uklanjanja ne možete opisati jednom rečenicom, granica je veća od problema.