Własny TLS, przekierowanie SSH lub VPN dla jednej usługi w chmurze

Pytanie rzadko brzmi, czy szyfrować coś między dwiema maszynami w chmurze; brzmi, który interfejs szyfrujesz i kto sprawdza czyją tożsamość. Te rozmowy zaczynam od usługi, a nie od diagramu sieci, bo usługa już wie, czego potrzebuje. Trzy granice obejmują większość przypadków: własny TLS aplikacji, jeden przekierowany port TCP przez SSH i trasowana nakładka dająca każdemu uczestnikowi adres. Nie są uszeregowane według siły, lecz według tego, jaką część problemu obejmują.

Zacznij od usługi, nie od sieci

Idź od procesu na zewnątrz. Jakim protokołem mówi, jaką nazwę zweryfikuje klient i kto w ogóle może otworzyć połączenie? Te trzy odpowiedzi eliminują opcje szybciej niż jakakolwiek tabela porównawcza, a własna konfiguracja usługi zwykle odpowiada na nie w kilka minut.

Weź małe wewnętrzne API, które już serwuje HTTPS na porcie 8443 z certyfikatem dla api.internal.example. ss -ltnp na hoście pokazuje, do czego się wiąże, a openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example pokazuje, czy certyfikat jest ważny dla nazwy, której klient faktycznie użyje. Jeśli oba są zdrowe, usługa może chronić własny strumień i zostaje tylko dostępność. To znacznie mniejszy problem niż budowanie sieci.

Krok 1: czy usługa chroni samą siebie?

To opcja do wyboru, gdy pasuje, a pasuje częściej, niż zakładają zespoły. Szyfrowanie usługi obejmuje całą drogę między klientem a serwerem, w tym każdy skok pomiędzy, czego nie poprawia żaden tunel wokół środka. Ustaw oczekiwaną nazwę i zaufanie jawnie, zamiast polegać na tym, co przypadkiem zawiera domyślny magazyn klienta.

Szyfrowanie i dostępność pozostają osobnymi kontrolami i właśnie ich połączenie jest miejscem, w którym ta opcja zawodzi. Usługa TLS na nieograniczonym publicznym nasłuchu nadal przyjmuje próby połączenia od każdego, więc nasłuch i reguły sieciowe trzeba wyznaczyć niezależnie od faktu, że ładunek jest chroniony. Następnie sprawdź zależności, bo API po TLS nic nie mówi o punkcie wykrywania, porcie administracyjnym ani sąsiednim kanale transferu masowego. Każdy z nich potrzebuje własnej odpowiedzi, a jeden niechroniony brat wystarczy, by cała granica stała się fikcją.

Krok 2: czy jeden port TCP to całe wymaganie?

Gdy wymaganiem jest naprawdę jeden port TCP, przekierowanie jest najmniejszą działającą rzeczą. Lokalne przekierowanie SSH przenosi ten port przez już istniejące uwierzytelnione połączenie.

Forma to ssh -N -L 8443:127.0.0.1:8443 [email protected], a szczegół, który ma znaczenie, to adres docelowy: 127.0.0.1 jest rozwiązywany po stronie zdalnej, więc połączenie z usługą otwiera bastion, a nie twój laptop. Zwiąż lokalny nasłuch wąsko jako -L 127.0.0.1:8443:..., aby przypadkowo nie opublikować usługi w swojej sieci lokalnej. Po stronie serwera ogranicz, co konto może przekazywać, zamiast ufać dobremu zachowaniu klienta. PermitOpen, AllowTcpForwarding local i domyślny GatewayPorts no to trzy ustawienia, które zamieniają ogólny przekaźnik w konkretny kanał.

Kontrakt jest wąski w obu kierunkach. SSH chroni własny kanał, a dalszy skok z bastionu do innej aplikacji wymaga własnej ochrony. Usługa nasłuchująca tylko na loopback bastionu ma zupełnie inną ekspozycję niż osiągalna przez inną sieć, a przekierowanie tego nie zmienia. Zachowaj uwierzytelnianie i kontrole TLS aplikacji, zamiast traktować tunel jako ich zamiennik.

Działa to dobrze dla jednego połączenia z jednym właścicielem. W skali staje się systemem: konflikty portów lokalnych, nadzór, rotacja kluczy i pytanie, kto ponownie uruchomi przekierowanie po restarcie.

Krok 3: czy routing to rzeczywiste wymaganie?

Ta lista to uczciwy koszt najmniejszej opcji i dlatego zespoły w końcu zastępują garść zapomnianych poleceń w tle czymś zarządzanym. Zamiennik nie jest automatycznie VPN. Jeśli wymaganiem nadal jest jeden port TCP, nadzorowane przekierowanie z udokumentowanym właścicielem jest tańsze w utrzymaniu niż nakładka i zawodzi w widoczny sposób. Zmierz własność operacyjną, zanim zmierzysz elegancję.

Routing staje się właściwą odpowiedzią, gdy routing jest wymaganiem. Kilka aplikacji potrzebujących zwykłej łączności IP, protokoły, których przekierowanie TCP nie uniesie, albo usługi przenoszące się między hostami wskazują w tę samą stronę.

Nakładka daje uczestnikom adres i trasę, a potem zaczyna się prawdziwa praca: niepokrywające się zakresy, własność tras, DNS, rejestracja, odwołanie i co się dzieje, gdy partner znika. Nic z tego nie przychodzi z adresem. Partner dopuszczony do nakładki nie jest też automatycznie upoważniony do każdej operacji w miejscu docelowym, więc uwierzytelnianie na poziomie usługi zostaje.

Co posiadasz potem

Dwie rzeczy należą do zapisu, który zostawiasz. Pierwsza to tożsamość, którą klient ma weryfikować, bo każda z tych granic cicho się pogarsza, gdy tylko kontrola nazwy zostanie poluzowana, by coś zadziałało. Druga to krok usunięcia: który klucz, która reguła albo która trasa znika, gdy dostęp się kończy, i kto to wykonuje.

Wędrówka kończy się tam, gdzie się zaczęła, przy usłudze. Wybierz granicę, która obejmuje rzeczywisty ruch i weryfikuje partnerów, których zamierzałeś zweryfikować, a potem zapisz, jak dostęp jest aktualizowany, monitorowany i usuwany. Dokumentacja OpenSSH to miejsce, w którym potwierdzasz opcje przekierowania, zanim obiecasz wąski kontrakt. Jeśli nie potrafisz opisać kroku usunięcia w jednym zdaniu, granica jest większa niż problem.