Hands on a Rubrik-kal – első rész

Lehet már öreg vagyok és egyre kevésbé bírom lenyelni a kamut. A gyártói marketing végtelen mocsara, hangzatos hívószavakban bővelkedik és ha ez nem lenne elég, semmitmondó rendezvényeken a semmi magyarázása és mutogatása tetétzi az elményt. Egyetlen ügyfelet sem a a rövidítések és átcimkézett – és egyébként 20 éve a piacon lévő – funkció érdekli, hanem mit tud pontosan a termék és az megoldás-e a problémájára. Ezért én inkább szeretem átugrani ezeket a részeket és saját tapasztalatot szerezni, ráadásul nem kattintgatható demó-ban – ami egy vezetett HTML – és nem is egy a világ másik felén lévő preparált adatközpontban lévő rendszerben, hanem úgy, hogy meg tudjam fogni kézzel és én állíthassam be az alapjaitól.

A munkáltatóm Rubrik partner lett és ennek keretében kaptunk egy demo rendszert, annak minden bekapcsolható és engedélyezhető képességével együtt.

Mindenkinek van mentése

A Rubrik bemutatómban érintettem a kérdést, de azóta beszélgettem több ügyféllel a mentési rendszerükről és egyre jobban látom a kihívást, amit érezhetnek. A ransomware-től nagyon tartanak és nem férek hozzá ilyen hazai statisztikákhoz, de az a rémhír, hogy több és több szervezetet érint és fog érinteni egy-egy ilyen támadás, legyen az célzott vagy csak úgy a sörét mentén szórványos. Hogy egy zsarolóvírus miképp kerül be egy rendszerbe és terjed el most vegyük irrelevánsnak és tételezzük fel, hogy most van az a pillanat, hogy kezd terjedni. A védelmi vonalakat szintén úgy veszem, hogy nincsenek vagy ha vannak, akkor azokon mint kés a vajon jut át a fertőzés. Mindenkinek van – lennie kellene – kiszolgáló oldali mentéssel – értsd az adatközpontban keletkező adatokat menti – kliens oldalon ritkábban. Sőt, van aki több ilyennel rendelkezik, de ez nem véletlen. A több tíz évre nyúló megőrzési idő mellett könnyen lehet a lecserélt mentési szofvert is életben kell tartani azzal párhuzamosan, amire lecseréltük.

Az adatok védelme egy réteges dolog kell legyen, minden rétegben a lehetőségekhez/költségekhez arányosan törekedni kell az adatok biztonságának elérésére. A virtualizáció és alapvetően a nem virtualizált rendszerek mögött (ha nem lokális a tároló), valamilyen központi tároló van használatban vagy valamilyen software defined storage (valljuk be a HCI mégsem/még nem vette át a piac nagyobb részét). Előbbi esetben a központi tárolón végzett snapshot is már egy olyan lehetőség, amit érdemes megragadni, még akkor is, ha például nem képes konzisztens mentést létrehozni – a semminél biztosan jobb. Lehetett olvasni mostanság arról, hogy pont egy ilyen mentett meg egy céget, teszem hozzá, akármilyen tároló lehetett volna ott, ami snapshot-ot tud készíteni. Software defined storage esetén – VSAN pl – VM-ekről lehet snapshot-ot készíteni, de az nem ekivalens egy tároló oldali snapshot-tal. Ha egy VSAN-on elhelyezkedő VM-et letörlök, akkor a snapshot is vele törlődik.

A ransomware egy más történet, de legyen a védelmi vonal valamilyen mentőrendszer vagy a kötelmúltban végtelenül nagy dobra vert snapshot, nem igazán lehet tudni, melyik mentést, melyik snapshot-ot kellene visszarakni, mikor nem volt még fertőzött valami/minden. Ezeket próbálgatni lehet, de az RPO ettől tuti nem lesz jobb, nem mellesleg elég hosszú idő maga a próbálgatás is. Ezekre mindenképpen ütős választ ad a Rubrik – később lesz erről egy fejezet.

Száz szónak is egy a vége….rendes mentési rendszerre szükség van. Eltekintve attól, melyik gyártó mit tud és mit ígér, ezt a réteget kell körültekintően megtervezni. Nincs rossz gyártó, de még ezeket is lehet hanyag módon implementálni, amikor az sem fog megbízható végső mentsvárat szolgáltatni. És ez a lényeg….

És itt van a Rubrik belépési pontja! Ez az utolsó bekezdés az.

Rubrik – a zárt rendszer

