Bevezető

Jelen korban a vállalatoknál keletkező adatok mennyisége egyre gyorsuló ütemben nő – jól jellemzik a növekedést a nagyvállalati tárolók eladásai és azok beszerzett kapacitása is – és ezzel együtt az értéke is emelkedik. Az a vállalat, amelyik az informatikát nem mint elsődleges értékteremtő komponensként használja pont úgy fenyegetett, mint amelyik lényegében csak valamilyen szolgáltatás biztosítására vagy éppen valamilyen termék gyártásának vezérlésére használja azt. Ebből fakadóan a vállalatok adatvagyonának részben vagy egészben történő kinyerése, illetve azok használatának ellehetetlenítése került fókuszba. As a service módon bérelhetőek fel ilyen támadók, akik a zsarolóvírusokkal a kívánt ügyfelet akár teljesen megbéníthatják, illetve teljes adatvesztés is okozhatnak.

Az adat tehát az elsődleges célpont és azok védelme kiemelten fontossá vált, ezúttal már nem csak természeti katasztrófák, hardver meghibásodás ellen kell védekezni, hanem akaratlagos adattörlés és célzott zsarolóvírus támadások ellen is. Az adatvédelmi rendszerek biztonsági képességei és lehetőségei fókuszterületté váltak és ez differenciálja is a gyártók termékeit és technológiáit.

A bejegyzés nem szól egyik gyártó mellett és ellen sem. Objektívan próbálja ismertetni a két mentőrendszer aktuális képességeit egy fiktív ügyfél rendszerére értelmezve, szem előtt tartva a biztonságot, az integráltságát és a könnyű felügyeletet.

A mentési rendszerek kihívásai

A mentett adat olyan kincs, amely az értékét akkor mutatja meg, mikor szükség van rá, ennél fogva a mentési kópiák biztonsága és a teljes mentési infrastruktúrának már elemeiben kell sérthetetlen és módosíthatatlannak lennie. Általánosan elmondható, hogy a piacon nincs olyan termék, amely ne lenne alkalmas szerteágazó forrásról mentés készíteni, majd azt helyreállítani, de jelentős különbség mutatkozik több szempontból, mind az architektúra, a skálázhatóság nézőpontjából.

A mentési rendszereket használhatatlanná tenni a támadók elsődleges feladata, mivel így biztosítható a ransom esetén kért váltságdíj kikényszeríthetősége és az adatok kinyerése – ami legtöbbször már az ransomware detektálása előtt megtörténik vagy legalább megkezdődik.

A támadások célja lehet:

• a mentési megoldás alatt futó operációs rendszer
• a mentési megoldás alatt futó fizikai szerver firmware-ei
• a mentési megoldás második faktor megoldásának kiiktatása
• a mentések lejáratása – a megőrzési idő módosításával
• a mentések körbefuttatása – a megőrzési példányszámnál több mentés készítésével a sérült adatról
• a mentési rendszer és az alatta futó operációs rendszer által használt időszinkron ellehetlenítése – time skew, time delay, clock jump
• a mentési rendszerbe történő bejutással és ott a mentések akaratlagos törlése

Magic quadrant

A Gartner Magic Quadrant egy független felmérés alapján sorolja be az adott kategóriában termékkel rendelkező gyártókat, azok képességei, fejlesztési lehetőségei és kutatásai alapján.

A skálán alapvetően a jobb felső kvadráns az a kategória, amelyet egyáltalán vizsgálni érdemes. Jelen dokumentum a Rubrik és a Veeam termékeit tárgyalja és bizonyos mértékben hasonlítja össze. Az összehasonlítás sem a forma, sem a terjedelem, sem pedig intellektuális okokból nem kerül teljesen bemutatásra.

Összehasonlíthatósági alap

Az összehasonlíthatóság a kettő felsorolt termék esetén igen komplex feladat, mivel azonos igény, más és más módon oldanak meg. Az alapvető architektúrájuk is jelentősen eltér és ez jellemző a mentési technológiáikra, a mentésekkel végezhető műveletekre és a licenszelésre is. Az egymással történő összevetés megkönnyítésére a következő fiktív környezeten kerül bemutatásra a kettő termék.

Ügyfél infrastruktúra

