Vienas laboratorijos serveris, trys pasitikėjimo vaidmenys, viena gedimo sritis

Viskas veikia tol, kol kūrimo vykdytojui prireikia to paties hosto lizdo, kurį naudoja VPN svečias, ir tada niekas negali paaiškinti, kodėl užduotis gali skaityti šliuzo raktus. Viskas buvo įdiegta vienoje mašinoje, nes tilpo, o kiekvienas svečias gavo plačią prieigą, nes tai buvo greičiausias būdas priversti tai veikti. Rezultatas – hostas, kurio pasitikėjimo riba yra maitinimo kabelis. Vaidmenų atskyrimas reikalauja mažiau darbo nei atrodo, ir jis prasideda nuo jų pavadinimų.

Trys vaidmenys, kurie šiuo metu dalijasi viskuo

VPN įėjimas, privačių paslaugų rinkinys ir kūrimo vykdytojas nori skirtingų dalykų. Pirmajam reikia viešo prievado ir siauro tinklo privačioje pusėje. Antrajam reikia nuolatinės saugyklos ir programos paslapčių. Trečiasis vykdo kodą, kurį parašė kas nors kitas.

Būtent tai, kad visi trys gauna tą pačią prieigą, daro simptomą painų, nes tada bet kuris iš jų gali paveikti kitus. Kūrimo užduotis, kuri pasiekia hipervizoriaus lizdą, yra užduotis, kuri gali sustabdyti VPN. Paslaugų svečias su maršrutu į valdymo tinklą gali pakeisti komutatoriaus konfigūraciją. Teisės yra problema, o procesų sąrašas tėra vieta, kur tai matosi. Vaidmenų pavadinimas iš anksto suteikia kiekvienai teisei vietą gyventi.

Žemiau esantis eskizas yra to padalijimo atspirties taškas, o ne aukšto prieinamumo pažadas. Traktuokite jį kaip hipotezę, kurią reikia patikrinti, o ne kaip baigtą projektą.

Atskirkite tris vaidmenis, o ne tris procesus

Trys svečiai viename hoste duoda tris teisių rinkinius ir tris tinklo pozicijas. Jie neduoda trijų gedimo sričių, ir projektas turėtų tai pasakyti garsiai.

Atskyrimas padeda tik tada, kai vieno svečio kompromitavimas automatiškai nesuteikia teisių kitiems, ir tai yra hipervizoriaus nustatymas, o ne pavadinimų konvencija. VM pavadinus šliuzu, kitas svečias vis tiek pasieks hostą. Skaitykite virtualaus komutatoriaus konfigūraciją, o ne hosto vardą, tada patvirtinkite, kad kiekvienas svečias yra ten, kur manote.

host
├─ vpn-gw      10.60.10.2/24   public 51820/udp only
├─ services    10.60.0.10/24   no route to the management network
└─ ci-runner   10.60.20.2/24   outbound only, no host socket

Užrašykite topologiją ir tada patikrinkite ją įrankiais, kuriems ji priklauso. Svečias, pasirodęs netinkamame tilte, yra radinys, o ne smulkmena. Ištaisykite tinklą prieš keisdami bet kokią paslaugos konfigūraciją.

Leiskite VPN svečiui atidaryti tik tas duris, kurios jam priklauso

Paskelbkite tunelio prievadą maršrutizatoriuje ir nieko daugiau. Svečių administravimo prievadai priklauso valdymo keliui, o ne internetui, ir paties hipervizoriaus sąsaja taip pat priklauso ten.

Privačios pusės tinklas turėtų pasiekti paslaugas, kurių reikia nuotoliniams naudotojams, ir ten sustoti. Programos autentifikavimas lieka įjungtas, nes tunelis yra transportas, o ne prisijungimas. Laikykite VPN svečio maršrutų lentelę pakankamai mažą, kad ją apibūdintumėte vienu sakiniu. Jei negalite jos taip paprastai apibūdinti, riba jau susiliejusi.

virsh net-list --all
virsh net-dumpxml lab-private
sudo nft list ruleset | grep -n -E '51820|10.60'

Viskas, kas klausosi hoste ir nėra reikalinga valdymui, neturėtų klausytis apskritai. Tai apima hipervizoriaus API, kurį lengva palikti atvirą viešoje sąsajoje.

Kūrimo užduotims reikia kitokio tipo ribos

CI užduotis vykdo saugyklos kontroliuojamas komandas, todėl jos pasitikėjimas priklauso nuo to, kas gali siųsti kodą. Shell vykdytojas vykdo tas komandas kaip vykdytojo naudotojas hoste, ir tai yra plačiausia prieinama riba.

Konteinerių vykdytojai yra siauresni, o privilegijuotas konteineris nėra vienas iš siaurųjų. Laikykite vykdytoją savo svečioje su savo tinklo apimtimi ir duokite jam tik tą artefaktų ir diegimo prieigą, kurios reikia užduotims. Vienkartiniai darbuotojai sumažina išlaikomą būseną; jie nesumažina pasiekiamumo ar paslapčių atskleidimo. Abiem vis dar reikia aiškių ribų.

Paslaugų svečias valdo duomenis, todėl jo atsarginių kopijų planas yra tas, kuris turi veikti. Laikykite saugyklas, įkėlimus ir duomenų bazę tame pačiame grafike. Išbandykite atkūrimą, o ne skaitykite užduoties būseną.

Planuokite gedimą, kurį visi trys dalijasi

Vienas hostas yra viena gedimo sritis. Perkrovimas pašalina tunelį ir kiekvieną privačią paslaugą tuo pačiu momentu, ir būtent tada kelias į vidų yra svarbiausias.

Išsaugokite konsolės prieigą, kuri nepriklauso nuo VPN svečio, ar tai būtų fizinė konsolė, juostos išorinė valdymo sąsaja ar teikėjo konsolė. Toje pačioje diske saugoma momentinė kopija nėra nepriklausoma kopija, o atsarginė kopija, kuri veikia saugomo svečio viduje, taip pat ne. Tada išbandykite šaltą paleidimą kaip seką, o ne kaip kontrolinį sąrašą: hostas, virtualūs tinklai, tunelio kelias ir viena pavadinta programa pagal įprastą paskyrą.

virsh list --all
systemctl is-active libvirtd
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://10.60.0.10/
ss -ltnp | grep -E ':51820|:443'

Procesų paleidimo tvarka nieko neįrodo apie maršrutus ir DNS, todėl bandykite kelią, o ne vienetų būsenas. Kelias yra tai, ko nuotoliniam naudotojui iš tikrųjų reikia.