Az önképzés – és szerencsére a munkám – része az, hogy gyártókat és azok termékeit vizsgáljam szakmai szemmel ilyenekre keresve választ: Érdemes-e vele foglalkozni? Eladható-e ez a piacon? Technológiai szinten mennyire előremutató?
A Rubrik gyártóról eddig csak ilyen ködös emlékeim voltak annak ellenére, hogy négy éve biztos naponta látom a VMworld-ön kapott táskám pántján, úgy 25 centire az arcomtól, mikor rajtam a táska.
Mint az bizonyára nem meglepetés, Herceg András a VMware-től átigazolt a Rubrik-hoz és kértem is, hogy egy röpke pár órában mondja el nekem, hogy ez mi. András meg is mutogatta és segített hozzájutni számtalan tanfolyamhoz, laborhoz – igazi eszközökkel – amik alapján azért kialakult egy kép bennem és meg kell mondjam meggyőzött. Nem árakról beszélek, hanem arról, hogy mit tud és azt, hogy tudja, illetve tudja-e más általam ismert gyártó ugyanazt.
Ha egy mondattal kellene leírnom a Rubrik-ot, akkor ez lenne az: A hiperkonvergens mentési rendszer, amelyet a biztonság köré építettek fel. Minden mentéssel foglalkozó gyártónál fókuszba került már a biztonság, az immutability, de itt szerintem a tervezés első lépésénél lefektették a biztonsági szabályokat és azután kezdték el kifejleszeni a mentés mikéntjét.
Hogy néz ki egy Rubrik mentőrendszer?
Az egész egy appliance alapú megoldás, azaz vagy a Rubrik-tól magától, általuk adott célhardveren vagy egyéb gyártók – Cisco, HPE és Dell – certified hardverén alapul. Mint említettem ez egy hiperkonvergens dolog, szóval egy appliance önmagában nem elég, nem tudna redundáns lenni, ezért az alaprendszer minimum 3 node-ból kell álljon. Ha az eszközt is a Rubrik-ról vásároljuk, akkor az egy 2U-s eszköz, amit Brik-nek hívnak.
Minden node-ban van CPU/RAM/NIC legalább 1 SSD és több HDD/SSD, de ha nem Brik-et vásárol valaki, akkor természetesen a médiák számában és típusában lehet más a konfiguráció. Bármelyik node képes ellátni a cluster bármely feladatát így SPOF nincs a rendszerben. A közös tárolási réteget az Atlas nevű elosztott fájlrendszer adja, ami már alapjaiban is immutable és titkosított. Egyiket sem kell bekapcsolni, főleg, hogy kikapcsolni sem lehet őket, ez alapértelmezett. A mentési kapacitás és/vagy teljesítmény pontosan olyan irányvonalak mentén végezhető, mint egy hiperkonvergens rendszer esetén. Ha a hardver engedi, akkor diszkekkel a tárterület, ha nem engedi/teljesítmény kell csak, akkor újabb node-ok felhasználásával.
Ez lényeges, mert ez egy olyan egység, aminek minden rétegét a Rubrik magáénak tudhat. Nem kell Microsoft Windows/akármilyen Linux disztribúció bizonyos komponensek alá, nem kell a mentési céltároló valami 3rd party gyártótól. Minden a mentéshez szükséges elem zárt, ezért is a magas biztonsági szint.
A klaszter menedzselhetőségét a rajtuk futó közös komponens, a Cloud Data Management – CDM – jelenti. Minden amit tehát az adminisztrációval és üzemeltetéssel kapcsolatos, azt ezen lehet végrehajtani. A node-oknak nincs más elérhetőségük – API-n kívül. Utóbbi nem kevés integrációs lehetőséget ad más termékekkel. (link)
Második faktort alapból támogat és ami nekem tetszik, hogy bizonyos beállítások változtatásakor szükség van egy másik személy megerősítésére is – Two-person rule.
Mondok egy példát: A mentések megtartási ideje legyen 3 év a virtuális gépek egy csoportján. Rubrik terminológia szerint SLA domain. Tegyük fel, hogy ezt a megtartási időt szeretém 3 órára átállítani, hogy azonnal lejárjanak megőrzési idők és törölje mentési rendszer az adatokat. Egy ilyen akciónál a CDM egy második adminisztrátor – akinek van joga – jóváhagyását kéri.
Jó példa lehet az is, hogy nem a megőrzési időt állítja át a támadó, hanem a mentési rendszer óráját. A végeredmény azonos lesz, mivel ezzel is lejáratható a mentés. A CDM által használt NTP szerverek IP-jét sem engedi átírni jóváhagyás nélkül. Bár hiába írja át valaki, mert a NTP poisoning vagy egyéb időszinkron alapú támadások nem működnek Rubrik esetén, mert monolitikus órát használnak a node-ok, tehát visszafelé nem haladhat és túl nagyot előre sem ugorhat az idő.
Azonban a Rubrik rendelkezik egy korábban Polaris-nak hívott, ma már inkább RSC-ként hivatkozott felhős komponenssel, amely segítségével globálisan menedzselhető az összes CDM függetlenül attól, hogy az hol van. Már ezen a ponton fontos megérteni, hogy az RSC-be nem kerül adat, onnan csak menedzselhető a rendszer és extra képességekkel ruházódik fel.
A mentési policy-t ezáltal központi helyen tudjuk konfigurálni és az a kívánt mentési rendszerben is megjelenik, egy helyen válik így auditálhatóvá az egész rendszer.
Az RSC másik – szerintem még lényegesebb – hozadéka, hogy segítségével egészen elképesztő lehetőségek nyílnak meg függően attól, melyik licenszet vásároljuk.
Maga az RSC felülete nagyon modern, jól áttekinthető, összevonva mutatja a mentések állapotát, a ransomware fenyegetettséget és anomáliákat, az érzékeny adatokban fellelhető változásokat.
Bármelyikre rákattintva jobban bele lehet merülni az kívánt képességbe. Alább például az sh1-PaloAlto klaszter által végzett mentéseket, a klaszter teljesítményét látjuk.
Ransomware Monitoring & Investigation
A mentés elkészülte után a CDM – azaz lokálisan, nem a felhőben – átnézi az mentett adatokat és számos szempontból vizsgálja őket. Néz mindenféle metaadatot (útvonalat, méretet, ACL-t és alapvetően a tartalmat is valamilyen formában. Megnézi, hogy a korábbi mentéshez képest mennyi új fájl jött létre, mennyi módosult és hányat töröltek. Ez már önmagában is több, mint más gyártó képessége. Azonban megnézi a fájlok tartalmát az entrópia szempontjából. Például arra meglehetősen kicsi az esély, hogy egy dokumentum neve nem változott, de 100%-a átíródott. Ha valaki ír egy már meglévő dokumentumba, akkor abban nem változik meg az utolsó bitig minden, amennyiben mégis, az nem marad a Rubrik radarja alatt.
Ha vannak gyanús elemek, akkor egészen egyszerűen meg lehet keresni a mentésekben azt a pontot, amikor az a fájl/könyvtárat megjelent a mentett rendszeren és visszaállítani a még egészséges adatokat. Tapasztalataim szerint pontosan ez szokott a bonyolult lenni, mert más termékeknél ez a „rinse and repeat” móddal oldható meg, azaz kinyitjuk a mentést és megnézzük kézzel, ha abban is a sérült adat van, akkor kinyitunk egy régebbi mentést. Ismételve ezt addig, amíg meg nem találjuk a még ép adatot.
Threat Monitoring & Hunting
Szorosan kapcsolódik az előbbi ponthoz. A Rubrik a korábbi és az éppen megjelnő ransomware-ek jellemzői ellen vizsgálja a mentéseket, de képes az adminisztrátor által beadott YARA szabályok alapján is nyomozni. Pontosan kiválaszható az a mentési példány, ahol felütötte a fejét egy támadás és akár annak terjedését is felvázolhatjuk.
Sensitive Data Discovery
A mentéseken alapulva – maga a feldolgozás lokálisan történik, azaz adat nem kerül ki a saját rendszerből – képes rengeteg beépített minta alapján azonosítani az érzékeny adatokat. Felkonfigurálható például úgy, hogy a magyar formátumú személyi számot is detektálja és pontosan meg tudja mondani, ilyen adatok melyik fájlban, hol, melyik mentésben vannak.
Az is látható, hogy ki fér hozzá az ilyen adatokhoz.
Mit tud menteni?
Természetesen képes menteni:
- VMware vCenter Server 6.5, 6.7, 7.0 és 8.0, Microsoft Hyper-V 2016 és 2019 (natív WMI és RCT), Nutanix AHV AOS 5.0-6.0 (néhány kivétellel)
- NAS-t : SMB v1,2,3 és NFSv3
- bármilyen nem share-t NFS/SMB-n
- Pure Storage-et: Purity 4.0 felett
- RHEL/Oracle Linux/CentOS: 6, 7, 8, Debian: 8+, SLES: 11, 12, 15, Ubuntu: 14.04 LTS, 16.04 LTS, 17.04, 18.04, 20, 20.04, AIX: 6.1, 7.1 TL3+, 7.2, Solaris: SPARC 10u11+, SPARK 11.1 SRU 14.5+, Microsoft Windows Server: 2008 R2*, 2012, 2012 R2, 2016, 2019 fizikai gépeket
- alkalmazás szinten Oracle Database 11gR2 and higher – (Standalone, RAC, and ASM configurations supported), SAP HANA 2.0+, Microsoft Exchange Server 2010-2016/2019, Microsoft SharePoint 2013, Microsoft SQL Server 2008/2008 R2/2012/2014/2016/2017/2019, Microsoft Active Directory in Windows Server 2019/2016/2012 R2/2012/2008 R2, Microsoft Windows Server 2008 R2/2012/2012 R2/2016/2019, Epic Cache on AIX and Linux
- Kubernetes : OpenShift OCP 4.9 and 4.10, Rancher 2.5.16, 2.6.4, and 2.6.5, Upstream K3s 1.21.9+k3s1 and 1.22.6+k2s1, Upstream Kubernetes 1.20–1.24
- AWS,GCP és Azure-ból
- M365/O365
Felsorolni nehéz, a linken lehet megnézni mit tud menteni/visszaállítani. (https://rubrik-docs.s3-us-west-1.amazonaws.com/en-us/compat_matrix/compat_matrix/cm_intro.html)
Hogyan ment?
A Rubrik node-ok ethernet hálózatot haszálnak, converged működésre nem képesek, azaz a SAN fabric-ba ilyen módon nem köthetőek bele. Ebből fakadóan storage oldali mentés helyett, az ethernet oldalon történik a mentés és visszaállítás is. A mentési rendszer tervezésekor ezért figyelembe kell venni a mentési terhelés ilyen igényeit is és adott esetben egy VMware esetén így kiakalakítani az ESXi réteg hálózati konfigurációját.
Hogy lehet mentést duplikálni és archíválni?
Egy Rubrik klaszter képes replikáció kapcsolatot kialakítan másik klaszterrel. Policy szinten állítható be az, hogy egy adott mentési házirend által kezelt mentések melyik másik klaszterre replikálódjanak és mikor – lehet például azonnal replikálni, naponta egyszer vagy akár úgy, hogy egy adott idő eltelte után áthelyeződik egészében a replikációs partnerre minden mentés. Az archív adatok helye egészen változatos lehet, mert támogatja a következőket:
- Amazon S3
- Google Cloud Platform
- Azure
- Object Store
- NFS
- Tape
Szalagos mentéseket egyébként a QStar-on keresztül tud, tehát mindenképpen kell hozzá egy kiegészítő komponens.
Lehet belőle elosztott rendszer csinálni?
Legyen a példa kedvéért 10 telephelyem, ahol mentésre szükség van, de jó lenne a központban biztonságban tudni a mentéseket. Ilyen esetben van lehetőség úgynevezett Edge-ek használatára, ami vagy fizikai vagy virtuális formában léteznek. Telephelyenként ebből egy is elég, oda történik a mentés és az replikálódik tovább a központi telephelyen lévő „igazi” Rubrik klaszterre vagy éppen egyenesen a felhőbe.
Hogyan licenszelődik?
A leggyakoribbat nézem, azaz legyen mondjuk 300 darab VMware vSphere-en futó virtuális gépem, 40 fizikai szerverem és 20TB NAS tárolóm. A Rubrik a mentési célterület alapján licenszelt, azaz nem instancia, socket alapú. Tehát a VM-ek összesen 80TB-ot, a fizikai gépeim 20TB-ot és a NAS szintén 20TB-ot foglal, a napi változás 5% és meg kívánok őrizni egy évnyi adatot a CDM-en, akkor deduplikáció/tömörítés után elfoglalt helyet kell licenszelni.
Összefoglaló
Két hét tanulás után azt kell mondjam nekem meggyőző a termék, mert önmagában egy hardened rendszer. Nem hagyatkozik külső komponensekre, nem kell neki Windows Server erre-arra, nem szükséges linux a hardened mentési célterülethez. Minden maga intéz és ezáltal az a túlélőcsomag tud lenni, amiben minden benne van, ami kellhet ha baj van és nem csak akkor derül ki hogy nincs benne valami, amikor szükség lesz rá.
A Rubrik egyébként anniyra biztos a termékében, hogy pár hete emelte meg 10 millió USD-re azt az összeget, amit akkor fizet az ügyfél részére – recovery cost címen – ha nem tud visszaállni egy Rubrik rendszerről. Természetesen függ pár dologtól az összeg és alapvetően, hogy ki kvalifikált erre a programra, de jól jelzi magabiztosságát és a termék robosztusságát.
Hamarosan saját infrastruktúrában is megépítek egy klasztert és élőben be tudom mutatni bárkinek, illetve valós körülmények között tudom tesztelni például ransomware ellen.
