Pašu TLS, SSH pāradresēšana vai VPN vienam mākoņpakalpojumam

Jautājums reti ir par to, vai starp divām mākoņa mašīnām kaut ko šifrēt; jautājums ir, kuru saskarni jūs šifrējat un kas pārbauda kā identitāti. Šīs sarunas sāku ar pakalpojumu, nevis ar tīkla diagrammu, jo pakalpojums jau zina, kas tam vajadzīgs. Trīs robežas aptver lielāko daļu gadījumu: pašas lietotnes TLS, viens caur SSH pāradresēts TCP ports un maršrutēts pārklājums, kas katram dalībniekam piešķir adresi. Tās netiek kārtotas pēc stipruma, bet pēc tā, cik lielu problēmas daļu tās aptver.

Sāciet ar pakalpojumu, nevis ar tīklu

Ejiet no procesa uz āru. Kādā protokolā tas runā, kādu vārdu pārbaudīs klients un kam vispār ir atļauts atvērt savienojumu? Šīs trīs atbildes izslēdz variantus ātrāk nekā jebkura salīdzināšanas tabula, un paša pakalpojuma konfigurācija parasti tās sniedz dažu minūšu laikā.

Paņemiet mazu iekšēju API, kas jau nodrošina HTTPS 8443 portā ar sertifikātu api.internal.example. ss -ltnp uz resursdatora parāda, kam tas piesaistīts, un openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example parāda, vai sertifikāts ir derīgs vārdam, ko klients faktiski izmantos. Ja abi ir veseli, pakalpojums var aizsargāt savu plūsmu un paliek tikai sasniedzamība. Tā ir daudz mazāka problēma nekā tīkla būvēšana.

1. solis: vai pakalpojums aizsargā sevi?

Šis ir variants, ko izvēlēties, kad tas der, un tas der biežāk, nekā komandas pieņem. Pakalpojuma šifrēšana aptver visu ceļu starp klientu un serveri, ieskaitot katru lēcienu starp tiem, ko neuzlabo neviens tunelis ap vidu. Iestatiet gaidāmo vārdu un uzticēšanos skaidri, nevis paļaujoties uz to, ko klienta noklusējuma krātuve nejauši satur.

Šifrēšana un sasniedzamība paliek atsevišķas kontroles, un tieši to apvienošana ir vieta, kur šis variants kļūdās. TLS pakalpojums neierobežotā publiskā klausītājā joprojām pieņem savienojuma mēģinājumus no jebkura, tāpēc klausītājs un tīkla noteikumi ir jādefinē neatkarīgi no tā, ka lietderīgā slodze ir aizsargāta. Pēc tam pārbaudiet atkarības, jo API virs TLS neko nepasaka par atklāšanas galapunktu, administratora portu vai blakus esošo lielapjoma pārsūtīšanas kanālu. Katram no tiem vajaga savas atbildes, un ar vienu neaizsargātu brāli pietiek, lai visa robeža kļūtu par izdomājumu.

2. solis: vai viens TCP ports ir visa prasība?

Kad prasība tiešām ir viens TCP ports, pāradresēšana ir mazākā lieta, kas darbojas. SSH vietējā pāradresēšana pārnēsā šo portu caur jau esošu autentificētu savienojumu.

Forma ir ssh -N -L 8443:127.0.0.1:8443 [email protected], un svarīgā detaļa ir mērķa adrese: 127.0.0.1 tiek atrisināta attālajā pusē, tāpēc savienojums ar pakalpojumu tiek atvērts no bastiona, nevis no jūsu portatīvā datora. Piesieniet vietējo klausītāju šauri kā -L 127.0.0.1:8443:..., lai nejauši nepublicētu pakalpojumu savā vietējā tīklā. Servera pusē ierobežojiet, ko konts drīkst pāradresēt, nevis paļaujieties uz klienta labu uzvedību. PermitOpen, AllowTcpForwarding local un noklusējuma GatewayPorts no ir trīs iestatījumi, kas vispārēju releju pārvērš konkrētā kanālā.

Līgums ir šaurs abos virzienos. SSH aizsargā savu kanālu, un tālākam lēcienam no bastiona uz citu lietotni vajadzīga sava aizsardzība. Pakalpojumam, kas klausās tikai bastiona loopback, ir pavisam cita pakļautība nekā tam, kas sasniedzams caur citu tīklu, un pāradresēšana to nemaina. Saglabājiet lietotnes autentifikāciju un TLS pārbaudes, nevis uzskatiet tuneli par to aizstājēju.

Tas labi darbojas vienam savienojumam ar vienu īpašnieku. Mērogā tas kļūst par sistēmu: vietējie portu konflikti, uzraudzība, atslēgu rotācija un jautājums, kas restartē pāradresēšanu pēc pārstartēšanas.

3. solis: vai maršrutēšana ir īstā prasība?

Šis saraksts ir godīgā mazākā varianta cena, un tāpēc komandas galu galā aizstāj sauju aizmirstu fona komandu ar kaut ko pārvaldītu. Aizstājējs nav automātiski VPN. Ja prasība joprojām ir viens TCP ports, uzraudzīta pāradresēšana ar dokumentētu īpašnieku ir lētāka ekspluatācijā nekā pārklājums, un tā neizdodas redzamos veidos. Mēriet operatīvo īpašumtiesības pirms elegances mērīšanas.

Maršrutēšana kļūst par pareizo atbildi, kad maršrutēšana ir prasība. Vairākas lietotnes, kurām vajadzīgs parasts IP savienojamība, protokoli, ko TCP pāradresēšana nevar pārnēsāt, vai pakalpojumi, kas pārvietojas starp resursdatoriem, visi norāda vienā virzienā.

Pārklājums piešķir dalībniekiem adresi un maršrutu, un tad sākas īstais darbs: nepārklājoši diapazoni, maršrutu īpašumtiesības, DNS, reģistrācija, atsaukšana un kas notiek, kad partneris pazūd. Nekas no tā nenāk kopā ar adresi. Pārklājumā uzņemts partneris arī nav automātiski pilnvarots katrai darbībai galamērķī, tāpēc pakalpojuma līmeņa autentifikācija paliek.

Kas jums pieder pēc tam

Divi dalībnieki pieder ierakstam, ko atstājat. Pirmais ir identitāte, kas klientam jāpārbauda, jo katra no šīm robežām klusi pasliktinās, tiklīdz vārda pārbaude tiek mīkstināta, lai kaut kas darbotos. Otrais ir noņemšanas solis: kura atslēga, noteikums vai maršruts pazūd, kad piekļuve beidzas, un kas to veic.

Pārskats beidzas tur, kur sākās, pie pakalpojuma. Izvēlieties robežu, kas aptver faktisko trafiku un pārbauda tos partnerus, kurus bijāt iecerējuši pārbaudīt, pēc tam pierakstiet, kā piekļuve tiek atjaunināta, uzraudzīta un noņemta. OpenSSH atsauce ir vieta, kur apstiprināt pāradresēšanas opcijas pirms šaura līguma apsolīšanas. Ja nevarat aprakstīt noņemšanas soli vienā teikumā, robeža ir lielāka par problēmu.