Lehet vitázni, hogy jó-e egy rendszer, amiben az ügyfélre/tanácsadóra/mérnökre van bízva, hogy alakítja ki és üzemelteti. Arról is lehet filozofálni, mennyivel jobb/rosszabb, ha nincs variancia, kötött a kiépítés.

Egy „nyílt” rendszer esetén, a mentési szoftver gyártója a terméke által használt és igényelt alrendszereket saját hatáskörén kívül helyezi és csak igényeket fogalmaz meg azokkal szemben – legjobb javaslatokat mellékel maximum mellé. Tehát a szoftver igényel valamilyen operációs rendszert, az igényel valamilyen fizikai kiszolgálót – vagy virtuálisat, de akkor gyűrűzik tovább a függőség. Egy lánc annyira erős mint a leggyengébb szeme, és itt bízni kell az operációs rendszer tökéletes beállításában, a fizikai kiszolgáló firmware/driver sértetlenségében és az OOB interfészének – ezért is javasolják, hogy húzd ki – hibátlanságában.

A Rubrik megközelítése ezzel szemben az, hogy nincs Microsoft Windows, nincs Always on SQL szerver és akármilyen mentési célterület egy NAS-on. Kulcsrakész rendszer, ami jelenti azt is, hogy minden Rubrik rendszer egyforma, maximum méretezésben és teljesítményben térnek el. Előző cikkemben írtam, hogy árul a Rubrik is hardvert – ha Brik-ről beszélnek, akkor az azt jelenti, mármint, hogy a Rubrik adja a fizikai szervereket is – és certified szerverek is használhatóak, viszont az közös az utóbbi esetekben, hogy már az operációs rendszert is a Rubrik adja, nem telepíthető bármi a szerverekre. Amikor ez megtörténik, akkor a Rubrik rendszeren előáll a Rubrik CDM és máris mentésre fogható.

A Rubrik által kínált család itt található: https://www.rubrik.com/content/dam/rubrik/en/resources/data-sheet/Spec-Sheet-Rubrik-Appliance-Specs-r6000.pdf

2U-s modell mind és egyetlen modellben van három szerver, a többiben négy darab van, tehát ez mind multinode chassis. Általános javaslat utóbbiakat használni, mert az elsőben R1 tükör van, ami eléggé helypazarló ugye, a 4U-sakban pedig erasure coding.

Amiben még eltérés van közöttük, az a node-onként 3 HDD mérete és a szerverekben lévő CPU típusa/RAM mennyisége. A „Useable capacity” a licenszelés alapja -vannak kivételek, azM365 például az) – ez után kell fizetni. A bring your own – certified – server a fenti kapacitásoktól jelentősen eltérhet.

Három ilyen telepítés elképzelhető:

  • három/négy szerver – ez a normál kiépítés
  • egy virtuális gép – fizikai gép – ez az edge kiépítés. Ennek replikálnia kell valahová egy teljes Rubrik klaszterre vagy a felhőbe CC-ES)
  • Rubrik Cloud Cluster – ez a felhős telepítése a CDM-nek (CC-ES)

Az NFR-ben lokális CDM-et kaptunk, ami az első eset, bár egy virtuális gép formában – ez nem vásárolható, viszont a Rubrik képességeit jól bemutatja. Ezen fut tehát a CDM, ami mindennek a lényege, a rendszer lelke. Önmagában működőképes, de majdnem elengedhetetlen a Rubrik Security Cloud-ba (nyomokban még látszik a korábbni neve, a Polaris) történő bekötése. A fejlettebb funkciókat (Ransomware monitoring, Sensitive data discovery) csak azzal együtt lehet használni. Három licenszelési szint érhető el és ezektől függ milyen funkciók fognak működni.

Rubrik CDM

A Rubrik nem használ telepíthető klienst, a CDM-en futó weblapon keresztül adminisztrálható. Alább már az alaptelepítés utáni állapot látszik – árulkodó módon az RSC-ből is lehet authentikálni, ez jelenti azt hogy be van kötve oda.

Az első oldal, a dashboard lényegében egész jó összefoglalót ad az éppen futó feladatokról, teljesítményről, dedup arányról, snapshot-ok számáról és arról, mennyi workload-ot ment a rendszer és mennyi hely van még a CDM-en. Érdekesség a felső figyelmeztetés, mégpedig 2023.09.06-án kötelező lesz az MFA már lokálisan is.

Ezen a ponton váltok az RSC-re, mert annyi plusz funkciót és lehetőséget ad, hogy nem is érdemes a napi üzemet lokálisan végezni.

Rubrik Security Cloud

