SaaS adatvédelem: a megfelelés még nem helyreállíthatóság

A SaaS adatvédelem azoknak a kontrolloknak az összessége, amelyek a felhős alkalmazásokban tárolt adatait bizalmasan, elérhetően és visszaállíthatóan tartják. Magyarul ez a szó félrevezető: az „adatvédelem" nálunk jellemzően a GDPR-t, a NAIH-ot és a jogi megfelelést idézi fel, miközben a szakterület harmadik lába — a visszaállíthatóság — kimarad belőle. Pedig az ügyfelet nem a rossz adatkezelési tájékoztató fogja megállítani egy hétfő reggelen, hanem az, hogy valaki pénteken kiürített egy megosztott meghajtót. Ez a bejegyzés szétválasztja a két feladatot, egy auditor által is ismert keretre helyezi őket, és végigveszi, hogyan néznek ki a rétegek Microsoft 365, Google Workspace, Slack és Atlassian Cloud környezetben.

Miért félrevezető a magyar szó

Angolul a „data protection" egyszerre jelent jogi adatvédelmet és az adatok műszaki megóvását, beleértve a helyreállíthatóságot is. A magyar „adatvédelem" szinte kizárólag az első jelentést hordozza — a második rendszerint „adatmentés" vagy „üzletmenet-folytonosság" néven, más értekezleten, más költségkereten, gyakran más felelősnél szerepel.

Ez nem nyelvészeti finomság. Ebből születik az a helyzet, amelyet sok hazai szervezetnél látni: rendben van az adatkezelési nyilvántartás, aláírt az adatfeldolgozói szerződés, megvolt a jogosultsági felülvizsgálat — és közben nincs mód visszaállítani egy négy hónapja törölt Confluence-teret. A megfelelés dokumentumai hibátlanok, az adat viszont elveszett.

A két feladat, amit összemosunk

Az első feladat a megelőzés és a korlátozás. Többfaktoros hitelesítés, feltételes hozzáférés, legkisebb jogosultság, eszközállapot, külső megosztás korlátozása, adatszivárgás-megelőzés. Ezek azt csökkentik, milyen gyakran jut el valami rossz az adataihoz.

A második feladat a visszaállíthatóság. Független másolatok, választható visszaállítási pontok, granuláris helyreállítás, tesztelt eljárások. Ezek azt csökkentik, mennyibe kerül egy rossz esemény akkor, amikor mégis bekövetkezik.

Azért mosódnak össze, mert a gyártók egy zászló alatt értékesítik őket — és azért számít, mert az első feladat semmit nem tesz a SaaS-adatvesztés leggyakoribb okai ellen. Amikor egy hitelesített felhasználó töröl egy rossz meghajtót, az nem hozzáférés-kezelési hiba: a hozzáférés-kezelés működött. Amikor a zsarolóvírus egy legitim szinkronkliensen vagy egy érvényes API-tokenen keresztül érkezik, az nem hitelesítési hiba. Mindkét esetben minden megelőző kontroll pontosan azt teszi, amire beállították — az adat mégis oda.

Helyezze ismert keretre

Ha a vezetőség vagy egy auditor előtt kell megindokolnia a programot, érdemes kész szerkezetet kölcsönözni. A NIST Cybersecurity Framework 2.0 hat funkcióba rendezi a területet: Govern, Identify, Protect, Detect, Respond és Recover — irányítás, azonosítás, védelem, észlelés, reagálás és helyreállítás. Ebben a felsorolásban az arány a tanulságos: öt funkció arról szól, hogy tudjunk az incidensről és ellenálljunk neki, és pontosan egy arról, hogyan indul újra az üzletmenet. A SaaS-biztonsági költés túlnyomó része a védelem és az észlelés funkcióba érkezik.

Irányítás

Rögzítse írásban, ki az adatgazda alkalmazásonként, meddig kell megőrizni az adatot, és mennyit engedhet meg magának elveszíteni. Ez az utolsó szám — munkaterhenként, órában vagy napban — teszi egyszerűvé az összes későbbi döntést, és rendszerint ez az, amit senki nem ír le.

Azonosítás

Nem védhető, amit nem leltározott. A SaaS-leltár gyorsabban avul, mint az infrastruktúráé, mert bármelyik csapatvezető létrehozhat egy új munkaterületet. Minimumként térképezze fel, mely üzleti folyamat mely alkalmazástól függ, hol tárolódik ténylegesen az adat, és mekkora az egyes munkaterhek natív helyreállítási korlátja. Ezek nem magától értetődők: a Teams-adatok nem egy Teams-adatbázisban ülnek, hanem csoportpostafiókok, egyéni postafiókok és SharePoint-webhelyek között szóródnak szét — erről szól a Microsoft Teams mentésről szóló bejegyzésünk.

Védelem

