PII на скриншотах: витоки у внутрішніх інструментах

Сліпа зона DLP, яку ви ще не перевірили

Інструменти запобігання втраті даних (DLP) відстежують мережевий трафік, вкладення електронної пошти та передачу файлів на наявність персонально ідентифікаційної інформації. Вони перехоплюють таблиці зі стовпцями ІПН, листи з прикладеними списками клієнтів і завантаження файлів з медичними записами.

Але скриншоти вони не перехоплюють.

Скриншот — це файл зображення. PII всередині скриншоту — імена клієнтів, видимі в інтерфейсі CRM, адреси електронної пошти у поданні папки «Вхідні», номери рахунків у системі білінгу — не зберігається як текст у зображенні. Вона відображається як пікселі. Стандартні DLP-рушії, що перевіряють вміст файлів на наявність шаблонів PII, нічого не знаходять.

Результат: щодня в організаціях із розвиненою DLP-інфраструктурою співробітники вставляють скриншоти з персональними даними клієнтів у канали Slack, завдання Jira, повідомлення Teams та ланцюжки листів — і жодного сповіщення DLP не спрацьовує.

Масштаб проблеми PII на скриншотах у сучасній роботі

Дистанційна та гібридна робота зробила обмін скриншотами повсюдним явищем. Внутрішні інструменти комунікації переповнені знімками екрана, якими обмінюються для контексту:

• Агенти підтримки роблять скриншоти облікових записів клієнтів, щоб поділитися з керівниками команди («подивіться на цей дивний стан облікового запису»)
• Розробники роблять скриншоти журналів помилок, що містять помилки валідації введення користувача, для інженерних каналів
• Менеджери з роботи з клієнтами роблять скриншоти записів CRM, щоб поділитися контекстом угоди з фінансовим відділом
• IT-адміністратори роблять скриншоти системних інтерфейсів для документування конфігурацій для підрядників
• Продуктові команди роблять скриншоти дашбордів аналітики користувачів для оновлення зацікавлених сторін

Кожен скриншот може містити PII. Скриншот облікового запису клієнта містить ім'я, електронну адресу, статус і платіжну адресу клієнта. Скриншот журналу помилок містить введення користувача — яке може включати імена, адреси або контактні дані, введені помилково. Скриншот запису CRM містить повний профіль облікового запису. Скриншот аналітичного дашборду може містити індивідуальні ідентифікатори користувачів у вихідних даних, видимих на діаграмі.

Вимір контролю доступу

Поряд із прогалиною в DLP, обмін скриншотами створює проблему контролю доступу.

Більшість організацій мають рольовий контроль доступу (RBAC) до своїх виробничих систем. Агент підтримки має доступ до записів клієнтів, що стосуються його черги; він не має доступу до повної бази даних клієнтів. Підрядник має доступ до конкретної проектної документації; він не має доступу до систем з PII клієнтів.

Коли агент підтримки робить скриншот запису клієнта та вставляє його в канал Slack, до якого мають доступ підрядники, контроль доступу обходиться. Підрядник отримує персональні дані клієнта, до яких він не зміг би отримати доступ звичайними шляхами. Угода про обробку даних (DPA), що регулює обробку даних підрядником, може не охоплювати цю передачу. Права GDPR клієнта можуть бути незастосовними щодо підрядника.

Це обхід контролю доступу є порушенням Статті 5(1)(f) GDPR (цілісність і конфіденційність) і може створювати проблеми з відповідністю Статті 28, якщо підрядники отримують PII без відповідних DPA.

Виявлення PII на зображеннях як технічний контроль

Технічний контроль, що вирішує проблему витоку PII на скриншотах, — це виявлення тексту на зображеннях: OCR, застосований до файлів зображень для вилучення видимого тексту, а потім виявлення PII засобами NLP у вилученому тексті.

Робочий процес:

