Лични данни в снимки в корпоративни бази от знания
Вътрешните бази от знания -- Confluence, Notion, SharePoint, GitBook -- крият специфичен тип проблем с личните данни, пропускан от стандартните инструменти за съответствие: лични данни на клиенти, вградени в снимки, използвани за документация на процеси.
Моделът се повтаря в хиляди екипи за поддръжка и операции.
Служител в поддръжката открива необичайна настройка на акаунт. Прави снимка на страницата с акаунта на клиента, за да документира проблема. Снимката показва името на клиента в заглавката на интерфейса, неговия имейл в настройките на акаунта и данните за плана.
Статията излиза в корпоративната база от знания. Сто и петдесет служители по поддръжка могат вече да я видят. Дванадесет изпълнители на външното помощно бюро могат също да я видят. Статията е полезна. Тя показва как да се обработва този граничен случай. Всеки служител, който среща тази настройка в бъдеще, ще я прочете.
Три години по-късно базата от знания съдържа 847 такива статии. Всяка съдържа снимки на клиентски акаунти. Показаните клиенти не са дали съгласие за това вторично използване на техните данни. Повечето не знаят, че данните им се съхраняват там.
Това не е малък проблем. Той расте с всяка нова статия.
GDPR рискове: защо това е важно
ГDPR анализът за снимки в бази от знания е директен.
Минимизиране на данните (член 5(1)(в)): Личните данни трябва да бъдат "подходящи, релевантни и ограничени до необходимото". Статия в база от знания за настройка на акаунт не се нуждае от реалното име и имейл на клиента. Размита снимка служи на целта по същия начин. Включването на живи клиентски данни не е необходимо.
Ограничение на целта (член 5(1)(б)): Данните, събрани за една цел -- обслужване на клиенти -- не могат да бъдат повторно използвани за друга цел -- вътрешна документация на процеси -- без правно основание. Данните на акаунта са събрани за доставка на услуги, а не за вътрешна документация. Това са две различни цели на обработване. Използването на едни и същи записи за двете изисква валидно правно основание, което повечето екипи не са установили.
Контрол на достъпа (член 5(1)(е) и член 32): Подходящи технически мерки трябва да защитават личните данни. Снимки на клиентски акаунти в инструмент, отворен за всичките 150 служители и изпълнители -- включително тези без достъп до основната система за акаунти -- създават прекалено широк достъп.
Право на заличаване (член 17): Субектът на данни, искащ заличаване, има право данните му да бъдат премахнати "без ненужно забавяне". Ако данните му се появяват в 23 статии в базата от знания като вградени снимки, искането изисква намиране и актуализиране на всичките 23 статии. Това е трудно без система. Нашето ръководство за право на заличаване по GDPR обхваща стъпките подробно.
Нито едно от тях не е гранично тълкуване. Те са директни приложения на текста на регламента към обичайна практика.
Заобикалянето на контрола на достъпа
Най-сериозният проблем за съответствие при снимките в Confluence е заобикалянето на контрола на достъпа, което създават.
Екипите за поддръжка използват ролеви контрол на достъпа (RBAC), за да ограничат кой може да вижда системите на клиентски акаунти. Служителите от ниво 1 виждат основни данни за акаунта. Служителите от ниво 2 виждат данни за фактуриране и технически записи. Мениджърите виждат пълния профил на акаунта.
Когато служител от ниво 2 създаде статия в база от знания със снимка на пълния клиентски акаунт, тази снимка става видима за всеки потребител на инструмента. Служителите от ниво 1, които не трябва да виждат данни за фактуриране, вече могат да ги видят. Изпълнители без достъп до системата могат да ги видят. Нов персонал при въвеждащо обучение може да ги види.
Снимката заобикаля RBAC контролите на системата за клиентски акаунти. Личните данни, за чиято защита е изграден RBAC, вече са отворени за всеки с достъп до базата от знания.
Това не е теоретичен риск. Това е нормалният резултат от работния процес по документация. Снимката стои там без изтичане, без дневник на достъпа и без одитна следа.
Практически стъпки за отстраняване
За екипи, открили този проблем при GDPR одит:
Ретроактивно отстраняване:
- Идентифицирайте всички страници в базата от знания с приложени изображения
- Изпълнете засичане на лични данни в изображения върху всеки приложен файл
- Прегледайте маркираните изображения: попаденията с висока увереност отиват в опашка за преглед
- За всяко маркирано изображение: заменете с дезинфекцирана версия или ограничете достъпа до страницата
- Вписвайте действията по отстраняване за GDPR записи
Мащабът на ретроактивната работа зависи от размера на базата от знания. За тригодишна база от знания на 50-членен екип за поддръжка броят на изображенията може да достигне хиляди. Пакетната обработка на изображения прави това осъществимо. Ръчният преглед на маркираните изображения е ключовото затруднение.
Превантивни контроли:
- Обучете целия персонал по поддръжката да дезинфекцира снимки преди публикуване в базата от знания
- Осигурете инструменти: инструменти за анотиране на снимки, размиващи имената на клиентите преди поставяне
- Добавете стъпка за преглед: определен рецензент проверява статиите преди публикуване, търсейки конкретно лични данни на клиенти в изображенията
- Изпълнявайте тримесечно пакетно сканиране на изображения на всички приложени файлове в Confluence
Минимален жизнеспособен контрол: Контролен списък при публикуване: "Премахнете или размийте всички имена, имейли и идентификатори на акаунти на клиенти от снимки преди публикуване." Ниско технологичен, неавтоматизиран, но създава документиран контрол. За малки екипи това е отправната точка.
Вижте нашия преглед за съответствие с GDPR за по-широката правна рамка, и защо политиката без технически контроли се проваля за причините, поради които само подходите с контролен списък се разпадат при мащаб.
Защо проблемът расте с времето
Без системни контроли излагането на лични данни в базата от знания се натрупва.
Обем: Всяка нова статия с клиентска снимка добавя към общото излагане. С разрастването на екипа за поддръжка и разширяването на базата от знания натрупаните лични данни също растат. Свойствата, правещи тези инструменти полезни -- лесно публикуване, трайност, широк достъп -- са причината проблемът с личните данни да се влошава.
Забравени статии: Статии за стари гранични случаи, които вече не се срещат, остават достъпни. Те съдържат лични данни на клиенти, подали оттогава искания за заличаване. Никой не проверява статия, последно актуализирана през 2022 г.
Разпространение между екипи: Базите от знания често стават многофункционални. Статия за поддръжка с клиентски снимки може да бъде споделена с продуктовия екип, инженерния екип или външни изпълнители за контекст по заявка за функция или доклад за грешка. Всяко споделяне разширява аудиторията за личните данни.
Изоставане от заличавания: С натрупването на повече клиентски записи в базата от знания реагирането на искания за заличаване става по-сложно. Без система няма надежден начин да се потвърди, че всеки екземпляр на данните на субект е намерен и премахнат. Екипът не може да направи достоверно удостоверяване на заличаването.
Личните данни в базата от знания са по-лесни за предотвратяване, отколкото за отстраняване. Контролите, въведени сега, избягват проблема с натрупаното отстраняване. Всяка статия, публикувана без размита снимка, е задача за отстраняване, отложена за бъдещето.