Problém hromadění PII v dokumentaci
Interní znalostní báze — Confluence, Notion, SharePoint, GitBook — si hromadí specifický typ problému s PII, který je prakticky neviditelný pro standardní nástroje souladu: osobní údaje zákazníků vložené do snímků obrazovky používaných pro dokumentaci procesů.
Scénář se opakuje v tisících týmů podpory a provozu:
Pracovník podpory narazí na neobvyklou konfiguraci účtu. Pořídí snímek zákaznické stránky účtu, aby zdokumentoval problém pro článek ve znalostní bázi. Snímek obsahuje jméno zákazníka v záhlaví rozhraní, jeho e-mailovou adresu v nastavení účtu a podrobnosti o předplatném.
Článek ve znalostní bázi je publikován do interní wiki. Může si jej prohlédnout 150 pracovníků podpory. Přístup k němu má 12 dodavatelů pracujících z externího helpdesku. Článek je užitečnou dokumentací toho, jak řešit daný okrajový případ.
O tři roky později wiki obsahuje 847 takových článků. Každý obsahuje snímky zákaznických účtů. Zákazníci, jejichž data se na snímcích objevují, k tomuto sekundárnímu použití svých dat nesouhlasili. Většina neví, že jejich data jsou v interní wiki.
Expozice dle GDPR: proč to není marginální problém
Analýza dle GDPR pro snímky interní dokumentace:
Minimalizace dat (článek 5 odst. 1 písm. c)): Osobní údaje musí být „přiměřené, relevantní a omezené na to, co je nezbytné.” Článek ve znalostní bázi o okrajových případech konfigurace účtu nevyžaduje skutečné jméno a e-mail zákazníka. Upravený snímek (jméno zákazníka rozmazáno) by dokumentační účel splnil stejně dobře. Zahrnutí skutečných zákaznických dat není nezbytné.
Omezení účelu (článek 5 odst. 1 písm. b)): Osobní údaje shromážděné pro jeden účel nemohou být bez právního základu přeúčelovány pro jiný účel. Data zákaznického účtu byla shromážděna pro poskytování služeb, nikoli pro dokumentaci interních okrajových případů.
Kontrola přístupu (článek 5 odst. 1 písm. f) a článek 32): Odpovídající technická opatření musí chránit osobní údaje. Snímky zákaznických účtů ve wiki přístupné všem 150 pracovníkům a dodavatelům — včetně těch, kteří nemusí mít přístup k podkladovému zákaznickému účetnímu systému — představují nevhodně široký přístup k osobním údajům.
Právo na výmaz (článek 17): Subjekt údajů požadující výmaz svých osobních údajů má právo na jejich výmaz „bez zbytečného odkladu.” Pokud se jeho data objevují ve 23 článcích ve znalostní bázi jako vložené snímky, vyžaduje žádost o výmaz nalezení a zpracování všech 23 článků — provozně náročný úkol bez systematické detekce.
Obejití kontroly přístupu
Nejzávažnějším problémem souladu u snímků wiki je obejití kontroly přístupu, které vytvářejí.
Organizace podpory obvykle používají RBAC k řízení přístupu k systémům zákaznických účtů. Agenti úrovně 1 mají přístup k základním informacím o účtu. Agenti úrovně 2 mají přístup k fakturačním a technickým podrobnostem. Manažeři a administrátoři mají přístup k úplnému profilu účtu.
Když agent úrovně 2 vytvoří článek ve znalostní bázi se snímkem úplného profilu zákaznického účtu, tento snímek se stane dostupným všem uživatelům wiki — včetně agentů úrovně 1, kteří by neměli mít přístup k fakturačním podrobnostem, dodavatelů, kteří nemají vůbec žádný systémový přístup, a nových zaměstnanců při onboardingu.
Snímek obejde RBAC kontroly zákaznického účetního systému. Osobní údaje, které měl RBAC chránit, jsou nyní přístupné každému s přístupem do wiki.
Praktická náprava: zpětná i prospektivní
Pro organizace zjišťující tento problém při auditu GDPR:
Zpětná náprava:
- Identifikujte všechny stránky interní wiki, které obsahují obrazové přílohy
- Spusťte detekci PII v obrazech na všech obrazových přílohách
- Třiďte výsledky: obrázky s detekcemi PII s vysokou spolehlivostí označte k revizi
- Pro označené obrázky: buď nahraďte upravenými verzemi, nebo přidejte vhodné kontroly přístupu ke stránce wiki
- Zdokumentujte nápravná opatření pro záznamy o odpovědnosti dle GDPR
Rozsah zpětné nápravy závisí na velikosti znalostní báze. Pro tři roky starou znalostní bázi 50členného týmu podpory může počet obrázků dosahovat tisíců. Dávkové zpracování obrazů to umožňuje zvládnout; klíčovým bottleneckem je lidská revize označených obrázků.
Prospektivní kontroly:
- Dokumentace procesu: všichni členové týmu podpory jsou školeni v úpravě snímků před použitím ve wiki
- Technická pomoc: nástroje pro anotaci snímků (rozmazání jmen zákazníků před vložením)
- Krok revize: určený kontrolor schvaluje články wiki před publikací, konkrétně kontroluje PII zákazníků v obrázcích
- Pravidelný audit: čtvrtletní dávkové skenování PII v obrazech všech příloh wiki
Minimální životaschopná kontrola (pro týmy s omezenými zdroji): Kontrolní seznam pro publikaci wiki, který zahrnuje „Odstraňte nebo rozmazejte všechna jména zákazníků, e-maily a ID účtů ze snímků před publikací.” Nízkoúrovňové, neautomatizované, ale dokumentuje existenci kontroly.
Proč se problém v čase zhoršuje
Bez systematických kontrol se problém PII v interní wiki v čase prohlubuje:
Objem: Každý nový článek ve znalostní bázi se snímkem zákazníka přidává k celkové expozici PII. Jak tým podpory roste a znalostní báze se rozrůstá, akumulovaná PII roste úměrně.
Zapomenuté články: Články dokumentující staré okrajové případy, které se již nevyskytují, mohou být ve wiki zapomenuty, ale stále přístupné — obsahující PII zákazníků, kteří mezitím podali žádosti o výmaz.
Šíření napříč týmy: Znalostní báze se často stávají mezifunkčními. Článek podpory se snímky zákazníků může být sdílen s produktovým týmem, technickým týmem nebo externími dodavateli jako kontext pro požadavek na funkci nebo hlášení chyby.
Backlog žádostí o výmaz: Jak ve wiki přibývá více zákaznických dat, odpovídání na žádosti o výmaz se stává složitějším. Bez systematické detekce není spolehlivý způsob, jak potvrdit, že byly identifikovány a vymazány všechny výskyty informací o subjektu.
V souladu s GDPR platí konzistentní zjištění: PII ve znalostní bázi je snazší předcházet než napravovat. Prospektivní kontroly — implementované nyní — zabrání exponenciálně rostoucímu problému s nápravou.
Zdroje: