Abszolút valid, amit az rsync + céloldali ZFS snapshotról írsz. Nem vitatom a te megoldásod helyességét, más szemléletű mint az enyém.
A "legutolsó bástya" felvetésed, amit most "pull" modellű mentésnek nevezek különösen tetszik. Ez OPSEC szempontból tényleg egy sokkal erősebb felállás. Ha ne adj' Isten feltörik az elsődleges szervert, a támadó nem talál semmilyen SSH kulcsot vagy IP-címet, ami elvezetné a mentésemhez. Ez egy hatalmas plusz védelmi pont, amit az én megoldásom nem tud.
Azonban továbbra is fenntartom az aggályaimat a sima rsync-kel szemben, amit a zfs send/receive natívan megold. Illetve előny ha nincs publikus SSH kapu. De ezek tényleg tökéletesség hajszolása érvek, mert összességében teljesen jó a te megoldás is.
A probléma: Én alapelvből soha nem teszek ki SSH portot a nyílt internetre. Már 10 éve is automatizált botok ezrei döngették a 22-es, sőt bármelyik másik portot ssh után kutatva, és ez ma csak rosszabb. Hiába biztonságos az OpenSSH, már azzal kárt okoznak, hogy terhelik a gépet és tele spam-elik a logokat.
Emiatt nálam a két szerver az Elsődleges és a Bástya kizárólag egy WireGuard VPN-en keresztül látja egymást. A WireGuard UDP-alapú "rejtőzködő kapu". tökéletes peremvédelmet ad, a támadók számára a szerverek nem is léteznek a hálózaton.
És itt jön a csavar, ami megváltoztatja a "pull" modell előnyét. Ha mindkét gép ugyanabban a belső VPN-ben van (pl. 10.0.0.0/24), akkor a "pull" modell fő előnye, a rejtettség azonnal elpárolog. Ha egy támadó bejut az Elsődleges gépemre, egy egyszerű nmap szkenneléssel a belső VPN hálózaton azonnal megtalálja a Bástya gép IP-címét.
Mivel a rejtettség már nem tényező, a kérdés már csak az, hogy melyik modell nyújt jobb kárcsökkentést egy sikeres behatolás után?
Szóval Ransomware és a Snapshotok
Először is, az sajnos igaz, hogy a "lassú" zsarolóvírus ellen sem az rsync, sem a zfs send nem véd meg. A ZFS sem végez tartalom-elemzést. Ha a vírus lassan titkosít, és én arról készítek snapshotokat, akkor a mentésembe (mindkét modellnél) ugyanúgy bekerül a titkosított adat.
A valódi védelem itt a régi, tiszta snapshotok megőrzése (retention), és ami még fontosabb: a régi snapshotok aktív védelme a törlés ellen.
A Biztonságosabb Architektúra szerintem: VPN + "PUSH" (WORM)
Ha a támadó az Elsődlegesről mindenképpen látni fogja a Bástyát a VPN-en belül, az a stratégia nyer, amelyik jobban felkészül erre a találkozásra.
A "PULL" modell (VPN-en belül):
Kockázat a bástya gépen ott vannak az SSH kulcsok visszafelé Elsődleges felé, és a bástyának "root" joga van saját magán, hogy a régi snapshotokat törölje (zfs destroy). Ha a támadó a VPN-en átjutva (bárhogyan) feltöri a bástyát, az a totális katasztrófa. Mindent visz: törli az összes mentést és a kulcsokkal átugrik az Elsődlegesre is.
"PUSH" (WORM) modell (VPN-en belül):
A védelem, hogy az Elsődleges gép indítja a replikációt. A támadó az Elsődlegest feltörve megtalálja a bástya IP-címét és az SSH kulcsot.
De a Bástya oldalon ez az SSH kulcs brutálisan le van korlátozva a zfs allow segítségével. Csak és kizárólag zfs recv (fogadás) és zfs snapshot (létrehozás) joga van. De zfs destroy (törlés) joga NINCS.
Eredmény: A támadó át tud jutni a bástyára. Megpróbálja törölni a 180 napnyi tiszta mentést, de "Permission denied" hibát kap. A régi mentések biztonságban vannak. A kár megáll, legfeljebb teleírhatja a lemezt új, titkosított snapshotokkal, de az adat megmarad.
Ezért az én esetemben, ahol a VPN az alap, a "PUSH + WORM" modell tűnik a legbiztonságosabbnak. A VPN védi a bejáratot, amiről feltételezem hogy védettebb kapu mint az SSH, a ZFS WORM-jogosultságai pedig megvédik a már meglévő adatokat egy sikeres behatolás esetén.
Ezeket végiggondolva pedig ez egy plusz érv a CrashPlan mellett, ami soha nem törli automatikusan a régi fájlverziókat, ellentétben a Backblaze Personal 30 napos szabályával.
Illetve a támadó az Elsődleges gépen maximum a klienst éri el, de a kliensből nem tudja törölni a régi, jó fájlverziókat.