Jak skutečně budovat systémy v souladu s GDPR

Většina týmů nerozumí nařízení špatně, ale špatně chápe jeho záměr.

Pokud se zeptáte typického vývojářského týmu na GDPR, obvykle znají povrchní požadavky. Vědí, že uživatelé mohou požádat o výmaz, vědí, že data by neměla být uchovávána navždy, a vědí, že v některých případech záleží na souhlasu.

Tyto požadavky jsou považovány za izolované povinnosti, nikoli za projevy toho, jak by se systém měl v průběhu času chovat.

Týmy tedy implementují to, co se zdá nutné. Přidají koncový bod pro výmaz, definují zásady uchovávání, možná zavedou vrstvu souhlasu a jdou dál. Každé rozhodnutí je samo o sobě smysluplné, ale žádné z nich samo o sobě nedefinuje systém.

Časem se systém vyvíjí jiným směrem. Data se hromadí, šíří a znovu používají způsoby, které již neodpovídají původnímu záměru. Soulad s předpisy se stává něčím, co se snažíte rekonstruovat zpětně, místo aby to systém přirozeně podporoval.

Čemu se zákon skutečně snaží zabránit

GDPR se nesnaží systémy „zajistit“ v abstraktním smyslu. Snaží se zabránit specifickému způsobu selhání, který je v softwarových systémech běžný.

Pokud se osobní údaje ponechají bez kontroly, rozšiřují se. Jsou shromažďovány s vágním zdůvodněním, kopírovány do protokolů a sekundárních systémů, znovu používány pro nové funkce a uchovávány dlouho po zániku jejich původního účelu. Postupem času je obtížné odpovědět na základní otázky o tom, kde se data nacházejí, proč existují a co se s nimi děje.

Zákon je navržen tak, aby přesně tomu zabránil.

Při tomto pohledu pravidla nepřipadají odděleně. Všechna omezují, jak se data mohou v systému vyvíjet. Data by měla existovat z nějakého důvodu, neměla by se tiše měnit v něco jiného, neměla by žít déle, než je zamýšleno, a neměla by se ocitnout na místech, která jste nepředvídali.

To je to, co skutečně znamená „ochrana soukromí návrhem a ve výchozím nastavení“

„Ochrana soukromí návrhem a ve výchozím nastavení“ není něco, co přidáte později. Znamená to, že tato omezení jsou zabudována do systému a stále platí, i když se jím později nikdo nezabývá.

V praxi se to projevuje ve výchozích nastaveních.

Pokud váš systém ve výchozím nastavení zaznamenává celé tělo požadavku, ve výchozím nastavení uchovává data neomezeně a bez omezení sdílí data s integracemi, pak je ve výchozím nastavení nekompatibilní.

Opak je to, co zákon očekává.

Pokud nasadíte svůj systém a nic jiného neuděláte, měl by shromažďovat pouze data, která potřebuje. Protokoly by neměly obsahovat nezpracovaná osobní data, pokud to není výslovně vyžadováno. Data by měla vypršet, pokud jejich životnost aktivně neprodloužíte. Integrace by měly přijímat pouze to, co potřebují, ne vše, co je k dispozici.

Tyto výsledky by neměly záviset na disciplíně nebo úklidové práci. Měly by to být způsoby, jak se systém chová, když se na něj nikdo nedívá.

A to je rozhodnuto v kódu.

Jak se systémy od tohoto záměru odchylují

Systémy zřídka porušují tento záměr jedním zjevným krokem. Odchylují se.

Vývojář přidá pole, protože by se mohlo hodit později. Například místo ukládání „is_verified“ systém ukládá plná identifikační data, protože by mohla být v budoucnu potřeba. Toto pole se stane součástí datové sady požadavku, která se zaznamenává. Záznam je nakonfigurován jednou, takže vše jde dovnitř – e-maily, identifikátory, nezpracovaný vstup.

Později jsou stejná data exportována do analytického nástroje, protože jsou již k dispozici. O několik měsíců později jsou znovu použita ve funkci, kterou nikdo původně neplánoval.

Data, která měla kdysi úzký účel, nyní existují na více místech, používají se způsoby, které nikdo neplánoval, a nemají jasný konec.

Stejný vzorec se objevuje u protokolování. Začíná to jako pozorovatelnost, ale v praxi to často znamená protokolování plných datových sad, protože to je nejjednodušší způsob ladění. V tu chvíli protokoly přestávají být pouze provozními daty a stávají se paralelním úložištěm dat – jedním, které je obtížnější kontrolovat a často se uchovává déle než primární data.