Az ügyfél három egymással egyenértékű adatközponttal rendelkezik, amelyek nagysebességű, redundáns kapcsolatokon vannak egymással összekötve IP és SAN fabric oldalon. Az adatközpontokban egyenlő számú kiszolgáló és központi tároló van aktív üzemben, tehát maga a működés aktív-aktív-aktív. A kiszolgálók 4 x 10Gbit-en vannak az IP és 2 x 16Gbit-en a SAN-hálózatba kötve, míg a tárolók – tárolónként – 8 x 32 Gbit-en. Az elsődleges tárolók párban replikálják szinkron módon minden kötetüket, de a működés egy kötet szempontjából aktív-készenléti, valamely kötetek preferáltan az egyik tárolón aktívak, illetve vannak készenlétben.

Igények:

• minden adatközpontban szükséges mentési szolgáltatást biztosítani
• minden mentendő workload a futásával azonos telephelyen kell mentési kópiával rendelkezzen és azt további két adatközpontba kell duplikálni
• a mentőrendszer a lehető legmagasabb szinten legyen önmagában redundáns és ugyanakkor független a mentett infrastruktúrától – kivétel hálózati, áramellátási és hűtési szolgáltatások
• saját adatközpontban futó VMware vSphere, K8s, fizikai Microsoft Windows, RedHat és Linux szerverek mentése
• 2 darab SAPhana kiszolgáló mentése
• 50TB NAS mentése
• 150TB mentési célterület adatközpontonként
• 600 VMware virtuális gép mentése – adatközpontonként egyenlő számban 200-200-200
• Kubernetes konform rendszerek mentése
• 30 darab fizikai szerver mentése – Microsoft Windows, RedHat és Debian linux
• 10TB napi változás
• szalagos mentés biztosítása a heti teljes mentés számára – 40TB
• izolált és eredeti helyre történő visszaállítás lehetősége, visszaállítási tervek alapján történő végrehajtással

Veeam

A Veeam 2006-ban kerül megalapításra és elsősorban a virtuális gépek mentésére specializálódott, azonban nem kevés erőforrást fordított a menthető rendszerek bővítésére és ma már nagyon kevés kivétellel képes gyakorlatilag az összes kurrens workload mentésére. Az ukrán-orosz háború miatt jelentős mértékben vesztettek fejlesztési képességet (R&D), mivel a két érintett országban is volt jelentős fejlesztői központja.

A Veeam az adatvédelmi feladatok fedését egy több termékből álló csomaggal valósítja meg, tehát bár egymással részben vagy egészben integrált, nem egyetlen rendszer, nem egyetlen szoftver.

A csomag neve Veeam Data Platform, amely a következő termékeket tartalmazza:

• Veeam Backup and Replication – mentés, visszaállítás, replikáció
• Veeam Backup Enterprise Manager – több Veeam Backup and Replication rendszer közös felügyeletét biztosítja
• Veeam One – monitoring és reporting
• Veeam Backup for AWS, Veeam Backup for Microsoft Azure, Veeam Backup for Google Cloud – a publikus felhő workload-ok mentésére
• Veeam Recovery Orchestrator – a visszaállítási terv szintű visszaállítás megvalósítására

A felsorolt szoftverek egy rendszerben, azonos kiszolgálókra nem minden esetben telepíthetőek, ennél fogva ha mindegyikre szükség van, akkor több nagyságrenddel megnöveli a szükséges kiszolgálók számát, ezáltal a függőségek miatt több támadási  pont is létrejöhet a rendszerben.

Például a Veeam Recovery Orchestrator nem telepíthető egybe a Veeam Backup and Replication vagy a Veeam One komponenssel.

Az adatvédelmi rendszer magját a Veeam Backup and Replication nevű termék adja, ami rendkívül skálázható és célzottan specializálható a vállalatok igényeinek megfelelően. Ez az előny egyben hátrány is, mivel a mentési rendszer biztonsága és sérthetetlensége ezáltal jelentősen függ annak architektúrájától, a telepítés során elvégzett beállításoktól és az üzemeltetés során történő változtatásoktól.

Kétségtelen előnye az, hogy a Veeam egy szoftver, tehát bármilyen támogatott operációs rendszerre telepíthető, a hardver konfigurációjában szabadon alakítható, ezáltal egy elosztott rendszer könnyen kialakítható, magasan skálázható. A gyártó az elmúlt két évben felkészítette termékét a lehető legtöbb komponensében a Microsoft termékek nélküli működésre és bizonyos Linux disztribúciókon alapulva törlés és ransom elleni védelemmel vértezte fel az. Azonban jelenleg még nem képes a legfontosabb komponens – maga a Veeam Backup Server – ilyen formában történő védelmére sem redundanciával történő ellátására.