Nézzük meg a Rubrik Security Cloud oldaláról – itt is kötelező lesz az MFA – a felületet. Eléggé globális szintet mutat, de bármelyik fő részre kattintva a részletekhez jutnunk. Integrálható Azure AD-val vagy akármilyen SAML2.0 képes IdP-vel.

Data Protection

Az mentés és visszaálllítás szekciója, ahol egy az egyben látszik, hogy 14 darab objektumot mentek és mindegyik „compliant” azaz a mentések védik őket. Ha van felhős mentésem vagy valamilyen M365-ös, akkor azt szintén látom – eseteben – a „Data Center” szekció árulja el, hogy a 14 védett elem, lokális.

A felső menüben magukért beszélnek az elemek, de lényeges az „SLA domains” rész. Van olyan mentési szoftver, ahol a mentési feladatban meghatározva, milyen gyakorisággal, milyen megőrzési időkkel és hová történjen a mentés, majd ebbe a mentési feladatba tesszük bele a mentendő objektumokat. A Rubrik esetén igazából nincs is ilyen formában mentési feladat vagy inkább maga az SLA domain az. Szóval készítünk egy ilyen SLA-t és azt rendeljük hozzá az objektumokhoz. Az SLA domain-ben meghatározható:

  • milyen objektumokhoz szeretnénk majd hozzárendelni az SLA-t. Pl vSphere, HyperV virtuális gépek, NAS-ok, fizikai gépek stb.
  • milyen gyakran szeretnénk menteni – a Rubrik snapshot-nak nevezi – és mennyi időre szeretnénk megtartani őket – óra,nap,hónap,negyedév és év.
  • mikorra szeretnénk a mentést ütemezni.
  • kell e archíválás – azaz bizonyos időtartam után lemozgatni az adatokat a lokális CDM-ről.
  • kell e repliáció – azaz egy másik Rubrik-ra adatokat replikálni, duplikálni pl.
  • egyéb opcionális beállítások az első lépésben kiválaszott objektumokra specifikusan.

Alább egy ilyen SLA domain látható annak megőrzési részleteivel és azon objektumok listájával, amihez hozzá tudjuk rendelni és aktuálisan melyekhez van hozzá is rendelve. Egy ilyen összerendelés lehet direct – tehát közvetlenül a védeni kívánt objektumhoz rendelem az SLA-t – vagy örökölt például vCenter tag miatt, vagy mondjuk adott klaszter vagy vCenter minden objektuma eshet ez alá.

Ha mentés történik, egy dolog tuti biztos meg fog vele történni, mégpedig index-elni fogja a rendszer. Lokálisan, tehát a felhőben nem kerül adat, a lokális klaszter dolgozik rajta csak. Ennek több előnye van, főleg ha vissza szeretnénk állítani egy fájlt, aminek a nevére vagy csak nevének egy részletére emlékszünk.

Például az valahol van egy „Nagyon Fontos Dokumentum” nevű könyvtár, ami vissza kellene állítani. A keresőbe beírva azonnal ki is írja, hol talál ilyet – globálisan – szóval ha több szerveren, share-en lenne hasonló, akkor azokat is írná.

Látszik, hogy a „jump” nevezető objektumon van és a pontos elérési útvonal is látszik. Egy másik nézetben látszik a méret, a mentés dátuma és a módosítás ideje is, vissza is állítható egyből a szokásos lehetőségek mentén.

A Rubrik CDM-en minden redundáns módon van tárolva, tehát amit mentettünk rá és SLA domain vonatkozik rá, azt törölni nem lehet. De mi van akkor, ha gonosz módon átállítom a megőrzési időt 31 napról egy órára és egy példányra, ezzel törölve a korábbi kópiákat vagy egészen egyszerűen leszedni az SLA domain-t egy VM-ről. Ez egy tipikus dolog, amit a támadó meg fog tenni!

Azonban itt nem sikerül majd neki, mert van egy úgynevezett Two Person Rule lehetőség a rendszerben. Általunk meghatározott eseményeknél, jóváhagyást kér egy másik – jóváhagyási jogosultsággal rendelkező – adminisztrátortól. A fenti akciót a rendszer legmagasabb jogosultságával bíró felhasználójával indítottam és így sem engedi.

Tehát be kell lépnie egy ahhoz jogosultsággal rendelkező személynek – hiába rendelkezne az a felhasználó is ezzel a jogosultsággal – hogy jóváhagyja a feladat végrehajtását.