1. Співробітник робить скриншот клієнтського інтерфейсу
2. Перед тим як поділитися в Slack/Jira/Teams: завантажує скриншот до інструмента виявлення PII на зображеннях
3. Інструмент вилучає видимий текст зі скриншоту за допомогою OCR
4. NLP виявляє PII-сутності у вилученому тексті
5. Співробітник отримує звіт: «Цей скриншот містить: [ім'я клієнта], [адреса електронної пошти], [ідентифікатор облікового запису]»
6. Співробітник або: (а) анонімізує PII, закриваючи її на скриншоті, (б) обирає більш обмежений обсяг поширення, або (в) продовжує обмін під задокументованим обґрунтуванням

Цей робочий процес не запобігає будь-якому обміну скриншотами з PII — він робить PII видимим для співробітника перед обміном, дозволяючи приймати зважені рішення.

Приклад: Політика щодо скриншотів у Jira для SaaS-служби підтримки

IT-служба підтримки SaaS-компанії створювала завдання Jira, що документують проблеми облікових записів користувачів. Скриншоти, прикріплені до завдань Jira, містили:

• Адреси електронної пошти користувачів (з інтерфейсів управління обліковими записами)
• Деталі плану підписки
• Суми та дати виставлення рахунків
• Іноді часткову платіжну інформацію

Аудит даних GDPR виявив, що 847 завдань Jira, створених протягом 18 місяців, містили скриншоти з PII. Доступ до Jira мали всі 200 інженерних співробітників, включаючи підрядників без Угод про обробку даних, що охоплюють доступ до платіжних даних клієнтів.

Підхід до усунення:

1. Ретроспективний аудит: виявлення PII на зображеннях для всіх скриншотів у наявних завданнях — переглянуто 847 завдань, 312 зі значним PII позначено для перегляду DPO
2. Виправлення завдань: в 89 завданнях скриншоти були замасковані (адреси електронної пошти клієнтів, платіжні деталі розмиті перед повторним прикріпленням)
3. Впровадження процесу: новий робочий процес підтримки, що вимагає перевірки PII на скриншоті перед прикріпленням до Jira
4. Навчання: 15-хвилинне навчання для всіх співробітників служби підтримки щодо процесу перевірки PII на скриншотах

Результати (через 90 днів після впровадження):

• Інциденти з PII на скриншотах у Jira: зменшилися на 90%
• Інциденти, що залишилися: випадки, коли співробітники підтримки продовжили роботу після перегляду із задокументованим обґрунтуванням (законна діагностична потреба з відповідним доступом на основі ролі)
• Перегляд DPA: обсяг доступу підрядників оновлено для виключення непотрібного витоку PII

312 історичних завдань Jira з PII-скриншотами стали висновком у аудиті GDPR. Зниження на 90% після впровадження задокументовано як свідчення усунення для відповіді на аудит.

Інтеграція перевірки скриншотів у колаборативні робочі процеси

Для організацій, що впроваджують контроль PII на скриншотах, не порушуючи операційних робочих процесів:

Легка інтеграція: Букмарклет браузера або легкий інструмент, який співробітники використовують перед вставкою в Slack/Jira — перетягніть скриншот → отримайте звіт про PII за 5 секунд → продовжуйте або анонімізуйте

Інтеграція з Jira/ServiceNow: Гачки перед прикріпленням, що запускають виявлення PII до прикріплення скриншотів до завдань — аналогічно антивірусній перевірці перед прикріпленням файлу

Інтеграція з ботом Slack: Бот, що отримує завантаження скриншотів до певних каналів, запускає виявлення PII та публікує відповідь у гілці з виявленими сутностями — роблячи PII видимим для каналу без блокування робочого процесу

Підхід на основі командних норм (найменше тертя): Командна норма + автоматизована вибірка щотижня — випадкова вибірка 10% скриншотів в інструментах співпраці, запуск виявлення PII на зображеннях, звітування результатів керівнику команди — створює відповідальність без блокування робочих процесів

Для документації GDPR: контроль PII на скриншотах є «організаційним заходом» відповідно до Статті 32. Документування контролю (політика + технічний інструмент) зі свідченнями впровадження (записи про навчання, показники зменшення інцидентів) відповідає принципу підзвітності Статті 5(2).

Джерела:

• Стаття 5 GDPR: Принципи обробки даних
• Стаття 32 GDPR: Безпека обробки
• ICO: Захист даних за задумом та за замовчуванням