SaaS katasztrófa-helyreállítási terv: amit a mentés önmagában nem old meg

A SaaS katasztrófa-helyreállítási terv azt írja le, mi történik akkor, ha a Microsoft 365, a Google Workspace, a Slack vagy az Atlassian Cloud használhatatlanná válik — bármilyen okból, nem csak támadás miatt. Ez a különbségtétel fontosabb, mint amilyennek hangzik, mert a SaaS-katasztrófák többsége nem adatvesztés. Egy szolgáltatói üzemzavar, egy elakadt bejelentkezés, egy nyáron lejárt előfizetés, egy rosszul beállított integráció, amely kilenc perc alatt negyvenezer fájlt törölt: négyből három esetben az adat teljesen ép — és teljesen elérhetetlen. Ezek közül egyetlenegyre válasz a mentés. A tervnek a többire is válaszolnia kell.

Ez az írás a zsarolóvírus helyreállítási terv minden veszélyforrásra kiterjesztett párja: az a támadási esetet és az RTO/RPO számtanát tárgyalja részletesen, ez pedig mindent, ami azon kívül esik — a kockázatokat, azt az egyetlen függőséget, amelyet szinte senki nem térképez fel, a kereskedelmi órát, amely csendben törlési óra is, és azt, hogyan tesztelhető mindez valódi katasztrófa nélkül.

Mit jelent a katasztrófa, ha nem Öné az infrastruktúra

A klasszikus katasztrófa-helyreállítás olyan hardverre készült, amelyhez oda lehetett sétálni. A katasztrófa fizikai volt — meghibásodott lemeztömb, elázott szerverszoba, telephely, ahonnan át kellett állni —, a válasz pedig egy második másolat egy második helyen.

SaaS-ban egyik meghibásodási mód sem az Öné. Nincs lemeztömb, amely elromolhat, nincs telephely, amely elázhat, nincs hypervisor, amelyet újra kellene indítani. Ehelyett az a rendszer romolhat el, amely egyáltalán hozzáférést ad az adathoz: a szolgáltató működése, a hitelesítés, a bérlőhöz (tenant) fűződő jogosultsága, és az a bizalom, amelyet alkalmazásoknak és rendszergazdáknak adott. A SaaS-tervnek erről a négy dologról kell szólnia — és ezek közül csak egyet old meg az, ha van egy másolata a fájlokról.

Így érdemes átfogalmazni: a saját szerveren a katasztrófa az adatot pusztította el, a hozzáférést érintetlenül hagyta. SaaS-ban a katasztrófa jellemzően a hozzáférést szünteti meg, az adatot pedig érintetlenül hagyja. Ez megfordítja a tervet.

Öt kockázat, amelyet néven kell nevezni

Írja le mindegyiket külön forgatókönyvként, mert mindegyiknél más az első lépés és más a felelős:

1. Szolgáltatói vagy régiós üzemzavar. A szolgáltatás áll vagy akadozik, és nincs mit visszaállítani — az adat biztonságban van egy ajtó túloldalán, amelyet nem tud kinyitni. Itt megkerülő megoldás kell, nem helyreállítás: hol fut az incidenskezelés, ha éppen a Teams vagy a Slack volt az incidenskezelés helye, hogyan teljesülnek aznap az ügyfélvállalások, ki kommunikál.
2. Hitelesítési hiba. Elromlik az egyszeri bejelentkezés, a címtár vagy egy feltételes hozzáférési szabály, és minden rendszer egyszerre válik elérhetetlenné. Ez a teljes eszközpark legerősebben korreláló hibája — külön szakaszt kap alább.
3. Jogosultsági hiba. Lejár az előfizetés, elévül a bankkártya, megszűnik a viszonteladói szerződés, felfüggesztik a fiókot. A hozzáférés a szerződés által meghatározott ütemben szűkül, és amikor az ütem lejár, az adat is.
4. Tömeges törlés géppel. Rosszul beállított szinkronkliens, rossz bérlőre irányított migrációs szkript, széles jogosultságú külső alkalmazás, egy héttel korábban lefutott kiléptető automatizmus. Ez az a kockázat, amelyet a mentés valóban és teljesen megold — és gyakoribb, mint a zsarolóvírus.
5. A rendszergazda feletti kontroll elvesztése. Egy feltört vagy egy távozó globális adminisztrátor. Amit a bérlőn belül tárolnak, az ezekkel a jogosultságokkal elérhető — beleértve magukat a megőrzési beállításokat is. Amit a bérlőn kívül, az nem.

Csak a 4. pont klasszikus mentési probléma. A 3. és az 5. csak akkor az, ha a másolat már az esemény előtt is a bérlő határain kívül élt. Az 1. és a 2. egyáltalán nem mentési probléma — és ezek fordulnak elő a leggyakrabban.

A függőség, amelyet senki nem térképez fel: a hitelesítés

Saját szerverparkban a hibák többnyire függetlenek egymástól: egy tárolóhiba az egyik rendszerben nem érinti a másikat. SaaS-ban azonban egyetlen elem fekszik mindegyik alatt — a címtár és a hozzá tartozó bejelentkezés.

Ha a hitelesítés elromlik — lejárt föderációs tanúsítvány, rosszul hatályosított feltételes hozzáférési szabály, a címtárszolgáltató üzemzavara, feltört címtár —, akkor a Microsoft 365, a Google Workspace, a Slack és az Atlassian Cloud egyszerre válik elérhetetlenné, azokkal az adminisztrációs felületekkel együtt, amelyekkel javítani lehetne. Mind a négyben ép az adat. Egyszerűen nem tudja igazolni, hogy Ön az.

Ebből három gyakorlati következtetés adódik:

• Kell egy vésztartalék belépési út, és tesztelni is kell. Platformonként legalább egy adminisztrátori fiók, amely nem a föderált bejelentkezéstől függ, és amelynek a jelszava olyan helyen van, amely maga sem az adott bejelentkezést igényli. Leírva, fizikailag vagy külön széfben tárolva — és évente egyszer valóban kipróbálva.
• A helyreállító eszköz ne osztozzon ugyanazon az egyetlen hibaponton. Ha az a felület, ahonnan visszaállítana, ugyanazon a címtáron keresztül hitelesít, amelyik éppen elromlott, akkor a robbanási zónán belül van. Ezt érdemes kimondva megkérdezni minden bevezetendő megoldásról.
• A hitelesítés is rendszer, tegye be a hatásvizsgálatba. A legtöbb hatáselemzésben szerepel az Exchange, a Drive, a Jira. Szinte egyikben sem szerepel az, hogy „be tudunk lépni” — pedig a többi mind erre épül.

Az előfizetés egyben törlési óra is

Ez az a kockázat, amely a legtöbb szervezetet váratlanul éri, mert nem az IT, hanem a pénzügy felől érkezik, és nem a biztonsági, hanem a szerződéses feltételekben van dokumentálva.

A Microsoft nyíltan közli az életciklust a Microsoft 365 üzleti előfizetéseknél: Aktív → Lejárt → Letiltott → Törölt. A legtöbb konstrukcióban a Lejárt állapot 30 napig tart — a felhasználók változatlanul dolgoznak, és lehet, hogy semmit sem vesznek észre. A Letiltott állapot további 90 napig áll fenn: ekkor a felhasználók már nem férnek hozzá, az adminisztrátorok viszont igen, kifejezetten azért, hogy a szervezet ki tudja menteni az adatait. Ezután következik a Törölt állapot, és a Microsoft egyértelműen kimondja, hogy ilyenkor az ügyféladat törlődik, és ugyanannak az előfizetésnek az újbóli megvásárlása nem hozza vissza.

Két részlet ezen belül külön figyelmet érdemel. Ha az előfizetést kifejezetten törlik ahelyett, hogy hagynák lejárni, akkor az állapot átugorja a Lejárt és a Letiltott fázist, és a Microsoft dokumentációja szerint a SharePoint Online tartalom — a OneDrive-ot is beleértve — azonnal törlődik. Ha pedig a lemondás a lemondási ablakon belül történik, az előfizetés egyből Letiltott állapotba kerül: az ott maradt adat 90 nap után törölhető, és a Microsoft megfogalmazásában legkésőbb a lemondástól számított 180 napon belül törlésre kerül.

A Google álláspontja rövidebb és keményebb: a Google Workspace-előfizetés lemondásakor a felhasználók Workspace-adatai — Gmail, Calendar, Chat, Drive — törlődnek, és nem állíthatók vissza, miközben maguk a felhasználói fiókok és a szervezeti struktúra megmaradnak. A Google saját ajánlása, hogy előbb exportáljon. A bökkenő az időzítés: az adminisztrátori adatexport eszköz a dokumentáció szerint legkorábban 48 órával az indítás után válik elérhetővé, jellemzően nagyjából 72 óráig tart, nagy domain esetén pedig akár 14 napig is. Ha a távozásról ugyanazon a héten születik döntés, amelyen a számlázás megszakad, az az eszköz, amely megmentené, lassabb lehet, mint az óra, amellyel versenyzik.

Magyar közepes vállalatoknál ez azért különösen éles kérdés, mert a licencet gyakran egy partneren keresztül vásárolják, és sokszor a partner kezében van a globális adminisztrátori jogosultság is. Így a 3. és az 5. kockázat egyetlen kapcsolattá esik össze: ha a szerződés megromlik, egyszerre kerülhet veszélybe a jogosultság és a hozzáférés. A tervbe ezért kell egy olyan, egyáltalán nem látványos sor, amelynek semmi köze a biztonsághoz: kit értesítenek, ha egy megújítás, egy fizetési mód vagy egy partnerszerződés megváltozik, és mit ellenőriz, mielőtt megváltozna. A gyakorlatban ez annyit jelent, hogy a számlázási felelős neve ugyanabban a dokumentumban szerepel, mint az incidensfelelősé — és hogy legalább egy globális adminisztrátori fiók a saját szervezetének a kezében van.