A gyártó több terméket kínál attól függően, hogy milyen rendszer védelme szükséges, így a Veeam Backup and Replication mellett elérhető, a Veeam Backup for M365 (O365 mailbox/teams/sharepoint/onedrive), a Veeam Backup for Salesforce, a Backup for Kubernetes (korábbi nevén Kasten). A felsorolt termékek nem integrálódnak egy rendszerbe, általánosan elmondható, hogy egyetlen kiszolgálóra telepíteni sem javasolt őket. A következmény az, hogy a mentési rendszer erősen szegmentált lesz, hiszen adott workload mentésére, saját szigetszerű rendszert kell kialakítani.

A mentési rendszer főbb komponensei – Veeam Backup and Replication:

• Veeam Backup Server: A mentési rendszer központi eleme, amely mentési, visszaállítási feladatok konfigurációjának helye és azok ütemezése is itt szükséges. Önmagában nem redundáns és nem is tehető könnyen azzá, tekintve hogy kötelezően egy Microsoft Windows kiszolgálóra kell telepíteni. Ennek közvetlen következménye, hogy a legfontosabb komponense védelme igényli az alatta szolgáló Microsoft Windows védelmét – illetéktelen belépés, hardening, végpontvédelmi megoldás – és a Veeam rendszer által használt Postgre vagy Microsoft SQL szerver védelme is szükséges. Telepíthető virtuális gépként és fizikai szerverre is.
• Veeam Backup Proxy: virtuális vagy fizikai kiszolgáló formájában telepíthető, szintén Microsoft Windows vagy támogatott Linux disztribúcióra és feladata a mentési feladatok végrehajtása. Az adatok olvasása a mentendő workload-ról vagy annak tárolójáról, ezen adatok deduplikációja és tömörítése, majd az így feldolgozott adat továbbítása a Veeam Backup Repository – vagy deduplikációs céltároló felé.
• Veeam Backup Repository: virtuális és fizikai formában is elérhető, Microsoft Windows vagy támogatott Linux disztribúcióra telepítve. Legfőbb feladata a Backup Proxy-tól – vagy agent alapú mentés (pl SAP) – érkező adatok letárolása. Ezen komponens ezáltal kiemelten kritikus, tehát amennyiben az operációs rendszere sérülékeny vagy a támadó kód, támadó aktor bejut rá, abban az esetben maguk a mentési kópiák semmisíthetőek meg vagy titkosíthatók le.
• Veeam Tape Server: kötelezően fizikai kiszolgáló szükséges. Az operációs rendszer Microsoft Windows vagy támogatott Linux disztribúció. Feladata a szalagos egységek és szalagkönyvtárak kezelése, azokra a mentések elvégzése/visszaállítása.

Előnyei:

• elosztott rendszer építhető
• saját hardver használható
• skálázható bármely elemében – kivéve Veeam Backup Server horizontálisan történő bővítése – ha csak mentési célterület vagy mentési kapacitás szükséges
• mentett workload alapon licenszelődik, előfizetéses modellben
• sok nagyvállalati tárolóval integrálható, ami lehetővé teszi a tároló oldali pillanatképekből történő mentést – storage snapshot alapú mentés
• SAN hálózaton történő mentés támogatott

Hátrányai:

• a rendszer központi eleme nem tehető redundánssá – Veeam Backup Server – elvesztése esetén először ezt a komponenst kell újra feltelepíteni és a beállításokat betölteni.
• a rendszer központi eleme szükségszerűen Microsoft Windows alapú
• a konténerizációs rendszerek mentése még nem teljesen integrált
• mivel a rendszer minden komponense igényli harmadik féltől származó – pl Microsoft és Linux disztribúciók használatát – szoftverek használatát, ezért az implementáció, az üzemeltetés a biztonságos működés szempontjából rendkívül komplex feladat.

A Veeam rendszeren alapuló és a legjobb gyakorlatoknak megfelelő architektúra a következő ábrán látható. A rendszer a lehető legtöbb komponensében redundáns, a mentések három példányban készülnek és három különböző adatközpontban kerülnek elhelyezésre.

A Veeam Backup Server javasolt módon fizikai kiszolgálón kell működjön, hogy a virtualizációt érintő hiba, támadás esetén a mentőrendszer működőképessége biztosított legyen. Redundanciája technológiailag nem megoldható, a legjobb gyakorlatok szerint, a komponens elvesztése esetén új komponenst újra fel kell telepíteni és a konfigurációs mentést bele  szükséges tölteni. Ebből fakadóan ebben a Veeam Backup Server esetén redundancia nem lehetséges, automatikus átállás nem kivitelezhető.

