Indbygget TLS, SSH-videresendelse eller VPN til én cloudtjeneste

Spørgsmålet er sjældent, om noget mellem to cloudmaskiner skal krypteres; det er, hvilken grænseflade du krypterer, og hvem der kontrollerer hvis identitet. Jeg starter disse samtaler med tjenesten frem for netværksdiagrammet, fordi tjenesten allerede ved, hvad den har brug for. Tre grænser dækker de fleste tilfælde: applikationens egen TLS, én videresendt TCP-port over SSH og et routet overlay, der giver hver deltager en adresse. De er ikke rangeret efter styrke, men efter hvor meget af problemet de dækker.

Start med tjenesten, ikke netværket

Gå udad fra processen. Hvilken protokol taler den, hvilket navn vil klienten kontrollere, og hvem må overhovedet åbne en forbindelse? De tre svar udelukker muligheder hurtigere end enhver sammenligningstabel, og tjenestens egen konfiguration svarer normalt på dem på et par minutter.

Tag en lille intern API, der allerede leverer HTTPS på port 8443 med et certifikat til api.internal.example. ss -ltnp på værten viser, hvad den binder til, og openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example viser, om certifikatet validerer for det navn, klienten faktisk bruger. Hvis begge er sunde, kan tjenesten beskytte sin egen strøm, og kun tilgængelighed er tilbage. Det er et meget mindre problem end at bygge et netværk.

Trin 1: beskytter tjenesten sig selv?

Det er den mulighed, man vælger, når den passer, og den passer oftere, end teams antager. Tjenestens kryptering dækker hele vejen mellem klient og server, inklusive hvert hop indimellem, hvilket ingen tunnel omkring midten forbedrer. Konfigurer det forventede navn og tillid eksplicit i stedet for at stole på, hvad klientens standardlager tilfældigvis indeholder.

Kryptering og tilgængelighed forbliver separate kontroller, og det er netop sammenlægningen, der gør denne mulighed forkert. En TLS-tjeneste på en ubegrænset offentlig lytter accepterer stadig forbindelsesforsøg fra enhver, så lytteren og netværksreglerne skal afgrænses uafhængigt af, at nyttelasten er beskyttet. Kontroller derefter afhængighederne, fordi en API over TLS intet siger om opdagelsesendepunktet, adminporten eller bulkoverførselskanalen ved siden af. Hver af dem kræver sit eget svar, og én ubeskyttet søster er nok til at gøre hele grænsen til fiktion.

Trin 2: er én TCP-port hele kravet?

Når kravet virkelig er én TCP-port, er en videresendelse det mindste, der virker. En lokal SSH-videresendelse bærer den port gennem en allerede eksisterende autentificeret forbindelse.

Formen er ssh -N -L 8443:127.0.0.1:8443 [email protected], og detaljen, der betyder noget, er måladdressen: 127.0.0.1 opløses på fjernsiden, så forbindelsen til tjenesten åbnes fra bastionen i stedet for din laptop. Bind den lokale lytter snævert som -L 127.0.0.1:8443:..., så du ikke ved et uheld udgiver tjenesten på dit eget lokale netværk. Begræns på serversiden, hvad kontoen må videresende, i stedet for at stole på, at klienten opfører sig ordentligt. PermitOpen, AllowTcpForwarding local og standarden GatewayPorts no er de tre indstillinger, der gør et generelt relæ til en bestemt kanal.

Kontrakten er snæver i begge retninger. SSH beskytter sin egen kanal, og et yderligere hop fra bastionen til en anden applikation kræver sin egen beskyttelse. En tjeneste, der kun lytter på bastionens loopback, har en helt anden eksponering end en, der nås over et andet netværk, og videresendelsen ændrer ikke det. Behold applikationens godkendelse og TLS-kontroller i stedet for at behandle tunnelen som deres erstatning.

Det fungerer godt til én forbindelse med én ejer. I skala bliver det et system: lokale portkonflikter, overvågning, nøglerotation og spørgsmålet om, hvem der genstarter videresendelsen efter en genstart.

Trin 3: er routing det egentlige krav?

Den liste er den ærlige pris for den mindste mulighed, og derfor erstatter teams til sidst en håndfuld glemte baggrundskommandoer med noget administreret. Erstatningen er ikke automatisk en VPN. Hvis kravet stadig er én TCP-port, er en overvåget videresendelse med en dokumenteret ejer billigere at drive end et overlay, og den fejler på måder, du kan se. Mål operationelt ejerskab, før du måler elegance.

Routing bliver det rigtige svar, når routing er kravet. Flere applikationer, der har brug for almindelig IP-forbindelse, protokoller, som en TCP-videresendelse ikke kan bære, eller tjenester, der flytter mellem værter, peger alle samme vej.

Et overlay giver deltagerne en adresse og en rute, og så begynder det egentlige arbejde: ikke-overlappende områder, ruteejerskab, DNS, tilmelding, tilbagekaldelse og hvad der sker, når en peer forsvinder. Intet af det kommer med adressen. En peer, der er optaget i overlayet, er heller ikke automatisk autoriseret til hver operation på destinationen, så godkendelse på tjenesteniveau bliver.

Hvad du ejer bagefter

To ting hører i den registrering, du efterlader. Det første er den identitet, klienten forventes at kontrollere, fordi hver af disse grænser stille forringes, når et navnekontrol lempes for at få noget til at virke. Det andet er fjernelsestrinet: hvilken nøgle, hvilken regel eller hvilken rute forsvinder, når adgangen slutter, og hvem der udfører det.

Gennemgangen slutter, hvor den begyndte, ved tjenesten. Vælg den grænse, der dækker den faktiske trafik og kontrollerer de peers, du mente at kontrollere, og skriv derefter ned, hvordan adgang opdateres, overvåges og fjernes. OpenSSH-referencen er stedet at bekræfte videresendelsesmulighederne, før du lover en snæver kontrakt. Hvis du ikke kan beskrive fjernelsestrinet i én sætning, er grænsen større end problemet.