A tároló oldali snapshot egy remek dolog, mert különösebb terhelés nélkül a tároló szintjén akár konzisztens pillanatképek százai is létrehozhatók. Sok tároló tud magán ilyet készíteni, ezt nem lehet biztonságnak hívni. A hírekben olvashatta mindenki, hogy mentett meg egy snapshot egy vállalatot – tekintsünk el attól, hogy ehhez sikerhez a snapshot-nak van köze, amit az elmúlt 10 évben értékesített összes tároló tud – kb még az otthoni NAS kategória is. Nézzük meg mikor nem segít azonban ez sem.
Mentési megoldásba integrált tároló
Például ha Veeam mentőrendszerem van és storage snapshot alapú mentésem, azaz a Veeam beszél a tárolóval és ő mondja neki, hogy készítsen snapshot-ot, majd a mentés ebből a snapshot-ból történik. Alább egy ilyen mentési folyamatot láthattok.
Az is lehetséges, hogy a Veeam vezérelje a tárolón a megőrzési időket is, tulajdonképpen ekkor szigorúan vett mentés nem is fut le, hiszen a storage snapshot-ot elkészítteti a tárolóval, de abból nem ment ki adatot valami repository-ra, hanem csak komponánja a snapshot-ok készítését és adott idő utáni törlését.
Mindkét esetben magában a Veeam-ben is megjelennek a pillanatképek, új készíthető onnan – is – és persze törölhető is bármelyik. Sőt azok is, amiknek semmi köze a mentéshez, teljesen függetelnül attól, hogy melyik felhasználó hozta létre
És ez itt a baj. Nem a Veeam a hibás, hanem a tároló, ami a felhasználók által készített snapshot-okat nem képes külön jogosultságok mentén kezelni.
Láttunk már olyan támadást, ahol akkurátusan a mentőrendszer volt az elsődleges célpont és ott tisztára töröltek minden repository-t, letöröltek minden szalagot és ha lett volna snapshot a tárolón – és az a tároló úgy működik mint az alábbi – akkor azon pillatatképek is megsemmisültek volna. Sőt, ha a mentőrendszer vezérli a storage oldali snapshot készítését, akkor elég gyorsan ki tudja futtatni a snapshot-okat is, mivel minden tároló csak meghatározott számút tud kezelni.
Példa
Egy méltán népszerű tárolón mutatom be, hogy a tárolón ütemezett snapshot – amihez köze nincs a Veeam – nek így jelenik meg. Ezen az első képen a tároló az „admin” felhasználóval van Veeam-be kötve.
Cseréljük le a fenti felhasználót, inkább valami másikra. Az általam használ tárolón elérhető pár szerepkör, tehát például van operator – aki tud snapshot-ot készíteni de törölni nem. Érezzük, hogy ez nem túlságosan használható a mentési rendszerben, mert hiába tud snapshot-ot készíteni a Veeam, ha a mentés végeztével – sőt soha az életben – nem tudja majd letörölni azt – kézzel kell majd takarítani.
Van „poweruser” role is, na az már mindent tud törölni, olyat is amit amúgy a tárolón hoztam létre admin-nal. Pont ez a probléma…..
Tehát nagyon fontos, hogy ha ilyen tárolóval rendelkezünk – ami nem tudja a felhasználói fiókok által készített snapshot-ok elválasztására – akkor ne storage integrált mentést alkalmazzunk – pl VMware snapshot-ból történjen a mentés – ezáltal nem kell bekötni a tárolót a Veeam mentőrendszerbe vagy olyan tárolót válasszunk, ahol egy adott tároló oldali felhasználó amit a mentőrendszer használ, nem tudja egy másik felhasználó elkészített pillanatképeit letörölni. Az is megoldás, ha a tároló oldalán bekapcsolható virtual lock, ami mentén sem a Veeam, sem a tároló adminja sem tud snapshot-ot törölni.
A fenti példában ez láthatóan nincs így, pedig egy méltán híres és népszerű tárolóról van szó. Érdemes megkérdezni a tároló gyártóját tud-e ilyet a terméke és ha nem, akkor mikor fogja tudni. Az is érdemes megkérdezni milyen MFA/2FA-t támogat a tároló, mert a felhasználó/jelszó páros az eléggé kevés biztonságot ad.
UPDATE (2023-07-01): Van olyan gyártó, akinek 4 éve megvásárolt és azóta csak átnevezgetett tárolója, csak pár hete tudja, azt is csak a legfrissebb firmware-telepítése után. Tehát a fenti eset és a hírekben olvasott csoda esetén, puszta mázli volt, hogy a snapshot-ok megmaradtak. Már végre tudja a tároló azt, amit eddig is kellett volna neki csak eddig nem beszéltek róla.
Offsite mentés legyen, immutable formában, a többi grátisz és szerencse – vagy szerencsés kimenetele a nem elvégzett integrációnak/elfelejtett jelszavaknak – lehet róla írni szép posztokat. Teszem hozzá, ha elfelejtem az admin jelszót, akkor biztosan nem frissítettem a tárolót, nem is nagyon néztem rá – utóbbit mondjuk adott gyártó felhős szolgáltatásával még talán me tudom tenni – nem üzemeltettem azt.
Milyen megoldások vannak?
Ha a snapshot az adatbizonsági stratégia ilyen kiemelt eleme és végső védelmi vonala:
- Használj olyan elsődleges tárolót, ami az elválasztást tudja. Ha nem tudja, akkor ne tedd be mentési rendszeredbe ilyen szinten azt a tárolót.
- Ha két egymásra replikálni képes tárolód van, akkor a replikálj a másikra és azt ne tedd be a mentési rendszeredbe.
- Olyan tárolót vásárolj, ami tud virtual lock-ot.
Ha viszont mentésről beszélünk és nem csak pillanatképekről, akkor ezek jöhetnek szóba:
- Szokásos szalagos mentés, kivéve a kazettákat a mentés után.
- Hardened repository vagy valamilyen object storage ami immutable.
- Felhőbe történő mentés – pl az általam épített és az 99999-nél elérhető offsite mentési célterület – ahol szintén immutable tud lenni a mentési másolat.