Hogy történik a mentés? Alapvetően a Rubrik a hálózaton keresztül ment, azonban vannak olyan tárolók, amelyekről a mentés forrását iSCSI-n keresztül meg tudja kapni és így igazából kvázi „frontend” mentes. De hogyan lesz konzisztens a mentés? Virtualizáció esetén ott van a VMware Tools és a HyperV Integration. Ha ezek nincsenek vagy fizikai gépről van szó, akkor agent-et kell telepíteni, ami a Rubrik CDM-ről tölthető – és specifikus csomag, hiszen nem kér bemenetet – le és ezzel sokkal mélyebb, akár alkalmazás szintű konzisztencia is elérhető. Azonban VMTools mellett is érdemel lehet feltenni, mert a file szintű restore például jelentősen gyorsítható általa.

Ransomware Monitoring

Az elkészült mentéseket ha már egyszer index-elni a Rubrik, miért ne nézné meg azokat ransomware tekintetében is. Figyeli a megváltozott fájlok mennyiségét, méretét, hash-ét, kiterjesztését és entrópiáját is. Ha túl sok véletlenszerű adat változott például egy fájlban, akkor az már eléggé gyanús. Szintén vannak olyan mintázatok, amelyek alapján következtetni tud arra, hogy fertőzés történt. Alább látható, hogy mennyi fájl, milyen mérettel változik a 14 védett objektum tekintetében – szűrhető SLA-ra stb.

Ha talál valamit, akkor, segít abban, hogy megmondja, melyik mentésben jelent meg és melyikben volt még „ép” az adat. Ha szeretnénk saját szabályok mentén is megnézni a mentéseket, akkor saját szabályokat alkothatunk (YARA szabályok, hash és pattern alapon) és célzottan kereshetünk azoknak megfelelőt, akár egy, akár több vagy az összes mentett objektumon. Sőt akár konkrét mentési pontokon is kereshetünk vagy intervallumban is.

Sensitive Data Discovery

Ismétlem az előző bekezdés elejét, ha van index, akkor miért ne néznénk meg egy újabb dolgot benne, így a kényes adatokat. Hogy mi számít annak, azt a Rubrik alapértelmezett szabályokkal segíti, de van lehetőség például regex alapon saját szabályt alkotni. Alább készítettem egy ilyet a TAJ számokra.

Több ilyen szabály lehet egy házirendbe összefogni és egy vagy több szabály mentén vizsgálni a mentéseket, példányról példányra – de lehet csak igény szerint lefuttatni, célzottan. Miután egy saját laborban dolgozom, generálnom kellett némi adatot és rajta forgalmat. Így az egyik virtuális gépben – jump nevű – létrehoztam egy mappát, amibe tettem egy fájlt, amibe beleírtam ezt „TAJ: 111 111 111”. Nézzük rátalál-e.

Megtalálta! És ami még lényegesebb, az ACL-t is ki tudja írni, ami természetesen jelentősen befolyásolja mely könytárakat és fájlokat tart magas kockázatúnak, főleg ha egy Domain Users csoport van rajta read jogosultsággal.

Az így kategorizált fájlok között trendet is készít, láthatóvá válnak olyan részletek:

  • mikor jönnek létre
  • hol vannak érzékeny adatokat tartalmazó állományok
  • milyen kockázattal rendelkeznek (high/low/no)
  • stale fájlok-e (az elmúlt egy évben senki sem módosította az állományt)

Mondanom sem kell, de erről a felhős felületről – RSC – nem lehet megnézni a fájl, annak tartalmát nem tudja megmutatni, mivel fel sem kerül oda az adat maga, lokálisan kerül kiértékelésre minden policy.

Orchestrated Recovery

Disaster Recovery tervet – azaz egy másik infrastruktúrára átállni – vagy izolált környezetbe történő visszaállítást – például validációra – vagy ha minden elveszett, akkor eredeti helyre történő visszaállítás forgatókönyveit itt lehet előkészíteni.

Mentett objektumok kiválasztása után megadhatjuk, melyik mentett kópiából álljon vissza – akár per objektum – és a lehetséges pontok tekintetében figyelembe vegye-e a Ransomware Monitoring által talált eredményeket. Ha igen, akkor olyan kópiát fel sem ajánl, amiben volt már fertőzött állomány.

Összefoglaló

A rendszer sebességéről nem tudok beszélni, mert virtuális formában fut a laborban, de a képességeit így is ki tudtam tesztelni. Igazából annyi van, hogy sem terjedelemben, sem időben nem tudnám mindet leírni – nem beszéltem a CDP-ről, az Oracle, az SQL és a felhős mentésekről sem. Későbbiekben biztosan lesz szó ezekről!