A szükséges komponensek:

• 2 x Veeam Backup Server kiszolgáló – a redundanciát az operációs rendszer szintjén szükséges megoldani
• 3 x Veeam Backup Proxy kiszolgáló
• 3 x Veeam Backup Repository – Linux alapú hardened repository
• 2 x Veeam Enterprise Manager kiszolgáló – a redundanciát az operációs rendszer szintjén szükséges megoldani
• 2 x Veeam Orchestrator kiszolgáló – a redundanciát az operációs rendszer szintjén szükséges megoldani
• 3 x Veeam Backup for M365 kiszolgáló
• 3 x Veeam Tape Server (opcionális, lehet azonos kiszolgálón a Backup Proxy komponenssel)

A Veeam Backup Proxy komponens képes SAN oldali – direct SAN access – mentés biztosítására azonban fontos kiemelni, hogy mivel így a SAN hálózatba be szükséges kötni, illetve a produktív/elsődleges tárolón szükséges jogosultságokkal ellátni, ebből fakadóan elsősorban a tároló képességeitől függ, hogy a backup server-nek kiajánlott kötetek – VMFS datastore stb – a Backup Server-en törölhetőek-e – támadás esetén.

A Veeam által támogatott tároló esetén a tárolón készített snapshot-ból is lehetséges a mentés, amely virtualizált rendszerek esetén lerövidíti a virtuális gépeken készített pillanatképek időszakát.

A Veeam Backup Repository esetén, ha nem deduplikációs céltároló – Dell EMC Data Domain, HPE Storeonce, ExaGrid – a mentési célterület, a kiszolgáló egy könyvtárát jelenti. A deduplikáció köre alapvetően az azonos virtuális gépekről készült mentések tekinthetőek. Korábban elérhető volt – már nem javasolt – a mentési feladat szintű deduplikáció. Ebből fakadóan az egy repository-n elhelyezett mentési kópiák nem deduplikáltak egymás között, csak az azonos mentési láncolatban és azonos entitásról készült mentés deduplikált ezáltal.

A három példányban, három telephelyen történő megőrzés a mentések kettős duplikációt igényli, amelyet a rendszer egészére vonatkozó módon nem, illetve még a mentési feladatok szintjén sem lehet konfigurálni. A mentések többszörösítése egy külön feladat – mentési feladatonként egy (Backup copy) – vagy alternatív esetben teljes repository tartalmak duplikációt igényli. Azonban ja a duplikációt nem láncban hanem „1:N” módon szükséges megvalósítani, akkor minden Veeam Backup Repository esetén legalább két célkönyvtár szükséges.

Rubrik

A Rubrik megoldásának előnye, annak zártsága. A megoldásban a gyártó biztosítja a mentési rendszer által használt operációs rendszert, a mentési szoftvert és annak minden járulékos és szükséges elemét. Egy Rubrik mentőrendszer esetén nem lehetséges a legtöbb komponens elosztott telepítése – kivéve az agent-ek – mivel a rendszer egy céleszköz, ami önmagában redundáns és sérthetetlen. Egy Rubrik rendszer rendelkezik ISO27001,ISO27017,ISO27018,SOC 2 Type II, SOC3, HIPA és DoDIN APL, FIPS 140 és Common Criteria minősítésekkel.

Az összes képességet a gyártó egy termékben és szolgáltatásban nyújtja.

A Rubrik esetén két lehetséges implementáció létezik:

• HPE, Dell és Cisco hardver alapú telepítés
• Rubrik által biztosított hardver alapú telepítés

A termék nem bontható komponensekre, mivel ez egy hiperkonvergens mentőrendszer. Az alapkiépítésében is teljesen redundáns minden elemében és jelentős mértékben skálázható.

Két fő elemből áll:

• CDM – a hiperkonvergens elem, ami a mentéseket végzi, dolgozza fel és tárolja
• RSC – Rubrik Security Cloud – ami az – alapértelmezetten – felhős felület, amiben a fejlettebb képességek (Ransomware detection, Sensitive Data Discovery) elérhetőek. Az RSC maga az állami ügyfelek számára futhat saját adatközpontban, ezáltal teljes air gap működést megvalósítva.

Előnyei:

