Слепое пятно DLP, которое вы ещё не проверяли
Инструменты DLP отслеживают сетевой трафик, вложения в письмах и передачу файлов. Они перехватывают таблицы со столбцами SSN. Помечают письма со списками клиентов. Блокируют загрузку медицинских записей.
Но снимки экрана они не перехватывают.
Снимок экрана — это графический файл. Персональные данные в нём представлены пикселями. Они не хранятся в виде текста. Системы DLP, сканирующие данные по шаблонам, не находят ничего.
Каждый день сотрудники вставляют снимки экрана в Slack, Jira, Teams и цепочки писем. Ни одного DLP-предупреждения.
Как скриншоты распространяют персональные данные на работе
Удалённая и гибридная работа сделала обмен скриншотами обычной практикой. Внутренние инструменты ежедневно пополняются ими.
Сотрудники делятся снимками для быстрой передачи контекста:
- Агенты поддержки захватывают экраны клиентских аккаунтов, чтобы поделиться с руководителями.
- Разработчики пересылают логи ошибок, содержащие данные пользовательского ввода.
- Менеджеры по работе с клиентами отправляют записи из CRM для предоставления контекста финансовым командам.
- IT-администраторы захватывают системные экраны, чтобы документировать конфигурации для подрядчиков.
- Продуктовые команды делятся видами дашбордов в обновлениях для заинтересованных сторон.
Каждое вложение может содержать персональные данные. Снимок клиентского аккаунта содержит имя, электронную почту, статус и адрес выставления счёта. Файл лога ошибок может включать имена, адреса или телефоны, введённые пользователями. Снимок записи CRM содержит полный профиль аккаунта. Файл дашборда может показывать идентификаторы пользователей в подписях к графикам.
Проблема контроля доступа
Обмен снимками экрана также создаёт проблему контроля доступа.
Большинство организаций применяют ролевое управление доступом к производственным системам. Агент поддержки видит только записи своей очереди. Подрядчик видит только файлы назначенного проекта.
Когда агент захватывает запись клиента и вставляет её в Slack-канал с подрядчиками, контроль доступа обходится. Подрядчик получает персональные данные, к которым не имел доступа по обычным каналам. Соглашение об обработке данных (DPA) для подрядных работ может не охватывать эту передачу. Права клиента по GDPR могут не распространяться на этого подрядчика.
Этот обход является нарушением Статьи 5(1)(f) GDPR, касающейся целостности и конфиденциальности. Он может также создавать проблемы соответствия Статье 28, если подрядчики получают персональные данные без надлежащих DPA. Подробный контрольный список обязательств по Статье 28 — в нашем руководстве по соответствию GDPR.
Обнаружение персональных данных в изображениях как техническая защитная мера
Технической защитной мерой против раскрытия персональных данных через снимки экрана является OCR в сочетании с обнаружением на основе NLP. Шаги просты.
- Сотрудник делает снимок экрана с клиентским интерфейсом.
- Перед отправкой: загружает снимок в инструмент обнаружения.
- Инструмент извлекает видимый текст через OCR.
- NLP находит сущности персональных данных в тексте.
- Сотрудник видит отчёт: «Этот снимок содержит: [имя клиента], [адрес электронной почты], [идентификатор аккаунта]».
- Сотрудник редактирует персональные данные, сужает круг получателей или продолжает с письменным обоснованием.
Это не блокирует обмен полностью. Это показывает персональные данные до того, как они будут переданы. Люди могут принимать осознанные решения. Узнайте, как это вписывается в вашу систему защиты на странице защитных мер.
Практический случай: политика проверки скриншотов в Jira для SaaS-компании
Служба поддержки SaaS-компании использовала Jira для регистрации проблем с аккаунтами. Файлы, прикреплённые к тикетам, содержали персональные данные пользователей. В частности:
- Электронные адреса пользователей с экранов управления аккаунтами.
- Сведения о тарифных планах.
- Суммы и даты выставления счётов.
- В некоторых случаях — частичные платёжные данные.
Аудит GDPR выявил 847 тикетов в Jira, созданных за 18 месяцев. Все содержали вложения с персональными данными. Jira была открыта для всех 200 инженеров. Некоторые из них были подрядчиками без DPA на клиентские платёжные записи.
Меры по устранению:
- Ретроспективный аудит: обнаружение персональных данных во всех существующих вложениях. 312 тикетов помечены для проверки DPO.
- Очистка тикетов: в 89 тикетах файлы были заменены до повторного прикрепления.
- Изменение процесса: внедрён новый рабочий процесс с обязательной проверкой на персональные данные перед прикреплением к Jira.
- Обучение: 15-минутный инструктаж для всего персонала службы поддержки.
Результаты через 90 дней:
- Инциденты с персональными данными в Jira: снижение на 90 процентов.
- Оставшиеся инциденты: случаи, когда сотрудники действовали с письменным обоснованием диагностической необходимости.
- Область действия DPA: обновлена для сокращения излишнего раскрытия персональных данных подрядчикам.
312 исторических тикетов стали выводом о несоответствии. Снижение на 90 процентов послужило доказательством устранения нарушений в ответе на аудит.
Интеграция проверки скриншотов в рабочие процессы команды
Для организаций, желающих внедрить контроль персональных данных, не замедляя работу, существует несколько вариантов.
Облегчённый вариант: Браузерный инструмент, который сотрудники используют перед вставкой в Slack или Jira. Перетащите снимок — получите отчёт о персональных данных за пять секунд, затем продолжите или отредактируйте.
Хук для Jira или ServiceNow: Обнаружение, которое срабатывает до того, как файлы попадают в тикеты. Работает как антивирусное сканирование перед загрузкой файла.
Slack-бот: Бот, принимающий загрузки скриншотов в выбранных каналах. Запускает обнаружение персональных данных. Публикует ответ в треде с обнаруженными сущностями. Делает персональные данные видимыми, не блокируя рабочий процесс.
Командная норма с выборочным контролем: Еженедельная автоматическая проверка. Выборка 10 процентов скриншотов в инструментах совместной работы. Запуск обнаружения. Отчёт для руководителя команды. Формирует ответственность, не блокируя ни один рабочий процесс.
Для записей GDPR: контроль персональных данных на скриншотах считается «организационной мерой» по Статье 32. Задокументируйте защитную меру — политику плюс технический инструмент. Добавьте доказательства использования. Это выполняет требование об ответственности по Статье 5(2). Подробнее — на нашей странице соответствия и в словарной статье для Статьи 32.
Хотите узнать, как anonym.legal решает эту задачу для вашей команды? Посетите страницу тарифов или ознакомьтесь с заявлением основателя об обезличивании данных.
Источники
- Статья 5 GDPR: Принципы обработки данных. VERIFIED-EXTERNAL.
- Статья 32 GDPR: Безопасность обработки. VERIFIED-EXTERNAL.
- ICO: Защита данных по дизайну и по умолчанию. VERIFIED-EXTERNAL.