Itt a szolgáltató valóban sokat visz a hátán, és ezt tisztességes kimondani. A Microsoft, a Google, a Slack és az Atlassian az infrastruktúrát, a titkosítást, a javítást és a fizikai biztonságot jobban üzemelteti, mint ügyfeleik többsége tudná. Az Ön oldala a konfiguráció és az identitásréteg: mindenhol MFA, rendszergazdai szerepek karbantartása, külső megosztás alapértelmezései, OAuth-alkalmazások felülvizsgálata, és olyan kiléptetés, amely ténylegesen megszünteti a hozzáférést. A határvonalat a megosztott felelősségi modellről szóló bejegyzés járja körül.

Észlelés

SaaS-adatoknál az észlelés azt jelenti, hogy nem csak a szokatlan bejelentkezést veszi észre, hanem a szokatlan adatmozgást is: tömeges törlést, fájlnevek vagy kiterjesztések sorozatos átírását, letöltési csúcsot, egy egész webhelyre kiterjedő jogosultságváltozást. Azért fontos, mert minden natív helyreállítási ablak a törléstől ketyeg, nem attól a pillanattól, amikor valaki észreveszi. Az észlelés nem akadályozza meg a támadást — azokat a napokat adja meg, amíg a natív ablakok még nyitva állnak.

Reagálás

Legyen tisztázva, ki mondja ki az incidenst, ki engedélyezheti a visszaállítást, és hogyan kommunikálnak, amíg egy rendszer nem elérhető. Azt is tudni kell, mikor indulnak a szabályozói órák: a GDPR szerint az elérhetőség elvesztése önmagában is adatvédelmi incidens, ezért él a GDPR adatmentési követelménye akkor is, ha semmilyen adat nem szivárgott ki.

Helyreállítás

Ehhez a funkcióhoz tartozik a mentés, és erről döntött már Ön helyett a szolgáltatója. Minden platform szállít egy natív helyreállítási korlátot — kukaidőt, rendszergazdai türelmi időt, megőrzési szabályt —, és mindegyiknek van dokumentált pontja, amely után az adat véglegesen elveszett. Ezeket munkateherenként a SaaS mentésről szóló bejegyzésünk gyűjti össze.

Hol bukik el a SaaS adatvédelem a gyakorlatban

Három minta ismétlődik.

A megőrzést helyreállításnak nézik. A megőrzési szabály vagy a jogi zárolás megakadályozza az ütemezett törlést. Egyik sem ad visszaállítást, és több platformon a megfelelési kontroll kifejezetten nem hosszabbítja meg a helyreállítási ablakot.

Senki nem próbál ki egy visszaállítást. A nem tesztelt mentés feltételezés. Az első éles próba ne egy incidens legyen — és az sem teszt, hogy „látjuk az adatot a konzolon": a teszt az, amikor egy jellemző elem használható állapotban visszakerül.

Az identitásréteg feltérképezetlen. Licencek járnak le, fiókokat törölnek kiléptetéskor, bérlői környezeteket szerveznek át. A legtöbb SaaS-platformon az adat fennmaradása a fiók tulajdonsága — így egy identitásdöntés csendben adatmegőrzési döntéssé válik.

Amit nem tud igazolni, az nem számít

Van egy megfelelési vetület, amely megváltoztatja, mit kell jelentenie a „védett" szónak. A GDPR elvárja, hogy képes legyen a személyes adatok elérhetőségét és a hozzáférést kellő időben helyreállítani — és külön azt is, hogy ezt a képességet rendszeresen tesztelje és értékelje. A NIS2 ugyanezt az elvárást tolja a vezetői felelősség szintjére a hatálya alá tartozó szervezeteknél; a hatályról a NIS2 mentési követelményeiről szóló bejegyzés ír.

Gyakorlatban ez azt jelenti, hogy a bizonyíték a kontroll része. Visszaállítási naplók, tesztjegyzőkönyvek és munkateherenként rögzített helyreállítási cél — ezek teszik a védhető álláspontot igazolhatóvá. Ha az egyetlen dokumentuma a szolgáltató rendelkezésre állási vállalása, akkor szolgáltatási szintje van, nem kontrollja.

Hol érdemes kezdeni

Három lépés, ebben a sorrendben, és a többi jórészt következik belőlük:

1. Írja le munkateherenként a maximálisan elviselhető adatvesztést órában vagy napban. Alkalmazásonként egy sor.
2. Vesse össze mindegyiket a platform dokumentált natív korlátjával. Ahol a korlát rövidebb a tűréshatáránál, ott olyan rés van, amelyet egyetlen biztonsági kontroll sem zár be.
3. Próbáljon ki egy visszaállítást még ebben a negyedévben azon a munkateherhen, amelyik a legjobban fájna — és őrizze meg a jegyzőkönyvet.

Segítünk kiválasztani és bevezetni a szervezetéhez illeszkedő megoldást Microsoft 365, Google Workspace, Slack és Atlassian Cloud környezetben, kísért bevezetéssel — utána Ön birtokolja és üzemelteti. Kérjen SaaS adatvédelmi felmérést, és végigvesszük a munkaterhenkénti tűréshatárait azzal szemben, amit az egyes platformok valóban garantálnak.