Oma TLS, SSH edastus või VPN ühe pilveteenuse jaoks

Küsimus on harva selles, kas kahe pilvemasina vahel midagi krüpteerida; see on, millist liidest te krüpteerite ja kes kelle identiteeti kontrollib. Alustan neid vestlusi teenusest, mitte võrguskeemist, sest teenus teab juba, mida ta vajab. Kolm piiri katavad enamiku juhtudest: rakenduse enda TLS, üks SSH kaudu edastatav TCP-port ja marsruuditud ülekate, mis annab igale osalejale aadressi. Neid ei järjestata tugevuse, vaid selle järgi, kui suure osa probleemist nad katavad.

Alustage teenusest, mitte võrgust

Liikuge protsessist väljapoole. Mis protokolli see räägib, millist nime klient kontrollib ja kellel üldse lubatakse ühendust avada? Need kolm vastust välistavad valikuid kiiremini kui ükski võrdlustabel ning teenuse enda konfiguratsioon annab need tavaliselt mõne minutiga.

Võtke väike sisemine API, mis juba teenindab HTTPS-i pordil 8443 sertifikaadiga api.internal.example jaoks. ss -ltnp hostis näitab, millega see seotud on, ja openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example näitab, kas sertifikaat kehtib nime jaoks, mida klient tegelikult kasutab. Kui mõlemad on terved, saab teenus oma voogu ise kaitsta ja järele jääb vaid kättesaadavus. See on palju väiksem probleem kui võrgu ehitamine.

Samm 1: kas teenus kaitseb end ise?

See on valik, mida valida, kui see sobib, ja see sobib sagedamini, kui meeskonnad eeldavad. Teenuse krüpteerimine katab kogu tee kliendi ja serveri vahel, sealhulgas iga hüppe nende vahel, mida ükski keskpaika ümbritsev tunnel ei paranda. Seadistage oodatav nimi ja usaldus selgesõnaliselt, selle asemel et loota sellele, mis kliendi vaikehoidlas juhtub olema.

Krüpteerimine ja kättesaadavus jäävad eraldi juhtelementideks ja just nende ühendamine on koht, kus see valik eksib. TLS-teenus piiramatul avalikul kuulajal võtab endiselt vastu ühenduskatseid kõigilt, seega tuleb kuulaja ja võrgureeglid piiritleda sõltumata sellest, et kasulik koormus on kaitstud. Seejärel kontrollige sõltuvusi, sest TLS-i kohal olev API ei ütle midagi avastamise lõpp-punkti, administraatori pordi ega kõrval oleva hulgiedastuskanali kohta. Igaüks neist vajab oma vastust ja ühest kaitsmata õest piisab, et kogu piir muutuks väljamõeldiseks.

Samm 2: kas üks TCP-port on kogu nõue?

Kui nõue on tõesti üks TCP-port, on edastus väikseim asi, mis töötab. SSH kohalik edastus kannab selle pordi juba olemasoleva autenditud ühenduse kaudu.

Kuju on ssh -N -L 8443:127.0.0.1:8443 [email protected] ja oluline üksikas on sihtaadress: 127.0.0.1 lahendatakse kaugküljel, seega avatakse ühendus teenusega bastionilt, mitte teie sülearvutist. Siduge kohalik kuulaja kitsalt kui -L 127.0.0.1:8443:..., et te ei avaldaks teenust kogemata oma kohalikus võrgus. Serveri poolel piirake, mida konto tohib edastada, selle asemel et usaldada kliendi head käitumist. PermitOpen, AllowTcpForwarding local ja vaikimisi GatewayPorts no on kolm seadet, mis muudavad üldotstarbelise relee kindlaks kanaliks.

Leping on kitsas mõlemas suunas. SSH kaitseb oma kanalit ja edasine hüpe bastionilt teise rakendusse vajab oma kaitset. Teenusel, mis kuulab ainult bastioni loopbackil, on täiesti erinev kokkupuude kui teenusel, mida saab teise võrgu kaudu, ja edastus ei muuda seda. Hoidke rakenduse autentimine ja TLS-kontrollid paigas, selle asemel et käsitleda tunnelit nende asendajana.

See töötab hästi ühe ühenduse ja ühe omaniku jaoks. Mahus muutub see süsteemiks: kohalikud pordikonfliktid, järelevalve, võtmete rotatsioon ja küsimus, kes taaskäivitab edastuse pärast taaskäivitust.

Samm 3: kas marsruutimine on tegelik nõue?

See loend on väikseima valiku aus hind ja seepärast asendavad meeskonnad lõpuks käputäie unustatud taustakäskude hallatava lahendusega. Asendus ei ole automaatselt VPN. Kui nõue on endiselt üks TCP-port, on dokumenteeritud omanikuga järelevalvatud edastus odavam käitada kui ülekate ja see ebaõnnestub viisil, mida näete. Mõõtke tööomandit enne, kui mõõdate elegantsust.

Marsruutimine muutub õigeks vastuseks, kui marsruutimine on nõue. Mitmed rakendused, mis vajavad tavalist IP-ühenduvust, protokollid, mida TCP edastus kanda ei suuda, või hostide vahel liikuvad teenused osutavad kõik samas suunas.

Ülekate annab osalejatele aadressi ja marsruudi ning siis algab tegelik töö: mittekattuvad vahemikud, marsruudi omand, DNS, registreerimine, tühistamine ja mis juhtub, kui partner kaob. Miski sellest ei tule aadressiga kaasa. Ülekattesse lubatud partner ei ole ka automaatselt volitatud sihtkoha iga toimingu jaoks, seega teenusetasandi autentimine jääb.

Mida te pärast omate

Kaks asja kuuluvad kirjesse, mille jätate. Esimene on identiteet, mida kliendilt oodatakse kontrollimist, sest igaüks neist piiridest halveneb vaikselt niipea, kui nimekontrolli lõdvendatakse, et midagi tööle saada. Teine on eemaldamise samm: milline võti, milline reegel või milline marsruut kaob, kui juurdepääs lõpeb, ja kes selle teeb.

Ringkäik lõpeb seal, kus algas, teenuse juures. Valige piir, mis katab tegeliku liikluse ja kontrollib neid partnerid, keda kavatsesite kontrollida, seejärel kirjutage üles, kuidas juurdepääsu uuendatakse, jälgitakse ja eemaldatakse. OpenSSH viide on koht, kus kinnitada edastusvalikud enne kitsa lepingu lubamist. Kui te ei suuda eemaldamise sammu ühe lausega kirjeldada, on piir probleemist suurem.