Nativní TLS, SSH forwarding nebo VPN pro jednu cloudovou službu

Otázka málokdy je, zda mezi dvěma cloudovými stroji něco šifrovat; jde o to, které rozhraní šifrujete a kdo komu ověřuje identitu. Tyto rozhovory začínám u služby, ne u síťového diagramu, protože služba už ví, co potřebuje. Většinu případů pokrývají tři hranice: vlastní TLS aplikace, jeden přesměrovaný TCP port přes SSH a směrovaný overlay, který každému účastníkovi dá adresu. Nejsou seřazeny podle síly, ale podle toho, jak velkou část problému pokrývají.

Začněte službou, ne sítí

Jděte od procesu ven. Jakým protokolem mluví, které jméno bude klient ověřovat a kdo vůbec smí otevřít spojení? Tyto tři odpovědi vyřadí možnosti rychleji než jakákoli srovnávací tabulka a vlastní konfigurace služby je obvykle zodpoví během několika minut.

Vezměte malé interní API, které už poskytuje HTTPS na portu 8443 s certifikátem pro api.internal.example. ss -ltnp na hostiteli ukáže, na co se váže, a openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example ukáže, zda certifikát platí pro jméno, které klient skutečně použije. Pokud je obojí v pořádku, služba může chránit svůj vlastní tok a zbývá jen dostupnost. To je mnohem menší problém než stavět síť.

Krok 1: chrání se služba sama?

Tuto možnost je třeba vzít, když se hodí, a hodí se častěji, než týmy předpokládají. Šifrování služby pokrývá celou cestu mezi klientem a serverem včetně každého skoku mezi nimi, což žádný tunel kolem středu nevylepší. Nastavte očekávané jméno a důvěru explicitně, místo abyste se spoléhali na to, co náhodou obsahuje výchozí úložiště klienta.

Šifrování a dostupnost zůstávají oddělené kontroly a právě jejich sloučení je místo, kde tato možnost selhává. Služba TLS na neomezeném veřejném posluchači stále přijímá pokusy o připojení od kohokoli, takže posluchač a síťová pravidla musí být vymezeny nezávisle na tom, že je obsah chráněn. Pak zkontrolujte závislosti, protože API přes TLS nic neříká o koncovém bodu zjišťování, administrativním portu ani kanálu hromadného přenosu vedle něj. Každý z nich potřebuje vlastní odpověď a jeden nechráněný sourozenec stačí k tomu, aby se celá hranice stala fikcí.

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

Když je požadavkem opravdu jediný TCP port, forwarding je nejmenší věc, která funguje. Lokální SSH forwarding nese tento port přes už existující ověřené spojení.

Tvar je ssh -N -L 8443:127.0.0.1:8443 [email protected] a důležitý detail je cílová adresa: 127.0.0.1 se překládá na vzdálené straně, takže spojení ke službě se otevírá z bastionu, ne z vašeho notebooku. Navažte lokální posluchač úzce jako -L 127.0.0.1:8443:..., abyste službu omylem nezveřejnili ve své lokální síti. Na straně serveru omezťe, co smí účet předávat, místo abyste věřili, že se klient zachová správně. PermitOpen, AllowTcpForwarding local a výchozí GatewayPorts no jsou tři nastavení, která z univerzálního relé dělají konkrétní kanál.

Smlouva je úzká v obou směrech. SSH chrání svůj kanál a další skok z bastionu do jiné aplikace potřebuje vlastní ochranu. Služba naslouchající jen na loopbacku bastionu má velmi odlišnou expozici než ta dostupná přes jinou síť a forwarding to nemění. Zachovejte ověřování a TLS kontroly aplikace, místo abyste tunel považovali za jejich náhradu.

To funguje dobře pro jedno spojení s jedním vlastníkem. Ve větším měřítku se z toho stane systém: lokální kolize portů, dohled, rotace klíčů a otázka, kdo po restartu znovu spustí forwarding.

Krok 3: je směrování skutečný požadavek?

Tento seznam je poctivá cena nejmenší možnosti a proto týmy nakonec nahradí hrst zapomenutých příkazů na pozadí něčím spravovaným. Náhrada není automaticky VPN. Pokud je požadavkem stále jediný TCP port, dohlížený forwarding s zdokumentovaným vlastníkem je levnější na provoz než overlay a selhává způsoby, které vidíte. Měřte provozní vlastnictví dřív, než budete měřit eleganci.

Směrování se stane správnou odpovědí, když je směrování požadavkem. Několik aplikací potřebujících běžnou IP konektivitu, protokoly, které TCP forwarding unést nedokáže, nebo služby přesouvající se mezi hostiteli ukazují stejným směrem.

Overlay dá účastníkům adresu a trasu a pak začíná skutečná práce: nepřekrývající se rozsahy, vlastnictví tras, DNS, zápis, odvolání a co se stane, když partner zmizí. Nic z toho s adresou nepřichází. Partner přijatý do overlaye také není automaticky oprávněn ke každé operaci na cíli, takže ověřování na úrovni služby zůstává.

Co vám zůstane

Do záznamu, který po sobě zanecháte, patří dvě věci. První je identita, kterou má klient ověřovat, protože každá z těchto hranic tiše degraduje, jakmile se ověření jména uvolní, aby něco fungovalo. Druhá je krok odstranění: který klíč, které pravidlo nebo která trasa zmizí, když přístup skončí, a kdo to provede.

Procházka končí tam, kde začala, u služby. Vyberte hranici, která pokrývá skutečný provoz a ověřuje partnery, které jste ověřit chtěli, a pak zapište, jak se přístup aktualizuje, sleduje a odstraňuje. reference OpenSSH je místo, kde si před slibem úzké smlouvy potvrdíte možnosti forwardingu. Pokud krok odstranění nedokážete popsat jednou větou, je hranice větší než problém.