Egen TLS, SSH-vidarebefordran eller VPN för en molntjänst

Frågan är sällan om något mellan två molnmaskiner ska krypteras; den är vilket gränssnitt du krypterar och vem som kontrollerar vems identitet. Jag börjar dessa samtal med tjänsten i stället för nätverksdiagrammet, eftersom tjänsten redan vet vad den behöver. Tre gränser täcker de flesta fall: applikationens egen TLS, en vidarebefordrad TCP-port över SSH och ett routat överlägg som ger varje deltagare en adress. De rangordnas inte efter styrka, utan efter hur mycket av problemet de täcker.

Börja med tjänsten, inte nätverket

Gå utåt från processen. Vilket protokoll talar den, vilket namn kommer klienten att kontrollera och vem får överhuvudtaget öppna en anslutning? De tre svaren utesluter alternativ snabbare än någon jämförelsetabell, och tjänstens egen konfiguration svarar vanligtvis på dem inom några minuter.

Ta en liten intern API som redan levererar HTTPS på port 8443 med ett certifikat för api.internal.example. ss -ltnp på värden visar vad den binder till, och openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example visar om certifikatet validerar för det namn klienten faktiskt använder. Om båda är friska kan tjänsten skydda sitt eget flöde och bara nåbarhet återstår. Det är ett mycket mindre problem än att bygga ett nätverk.

Steg 1: skyddar tjänsten sig själv?

Detta är alternativet att välja när det passar, och det passar oftare än team antar. Tjänstens kryptering täcker hela vägen mellan klient och server, inklusive varje hopp däremellan, vilket ingen tunnel runt mitten förbättrar. Ange det förväntade namnet och förtroendet uttryckligen i stället för att lita på vad klientens standardlager råkar innehålla.

Kryptering och nåbarhet förblir separata kontroller, och det är sammanslagningen av dem som gör att detta alternativ går fel. En TLS-tjänst på en obegränsad offentlig lyssnare accepterar fortfarande anslutningsförsök från vem som helst, så lyssnaren och nätverksreglerna måste avgränsas oberoende av att nyttolasten är skyddad. Kontrollera sedan beroendena, eftersom ett API över TLS inte säger något om upptäcktsändpunkten, adminporten eller bulköverföringskanalen intill. Var och en behöver sitt eget svar, och en oskyddad syster räcker för att göra hela gränsen till fiktion.

Steg 2: är en TCP-port hela kravet?

När kravet verkligen är en TCP-port är en vidarebefordran det minsta som fungerar. En lokal SSH-vidarebefordran bär den porten genom en redan befintlig autentiserad anslutning.

Formen är ssh -N -L 8443:127.0.0.1:8443 [email protected], och detaljen som spelar roll är måladressen: 127.0.0.1 löses på fjärrsidan, så anslutningen till tjänsten öppnas från bastionen i stället för från din laptop. Bind den lokala lyssnaren snävt som -L 127.0.0.1:8443:... så att du inte av misstag publicerar tjänsten på ditt eget lokala nätverk. På serversidan begränsar du vad kontot får vidarebefordra i stället för att lita på att klienten uppför sig. PermitOpen, AllowTcpForwarding local och standard-GatewayPorts no är de tre inställningar som förvandlar en allmän relä till en specifik kanal.

Kontraktet är smalt i båda riktningarna. SSH skyddar sin egen kanal, och ett vidare hopp från bastionen till en annan applikation behöver sitt eget skydd. En tjänst som bara lyssnar på bastionens loopback har en helt annan exponering än en som nås över ett annat nätverk, och vidarebefordran ändrar inte det. Behåll applikationens autentisering och TLS-kontroller i stället för att behandla tunneln som deras ersättning.

Detta fungerar bra för en anslutning med en ägare. I skala blir det ett system: lokala portkonflikter, övervakning, nyckelrotation och frågan om vem som startar om vidarebefordran efter en omstart.

Steg 3: är routning det egentliga kravet?

Den listan är det ärliga priset för det minsta alternativet, och därför ersätter team till slut en handfull glömda bakgrundskommandon med något hanterat. Ersättningen är inte automatiskt en VPN. Om kravet fortfarande är en TCP-port är en övervakad vidarebefordran med dokumenterad ägare billigare att driva än ett överlägg, och den misslyckas på sätt du kan se. Mät operativt ägande innan du mäter elegans.

Routning blir rätt svar när routning är kravet. Flera applikationer som behöver vanlig IP-anslutning, protokoll som en TCP-vidarebefordran inte kan bära eller tjänster som flyttar mellan värdar pekar alla åt samma håll.

Ett överlägg ger deltagarna en adress och en rutt, och sedan börjar det verkliga arbetet: icke-överlappande intervall, ruttägande, DNS, registrering, återkallande och vad som händer när en peer försvinner. Inget av det kommer med adressen. En peer som släpps in i överlägget är inte heller automatiskt behörig för varje operation på målet, så autentisering på tjänstenivå kvarstår.

Vad du äger efteråt

Två saker hör hemma i den dokumentation du lämnar efter dig. Det första är identiteten som klienten förväntas kontrollera, eftersom var och en av dessa gränser försämras tyst så snart en namnkontroll luckras upp för att få något att fungera. Det andra är borttagningssteget: vilken nyckel, vilken regel eller vilken rutt som försvinner när åtkomsten upphör, och vem som utför det.

Genomgången slutar där den började, vid tjänsten. Välj den gräns som täcker den faktiska trafiken och kontrollerar de peers du avsåg att kontrollera, och skriv sedan ned hur åtkomst uppdateras, övervakas och tas bort. OpenSSH-referensen är platsen för att bekräfta vidarebefordringsalternativen innan du lovar ett smalt kontrakt. Om du inte kan beskriva borttagningssteget i en mening är gränsen större än problemet.