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

Pitanje je rijetko treba li što šifrirati između dva računala u oblaku; pitanje je koje sučelje šifrirate i tko provjerava čiji identitet. Ove razgovore započinjem od usluge, a ne od mrežnog dijagrama, jer usluga već zna što joj treba. Tri granice pokrivaju većinu slučajeva: vlastiti TLS aplikacije, jedan proslijeđeni TCP port preko SSH-a i rutirano prekrivanje koje svakom sudioniku daje adresu. Nisu poredane po snazi, nego po tome koliko problema pokrivaju.

Počnite od usluge, a ne od mreže

Krenite 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 tablice usporedbe, a vlastita konfiguracija usluge obično ih daje za nekoliko minuta.

Uzmite mali interni API koji već poslužuje HTTPS na portu 8443 s certifikatom za api.internal.example. ss -ltnp na hostu pokazuje na što se veže, a openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example pokazuje vrijedi li certifikat za ime koje će klijent doista 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 kad odgovara, a odgovara češće nego što timovi pretpostavljaju. Šifriranje usluge pokriva cijeli put između klijenta i poslužitelja, uključujući svaki skok između, što nijedan tunel oko sredine ne poboljšava. Postavite očekivano ime i povjerenje izričito umjesto da se oslanjate na ono što se slučajno nalazi u zadanom spremištu klijenta.

Šifriranje i dostupnost ostaju odvojene kontrole, i upravo je njihovo spajanje mjesto gdje ova opcija pogriješi. TLS usluga na neograničenom javnom slušaču i dalje prihvaća pokušaje veze od svakoga, pa se slušač i mrežna pravila moraju odrediti neovisno od činjenice da je sadržaj zaštićen. Zatim provjerite ovisnosti, jer API preko TLS-a ne govori ništa o krajnjoj točki otkrivanja, administrativnom portu ili kanalu za masovni prijenos pokraj 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?

Kad je zahtjev doista jedan TCP port, prosljeđivanje je najmanja stvar koja radi. Lokalno SSH 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 razrješava se na udaljenoj strani, pa se veza prema usluzi otvara s bastiona, a ne s vašeg prijenosnika. 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 poslužitelja ograničite što 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 skok 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 sustav: lokalni sukobi portova, nadzor, rotacija ključeva i pitanje tko ponovno pokreće prosljeđivanje nakon restarta.

Korak 3: je li rutiranje stvarni zahtjev?

Taj popis je poštena cijena najmanje opcije, i zato timovi na kraju zamijene šaku zaboravljenih pozadinskih naredbi 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 prekrivanja i pada na načine koje vidite. Izmjerite operativno vlasništvo prije nego što mjerite eleganciju.

Rutiranje postaje pravi odgovor kad 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.

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

Što 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 kad 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.