Egy laboratóriumi szerver, három bizalmi szerep, egy hiba tartomány

Minden működik, amíg a build futtató nem igényli ugyanazt a gazdagép-csatlakozót, amelyet a VPN vendég használ, és akkor senki nem tudja megmagyarázni, miért olvashat egy feladat kulcsokat az átjáróból. Minden egy gépre került, mert elfért, és minden vendég széles hozzáférést kapott, mert ez volt a leggyorsabb út, hogy működjön. Az eredmény egy gazdagép, amelynek bizalmi határa a tápkábel. A szerepek szétválasztása kevesebb munka, mint amilyennek hangzik, és a nevük megadásával kezdődik.

Három szerep, amely jelenleg mindent megoszt

A VPN-belépés, a privát szolgáltatások halmaza és a build futtató különböző dolgokat akarnak. Az elsőnek nyilvános portra és szűk hálózatra van szüksége a privát oldalon. A másodiknak tartós tárolásra és alkalmazási titkokra. A harmadik olyan kódot futtat, amelyet valaki más írt.

Éppen az teszi zavaróvá a tünetet, hogy mindhárom ugyanazt a hozzáférést kapja, mert utána bármelyik hatással lehet a többire. Az a build feladat, amely eléri a hipervizor csatlakozóját, olyan feladat, amely leállíthatja a VPN-t. A felügyeleti hálózat felé útvonallal rendelkező szolgáltatás-vendég módosíthatja a kapcsoló konfigurációját. A jogosultságok a probléma, és a folyamatlista csak az a hely, ahol ez látszik. A szerepek előzetes elnevezése minden jogosultságnak ad egy helyet, ahol élhet.

Az alábbi vázlat kiindulópont ehhez a felosztáshoz, nem magas rendelkezésre állási ígéret. Tekintse ellenőrizendő hipotézisnek, nem kész tervnek.

Három szerepet válasszon szét, ne három folyamatot

Három vendég egy gazdagépen három jogosultsági halmazt és három hálózati pozíciót ad. Nem ad három hiba tartományt, és a tervnek ezt hangosan ki kell mondania.

A szétválasztás csak akkor segít, ha az egyik vendég kompromittálása nem ad automatikusan jogosultságot a többieknek, és ez hipervizor-beállítás, nem elnevezési konvenció. Egy VM átjárónak nevezése nem akadályozza meg egy másik vendéget, hogy elérje a gazdagépet. Olvassa a virtuális kapcsoló konfigurációját a gazdagépnév helyett, majd erősítse meg, hogy minden vendég ott ül, ahol gondolja.

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

Írja fel a topológiát, majd ellenőrizze azokkal az eszközökkel, amelyek birtokolják. A rossz hídon megjelenő vendég lelet, nem részlet. Javítsa a hálózatot, mielőtt bármilyen szolgáltatáskonfigurációt módosít.

Hagyja, hogy a VPN vendég csak a saját ajtóit nyissa ki

Tegye közzé az alagút portját az útválasztón, és semmi mást. A vendégek felügyeleti portjai felügyeleti útvonalra tartoznak, nem az internetre, és a hipervizor saját csatolója is oda tartozik.

A privát oldali hálózatnak el kell érnie azokat a szolgáltatásokat, amelyekre a távoli felhasználóknak szükségük van, és ott meg kell állnia. Az alkalmazás-hitelesítés bekapcsolva marad, mert az alagút szállítás, nem bejelentkezés. Tartsa a VPN vendég útválasztási táblázatát elég kicsinek ahhoz, hogy egy mondatban leírja. Ha nem tudja ilyen egyszerűen leírni, a határ már elmosódott.

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

Semmi, ami a gazdagépen figyel, és a felügyelethez nem kell, nem figyelhet egyáltalán. Ez magában foglalja a hipervizor API-ját, amelyet könnyű nyitva hagyni egy nyilvános csatolón.

A build feladatoknak másfajta határ kell

A CI-feladat a tároló által vezérelt parancsokat futtat, így a bizalma attól függ, ki tud kódot küldeni. A shell végrehajtó ezeket a parancsokat a futtató felhasználójaként hajtja végre a gazdagépen, és ez a legszélesebb elérhető határ.

A konténer-végrehajtók szűkebbek, és a kiemelt konténer nem a szűkek közül való. Tartsa a futtatót a saját vendégében, saját hálózati hatókörrel, és csak azt az artefakt- és telepítési hozzáférést adja neki, amelyre a feladatoknak szükségük van. Az eldobható munkások csökkentik a megtartott állapotot; nem csökkentik az elérhetőséget vagy a titkok kitettségét. Mindkettőnek továbbra is kifejezett korlátok kellenek.

A szolgáltatás-vendég birtokolja az adatokat, ezért az ő biztonsági mentési terve az, amelynek működnie kell. Tartsa a tárolókat, a feltöltéseket és az adatbázist ugyanabban az ütemtervben. Teszteljen helyreállítást ahelyett, hogy a feladat állapotát olvasná.

Tervezze meg a hibát, amelyet mindhárom megoszt

Egy gazdagép egy hiba tartomány. Az újraindítás ugyanabban a pillanatban távolítja el az alagutat és minden privát szolgáltatást, és pontosan akkor számít a legtöbbet egy bejárat.

Tartson olyan konzolhozzáférést, amely nem függ a VPN vendégtől, legyen az fizikai konzol, sávon kívüli felügyeleti csatoló vagy szolgáltatói konzol. Az ugyanazon a lemezen tárolt pillanatkép nem független másolat, és az a biztonsági mentés sem, amely abban a vendégben fut, amelyet véd. Ezután tesztelje a hideg indítást sorrendként, nem ellenőrzőlistaként: gazdagép, virtuális hálózatok, alagútútvonal és egy megnevezett alkalmazás egy hétköznapi fiók alatt.

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'

A folyamatok indítási sorrendje semmit nem bizonyít az útvonalakról és a DNS-ről, ezért az útvonalat tesztelje, ne az egységek állapotát. Az útvonal az, amire egy távoli felhasználónak valóban szüksége van.