Inheemse TLS, SSH-deurstuur of VPN vir een wolkdiens

Die vraag is selde of iets tussen twee wolkmakines geënkripteer moet word; dit is watter koppelvlak jy enkripteer en wie wie se identiteit kontroleer. Ek begin hierdie gesprekke by die diens eerder as by die netwerkdiagram, want die diens weet reeds wat hy nodig het. Drie grense dek die meeste gevalle: die toepassing se eie TLS, 'n enkele deurgestuurde TCP-poort oor SSH, en 'n geroteerde oorleglaag wat elke deelnemer 'n adres gee. Hulle word nie volgens sterkte gerangskik nie, maar volgens hoeveel van die probleem hulle dek.

Begin by die diens, nie die netwerk nie

Werk van die proses af uitwaarts. Watter protokol praat dit, watter naam sal die kliënt verifieer, en wie mag hoegenaamd 'n verbinding oopmaak? Daardie drie antwoorde skakel opsies vinniger uit as enige vergelykingstabel, en die diens se eie konfigurasie beantwoord hulle gewoonlik binne 'n paar minute.

Neem 'n klein interne API wat reeds HTTPS op poort 8443 bedien met 'n sertifikaat vir api.internal.example. ss -ltnp op die gasheer wys waaraan dit bind, en openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example wys of die sertifikaat geldig is vir die naam wat die kliënt werklik sal gebruik. As albei gesond is, kan die diens sy eie stroom beskerm en is bereikbaarheid die enigste oorblywende werk. Dit is 'n veel kleiner probleem as om 'n netwerk te bou.

Stap 1: beskerm die diens homself?

Dit is die opsie om te kies wanneer dit pas, en dit pas dikwels meer as wat spanne aanneem. Die diens se enkripsie dek die hele pad tussen kliënt en bediener, insluitend elke hop tussenin, wat geen tonnel om die middel verbeter nie. Stel die verwagte naam en vertroue eksplisiet op eerder as om te vertrou op wat die kliënt se verstekbewaarplek toevallig bevat.

Enkripsie en bereikbaarheid bly aparte kontroles, en dit is waar hierdie opsie verkeerd loop as hulle saamgevoeg word. 'n TLS-diens op 'n onbeperkte openbare luisteraar aanvaar steeds verbindingspogings van enigiemand, so die luisteraar en die netwerkreekels moet onafhanklik van die feit dat die vrag beskerm is, bepaal word. Kontroleer dan die afhanklikhede, want 'n API oor TLS sê niks oor die ontdekkingspunt, die administratiewe poort of die grootmaat-oordragkanaal daarnaas nie. Elkeen daarvan het sy eie antwoord nodig, en een onbeskermde broer is genoeg om die hele grens 'n fiksie te maak.

Stap 2: is een TCP-poort die hele vereiste?

Wanneer die vereiste regtig een TCP-poort is, is 'n deurstuur die kleinste ding wat werk. 'n SSH-plaaslike deurstuur dra daardie poort deur 'n geauthentiseerde verbinding wat reeds bestaan.

Die vorm is ssh -N -L 8443:127.0.0.1:8443 [email protected], en die detail wat saak maak, is die teikenadres: 127.0.0.1 word aan die remote kant opgelos, so die verbinding na die diens word van die bastion eerder as van jou skootrekenaar oopgemaak. Bind die plaaslike luisteraar eng as -L 127.0.0.1:8443:... sodat jy nie die diens per ongeluk aan jou eie plaaslike netwerk publiseer nie. Beperk aan die bedienerkant wat die rekening mag deurstuur eerder as om die kliënt te vertrou om hom te gedra. PermitOpen, AllowTcpForwarding local en 'n GatewayPorts no-verstek is die drie instellings wat 'n algemene aflos in 'n spesifieke kanaal verander.

Die kontrak is in albei rigtings eng. SSH beskerm sy eie kanaal, en 'n verdere hop van die bastion na 'n ander toepassing benodig sy eie beskerming. 'n Diens wat net op die bastion se loopback luister, het 'n heel ander blootstelling as een wat oor 'n ander netwerk bereik word, en die deurstuur verander dit nie. Hou die toepassing se verifikasie en TLS-kontroles in plek eerder as om die tonnel as 'n plaasvervanger daarvoor te behandel.

Dit werk goed vir een verbinding met een eienaar. Op skaal word dit 'n stelsel: plaaslike poortkonflikte, toesig, sleutelrotasie en die vraag wie die deurstuur ná 'n herlaai herbegin.

Stap 3: is roetering die werklike vereiste?

Daardie lys is die eerlike koste van die kleinste opsie, en dit is waarom spanne uiteindelik 'n handvol vergete agtergrondopdragte met iets bestuurds vervang. Die vervanging is nie outomaties 'n VPN nie. As die vereiste steeds een TCP-poort is, is 'n onder toesig deurgestuurde poort met 'n gedokumenteerde eienaar goedkoper om te bedryf as 'n oorleglaag, en dit faal op maniere wat jy kan sien. Meet operasionele eienaarskap voordat jy elegansie meet.

Roetering word die regte antwoord wanneer roetering die vereiste is. Verskeie toepassings wat gewone IP-verbinding nodig het, protokolle wat 'n TCP-deurstuur nie kan dra nie, of dienste wat tussen gashere beweeg, wys almal dieselfde kant toe.

'n Oorleglaag gee deelnemers 'n adres en 'n roete, en dan begin die werklike werk: nie-oorvleuelende reekse, roeteeienaarskap, DNS, inskrywing, herroeping en wat gebeur wanneer 'n eweknie verdwyn. Niks daarvan kom saam met die adres nie. 'n Eweknie wat tot die oorleglaag toegelaat is, is ook nie outomaties gemagtig vir elke bewerking op die bestemming nie, so diensvlak-verifikasie bly.

Wat jy daarna besit

Twee dinge hoort in die rekord wat jy agterlaat. Die eerste is die identiteit wat die kliënt verwag word om te verifieer, want elkeen van hierdie grense verswak stilweg sodra 'n naamkontrole verslap word om iets te laat werk. Die tweede is die verwyderingsstap: watter sleutel, watter reël of watter roete verdwyn wanneer toegang eindig, en wie dit doen.

Die deurloop eindig waar dit begin het, by die diens. Kies die grens wat die werklike verkeer dek en die eweknieë verifieer wat jy bedoel het om te verifieer, en skryf dan neer hoe toegang opgedateer, gemonitor en verwyder word. Die OpenSSH-verwysing is die plek om die deurstuur-opsies te bevestig voordat jy 'n eng kontrak belowe. As jy die verwyderingsstap nie in een sin kan beskryf nie, is die grens groter as die probleem.