Oma TLS, SSH-edelleenohjaus vai VPN yhdelle pilvipalvelulle

Kysymys on harvoin siitä, pitäisikö kahden pilvikoneen välillä salata jotain; se on siitä, mitä rajapintaa salailet ja kuka tarkistaa kenen identiteetin. Aloitan nämä keskustelut palvelusta enkä verkkokaaviosta, koska palvelu tietää jo, mitä se tarvitsee. Kolme rajaa kattaa useimmat tapaukset: sovelluksen oma TLS, yksi SSH:n kautta edelleenohjattu TCP-portti ja reititetty päällekkäisverkko, joka antaa jokaiselle osallistujalle osoitteen. Niitä ei järjestetä voimakkuuden vaan sen mukaan, kuinka suuren osan ongelmasta ne kattavat.

Aloita palvelusta, älä verkosta

Liiku prosessista ulospäin. Mitä protokollaa se puhuu, minkä nimen asiakas tarkistaa ja kuka ylipäätään saa avata yhteyden? Nämä kolme vastausta karsivat vaihtoehtoja nopeammin kuin mikään vertailutaulukko, ja palvelun oma kokoonpano vastaa niihin yleensä muutamassa minuutissa.

Ota pieni sisäinen API, joka jo tarjoilee HTTPS:ää portissa 8443 sertifikaatilla api.internal.example-osoitteelle. ss -ltnp isännässä näyttää, mihin se sitoutuu, ja openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example näyttää, onko sertifikaatti voimassa nimelle, jota asiakas todella käyttää. Jos molemmat ovat kunnossa, palvelu voi suojata oman virtansa ja jäljelle jää vain tavoitettavuus. Se on paljon pienempi ongelma kuin verkon rakentaminen.

Vaihe 1: suojaako palvelu itseään?

Tämä on valinta, joka tehdään, kun se sopii, ja se sopii useammin kuin tiimit olettavat. Palvelun salaus kattaa koko polun asiakkaan ja palvelimen välillä, mukaan lukien jokainen hyppy niiden välissä, mitä mikään keskiosan ympärillä oleva tunneli ei paranna. Aseta odotettu nimi ja luottamus eksplisiittisesti sen sijaan, että luottaisit siihen, mitä asiakkaan oletusvarasto sattuu sisältämään.

Salaus ja tavoitettavuus pysyvät erillisinä kontrolleina, ja juuri niiden yhdistäminen on kohta, jossa tämä valinta menee pieleen. TLS-palvelu rajoittamattomassa julkisessa kuuntelijassa hyväksyy edelleen yhteydenottoja keneltä tahansa, joten kuuntelija ja verkkosäännöt on rajattava riippumatta siitä, että hyötykuorma on suojattu. Tarkista sitten riippuvuudet, koska TLS:n päällä oleva API ei kerro mitään löytöpäätepisteestä, ylläpitoportista tai vieressä olevasta massansiirtokanavasta. Jokainen niistä tarvitsee oman vastauksensa, ja yksi suojaamaton sisar riittää tekemään koko rajasta fiktiota.

Vaihe 2: onko yksi TCP-portti koko vaatimus?

Kun vaatimus on todella yksi TCP-portti, edelleenohjaus on pienin toimiva asia. SSH:n paikallinen edelleenohjaus kuljettaa tuon portin jo olemassa olevan todennetun yhteyden kautta.

Muoto on ssh -N -L 8443:127.0.0.1:8443 [email protected], ja tärkeä yksityiskohta on kohdeosoite: 127.0.0.1 ratkaistaan etäpäässä, joten yhteys palveluun avataan bastionilta eikä kannettavaltasi. Sido paikallinen kuuntelija kapeasti muodossa -L 127.0.0.1:8443:..., jotta et vahingossa julkaise palvelua omassa lähiverkossasi. Palvelimen puolella rajoita, mitä tili saa välittää, sen sijaan että luottaisit asiakkaan hyvään käytökseen. PermitOpen, AllowTcpForwarding local ja oletusarvoinen GatewayPorts no ovat kolme asetusta, jotka muuttavat yleiskäyttöisen releen tietyksi kanavaksi.

Sopimus on kapea molempiin suuntiin. SSH suojaa oman kanavansa, ja lisähyppy bastionilta toiseen sovellukseen tarvitsee oman suojauksensa. Palvelulla, joka kuuntelee vain bastionin loopbackissa, on täysin erilainen altistus kuin toisen verkon kautta saavutettavalla, eikä edelleenohjaus muuta sitä. Pidä sovelluksen todennus ja TLS-tarkistukset paikallaan sen sijaan, että pitäisit tunnelia niiden korvikkeena.

Tämä toimii hyvin yhdelle yhteydelle yhden omistajan kanssa. Mittakaavassa siitä tulee järjestelmä: paikalliset porttiristiriidat, valvonta, avainten kierrätys ja kysymys siitä, kuka käynnistää edelleenohjauksen uudelleen uudelleenkäynnistyksen jälkeen.

Vaihe 3: onko reititys varsinainen vaatimus?

Tuo luettelo on pienimmän vaihtoehdon rehellinen hinta, ja siksi tiimit lopulta korvaavat kourallisen unohdettuja taustakomentoja hallitulla ratkaisulla. Korvaaja ei ole automaattisesti VPN. Jos vaatimus on edelleen yksi TCP-portti, dokumentoidun omistajan valvoma edelleenohjaus on halvempi ylläpitää kuin päällekkäisverkko, ja se epäonnistuu näkyvästi. Mittaa operatiivinen omistajuus ennen kuin mittaat tyylikkyyttä.

Reitityksestä tulee oikea vastaus, kun reititys on vaatimus. Useat sovellukset, jotka tarvitsevat tavallista IP-yhteyttä, protokollat, joita TCP-edelleenohjaus ei voi kuljettaa, tai isäntien välillä liikkuvat palvelut osoittavat kaikki samaan suuntaan.

Päällekkäisverkko antaa osallistujille osoitteen ja reitin, ja sitten varsinainen työ alkaa: päällekkäisyyttömät alueet, reittien omistajuus, DNS, rekisteröinti, peruutus ja se, mitä tapahtuu, kun vertaiskumppani katoaa. Mikään siitä ei tule osoitteen mukana. Päällekkäisverkkoon hyväksytty vertaiskumppani ei myöskään ole automaattisesti valtuutettu jokaiseen kohteen toimintoon, joten palvelutason todennus säilyy.

Mikä omistat jälkeenpäin

Kaksi asiaa kuuluu jättämääsi kirjaukseen. Ensimmäinen on identiteetti, jonka asiakkaan odotetaan tarkistavan, koska jokainen näistä rajoista heikkenee hiljaa heti, kun nimien tarkistusta löysätään jonkin saamiseksi toimimaan. Toinen on poistovaihe: mikä avain, sääntö tai reitti katoaa, kun pääsy päättyy, ja kuka sen tekee.

Kävely päättyy sinne, mistä se alkoi, palveluun. Valitse raja, joka kattaa todellisen liikenteen ja tarkistaa ne vertaiskumppanit, jotka aioit tarkistaa, ja kirjaa sitten, miten pääsyä päivitetään, valvotaan ja poistetaan. OpenSSH-viite on paikka vahvistaa edelleenohjausasetukset ennen kuin lupaat kapean sopimuksen. Jos et voi kuvata poistovaihetta yhdellä lauseella, raja on suurempi kuin ongelma.