Проблемът с натрупването на PII в документацията
Вътрешните бази знания — Confluence, Notion, SharePoint, GitBook — натрупват специфичен тип проблем с PII, който е почти напълно невидим за стандартните инструменти за съответствие: лични данни на клиента, вградени в екранни снимки, използвани за документация на процеса.
Сценарият се разиграва в хиляди екипи за поддръжка и операции:
Агент по поддръжката открива необичайна конфигурация на акаунта. Те правят екранна снимка на страницата на акаунта на клиента, за да документират проблема за статията в базата знания, която се пише. Екранната снимка съдържа името на клиента в заглавката на потребителския интерфейс, неговия имейл адрес в настройките на акаунта и подробностите за абонамента му.
Статията в базата знания се публикува във вътрешното wiki. 150 агенти за поддръжка вече имат достъп до него. 12 изпълнители, работещи от външното бюро за помощ, имат достъп до него. Статията е полезна документация за това как да се справите с edge case.
Три години по-късно базата от знания има 847 такива статии. Всеки съдържа екранни снимки на клиентски акаунти. Клиентите, чиито данни за акаунта се появяват на екранните снимки, не са се съгласили с това вторично използване на техните данни. Повечето не знаят, че данните им са във вътрешното wiki.
GDPR Експозиция: Защо това не е маловажен проблем
Анализът GDPR за екранни снимки на вътрешна документация:
**Минимизиране на данните (член 5, параграф 1, буква в)): ** Личните данни трябва да бъдат „адекватни, подходящи и ограничени до необходимото“. Статия в базата знания за крайните случаи на конфигурация на акаунта не изисква име и имейл адрес на истинския клиент. Дезинфекцирана екранна снимка (името на клиента е замъглено) би послужила еднакво добре за целите на документацията. Не е необходимо включването на реални клиентски данни.
Ограничение на целта (Член 5(1)(b)): Личните данни, събрани за една цел (взаимодействие с обслужване на клиенти), не могат да бъдат преназначени за друга цел (документация на вътрешния процес) без правно основание. Данните за акаунта на клиента бяха събрани за предоставяне на услуга, а не за документиране на вътрешни крайни случаи.
**Контрол на достъпа (член 5, параграф 1, буква е) и член 32): ** Подходящите технически мерки трябва да защитават личните данни. Екранните снимки на клиентски акаунт в wiki, достъпен за всичките 150 агенти и изпълнители – включително тези, които може да нямат достъп до основната система за клиентски акаунт – представляват неподходящ широк достъп до лични данни.
Право на изтриване (Член 17): Субект на данни, който иска изтриване на своите лични данни, има право те да бъдат изтрити „без неоправдано забавяне“. Ако техните данни се появяват в 23 статии от базата знания като вградени екранни снимки, заявката за изтриване изисква намиране и обработка на всичките 23 статии — трудна от гледна точка на работа задача без систематично откриване.
Байпасът за контрол на достъпа
Най-значимият проблем със съответствието с wiki екранните снимки е байпасът за контрол на достъпа, който създават.
Организациите за поддръжка обикновено използват RBAC, за да контролират кой има достъп до системите на клиентски акаунти. Агентите от ниво 1 имат достъп до основна информация за акаунта. Агентите от ниво 2 имат достъп до фактуриране и технически подробности. Мениджърите и администраторите имат достъп до пълния профил на акаунта.
Когато агент от ниво 2 създаде статия в базата знания с екранна снимка на пълния профил на клиентския акаунт, тази екранна снимка става достъпна за всички потребители на wiki — включително агенти от ниво 1, които не трябва да имат достъп до данните за фактуриране, изпълнители, които изобщо нямат достъп до системата, и нови служители по време на включване.
Екранната снимка заобикаля контролите RBAC в системата на клиентския акаунт. Личните данни, които RBAC е проектиран да защитава, вече са достъпни за всеки с wiki достъп.
Практическо възстановяване: ретроактивно и бъдещо
За организации, открили този проблем по време на одит GDPR:
Коригиране със задна дата:
- Идентифицирайте всички вътрешни wiki страници, които включват прикачени изображения
- Стартирайте откриване на PII за всички изображения
- Резултати от сортиране: изображения с откриване на PII с висока степен на сигурност, маркирани за преглед
- За маркирани изображения: или заменете със санирани версии, или добавете подходящи контроли за достъп до wiki страницата
- Документирайте действията за коригиране на отчетните записи на GDPR
Мащабът на санирането със задна дата зависи от размера на базата от знания. За 3-годишна база от знания в екип за поддръжка от 50 души, броят на изображенията може да бъде в хиляди. Пакетната обработка на изображения прави това възможно; основното тясно място е човешкият преглед на маркирани изображения.
Проспективни контроли:
- Документация на процеса: всички членове на екипа за поддръжка са обучени да дезинфекцират екранните снимки преди използване на wiki
- Техническа помощ: инструменти за анотации на екранни снимки (замъгляване на имена на клиенти преди поставяне)
- Стъпка на преглед: определеният рецензент одобрява wiki статии преди публикуване, като специално проверява за лични данни на клиента в изображения
- Периодичен одит: тримесечно партидно сканиране на изображения с PII на всички уики прикачени файлове
Минимален жизнеспособен контрол (за екипи с ограничени ресурси): Контролен списък за публикации в wiki, който включва „Премахване или замъгляване на всички имена на клиенти, имейли и идентификатори на акаунти от екранни снимки преди публикуване“. Нискотехнологичен, неавтоматизиран, но създава документация на контрола.
Защо проблемът се влошава с времето
Без систематичен контрол вътрешният проблем с личните данни на wiki се задълбочава с течение на времето:
Обем: Всяка нова статия в базата знания с екранна снимка на клиент добавя към общата експозиция на PII. С нарастването на екипа за поддръжка и разширяването на базата от знания, натрупаната PII нараства пропорционално.
Забравени статии: Статии, документиращи стари крайни случаи, които вече не се срещат, може да са забравени в уикито, но все още достъпни — съдържащи PII от клиенти, които след това са изпратили заявки за изтриване.
Разпространение между екипи: Базите знания често стават многофункционални. Статия за поддръжка с клиентски екранни снимки може да бъде споделена с продуктовия екип, инженерния екип или външни изпълнители като контекст за заявка за функция или доклад за грешка.
Право на натрупване на изтриване: Тъй като в уикито се натрупват повече клиентски данни, отговарянето на заявки за изтриване става по-сложно. Без систематично откриване няма надежден начин да се потвърди, че всички екземпляри на информацията на субект на данни са идентифицирани и изтрити.
За съответствие със GDPR последователната констатация е, че PII в базата знания е по-лесно да се предотврати, отколкото да се коригира. Проспективните контроли — въведени сега — избягват експоненциално нарастващия проблем с отстраняването.
Източници:
- [GDPR член 5: Принципи за обработка на данни] (https://gdpr-info.eu/art-5-gdpr/)
- ICO: Ръководство за минимизиране на данните
- [GDPR Член 17: Право на изтриване] (https://gdpr-info.eu/art-17-gdpr/)