Integrace vytvářejí další vrstvu. Služba třetí strany přijímá data, protože je pohodlné je předat. Ale nyní tato data sledují jiný životní cyklus: jiné uchovávání, jiný přístup, jinou viditelnost. Z pohledu vašeho systému odešla. Z právního hlediska ne.

Proč implementace „pravidel“ nestačí

Když týmy nerozumí této dynamice, snaží se opravit soulad na okrajích.

Budují mechanismy výmazu, aniž by věděly, kde data existují. Funkce „smazat uživatele“ odstraní hlavní záznam, ale protokoly ponechá nedotčené, analytická data nedotčená a systémy třetích stran nezměněné. Definují zásady uchovávání, aniž by kontrolovaly všechna místa úložiště. Databáze může data vyčistit po 30 dnech, ale protokoly je uchovávají po dobu jednoho roku, protože to je výchozí konfigurace. Zavádějí toky souhlasu, aniž by je sladily se skutečným používáním dat. Uživatelské rozhraní odráží jednu věc, zatímco systém pod ním se nadále chová stejně.

Zvenčí to vypadá v pořádku.

Ve skutečnosti to neřeší základní problém. Pokud se data již rozšířila, výmaz se stává neúplným. Pokud jsou zkopírována do protokolů nebo externích nástrojů, uchovávání se stává nekonzistentním. Pokud účel není promítnut do toho, jak jsou data strukturována a používána, omezení jejich použití se stává obtížným.

Systém se zdá být v souladu, ale chová se způsoby, které jsou v rozporu se záměrem zákona.

Co se změní, když pochopíte záměr

Pro tvůrce není posun o učení se více pravidel. Je to o rozpoznání toho, co se nesmí časem stát.

Data by se neměla rozšiřovat nad rámec svého původního účelu. Neměla by se duplikovat do částí systému, které je nikdy neměly zpracovávat. Neměla by přežít důvod, proč byla shromážděna. A neměla by být znovu použita bez toho, aby tato změna byla explicitní.

Jakmile to uvidíte, požadavky přestanou působit libovolně. Stávají se ochrannými zábradlími, která brání systému v odchýlení.

To mění způsob, jakým se dělají rozhodnutí.

Přidání pole již není triviální, protože musíte rozhodnout, zda skutečně potřebujete nezpracovanou hodnotu, nebo zda by odvozená verze stačila. Záznam již není jen ladění, protože musíte rozhodnout, zda tam to datové zatížení vůbec musí být. Integrace jiného systému již není jen zkratka, protože musíte pochopit, jaká data posíláte a proč.

Nic z toho vás nezpomalí. Jen to zviditelní důsledky v okamžiku, kdy se rozhodnutí dělají.

Oprava toho včas je důležitá

Tyto dynamiky se nejsnadněji řídí, když je systém malý a datové toky jsou jednoduché.

V této fázi je stále možné bez velkého úsilí odpovědět na otázky jako „kam toto pole nakonec doputuje?“ nebo „jak bychom mohli tohoto uživatele kompletně smazat?“.

Jak systém roste, každé rozhodnutí se skládá. Data se duplikují, závislosti se zvyšují a náklady na změnu rostou. Oprava problémů se přestává být lokální a stává se systémovou. Odstranění jediného kusu dat může vyžadovat změny napříč více službami, pipeline a integracemi.

Proto se GDPR v zralých systémech zdá obtížné. Ne proto, že by požadavky byly složité, ale proto, že systém nikdy nebyl navržen s ohledem na tato omezení.

Jak skutečně vypadá budování se zákonem

Budování s ohledem na GDPR neznamená proměnit inženýry v právní experty. Znamená to navrhovat systémy, které odolávají přirozené tendenci dat šířit se a hromadit.

V praxi to znamená, že víte, co se stane s daty poté, co je zavedete. Víte, kam proudí, kde jsou uložena a jak je lze odstranit. Vyhýbáte se zavádění dat, která nemůžete později sledovat nebo smazat. Vědomě se rozhodujete o tom, co se zaznamenává, co se sdílí a co se uchovává.

Data vstupují do systému z jasného důvodu. Jejich pohyb je záměrný. Jejich životnost je ohraničená. A jejich odstranění je možné bez reverzního inženýrství systému.

Když jsou tyto vlastnosti přítomny, soulad již není něčím, co sestavujete později. Již je promítnut do toho, jak se systém chová.

Většina týmů nepochybí v GDPR proto, že by ho ignorovala. Pochybí proto, že nikdy nepochopily, čemu se snaží zabránit – a než si to uvědomí, systém už se příliš odchýlil.