A legal hold nem mentés

A legal hold — magyarul jogi visszatartás — olyan utasítás, amely egy jogvitában vagy hatósági eljárásban potenciálisan releváns adatok megőrzésére kötelez: felfüggeszti a szokásos törlési és megőrzési szabályokat, hogy a bizonyíték az ügy lezárásáig fennmaradjon. A Microsoft 365-ben, a Google Workspace-ben és a Slackben ez valódi, beépített funkció, és működik is. Amire viszont egyik platformon sem alkalmas: mentésnek. A legal hold ugyanabban a tenantban fagyasztja be az adatot, ahol az éles adat is van, ugyanazokkal az adminisztrátori jogosultságokkal, és a jogi terület, nem pedig az üzemeltetés igényeire szabva. Ha Ön a jogi visszatartást tekinti helyreállítási tervnek, azzal maga a Microsoft dokumentációja vitatkozik — írásban.

Mit csinál valójában a jogi visszatartás

A működés platformonként eltér, az alakja viszont azonos: ha egy tartalomra visszatartás vonatkozik, a felhasználó törlése nem szünteti meg az adatot. A törlés a felhasználó szemszögéből sikeresnek látszik, a megőrzött példány viszont olyan helyre kerül, ahová a felhasználó nem fér hozzá, az adminisztrátorok és a vizsgálati eszközök számára viszont elérhető marad.

Ez megőrzési garancia, és egy jogi kérdésre válaszol: elő tudjuk-e adni, ha kérik? Arra az üzemeltetési kérdésre viszont nem válaszol, hogy vissza tudjuk-e tenni oda, ahol volt, nagy mennyiségben és gyorsan? A két kérdésre más a válasz, és más eszköz is kell hozzá — az egész írás erre a különbségtételre épül.

Microsoft 365: visszatartás, Recoverable Items és inaktív postafiók

A Microsoft 365-ben a Litigation Hold megőrzi a postafiók tartalmát, beleértve a törölt elemeket és a módosított elemek eredeti változatát is, a Recoverable Items mappában tárolva őket. A Microsoft ma a legtöbb megőrzési esetre a Microsoft 365 megőrzési szabályzatokat ajánlja a Litigation Hold helyett; az In-Place Hold új használatát 2020. július 1-jén nyugdíjazták az Exchange Online-ban.

A leglényegesebb viselkedés a kilépőkhöz kötődik. A Microsoft dokumentációja rögzíti az alapesetet: a munkavállaló postafiókjának adatai a fiók eltávolítása után 30 napig őrződnek meg, ezalatt a fiók visszaállításával az adat is visszanyerhető, 30 nap után viszont véglegesen törlődik. A visszatartás ezen változtat — de csak akkor, ha a sorrend helyes: ha a postafiókra a Microsoft 365-fiók törlése előtt visszatartás került, a postafiók inaktív postafiókká alakul.

Az „előtt” itt a lényeg, és a Microsoft a hibát is kimondja: a véletlen törlés megelőzése érdekében a fiók törlése előtt javasolt meggyőződni arról, hogy a visszatartás ténylegesen érvényre jutott — ha a visszatartás nincs érvényben, a postafiók nem alakul inaktív postafiókká. Ha pénteken lépteti ki a kollégát, és hétfőn tenné rá a visszatartást, már nincs mire rátenni.

Van egy mondat, amelynek önmagában le kellene zárnia a „mentés-e ez” vitát. Az automatikusan bővülő archívummal rendelkező inaktív postafiókról a Microsoft azt írja, hogy az nem nyerhető vissza és nem állítható helyre, helyette tartalomkereséssel exportálható — és hogy ez az eljárás kizárólag e-discovery célra támogatott, mentési megoldásként nem használható. Ez nem egy versenytárs marketingállítása, hanem a platform gyártójának közlése arról, mire való a funkció.

További csapda: az e-discovery ügyhöz kötött visszatartás az ügy életciklusához kapcsolódik. A Microsoft figyelmeztet, hogy ha az ilyen visszatartást feloldják, vagy az ügyet lezárják, illetve törlik, az inaktív postafiók véglegesen törlődik. Egy ügy lezárása tehát megsemmisítheti azt az adatot, amelyet éppen megőrizni akartak.

Google Workspace: Vault-visszatartás és a licencfüggőség

A Google Vault elvben ugyanígy működik, a gyakorlatban viszont van egy élesebb pereme. A Google szerint a visszatartások felülírják a megőrzési szabályokat, így a visszatartás alatt álló adatot a szokásos adatkezelési szabályok nem törlik — a felhasználói élményt pedig pontosan írja le: ha a felhasználó töröl egy visszatartás alatt álló üzenetet, az üzenet számára többé nem hozzáférhető, de nem törlődik véglegesen.

A pereme az, hogy mitől függ a visszatartás. Ha egy adminisztrátor elveszi a felhasználótól a Vaultot támogató licencet, a visszatartás többé nem védi az adott felhasználó adatait — a következményt pedig a Google nyíltan kimondja: a törlésre megjelölt adat azonnal véglegesen törölhető, és nem állítható vissza.

A Google Workspace-ben tehát a megőrzési garancia egy licenc-hozzárendelés függvénye. Egy rutinszerű költségoptimalizálás, egy kiléptetéskor visszavett licenc vagy egy számlázási változás úgy vonhatja vissza, hogy közben senki nem nyúl a Vaulthoz. Ugyanaz az identitás alakú hiba ez, amely a Google Workspace e-mail mentést általában is meghatározza: a védelem a fiókot követi, a fiók pedig olyan adminisztratív objektum, amelyet bárki módosíthat.

Slack: legal hold és a törölt csatorna problémája