A visszaállítás és a máshol való helyreállítás nem ugyanaz

Egyetlen mondatban megfogalmazható az a kérdés, amely elválasztja a mentést a valódi katasztrófa-helyreállítási képességtől:

Vissza tudja állítani az adatait olyan bérlőbe, domainbe vagy munkaterületre, amely nem az, ahonnan származnak?

A fenti kockázatok közül a tömeges törlésen kívül mindegyik úgy végződik, hogy az eredeti bérlő elérhetetlen, nem megbízható vagy megszűnt. Ha az egyetlen visszaállítási út abba a bérlőbe ír vissza, akkor a másolat pontosan azokban a helyzetekben használhatatlan, amelyekre készült. A helyben visszaállítás a kedden törölt fájlt kezeli. A máshová történő helyreállítás a katasztrófát.

Két kapcsolódó képességet érdemes ugyanekkor ellenőrizni, mert ezek teszik a másolatot helyreállítássá: el tudja-e olvasni és át tudja-e keresni a másolatot akkor is, amikor a forrásplatform nem érhető el — egy üzemzavar éppen az a pillanat, amikor a múlt havi szerződésre szüksége van —, és olyan formátumú-e az export, amelyet egy másik platform be tud fogadni. Ez a különbség aközött, hogy birtokolja az adatait, és aközött, hogy csak tárolja őket valahol. Ugyanezt az érvet a szolgáltató felől nézve a SaaS megosztott felelősségi modell fogalmazza meg: a platformért ő felel, az adat folytonosságáért Ön.

Hogyan tesztelhető a SaaS katasztrófa-helyreállítási terv

Három gyakorlat, mindegyik olcsó, és mindegyik mást mér.

A belépési teszt. Évente egyszer lépjen be szándékosan minden platform adminisztrációs felületére a vésztartalék úton, ne az egyszeri bejelentkezéssel. Húsz percet vesz igénybe, és ez a lista legértékesebb tesztje, mert azt a függőséget próbálja ki, amelyen az összes többi nyugszik.

A máshová állítás tesztje. Állítson vissza valami valódit egy nem éles helyre — másik fiókba, tartalék domainbe, elkülönített munkaterületre —, és mérje órával, ne adatlapról. Jegyezze fel a tényleges eltelt időt, azzal a szakasszal együtt, amelyben valaki a megfelelő visszaállítási pontot keresi. Ezután hasonlítsa össze a leírt helyreállítási célidővel. Ha a kettő nem találkozik, vagy az eszközön, vagy a célon kell változtatni; mindkettő tisztességes válasz — a rést az incidens közben felfedezni nem az.

A sötétben tartott átbeszélés. Kilencven perc egy asztal körül, egyetlen szabállyal: a forgatókönyvben szereplő platform nem elérhető, és semmi sem érhető el, ami rajta fut. Ha az elérhetőségi lista a Teamsben van, és éppen a Teams a forgatókönyv, akkor máris megvan az első megállapítás. Itt érdemes azt is ellenőrizni, hogy a bejelentési határidőknek van-e gazdájuk: a NIS2 hatálya alá tartozó szervezeteknél a korai előrejelzés 24 órán, az incidensbejelentés 72 órán belül esedékes, és ezek az órák akkor is futnak, ha a visszaállítás nem halad — erről bővebben a NIS2 SaaS-mentési követelményeiről szóló írásunkban.

Egyik gyakorlathoz sem kell keret. Egy naptári dátum kell hozzá, és valaki, aki elviseli a kényelmetlen választ.

Hol érdemes kezdeni

Ha ma semmi nincs leírva, az első változat elfér egy oldalon: a fenti öt kockázat sorokként, és négy oszlop — ki a felelős, mi az első lépés, segítene-e egy bérlőn kívüli másolat, és mikor tesztelték utoljára. Az üres cellák adják a projekttervet, és nem egyenletesen fognak eloszlani. A legtöbb szervezetnél a hiányok a hitelesítés és a kereskedelmi óra körül sűrűsödnek, mert ez a kettő senkihez sem tartozik igazán.

Abban segítünk, hogy megtalálja a szervezetéhez illő megoldást, és bevezesse a Microsoft 365, a Google Workspace, a Slack és az Atlassian Cloud mellé — a beállításon és a bevezetésen végigkísérjük, hogy a tervben szereplő helyreállítási utak valóban létezzenek is. A platformot Ön birtokolja és üzemelteti; a mi dolgunk, hogy az a leírt forgatókönyvekre válaszoljon, beleértve azt is, amikor nem oda kell visszaállítani, ahonnan az adat származott.

Ha inkább a jelenlegi helyzetből indulna, mint egy üres lapról, az ingyenes kockázati audit egy rövid, gyakorlatias áttekintés arról, mi állítható vissza ma, honnan, és mennyi idő alatt.