A ransomware által fenyegetett világban semminél sincs fontosabb mint a last resort terv, ami minden esetben a mentési rendszer. Bízva bízunk abban, ha a szervereink meghajtóit letitkosította egy támadó vagy éppen a mentési rendszer által előállított mentési fájlokat, felhasznált szalagokat, illetve a mentési céltárolókat üresre törölve van tervünk arra, hogy állítjuk elő legalább az adataink és velük együtt a szervereink egy pillanatnyi kópiáját.
A Veeam méltán híres arról, hogy könnyen használható és megbízható mentési szoftvert gyárt. Pár helyen vezettem már be és alá kell támasztani, hogy amit tud, azt a piacon a legjobban tudja. Minden egyes bevezetésnél azonban felhívom a figyelmet az annó még HPE-s szinekben prosperáló Varsányi András mondott, méghozzá a 3-2-1 szabály. Gondolom mindenki ismeri már, de a lényeg, hogy „3 mentési kópia – 2 különböző médián – 1 offsite”. Ééééés pont ez az utolsó, ami az ügyfelek szignifikáns részénél nem valósul meg, egészen egyszerűen azért mert:
- nincs offsite telephely/széf
- túl sok az adata, ahhoz hogy mobilis formába lehessen hozni – nincs kazettás mentése
- túl sok erőforrás az offsite mentést kezelni hétről hétre
Mindhárom végeredménye az, hogy drágának ítéli meg az offsite mentés megvalósítását és inkább nem is teszi. Ha Veeam mentési rendszerük van, akkor íme a megoldás. Félreértés ne essék, ez nem új dolog, de kevéssé promotált hazánkban.
Offsite mentés as a Service
Tisztázzuk az elején, az ügyfél oldalán alapesetben semmi olyanra nincs szükség, ami még ne lenne neki.
Az opcionális rész a képen a WAN accelerator, minden más a kép bal oldalán pedig kimerül egy Veeam Backup and Replication szerverben.
Rengeteg videó és cikk van róla, milyen egyszerű, tiszta és száraz érzés ezt beállítani és használni, de nézzük validáljuk ezt. Először a kliens/ügyfél szemszögéből mutatom be.
Ügyfél Veeam B&R
A beállítás ígérem, hogy nem több három percnél.
- Backup infrastructure tab – > Service Providers -> Add service provider
2. A szolgáltató által adott FQDN-t kell beírni és a portot. Az alsó pipa elenyésző esetben hasznos, lényegében azt jelenti, hogy a szolgáltató képes az ügyfél Veeam B&R konfigurációját és minden egyebet állítgatni.
3. A certificate elfogadása után be kell adni a szolgáltató által adott felhasználó-jelszó párost.
4. Ezek után megjelentíti a szolgáltató oldalán definiált Repository nevét, a kapacitását – ami neki van allokálva – és hogy van-e WAN accelerator.
5. Sok lehetőség nincs, Apply és Finish után készen is vagyunk.
6. Állítsunk be mentést/backup copy-t. Előbbivel a VM-et direktben a szolgáltatóhoz lehet menteni, utóbbi esetben pedig akár már meglévő mentést lehet a szolgáltatóhoz vinni akár GFS módon. Én utóbbit mutatom be, szóval egy meglévő mentésből fogom elvinni a mentéseket.
7. Kiválasztom a mentési feladatot, amiből a mentést elviszem – de persze megadható maga a VM-is vagy fájlok is például.
8. A backup repository-nál egészen egyszerűen válasszuk ki a felhős repository-t.
9. A következőben adjuk meg a WAN accelerator-t ha van, esetemben nincs.
10. Illetve maga az üzemezés, mármint mikor futhat a backup copy.
Kész! Na nézzük meg mit csinál ez a job a futáskor kliens és szolgáltató oldalán, lesz különbség, abban ki mit lát.
Az ügyfél oldalán a felhős job így néz ki:
A hosszú szöveget szerencsétlen módon nem képes a Veeam tördelni, de ez áll ott: „9:19:39 :: Your service provider has implemented backup files protection against deletion by an insider for this cloud repository. To protect against advanced attack vectors, we recommend that you configure your cloud backup jobs to keep multiple full backups on disk (as opposed to forever-incremental chain with a single full backup).” Ezt azért írja mert a szolgáltató engedélyezve van hogy a törölt fájlokat tartsa meg X napig a rendszer.
Ha a VM-re – topsecretVM – kattintunk akkor semmi meglepő nincs benne, de fontos hogy látjuk a nevét, a VMX és NVRAM fájlt és alapvetően azt hogy a hálózati kommunikáció titkosítva lesz.
A szolgáltatónál lévő mentéseket itt is látjuk:
Most ugorjunk át a szolgáltató oldalára és nézzük Ő mit lát.
A mentési feladat nevét biztosan, de a VM nevét már egyáltalán nem. Ha a vm-98564-re kattintunk, akkor az is látszik, hogy az ég világon semmi részletet nem lát, tehát ő nem is tudja mi az a topsecretVM.
De keressük meg egy pillanatra ezt a mentési fájlt a szolgáltató repository-ján.
Nyissuk is meg Veeam-ben. Itt már megjelenik a VM neve és vissza is lehet állítani belőle.
Ki is választom a „Guest files (Microsoft Windows)”-t. Rögvest elindul a Backup Browser és látom a fájlokat is.
Na ez így nem jó, zárjuk ki a szolgáltatót, ne is lássa ilyen mélyen az adatainkat. Ezt az ügyfél oldalán kell megtenni, méghozzá a mentési fájl titkosításával.
Természetesen kell egy full mentés ennek érvénybe léptetéséhez. Már a mentés is írja hogy titkosítva lesz a fájl.
Nézzük meg mit lát a szolgáltató, ha a mentési fájlra kattint és megpróbálja kibontani ezek után.
Semmit! Jó hír, ez rendben van.
Összefoglaló
Azt hiszem látszik, hogy mennyire egyszerű és biztonságos egy ilyen szolgáltatóhoz történő mentés kialakítása és használata. Természetesen egy Azure blob-ba is lehet offsite mentéseket is tenni, de nem biztos hogy az a költséghatékonyabb – gyorsabb – minden esetben. Itt is van lehetőség arra hogy ha valaki például egy VPN-en keresztül szeretne a szolgáltatójához menteni, akkor megtehesse. Ebben az esetben természetesen hálózati komponensekre is van szükség a VPN megvalósításához.
Reális opció a végső védvonal biztosítására, szóval keressetek magatoknak egy ilyen Veeam Cloud Connect szolgáltatót, egyszerű, gyors és működik, mint a Veeam általában.
