Egen TLS, SSH-videresending eller VPN for én skytjeneste

Spørsmålet er sjelden om noe mellom to skyvmaskiner skal krypteres; det er hvilket grensesnitt du krypterer, og hvem som kontrollerer hvis identitet. Jeg starter disse samtalene med tjenesten i stedet for nettverksdiagrammet, fordi tjenesten allerede vet hva den trenger. Tre grenser dekker de fleste tilfeller: applikasjonens egen TLS, én videresendt TCP-port over SSH og et rutet overlegg som gir hver deltaker en adresse. De er ikke rangert etter styrke, men etter hvor mye av problemet de dekker.

Start med tjenesten, ikke nettverket

Gå utover fra prosessen. Hvilken protokoll snakker den, hvilket navn vil klienten kontrollere, og hvem får i det hele tatt åpne en forbindelse? De tre svarene utelukker alternativer raskere enn noen sammenligningstabell, og tjenestens egen konfigurasjon svarer vanligvis på dem i løpet av noen minutter.

Ta en liten intern API som allerede leverer HTTPS på port 8443 med et sertifikat for api.internal.example. ss -ltnp på verten viser hva den binder til, og openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example viser om sertifikatet validerer for navnet klienten faktisk bruker. Hvis begge er friske, kan tjenesten beskytte sin egen strøm, og bare tilgjengelighet gjenstår. Det er et mye mindre problem enn å bygge et nettverk.

Trinn 1: beskytter tjenesten seg selv?

Dette er alternativet å velge når det passer, og det passer oftere enn team antar. Tjenestens kryptering dekker hele veien mellom klient og server, inkludert hvert hopp imellom, noe ingen tunnel rundt midten forbedrer. Sett det forventede navnet og tilliten eksplisitt i stedet for å stole på hva klientens standardlager tilfeldigvis inneholder.

Kryptering og tilgjengelighet forblir separate kontroller, og det er nettopp sammenslåingen som gjør at dette alternativet går galt. En TLS-tjeneste på en ubegrenset offentlig lytter godtar fortsatt tilkoblingsforsøk fra hvem som helst, så lytteren og nettverksreglene må avgrenses uavhengig av at nyttelasten er beskyttet. Sjekk deretter avhengighetene, fordi en API over TLS ikke sier noe om oppdagelsesendepunktet, adminporten eller bulkoverføringskanalen ved siden av. Hver av dem trenger sitt eget svar, og én ubeskyttet søster er nok til å gjøre hele grensen til fiksjon.

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

Når kravet virkelig er én TCP-port, er en videresending det minste som fungerer. En lokal SSH-videresending bærer den porten gjennom en allerede eksisterende autentisert forbindelse.

Formen er ssh -N -L 8443:127.0.0.1:8443 [email protected], og detaljen som betyr noe er måladdressen: 127.0.0.1 løses på fjernsiden, så forbindelsen til tjenesten åpnes fra bastionen i stedet for fra laptopen din. Bind den lokale lytteren smalt som -L 127.0.0.1:8443:..., så du ikke ved et uhell publiserer tjenesten på ditt eget lokale nettverk. På serversiden begrenser du hva kontoen får videresende i stedet for å stole på at klienten oppfører seg. PermitOpen, AllowTcpForwarding local og standard GatewayPorts no er de tre innstillingene som gjør en generell relé til en bestemt kanal.

Kontrakten er smal i begge retninger. SSH beskytter sin egen kanal, og et videre hopp fra bastionen til en annen applikasjon trenger sin egen beskyttelse. En tjeneste som bare lytter på bastionens loopback har en helt annen eksponering enn en som nås over et annet nettverk, og videresendingen endrer ikke det. Behold applikasjonens autentisering og TLS-kontroller i stedet for å behandle tunnelen som deres erstatning.

Dette fungerer godt for én forbindelse med én eier. I skala blir det et system: lokale portkonflikter, overvåking, nøkkelrotasjon og spørsmålet om hvem som starter videresendingen på nytt etter en omstart.

Trinn 3: er ruting det egentlige kravet?

Den listen er den ærlige prisen for det minste alternativet, og derfor erstatter team til slutt en håndfull glemte bakgrunnskommandoer med noe administrert. Erstatningen er ikke automatisk en VPN. Hvis kravet fortsatt er én TCP-port, er en overvåket videresending med dokumentert eier billigere å drive enn et overlegg, og den feiler på måter du kan se. Mål operasjonelt eierskap før du måler eleganse.

Ruting blir det riktige svaret når ruting er kravet. Flere applikasjoner som trenger vanlig IP-tilkobling, protokoller en TCP-videresending ikke kan bære, eller tjenester som flytter mellom verter peker alle samme vei.

Et overlegg gir deltakerne en adresse og en rute, og så begynner det egentlige arbeidet: ikke-overlappende områder, ruteeierskap, DNS, påmelding, tilbakekalling og hva som skjer når en peer forsvinner. Ingenting av det kommer med adressen. En peer som er tatt opp i overlegget er heller ikke automatisk autorisert for hver operasjon på destinasjonen, så autentisering på tjenestenivå består.

Hva du eier etterpå

To ting hører hjemme i registreringen du etterlater deg. Det første er identiteten klienten forventes å kontrollere, fordi hver av disse grensene forringes stille når en navnekontroll lempes for å få noe til å virke. Det andre er fjernelsestrinnet: hvilken nøkkel, hvilken regel eller hvilken rute forsvinner når tilgangen avsluttes, og hvem som utfører det.

Gjennomgangen slutter der den begynte, ved tjenesten. Velg grensen som dekker den faktiske trafikken og kontrollerer de peerne du mente å kontrollere, og skriv deretter ned hvordan tilgang oppdateres, overvåkes og fjernes. OpenSSH-referansen er stedet for å bekrefte videresendingsalternativene før du lover en smal kontrakt. Hvis du ikke kan beskrive fjernelsestrinnet i én setning, er grensen større enn problemet.