• teljesen zárt rendszer, a biztonság nem függ külső gyártóktól – Microsoft stb. – sem az mentőrendszerre nézve szűkebb architektúrától.
• a mentések már elkészülésük pillanatában módosíthatatlanná válnak – immutable
• globális deduplikáció, azaz egy CDM-en az egyszer leírt adat csak egyszer, de redundánsan tárolódik
• harmadik fél által történő jóváhagyás – bizonyos konfigurációk előtt a rendszer jóváhagyást kér
• a rendszerhez nem lehet sem fájl, sem operációs rendszer szintjén hozzáférni, ezáltal nem támadható
• monolitic clock használata
• a mentett adatokon képes ransomware detektálására, érzékeny adatok felderítésére
• elemi szinten képes több CDM – azaz több különálló mentőrendszer – egységes kezelésére, azok között replikációs kapcsolatok kialakítására
• képes virtuális gépek, fizikai kiszolgálók, NAS tárolók, Kubernetes konform rendszerek, Microsoft M365, Salesforce mentésére, külön komponens nélkül.
• nem szükséges külön termékek vásárlása, mindent egyben képes lefedni – mentés, terv szintű visszaállítás, felhős elemek mentése

Hátrányai:

• nem képes SAN oldali mentésre és ezáltal storage snapshot alapú mentésre sem
• nem használható bármilyen hardver a mentési rendszer kiszolgálására – csak támogatott gyártók és modellek

A javasolt architektúra a Rubrik esetén egészen egyszerű. A mentéseket a CDM-ek végzik és azok is tárolják, tehát a mentési teljesítmény és kapacitás szempontjából legalább négy darab node alkot egy CDM-et. Minden adatközpontban szükséges egy-egy ilyen CDM klaszter, így a három telephely összesen három CDM-et jelent, amelyet a közös felület az RSC fog össze egységbe. A CDM-ek maguk is működőképesek, azaz a mentések és visszaállítások elvégezhetőek közvetlenül az általuk biztosított felületen is, de a felhasználás elsősorban a sokkal magasabb képességeket és globális átláthatóságot biztosító RSC-ben javasolt. Mivel a CDM legalább négy kiszolgálóból áll, ezért egy kiszolgáló elvesztése nem okoz kiesést sem a mentési képességekben, sem az adminisztrációban, manuális beavatkozás nem szükséges, automatikusan működik.

A mentések duplikációja az 1:N módozattal megoldott, amint a mentés elkészült, az a forrásról, mindkét másik adatközpontban replikálódik.

Amennyiben a Rubrik-tól kerül megvásárlásra a hardver is, akkor a biztonság egy magasabb foka érhető el, hiszen a Rubrik validálja és vizsgálja a hadver firmware-einek sérülékenységeit is, illetve a szoftvert és a hardvert érintő hibák kezelése is egy pontban történik. Azonban van előnye annak is, ha a hardver nem a Rubrik-tól érkezik, mivel a bővíthetőségben eltérés van a két kiépítés között.

Egy CDM alapesetben négy kiszolgálóból áll, amely, ha a Rubrik-től érkezik, akkor 2U méretű. Amennyiben a mentési teljesítmény és/vagy a mentési célterület mérete bővítésre szorul, akkor ebben az esetben újabb egy 2U-s és négy kiszolgálót tartalmazó eszköz vásárlása szükséges, így a felbővített CDM ezáltal nyolc kiszolgálón működik majd. A bővítés történhet azonos vagy attól eltérő kapacitású modellel. Ezzel szemben, ha a hardver valamely Rubrik által támogatott modellen alapul, akkor az alaptelepítést követően a négy node, akár egy kiszolgálóval is bővíthető, tehát nem csak négy egész számú többszöröseivel. Ez növeli a granularitást, de a már ismertetett – a hardver gyártójától való – függőség miatt csökkentheti a biztonsági szintet.

A Rubrik licenszelése a mentési célterület alapján történik, azaz a CDM-ek által biztosított felhasználható kapacitás alapján szükséges. Ez jelenti azt is, hogy a legtöbb esetben – on premises esetben nem függ, felhő mentés esetében függ – a mentett elemek számától, azaz nincs különbség a licenszelési költségben egy virtuális gép vagy kétszáz fizikai szerver mentése között. Az így licenszelt célterületen jóval több adat tárolható, mivel az eszköz deduplikálja a mentéseket, jól lehet a 150TB célterület valójában 250-300TB kapacitással bír majd. Ennek becsléséhez pontos bemenő adatok szükségesek és a gyártó elvégzi a kalkulációt.

A szükséges komponensek:

