Eigen TLS, SSH-vidareføring eller VPN for éin skylagsteneste

Spørsmålet er sjeldan om noko mellom to skyvmaskinar skal krypterast; det er kva grensesnitt du krypterer, og kven som kontrollerer kven si identitet. Eg startar desse samtalane med tenesta i staden for nettverksdiagrammet, fordi tenesta allereie veit kva ho treng. Tre grenser dekkjer dei fleste tilfella: eigen TLS i applikasjonen, éin vidareført TCP-port over SSH og eit ruta overlegg som gjev kvar deltakar ei adresse. Dei er ikkje rangert etter styrke, men etter kor mykje av problemet dei dekkjer.

Start med tenesta, ikkje nettverket

Gå utover frå prosessen. Kva protokoll snakkar han, kva namn vil klienten kontrollere, og kven får i det heile opne ei tilknyting? Dei tre svara utelukkar alternativ raskare enn noka samanlikningstabell, og eigen konfigurasjon i tenesta svarar vanlegvis på dei i løpet av nokre minutt.

Ta eit lite internt API som allereie leverer HTTPS på port 8443 med eit sertifikat for api.internal.example. ss -ltnp på verten viser kva det bind til, og openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example viser om sertifikatet validerer for namnet klienten faktisk brukar. Viss begge er friske, kan tenesta verne sin eigen straum, og berre tilgjengelegheit står att. Det er eit mykje mindre problem enn å byggje eit nettverk.

Steg 1: vernar tenesta seg sjølv?

Dette er alternativet å velje når det passar, og det passar oftare enn team antek. Krypteringa i tenesta dekkjer heile vegen mellom klient og tenar, inkludert kvart hopp imellom, noko ingen tunnel rundt midten betrar. Set det forventa namnet og tilliten eksplisitt i staden for å stole på kva standardlageret til klienten tilfeldigvis inneheld.

Kryptering og tilgjengelegheit blir verande separate kontrollar, og det er nettopp samanslåinga som gjer at dette alternativet går gale. Ei TLS-teneste på ein ubegrensa offentleg lyttar godtek framleis tilknytingsforsøk frå kven som helst, så lyttaren og nettverksreglane må avgrensast uavhengig av at nyttelasta er verna. Sjekk deretter avhengnadene, fordi eit API over TLS ikkje seier noko om oppdagingsendepunktet, adminporten eller bulkoverføringskanalen ved sida av. Kvar av dei treng sitt eige svar, og éi uverna syster er nok til å gjere heile grensa til fiksjon.

Steg 2: er éin TCP-port heile kravet?

Når kravet verkeleg er éin TCP-port, er ei vidareføring det minste som fungerer. Ei lokal SSH-vidareføring ber den porten gjennom ei allereie eksisterande autentisert tilknyting.

Formen er ssh -N -L 8443:127.0.0.1:8443 [email protected], og detaljen som tel er måladdressa: 127.0.0.1 blir løyst på fjernsida, så tilknytinga til tenesta blir opna frå bastionen i staden for frå laptoppen din. Bind den lokale lyttaren smalt som -L 127.0.0.1:8443:..., så du ikkje ved eit uhell publiserer tenesta på ditt eige lokale nettverk. På tenarsida avgrensar du kva kontoen får vidareføre i staden for å stole på at klienten oppfører seg. PermitOpen, AllowTcpForwarding local og standard GatewayPorts no er dei tre innstillingane som gjer ein generell relé til ein bestemd kanal.

Kontrakten er smal i begge retningar. SSH vernar sin eigen kanal, og eit vidare hopp frå bastionen til ein annan applikasjon treng si eiga vern. Ei teneste som berre lyttar på loopback til bastionen har ei heilt anna eksponering enn ei som blir nådd over eit anna nettverk, og vidareføringa endrar ikkje det. Hald autentiseringa og TLS-kontrollane til applikasjonen på plass i staden for å handsame tunnelen som erstatninga deira.

Dette fungerer godt for éi tilknyting med éin eigar. I skala blir det eit system: lokale portkonfliktar, overvaking, nøkkelrotasjon og spørsmålet om kven som startar vidareføringa på nytt etter ein omstart.

Steg 3: er ruting det eigentlege kravet?

Den lista er den ærlege prisen for det minste alternativet, og difor byter team til slutt ut ein handfull gløymde bakgrunnskommandoar med noko administrert. Erstatninga er ikkje automatisk ein VPN. Viss kravet framleis er éin TCP-port, er ei overvaka vidareføring med dokumentert eigar billegare å drive enn eit overlegg, og ho feilar på måtar du kan sjå. Mål operasjonelt eigarskap før du måler eleganse.

Ruting blir det rette svaret når ruting er kravet. Fleire applikasjonar som treng vanleg IP-tilknyting, protokollar ei TCP-vidareføring ikkje kan bere, eller tenester som flyttar mellom vertar peikar alle same veg.

Eit overlegg gjev deltakarane ei adresse og ei rute, og då byrjar det eigentlege arbeidet: ikkje-overlappande område, ruteeigarskap, DNS, påmelding, tilbakekalling og kva som skjer når ein peer forsvinn. Ingenting av det kjem med adressa. Ein peer som er teken opp i overlegget er heller ikkje automatisk autorisert for kvar operasjon på destinasjonen, så autentisering på tenestenivå blir verande.

Kva du eig etterpå

To ting høyrer heime i registreringa du lèt etter deg. Det første er identiteten klienten blir venta å kontrollere, fordi kvar av desse grensene blir svekt stille når ein namnekontroll blir lempa for å få noko til å verke. Det andre er fjerningssteget: kva nøkkel, kva regel eller kva rute forsvinn når tilgangen sluttar, og kven som utfører det.

Gjennomgangen sluttar der han byrja, ved tenesta. Vel grensa som dekkjer den faktiske trafikken og kontrollerer dei peerane du meinte å kontrollere, og skriv deretter ned korleis tilgang blir oppdatert, overvaka og fjerna. OpenSSH-referansen er staden for å stadfeste vidareføringsvala før du lovar ein smal kontrakt. Viss du ikkje kan skildre fjerningssteget i éi setning, er grensa større enn problemet.