Vlastný TLS, SSH presmerovanie alebo VPN pre jednu cloudovú službu

Otázka málokedy je, či medzi dvoma cloudovými strojmi niečo šifrovať; ide o to, ktoré rozhranie šifrujete a kto komu overuje identitu. Tieto rozhovory začínam pri službe, nie pri sieťovej schéme, pretože služba už vie, čo potrebuje. Väčšinu prípadov pokrývajú tri hranice: vlastný TLS aplikácie, jeden presmerovaný TCP port cez SSH a smerovaný overlay, ktorý každému účastníkovi dá adresu. Nie sú zoradené podľa sily, ale podľa toho, akú časť problému pokrývajú.

Začnite službou, nie sieťou

Choďte od procesu von. Akým protokolom hovorí, ktoré meno bude klient overovať a kto vôbec smie otvoriť spojenie? Tieto tri odpovede vyradia možnosti rýchlejšie než akákoľvek porovnávacia tabuľka a vlastná konfigurácia služby ich zvyčajne zodpovie za pár minút.

Vezmite malé interné API, ktoré už poskytuje HTTPS na porte 8443 s certifikátom pre api.internal.example. ss -ltnp na hostiteľovi ukáže, na čo sa viaže, a openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example ukáže, či certifikát platí pre meno, ktoré klient skutočne použije. Ak je oboje v poriadku, služba môže chrániť svoj vlastný tok a zostáva len dostupnosť. To je oveľa menší problém než stavať sieť.

Krok 1: chráni sa služba sama?

Túto možnosť treba vziať, keď sa hodí, a hodí sa častejšie, než tímy predpokladajú. Šifrovanie služby pokrýva celú cestu medzi klientom a serverom vrátane každého skoku medzi nimi, čo žiadny tunel okolo stredu nevylepší. Nastavte očakávané meno a dôveru explicitne, namiesto spoliehania sa na to, čo náhodou obsahuje predvolené úložisko klienta.

Šifrovanie a dostupnosť zostávajú oddelené kontroly a práve ich spojenie je miesto, kde táto možnosť zlyháva. Služba TLS na neobmedzenom verejnom poslucháčovi stále prijíma pokusy o pripojenie od kohokoľvek, takže poslucháč a sieťové pravidlá musia byť vymedzené nezávisle od toho, že je obsah chránený. Potom skontrolujte závislosti, pretože API cez TLS nič nehovorí o koncovom bode zisťovania, administratívnom porte ani kanáli hromadného prenosu vedľa neho. Každý z nich potrebuje vlastnú odpoveď a jeden nechránený súrodenec stačí na to, aby sa celá hranica stala fikciou.

Krok 2: je jediný TCP port celá požiadavka?

Keď je požiadavkou naozaj jediný TCP port, presmerovanie je najmenšia vec, ktorá funguje. Lokálne SSH presmerovanie nesie tento port cez už existujúce overené spojenie.

Tvar je ssh -N -L 8443:127.0.0.1:8443 [email protected] a dôležitý detail je cieľová adresa: 127.0.0.1 sa prekladá na vzdialenej strane, takže spojenie so službou sa otvára z bastionu, nie z vášho notebooku. Navažte lokálneho poslucháča úzko ako -L 127.0.0.1:8443:..., aby ste službu omylom nezverejnili vo svojej lokálnej sieti. Na strane servera obmedzte, čo smie účet presmerovať, namiesto toho, aby ste verili, že sa klient zachová správne. PermitOpen, AllowTcpForwarding local a predvolený GatewayPorts no sú tri nastavenia, ktoré z univerzálneho relé robia konkrétny kanál.

Zmluva je úzka v oboch smeroch. SSH chráni svoj kanál a ďalší skok z bastionu do inej aplikácie potrebuje vlastnú ochranu. Služba, ktorá počúva len na loopbacku bastionu, má veľmi odlišnú expozíciu než tá dostupná cez inú sieť, a presmerovanie to nemení. Zachovajte overovanie a TLS kontroly aplikácie, namiesto toho, aby ste tunel považovali za ich náhradu.

Toto funguje dobre pre jedno spojenie s jedným vlastníkom. Vo väčšom meradle sa z toho stane systém: lokálne kolízie portov, dohľad, rotácia kľúčov a otázka, kto po reštarte znova spustí presmerovanie.

Krok 3: je smerovanie skutočná požiadavka?

Tento zoznam je čestná cena najmenšej možnosti, a preto tímy nakoniec nahradia hrsť zabudnutých príkazov na pozadí niečím spravovaným. Náhrada nie je automaticky VPN. Ak je požiadavkou stále jediný TCP port, dohliadané presmerovanie s zdokumentovaným vlastníkom je lacnejšie na prevádzku než overlay a zlyháva spôsobmi, ktoré vidíte. Merajte prevádzkové vlastníctvo skôr, než budete merať eleganciu.

Smerovanie sa stane správnou odpoveďou, keď je smerovanie požiadavkou. Niekoľko aplikácií potrebujúcich bežnú IP konektivitu, protokoly, ktoré TCP presmerovanie nedokáže uniesť, alebo služby presúvajúce sa medzi hostiteľmi ukazujú rovnakým smerom.

Overlay dá účastníkom adresu a trasu a potom sa začína skutočná práca: neprekrývajúce sa rozsahy, vlastníctvo trás, DNS, zápis, odvolanie a čo sa stane, keď partner zmizne. Nič z toho neprichádza s adresou. Partner prijatý do overlaya tiež nie je automaticky oprávnený na každú operáciu na cieli, takže overovanie na úrovni služby zostáva.

Čo vám zostane

Do záznamu, ktorý po sebe zanecháte, patria dve veci. Prvá je identita, ktorú má klient overovať, pretože každá z týchto hraníc ticho degraduje, len čo sa overenie mena uvoľní, aby niečo fungovalo. Druhá je krok odstránenia: ktorý kľúč, ktoré pravidlo alebo ktorá trasa zmizne, keď prístup skončí, a kto to vykoná.

Prechádzka končí tam, kde začala, pri službe. Vyberte hranicu, ktorá pokrýva skutočnú prevádzku a overuje partnerov, ktorých ste chceli overiť, a potom zapíšte, ako sa prístup aktualizuje, sleduje a odstraňuje. referencia OpenSSH je miesto, kde si pred sľubom úzkej zmluvy potvrdíte možnosti presmerovania. Ak krok odstránenia nedokážete opísať jednou vetou, hranica je väčšia než problém.