Savas TLS, SSH peradresavimas ar VPN vienai debesijos paslaugai

Klausimas retai kada yra, ar šifruoti ką nors tarp dviejų debesijos mašinų; klausimas yra, kurią sąsają šifruojate ir kas tikrina kieno tapatybę. Šiuos pokalbius pradedu nuo paslaugos, o ne nuo tinklo schemos, nes paslauga jau žino, ko jai reikia. Trys ribos apima daugumą atvejų: pačios programos TLS, vienas per SSH peradresuojamas TCP prievadas ir maršrutizuotas perdangos tinklas, suteikiantis kiekvienam dalyviui adresą. Jos rikiuojamos ne pagal stiprumą, o pagal tai, kiek problemos apima.

Pradėkite nuo paslaugos, ne nuo tinklo

Eikite nuo proceso į išorę. Kokiu protokolu ji kalba, kokį vardą tikrins klientas ir kam apskritai leidžiama atidaryti ryšį? Šie trys atsakymai pašalina variantus greičiau nei bet kuri palyginimo lentelė, o pačios paslaugos konfigūracija paprastai juos pateikia per kelias minutes.

Paimkite mažą vidinį API, kuris jau teikia HTTPS 8443 prievade su sertifikatu api.internal.example. ss -ltnp pagrindiniame kompiuteryje parodo, prie ko jis prisirišęs, o openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example parodo, ar sertifikatas galioja vardui, kurį klientas iš tikrųjų naudos. Jei abu sveiki, paslauga gali apsaugoti savo srautą ir lieka tik pasiekiamumas. Tai daug mažesnė problema nei statyti tinklą.

1 žingsnis: ar paslauga apsaugo save?

Tai variantas, kurį rinktis, kai jis tinka, ir jis tinka dažniau, nei komandos mano. Paslaugos šifravimas apima visą kelią tarp kliento ir serverio, įskaitant kiekvieną šuolį tarp jų, ko nepagerina joks tunelis aplink vidurį. Nustatykite laukiamą vardą ir pasitikėjimą aiškiai, o ne pasikliaukite tuo, ką kliento numatytoji saugykla atsitiktinai turi.

Šifravimas ir pasiekiamumas lieka atskirais valdikliais, ir būtent jų sujungimas yra vieta, kur šis variantas suklysta. TLS paslauga neapribotame viešame klausytoje vis dar priima ryšio bandymus iš bet ko, todėl klausytojas ir tinklo taisyklės turi būti apibrėžti nepriklausomai nuo to, kad turinys apsaugotas. Tada patikrinkite priklausomybes, nes API per TLS nieko nesako apie aptikimo galinį tašką, administravimo prievadą ar šalia esantį masinio perdavimo kanalą. Kiekvienam jų reikia savo atsakymo, o vieno neapsaugoto brolio pakanka, kad visa riba taptų fikcija.

2 žingsnis: ar vienas TCP prievadas yra visas reikalavimas?

Kai reikalavimas tikrai yra vienas TCP prievadas, peradresavimas yra mažiausias veikiantis dalykas. SSH vietinis peradresavimas perneša tą prievadą per jau egzistuojantį autentifikuotą ryšį.

Forma yra ssh -N -L 8443:127.0.0.1:8443 [email protected], o svarbi detalė yra tikslo adresas: 127.0.0.1 sprendžiamas nuotolinėje pusėje, todėl ryšys su paslauga atidaromas iš bastiono, o ne iš jūsų nešiojamojo kompiuterio. Pririškite vietinį klausytoją siaurai kaip -L 127.0.0.1:8443:..., kad netyčia nepaskelbtumėte paslaugos savo vietiniame tinkle. Serverio pusėje apribokite, ką paskyra gali peradresuoti, o ne pasikliaukite geru kliento elgesiu. PermitOpen, AllowTcpForwarding local ir numatytasis GatewayPorts no yra trys nustatymai, paverčiantys bendrą relę konkrečiu kanalu.

Sutartis siaura abiem kryptimis. SSH saugo savo kanalą, o tolesnis šuolis iš bastiono į kitą programą reikalauja savo apsaugos. Paslauga, klausanti tik bastiono loopback, turi visiškai kitokią ekspoziciją nei pasiekiama per kitą tinklą, ir peradresavimas to nekeičia. Išlaikykite programos autentifikavimą ir TLS patikras, o ne traktuokite tunelį kaip jų pakaitalą.

Tai gerai veikia vienam ryšiui su vienu savininku. Mastelyje tai tampa sistema: vietiniai prievadų konfliktai, priežiūra, raktų rotacija ir klausimas, kas paleis peradresavimą iš naujo po perkrovimo.

3 žingsnis: ar maršrutizavimas yra tikrasis reikalavimas?

Tas sąrašas yra sąžininga mažiausio varianto kaina, ir todėl komandos galiausiai pakeičia saują pamirštų fono komandų valdomu sprendimu. Pakaitalas nebūtinai yra VPN. Jei reikalavimas vis dar vienas TCP prievadas, prižiūrimas peradresavimas su dokumentuotu savininku pigiau eksploatuojamas nei perdanga ir nepavyksta matomais būdais. Matuokite operacinę nuosavybę prieš matuodami eleganciją.

Maršrutizavimas tampa teisingu atsakymu, kai maršrutizavimas yra reikalavimas. Kelios programos, kurioms reikia įprasto IP ryšio, protokolai, kurių TCP peradresavimas negali pernešti, ar paslaugos, judančios tarp pagrindinių kompiuterių, visi rodo ta pačia kryptimi.

Perdanga suteikia dalyviams adresą ir maršrutą, tada prasideda tikrasis darbas: nesikertantys diapazonai, maršrutų nuosavybė, DNS, registracija, atšaukimas ir kas nutinka, kai partneris dingsta. Niekas iš to neateina su adresu. Į perdangą priimtas partneris taip pat nėra automatiškai įgaliotas kiekvienai operacijai paskirties vietoje, todėl paslaugos lygio autentifikavimas lieka.

Ką turite po to

Dalykai du priklauso įrašui, kurį paliekate. Pirmasis yra tapatybė, kurią klientas turi patikrinti, nes kiekviena iš šių ribų tyliai prastėja, kai tik vardo patikra sušvelninama, kad kažkas veiktų. Antrasis yra pašalinimo žingsnis: kuris raktas, taisyklė ar maršrutas dingsta pasibaigus prieigai, ir kas tai atlieka.

Apžvalga baigiasi ten, kur prasidėjo, prie paslaugos. Pasirinkite ribą, kuri apima tikrąjį srautą ir patikrina tuos partnerius, kuriuos ketinote patikrinti, tada užrašykite, kaip prieiga atnaujinama, stebima ir pašalinama. OpenSSH nuoroda yra vieta patvirtinti peradresavimo parinktis prieš žadant siaurą sutartį. Jei negalite aprašyti pašalinimo žingsnio vienu sakiniu, riba didesnė už problemą.