A Slack legal hold funkciója Enterprise csomagokban érhető el, és külön Legal Holds Admin szerepkör kezeli. Érvényes visszatartás mellett a Slack megőrzi a beszélgetésben részt vevő összes tag által küldött üzeneteket és fájlokat, függetlenül a megőrzési beállításoktól, és attól is, ha a tagok szerkesztik vagy törlik a tartalmat. Egy visszatartás legfeljebb 1000 érintettre terjedhet ki, a megőrzött adat pedig JSON-exporton vagy a Discovery API-n keresztül érhető el.

Érdemes megállni ennél a hozzáférési útnál. Még ha a Slack tökéletesen meg is őrzi az adatot, amit visszakap, az egy export — egy fájl, amelyben keresni lehet, nem pedig egy helyreállított munkaterület. Ugyanez a korlát részletesen szerepel a Slack exportról szóló írásunkban.

És van egy dokumentált hiányosság, amelynek minden kockázati nyilvántartásban helye van: ha a visszatartásba bevont csatornát törlik, az üzenet- és fájladatok nem őrződnek meg. A visszatartás az érintettekhez és a beszélgetésekhez van rendelve; ha a tárolóedényt törlik, a megőrzés nem követi.

Atlassian Cloud: itt nincs megfelelője

A Jira és a Confluence Cloud nem rendelkezik a másik háromhoz hasonló natív legal hold funkcióval. A jogi vizsgálati képesség évek óta nyitott fejlesztési kérés az Atlassian nyilvános hibakövetőjében (CONFCLOUD-9985), az ezt igénylő csapatok pedig jogosultsági korlátozásokra, kézi exportokra vagy Marketplace-alkalmazásokra kényszerülnek. Ha az ügy mérnöki dokumentációt érint — jegyeket, specifikációkat, döntési oldalakat —, a megőrzés annyi, amennyit Ön felépített, nem amennyit a platform ad.

Hol feszül egymásnak a visszatartás és a mentés

A legélesebb érv a kettő szétválasztása mellett az, hogy valódi konfliktusban is állhatnak egymással.

A GDPR biztosítja a törléshez való jogot, ez a jog azonban nem korlátlan. A 17. cikk (3) bekezdés e) pontja kiveszi a hatálya alól azt az esetet, amikor az adatkezelés „jogi igények előterjesztéséhez, érvényesítéséhez, illetve védelméhez” szükséges — vagyis pontosan azt, amire a jogi visszatartás szolgál. A visszatartás tehát jogalap lehet arra, hogy megtagadja egy olyan adat törlését, amelynek törlését kérték Öntől.

A magyar gyakorlatban ehhez jön a jogszabályi iratmegőrzés külön rétege: a számvitelről szóló 2000. évi C. törvény 169. §-a alapján a beszámolót és az azt alátámasztó könyvviteli bizonylatokat legalább 8 évig olvasható formában meg kell őrizni. Ez a kötelezettség egyik platform natív megőrzési ablakával sem esik egybe.

• Visszatartás mentés nélkül: elő tudja adni a bizonyítékot, de nem tudja újraindítani a működést. Bizonyítani tudja, mi állt a törölt projekttervben; visszatenni nem tudja.
• Mentés visszatartás-tudatosság nélkül: csendben újrateremthet olyan adatot, amelyet jogilag törölnie kellett volna, vagy lejárathat olyan példányt, amelyet be kellett volna fagyasztani.
• Mindkettő, összehangolatlanul: ez a leggyakoribb állapot, és ez adja a hatóság felé az egymásnak ellentmondó válaszokat.

A gyakorlati követelmény az, hogy a megőrzési ütemterv, a visszatartások és a mentés megőrzési ideje egyetlen, együtt dokumentált tervezési döntés legyen. A megőrzési oldalról a GDPR SaaS mentési követelmények írásunk szól részletesen, a megőrzési és helyreállítási kontrollok viszonyáról pedig a SaaS adatvédelem.

Mit tegyen

Néhány kényelmetlen kérdés a következő felülvizsgálatra:

1. Meg tudja nevezni, ki helyez el visszatartást, és milyen gyorsan? A Microsoft 365-ben a visszatartásnak a fiók törlése előtt kell léteznie, a Slackben Legal Holds Admin kell hozzá.
2. A kiléptetési folyamat ellenőrzi a visszatartásokat a licencek visszavonása előtt? A Google Vault visszatartása a licenccel együtt szűnik meg; a Microsoft 365 inaktív postafiókja pedig létre sem jön, ha a visszatartás elkésik.
3. Mi semmisül meg, ha egy ügy lezárul? Az e-discovery visszatartás feloldása véglegesen törölheti az inaktív postafiókot.
4. Vissza tud állítani, nem csak előadni? Ha a válasz csak annyi, hogy „exportálunk és keresünk”, akkor vizsgálati képessége van, nem helyreállítási.
5. Lefedi bármi az Atlassiant? Jellemzően semmi.

A jogi visszatartás egy jogi kockázattól védi a céget. A független mentés egy üzemeltetésitől: véletlen törléstől, távozó munkatárstól, kompromittált adminisztrátori fióktól, zsarolóvírustól. Egyik sem helyettesíti a másikat, és a platformok őszintén megmondják, melyik feladatot látják el. Segítünk kiválasztani az Ön rendszeréhez illeszkedő mentési megközelítést, és segítünk be is vezetni, hogy a helyreállítási fele rendesen le legyen fedve.

Töltse ki ingyenes felmérésünket, és feltérképezzük, hol érnek véget a visszatartásai, és hol kezdődnek a helyreállítási hiányai — Microsoft 365, Google Workspace, Slack és Atlassian területén.