Smazáno z databáze – živé v zálohách

Každá společnost má zásady uchovávání dat. Žijí někde v dokumentu, pravděpodobně naposledy aktualizovaném, když si někdo uvědomil, že se blíží audit, a říká něco sebevědomého jako „osobní údaje jsou smazány po 90 dnech“, což je číslo zvolené tak, aby znělo působivě krátce, spíše než odvozené z jakékoli zdokumentované analýzy omezení účelu. Vedení přikývne. Právní oddělení schválí. Dokument je uložen.

Data jsou mezitím nesmrtelná. Zvláště v zálohách, o kterých se nikdo nezmínil během schůzky o zásadách a které tiše uchovávají vše po poslední tři roky.

Toto je mezera, o které nikdo nemluví: rozdíl mezi mít zásady uchovávání dat a skutečně je prosazovat. Napsání zásad zabere odpoledne. Prosazování v reálném produkčním systému (databáze, zálohy, logy, zpracovatelé třetích stran, archivované exporty, datové sklady, stínové kopie) trvá podstatně déle a odhaluje architektonická rozhodnutí, která jste pravděpodobně neudělali s ohledem na mazání.

Proč většina prosazování uchovávání dat selže, než vůbec začne

Hlavním problémem je, že se data hromadí na více místech, než o kterých věděli lidé, kteří zásady psali. Mysleli na hlavní databázi. Nemysleli na logovací pipeline, která zachycuje těla požadavků obsahující uživatelská data, uchovávaná neomezeně, protože nikdo nenastavil politiku rotace logů, která by skutečně běžela. Nebo na analytický sklad, kam byla před osmnácti měsíci vyhozena surová data událostí pro projekt, který nikdy nebyl spuštěn, stále obsahující plné identifikátory uživatelů, protože pseudonymizace byla „na cestovní mapě“. Nebo na noční zálohu databáze uchovávanou po devadesát dní, což znamená, že data, která jste smazali z vaší živé databáze první den, sedí nedotčená v záloze až do devadesátého prvního dne, možná déle, pokud někdo ručně archivoval kopii před velkým vydáním „jen pro případ“.

Vaše povinnost uchovávání dat se také vztahuje na každou integraci třetí strany, kterou jste mapovali v předchozím příspěvku. Pokud smažete uživatele z vašeho systému, ale vaše CRM stále má jeho záznam, váš nástroj pro monitorování chyb stále má jeho stack trace a vaše API AI modelu stále má jeho historii konverzací v datové sadě pro jemné ladění, ve skutečnosti jste nic nesmazali. Smazali jste pouze kopii, kterou ovládáte.

A pak je tu CSV, které někdo exportoval pro jednorázovou analýzu a uložil na svůj notebook. Z toho se nemůžete automaticky dostat, ale můžete z toho udělat disciplinární záležitost spíše než technickou dodatečnou myšlenku.

Smazání, anonymizace, pseudonymizace: proč je rozdíl důležitý

Než napíšete jediný řádek kódu pro smazání, rozhodněte se, jaký přístup skutečně zvolíte, protože jsou skutečně odlišné a GDPR s nimi zachází odlišně.

Smazání znamená, že data jsou pryč. Pokud někdo po smazání podá žádost o přístup k subjektu, správná odpověď je „neuchováváme o vás žádná data“. Čisté, jednoduché a nejtěžší na čistou implementaci ve velkém měřítku.

Anonymizace znamená, že data stále existují, ale již je nelze spojit s žádnou osobou. Ani vámi, ani nikým, ani s dalšími datovými sadami nebo přiměřeným úsilím. Pokud to uděláte správně, GDPR se na anonymizovaná data již nevztahuje. Můžete je uchovávat neomezeně. Použijte je pro analýzy, datové sady QA, trénování modelů, zátěžové testování, cokoli potřebujete. Toto není mezera. Je to zamýšlené řešení. GDPR aktivně podporuje anonymizaci právě proto, aby organizace mohly uchovávat data pro legitimní sekundární účely, aniž by běžely hodiny uchovávání. Nařízení chce, abyste to dělali. Jen chce, abyste to dělali správně.

Háček je v tom, že správná anonymizace je těžší, než se zdá. Odstranění jména a e-mailu ze záznamu není anonymizace, pokud zbývající pole (věková skupina, PSČ, pracovní pozice, datum vytvoření účtu) jsou dostatečně specifická, aby odhodlaná osoba mohla stejně identifikovat jednotlivce. Toto se nazývá riziko opětovné identifikace a podcenění je to, jak se projekty anonymizace tiše stávají projekty pseudonymizace, které nikoho neoklamou, nejméně pak regulátora.

Pseudonymizace (nahrazení přímých identifikátorů tokeny při zachování mapovací tabulky někde) je provozně užitečná a GDPR vám za ni dává kredit, ale sama o sobě nesplňuje povinnost smazání. Jednotlivec je stále identifikovatelný prostřednictvím mapovací tabulky. Smazání mapovací tabulky pomáhá, ale také není zaručeno, že bude dostatečné, protože pseudonymizované záznamy mohou být stále opětovně identifikovatelné prostřednictvím jiných atributů v datové sadě. Pokud plánujete spoléhat na pseudonymizaci pro splnění povinností uchovávání, získejte řádné stanovisko před odesláním úlohy, nikoli po něm.

Praktické rozdělení pro většinu vývojářů: smažte osobní údaje, které již nepotřebujete pro původní účel, anonymizujte data, pro která máte skutečný legitimní důvod uchovávat pro sekundární účely, jako je QA, testování a zlepšování modelů. Proveďte anonymizaci správně: odstraňte přímé identifikátory, posuďte riziko opětovné identifikace proti zbývajícím polím, zdokumentujte své posouzení. Pokud to nemůžete udělat s jistotou, smažte je. Chybná anonymizace a její prohlášení za hotovou věc je horší než se o to vůbec nepokusit.

