Проблема накопичення PII у документації
Внутрішні бази знань — Confluence, Notion, SharePoint, GitBook — накопичують специфічний тип проблеми з PII, який є практично невидимим для стандартних інструментів відповідності: персональні дані клієнтів, вбудовані у скриншоти, що використовуються для документування процесів.
Сценарій розгортається в тисячах команд підтримки та операцій:
Агент підтримки виявляє незвичайну конфігурацію облікового запису. Він робить скриншот сторінки облікового запису клієнта для документування проблеми у статті бази знань, що пишеться. Скриншот містить ім'я клієнта в заголовку інтерфейсу, його адресу електронної пошти в налаштуваннях облікового запису та деталі підписки.
Стаття бази знань публікується у внутрішній вікі. 150 агентів підтримки тепер мають до неї доступ. 12 підрядників, що працюють із зовнішнього центру підтримки, мають до неї доступ. Стаття є корисною документацією того, як обробляти граничний випадок.
Три роки потому база знань налічує 847 таких статей. Кожна містить скриншоти облікових записів клієнтів. Клієнти, чиї дані облікових записів з'являються на скриншотах, не надавали згоди на це вторинне використання їхніх даних. Більшість не знають, що їхні дані є у внутрішній вікі.
Ризики GDPR: чому це не є незначним питанням
Аналіз GDPR для скриншотів внутрішньої документації:
Мінімізація даних (Стаття 5(1)(c)): Персональні дані повинні бути «адекватними, релевантними та обмеженими тим, що необхідно». Стаття бази знань про граничні випадки конфігурації облікового запису не потребує реального імені та адреси електронної пошти клієнта. Знезаражений скриншот (ім'я клієнта розмито) слугував би меті документування так само добре. Включення реальних даних клієнта не є необхідним.
Обмеження цілі (Стаття 5(1)(b)): Персональні дані, зібрані для однієї цілі (взаємодія з клієнтом), не можуть бути перепрофільовані для іншої цілі (внутрішня документація процесів) без правової підстави. Дані облікового запису клієнта були зібрані для надання послуг, а не для документування внутрішніх граничних випадків.
Контроль доступу (Стаття 5(1)(f) і Стаття 32): Відповідні технічні заходи повинні захищати персональні дані. Скриншоти облікових записів клієнтів у вікі, доступній для всіх 150 агентів і підрядників — включаючи тих, хто може не мати доступу до базової системи облікових записів клієнтів — являють собою неналежний широкий доступ до персональних даних.
Право на видалення (Стаття 17): Суб'єкт даних, що вимагає видалення своїх персональних даних, має право на їх видалення «без невиправданої затримки». Якщо його дані з'являються у 23 статтях бази знань у вигляді вбудованих скриншотів, запит на видалення вимагає пошуку та обробки всіх 23 статей — оперативно складне завдання без систематичного виявлення.
Обхід контролю доступу
Найзначнішою проблемою відповідності зі скриншотами вікі є обхід контролю доступу, який вони створюють.
Організації підтримки зазвичай використовують RBAC для контролю доступу до систем облікових записів клієнтів. Агенти рівня 1 мають доступ до базової інформації облікового запису. Агенти рівня 2 мають доступ до деталей виставлення рахунків і технічних деталей. Менеджери та адміністратори мають доступ до повного профілю облікового запису.
Коли агент рівня 2 створює статтю бази знань зі скриншотом повного профілю облікового запису клієнта, цей скриншот стає доступним для всіх користувачів вікі — включаючи агентів рівня 1, які не повинні мати доступ до деталей виставлення рахунків, підрядників, що взагалі не мають системного доступу, та нових співробітників під час адаптації.
Скриншот обходить контроль RBAC у системі облікових записів клієнтів. Персональні дані, які RBAC мав захищати, тепер доступні всім, хто має доступ до вікі.
Практичне усунення: ретроспективне та перспективне
Для організацій, що виявляють цю проблему під час аудиту GDPR:
Ретроспективне усунення:
- Ідентифікуйте всі сторінки внутрішньої вікі, що включають вкладення зображень
- Запустіть виявлення PII на зображеннях для всіх вкладень зображень
- Класифікуйте результати: зображення з виявленням PII з високою достовірністю позначте для перегляду
- Для позначених зображень: або замініть знезаражені версії, або додайте відповідні засоби контролю доступу до сторінки вікі
- Задокументуйте дії щодо усунення для записів підзвітності GDPR
Масштаб ретроспективного усунення залежить від розміру бази знань. Для 3-річної бази знань команди підтримки з 50 осіб кількість зображень може сягати тисяч. Пакетна обробка зображень робить це здійсненним; ключовим вузьким місцем є перегляд людиною позначених зображень.
Перспективні засоби контролю:
- Документування процесів: усі члени команди підтримки навчені знезаражувати скриншоти перед використанням у вікі
- Технічна допомога: інструменти анотації скриншотів (розмивання імен клієнтів перед вставкою)
- Крок перегляду: призначений рецензент схвалює статті вікі перед публікацією, спеціально перевіряючи PII клієнтів у зображеннях
- Періодичний аудит: щоквартальне пакетне сканування PII на зображеннях усіх вкладень вікі
Мінімально необхідний засіб контролю (для команд з обмеженими ресурсами): Контрольний список публікації вікі, що включає «Видаліть або розмийте всі імена клієнтів, адреси електронної пошти та ідентифікатори облікових записів зі скриншотів перед публікацією». Низькотехнологічний, неавтоматизований, але документує наявність засобу контролю.
Чому проблема погіршується з часом
Без систематичних засобів контролю проблема PII у внутрішній вікі поглиблюється з часом:
Обсяг: Кожна нова стаття бази знань зі скриншотом клієнта додається до загального впливу PII. Зі зростанням команди підтримки та розширенням бази знань накопичений PII зростає пропорційно.
Забуті статті: Статті, що документують старі граничні випадки, які більше не виникають, можуть бути забуті у вікі, але залишатися доступними — містячи PII клієнтів, які відтоді подали запити на видалення.
Міжкомандне поширення: Бази знань часто стають міжфункціональними. Стаття підтримки зі скриншотами клієнтів може бути поширена з продуктовою командою, інженерною командою або зовнішніми підрядниками як контекст для запиту на функцію або звіту про помилку.
Накопичення запитів на видалення: Зі зростанням кількості даних клієнтів у вікі відповідь на запити на видалення стає складнішою. Без систематичного виявлення немає надійного способу підтвердити, що всі екземпляри інформації суб'єкта даних були ідентифіковані та видалені.
Для відповідності GDPR стабільний висновок полягає в тому, що PII у базі знань легше запобігти, ніж усунути. Перспективні засоби контролю — впроваджені зараз — дозволяють уникнути експоненційно зростаючої проблеми усунення.
Джерела: