Saját TLS, SSH-továbbítás vagy VPN egy felhőszolgáltatáshoz

A kérdés ritkán az, hogy kell-e titkosítani valamit két felhőgép között; az a kérdés, melyik interfészt titkosítja, és ki kinek az identitását ellenőrzi. Ezeket a beszélgetéseket a szolgáltatásnál kezdem, nem a hálózati diagramnál, mert a szolgáltatás már tudja, mire van szüksége. Három határ fedi le a legtöbb esetet: az alkalmazás saját TLS-e, egy SSH-n keresztül továbbított TCP-port és egy routolt átfedő hálózat, amely minden résztvevőnek címet ad. Nem erősség szerint rangsorolják őket, hanem aszerint, mennyit fednek le a problémából.

A szolgáltatással kezdje, ne a hálózattal

Haladjon kifelé a folyamatból. Milyen protokollt beszél, melyik nevet fogja ellenőrizni a kliens, és egyáltalán ki nyithat kapcsolatot? Ez a három válasz gyorsabban kizárja a lehetőségeket, mint bármely összehasonlító táblázat, és a szolgáltatás saját konfigurációja általában néhány perc alatt megadja őket.

Vegyen egy kis belső API-t, amely már HTTPS-t szolgál ki a 8443-as porton, api.internal.example tanúsítványával. A hoszton a ss -ltnp megmutatja, mihez kötődik, a openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example pedig megmutatja, érvényes-e a tanúsítvány arra a névre, amelyet a kliens valóban használni fog. Ha mindkettő egészséges, a szolgáltatás meg tudja védeni a saját adatfolyamát, és csak az elérhetőség marad. Ez sokkal kisebb probléma, mint hálózatot építeni.

1. lépés: megvédi-e magát a szolgáltatás?

Ezt a lehetőséget akkor választja, amikor illik, és gyakrabban illik, mint a csapatok feltételezik. A szolgáltatás titkosítása a kliens és a szerver közötti teljes utat lefedi, beleértve minden köztes ugrást, amit semmilyen közép körüli alagút nem javít. Állítsa be az elvárt nevet és a bizalmat kifejezetten, ahelyett hogy arra hagyatkozna, ami véletlenül a kliens alapértelmezett tárolójában van.

A titkosítás és az elérhetőség külön kontrollok maradnak, és éppen összemosásuk az a pont, ahol ez a lehetőség elhibázza. Egy TLS-szolgáltatás korlátlan nyilvános figyelőn továbbra is elfogad kapcsolódási kísérleteket bárkitől, ezért a figyelőt és a hálózati szabályokat attól függetlenül kell meghatározni, hogy a hasznos teher védett. Ezután ellenőrizze a függőségeket, mert a TLS feletti API semmit sem mond a felderítési végpontról, az admin portról vagy a mellette lévő tömeges átviteli csatornáról. Mindegyiknek saját válasz kell, és egyetlen védelem nélküli testvér elég ahhoz, hogy az egész határ fikcióvá váljon.

2. lépés: egyetlen TCP-port az egész követelmény?

Amikor a követelmény valóban egyetlen TCP-port, a továbbítás a legkisebb működő dolog. Az SSH helyi továbbítása ezt a portot egy már létező hitelesített kapcsolaton keresztül viszi.

A forma ssh -N -L 8443:127.0.0.1:8443 [email protected], és a fontos részlet a célcím: a 127.0.0.1 a távoli oldalon oldódik fel, ezért a szolgáltatáshoz a kapcsolat a bástyáról nyílik, nem a laptopjáról. A helyi figyelőt szűken kösse -L 127.0.0.1:8443:... formában, hogy véletlenül se tegye közzé a szolgáltatást a saját helyi hálózatán. A szerver oldalán korlátozza, mit továbbíthat a fiók, ahelyett hogy a kliens jó viselkedésében bízna. A PermitOpen, a AllowTcpForwarding local és az alapértelmezett GatewayPorts no az a három beállítás, amely az általános relét meghatározott csatornává alakítja.

A szerződés mindkét irányban szűk. Az SSH védi a saját csatornáját, és a bástyáról egy másik alkalmazáshoz vezető további ugrás saját védelmet igényel. Egy szolgáltatás, amely csak a bástya loopbackjén figyel, egészen más kitettséggel rendelkezik, mint amelyik más hálózaton keresztül érhető el, és a továbbítás ezen nem változtat. Tartsa meg az alkalmazás hitelesítését és TLS-ellenőrzéseit ahelyett, hogy az alagutat azok helyettesítőjének tekintené.

Ez jól működik egy kapcsolat és egy tulajdonos esetén. Nagy méretekben rendszerré válik: helyi portütközések, felügyelet, kulcsforgatás és az a kérdés, ki indítja újra a továbbítást az újraindítás után.

3. lépés: a routing az igazi követelmény?

Ez a lista a legkisebb lehetőség őszinte ára, és ezért cserélik le a csapatok végül a néhány elfelejtett háttérparancsot valami felügyelttel. A csere nem automatikusan VPN. Ha a követelmény továbbra is egyetlen TCP-port, egy dokumentált tulajdonossal felügyelt továbbítás olcsóbban üzemeltethető, mint egy átfedő hálózat, és látható módokon hibázik. Mérje az üzemeltetési tulajdonjogot, mielőtt az eleganciát méri.

A routing akkor lesz a helyes válasz, amikor a routing a követelmény. Több alkalmazás, amely közönséges IP-kapcsolatot igényel, olyan protokollok, amelyeket a TCP-továbbítás nem tud hordozni, vagy a hosztok között mozgó szolgáltatások mind ugyanabba az irányba mutatnak.

Az átfedő hálózat címet és útvonalat ad a résztvevőknek, aztán kezdődik az igazi munka: nem átfedő tartományok, útvonal-tulajdonjog, DNS, regisztráció, visszavonás és az, hogy mi történik, ha egy társ eltűnik. Ebből semmi sem jön a címmel együtt. Az átfedő hálózatba felvett társ sem jogosult automatikusan a cél minden műveletére, ezért a szolgáltatásszintű hitelesítés megmarad.

Mi az Öné utána

Két dolog tartozik a hátrahagyott feljegyzésbe. Az első az az identitás, amelyet a kliensnek ellenőriznie kell, mert e határok mindegyike csendesen romlik, amint egy névellenőrzést lazítanak, hogy valami működjön. A második az eltávolítás lépése: melyik kulcs, melyik szabály vagy melyik útvonal tűnik el, amikor a hozzáférés véget ér, és ki hajtja végre.

A végigvezetés ott ér véget, ahol elkezdődött, a szolgáltatásnál. Válassza azt a határt, amely lefedi a tényleges forgalmat és ellenőrzi azokat a társakat, amelyeket ellenőrizni akart, majd írja le, hogyan frissül, figyeli és távolítja el a hozzáférést. Az OpenSSH-referencia az a hely, ahol megerősítheti a továbbítási lehetőségeket, mielőtt szűk szerződést ígér. Ha az eltávolítás lépését nem tudja egy mondatban leírni, a határ nagyobb, mint a probléma.