• 3 x Rubrik CDM r6420s
• 3 x fizikai kiszolgáló a szalagos mentőegységek kezelésére – Qstar szoftver

Az összehasonlíthatatlanság

A Veeam és Rubrik összehasonlíthatósága az elosztott és hiperkonvergens rendszerek vonzatában nem lehetséges. Elmondható, hogy a Veeam legtöbb komponense redundánssá tehető, de nem az összes (a legtöbb nem), míg a Rubrik esetén minden komponens kötelezően rendelkezik hibatűréssel, azonban a hibatűrés mértéke is eltérő. A mentési kópiák tárolási helye a Veeam esetén nem rendelkezik kiszolgáló szintű redundanciával – a javasolt architektúrában és a költségek bemutatására vonatkozóan – míg a Rubrik rendszer igen. Tehát a teljes összehasonlítás azt igényelné, hogy a Veeam alatti mentési célterület is duplán kerüljön be a rendszerbe – a szükséges terület kétszerese szükséges telephelyenként – vagy valamilyen közös tároló beszerzése szükséges.

A szolgáltatások tekintetében a Rubrik alapértelmezetten rendelkezik olyan képességekkel, amiket a Veeam egyáltalán nem képes nyújtani vagy kiegészítő termékek beszerzése szükséges.

Ilyen szolgáltatások:

• ransomware detection

Veeam	Rubrik
A mentésből a mentett workload-ot el kell indítani valamilyen kiszolgálón – pl VMware – és abban szükséges valamilyen harmadik féltől származó védelmi komponens segítségével a keresés   illetve   A mentést a Veeam egyik komponensén mount-olni szükséges és az ott telepített harmadik féltől származó védelmi komponens segítségével kell vizsgálni az adatot A fenti lehetőségek végrehajtása erre vonatkozó feladatok – SureBackup – ütemezését és futtatását igényli.	A mentések elkészülése után azok vizsgálata a teljes Rubrik rendszeren teljesen automatikus, a CDM maga végzi a folyamatosan frissülő felismerési minták – entrópia,hash – alapján. Ebből fakadóan a mentéseket nem szükséges csatolni és elindítani. A forensic képességek bővítésére lehetséges célzott keresés YARA szabályok, file pattern-ek segítségével.

• érzékeny adatok felderítés

Veeam	Rubrik
Nincs ilyen képesség	A mentések elkészülése után azok vizsgálata a teljes Rubrik rendszeren teljesen automatikus, a CDM maga végzi a beépített vagy szabadon létrehozható szabályok mentén (regex). A mentett állományokban a rendszer jelzi, hogy milyen érzékeny adatok találhatóak meg és azok mely esetben rendelkeznek széles hozzáféréssel – például Everyone.

• globális áttekinthetőséget biztosító felület

Veeam	Rubrik
A Veeam Enterprise Manager telepítését igényli, amely önmagában szintén nem redundáns komponens – Microsoft Windows Server operációs rendszert és Microsoft SQL Server-t igényel.	A mentések elkészülése után azok vizsgálata a teljes Rubrik rendszeren teljesen automatikus, a CDM maga végzi a beépített vagy szabadon létrehozható szabályok mentén (regex). A mentett állományokban a rendszer jelzi, hogy milyen érzékeny adatok találhatóak meg és azok mely esetben rendelkeznek széles hozzáféréssel – például Everyone.

Licenszelés módja:

Veeam	Rubrik
Terméktől függően a licenszelés módja lehet instancia és socket alapú, agent alapú és mag alapú is – Kasten – előfizetéses modellben.	A licenszelés alapja a CDM által biztosított, mentési célra használható tárkapacitás, előfizetéses modellben.

Összefoglaló

A két gyártó bármelyike képes lefedni a jelentkező igényeket, azonban abban igen nagy eltérés van, hogy azt egy vagy több termékkel fedik le. A több termék, nyilvánvalóan több kiszolgálót igényel – nem javasolt virtuális gépre telepíteni egyetlen rendszert sem, mivel a virtualizációs rendszer támadása ma már jelentős kockázat és ebből következően az érinti a mentési képességeket is – több támadási pontot – több operációs rendszert, több adatbázist és ezzel együtt magasabb üzemeltetési ráfordítást is igényel.

Technológiai és biztonsági szemmel a központosítás és a sérthetetlen, fekete doboz szintű működés véleményünk szerint képes ellensúlyozni a legtöbb esetben azokat a kötöttségeket, amelyek egy ilyen zárt rendszert jellemeznek.