Jak skutečně implementovat smazání

Začněte mapováním každého místa, kde se nacházejí uživatelská data. Ne místa, o kterých si myslíte, že se tam nacházejí. Místa, kde se skutečně nacházejí. Proveďte cvičení stejným způsobem, jako jste provedli audit integrace v předchozím příspěvku: začněte tím, co je pozorovatelné (databázové tabulky, cíle logů, integrace třetích stran), nikoli tím, co říká architektonický diagram.

Pro každé místo odpovězte na tři otázky. Můžete smazat nebo anonymizovat na vyžádání? Můžete toto smazání automatizovat podle plánu? Můžete ověřit, že smazání proběhlo?

Třetí otázka je ta, kterou většina týmů přeskočí. Úloha smazání, která tiše selže a ohlásí úspěch, je horší než žádná úloha smazání, protože nyní máte záznam o dodržování předpisů, který tvrdí, že data byla smazána, když nebyla. Vestavte ověření od začátku. Zaznamenejte smazání, zaznamenejte počet ovlivněných záznamů, upozorněte na smazání s nulovým počtem pro uživatele, kteří by měli mít data.

Pro vaši hlavní databázi je smazání obvykle přímočaré: naplánovaná úloha klíčovaná podle created_at nebo last_active, s obdobím měkkého smazání, pokud váš tým podpory potřebuje okno pro obnovu. Období měkkého smazání je také období uchovávání. Definujte ho explicitně a prosazujte ho.

Pro logy nastavte zásady uchovávání na úrovni pipeline, nikoli jako ruční úklidovou úlohu. Pokud vaše logovací infrastruktura podporuje, filtrujte PII z logovacích záznamů při ingestování, spíše než se je snažit smazat později. Retrospektivní smazání konkrétních záznamů z logovacího streamu je bolestivé. Nezapisovat je na prvním místě je mnohem snazší.

Pro zálohy přijměte, že budete mít zpoždění. Pokud jsou vaše zálohy uchovávány po dobu třiceti dnů, data smazaná z vašeho živého systému přetrvají v zálohách až třicet dní. Zdokumentujte to. To je obecně přijatelné podle GDPR, pokud vaše zásady uchovávání dat s tím počítají a nepoužíváte zálohy jako způsob, jak obejít povinnosti smazání. Co není přijatelné, je uchovávání záloh neomezeně, protože nikdo nikdy nezkontroloval nastavení uchovávání u úlohy zálohování.

Pro zpracovatele třetích stran musí požadavky na smazání proudit dále. To znamená buď automatizované volání API pro spuštění smazání u každého zpracovatele, nebo zdokumentovaný manuální proces se záznamem o dokončení. Většina hlavních dodavatelů podporuje API pro smazání. Použijte je. Pro dodavatele, kteří je nepodporují, je to rozhovor, který je třeba vést, než se na ně spolehnete pro cokoli, co zahrnuje osobní údaje.

Problém se zálohami v jednoduchých termínech

Zálohy si zaslouží vlastní odstavec, protože právě tam většina programů uchovávání dat tiše selhává.

Záloha je snímek v čase. Když smažete data z vašeho živého systému, toto smazání se nešíří do existujících záloh. Smazaná data stále existují v každé záloze pořízené před smazáním. To je v pořádku a očekávané. Otázkou je, jak dlouho jsou tyto zálohy uchovávány.

Odpověď u většiny společností je „déle, než si kdokoli uvědomil“. Nastavení uchovávání záloh se nakonfiguruje jednou a zapomene se na ně. Úložiště je levné. Nikdo neaudituje zásady uchovávání záloh proti zásadám uchovávání dat. Výsledkem je hřbitov časových snímků obsahujících osobní údaje uživatelů, kteří si smazali účty před lety.

Zkontrolujte nastavení uchovávání záloh hned teď. Slaďte je s vašimi zásadami uchovávání dat. Pokud vaše zásady říkají, že data jsou smazána po devadesáti dnech, vaše zálohy by neměly být uchovávány po dobu jednoho roku. A pokud obdržíte žádost o smazání pro konkrétního jednotlivce, poznamenejte si do svých záznamů, že smazání bude dokončeno, jakmile vyprší příslušné okno zálohování. To je upřímná odpověď a je obhajitelná.

Jak vypadá dobrý stav

Program uchovávání dat, který skutečně funguje, má čtyři vlastnosti:

Je automatizovaný. Manuální procesy smazání selhávají, protože lidé zapomínají, onemocní, opustí společnost a zdědí nevyřízené smazání od toho, kdo odešel před nimi. Pokud to není automatizované, není to program uchovávání dat. Je to dobrý úmysl.

Je ověřený. Každá úloha smazání vytváří záznam o tom, co bylo smazáno, kdy a kolik záznamů bylo ovlivněno. Anomálie spouštějí upozornění. Záznam o ověření je uchováván. Ano, je v tom jistá ironie v uchovávání záznamů o vašich záznamech o smazání, ale takto vypadají důkazy auditu.

Pokrývá celý datový majetek. Hlavní databáze, logy, zálohy, zpracovatelé třetích stran, datové sklady, exportované soubory, kde je to možné. Prosazování uchovávání dat, které se dotýká pouze hlavní databáze, není prosazování uchovávání dat. Je to uklízení jedné police, zatímco zbytek domu se hromadí.

Je testovaný. Spusťte úlohu smazání na testovací datové sadě, než ji spustíte na produkci. Ověřte výsledek. Dělejte to pokaždé, když se úloha změní. „Úloha smazání běží“ a „úloha smazání funguje správně“ jsou různá tvrzení a chcete důkazy pro obě.