Персональные данные на скриншотах во внутренних базах знаний
Внутренние базы знаний — Confluence, Notion, SharePoint, GitBook — содержат специфический тип проблемы с персональными данными, который стандартные инструменты соответствия пропускают: персональные данные клиентов, встроенные в скриншоты для документации процессов.
Эта схема воспроизводится в тысячах команд поддержки и операций.
Агент поддержки обнаруживает необычную настройку аккаунта. Он делает снимок экрана со страницей аккаунта клиента, чтобы задокументировать проблему. На снимке видно имя клиента в заголовке интерфейса, его электронная почта в настройках аккаунта и данные о тарифном плане.
Статья публикуется во внутренней базе знаний. Сто пятьдесят агентов поддержки теперь могут её видеть. Двенадцать подрядчиков внешнего хелпдеска — тоже. Статья полезна: она показывает, как разбирать этот пограничный случай. Каждый агент, столкнувшийся с такой ситуацией в будущем, прочитает её.
Три года спустя база знаний содержит 847 подобных статей. В каждой — скриншоты клиентских аккаунтов. Клиенты, чьи данные там отображены, не давали согласия на такое вторичное использование своих записей. Большинство из них даже не знают, что их данные там хранятся.
Это не мелкая проблема. С каждой новой статьей она растёт.
Уязвимость по GDPR: почему это важно
Анализ базы знаний со скриншотами по GDPR однозначен.
Минимизация данных (Статья 5(1)(c)): Персональные данные должны быть «адекватными, относимыми и ограниченными необходимым». Статья базы знаний о настройке аккаунта не нуждается в реальном имени и электронной почте клиента. Размытый скриншот служит той же цели. Включение реальных данных клиента не является необходимостью.
Ограничение цели (Статья 5(1)(b)): Данные, собранные для одной цели — обслуживания клиентов, — не могут быть использованы для другой цели — внутренней документации процессов — без правового основания. Данные аккаунта были собраны для предоставления услуг, а не для внутренней документации. Это два отдельных вида обработки. Использование одних и тех же данных для обоих требует действительного правового основания, которое большинство команд не установили.
Контроль доступа (Статья 5(1)(f) и Статья 32): Надлежащие технические меры должны защищать персональные данные. Скриншоты клиентских аккаунтов в инструменте, открытом для всех 150 агентов и подрядчиков — в том числе тех, у кого нет доступа к основной системе аккаунтов, — создают чрезмерно широкий доступ.
Право на удаление (Статья 17): Субъект данных, запрашивающий удаление, имеет право на удаление своих данных «без неоправданной задержки». Если его данные присутствуют в 23 статьях базы знаний в виде встроенных скриншотов, запрос требует поиска и обновления всех 23 статей. Без системы это затруднительно. Подробный порядок действий — в нашем руководстве по праву на удаление по GDPR.
Ни одна из этих трактовок не является пограничной. Это прямое применение текста регламента к распространённой практике.
Обход контроля доступа
Наиболее серьёзная проблема соответствия со скриншотами в Confluence — это создаваемый ими обход контроля доступа.
Команды поддержки используют ролевое управление доступом (RBAC) для ограничения круга лиц, имеющих доступ к системам клиентских аккаунтов. Агенты первого уровня видят базовые данные аккаунта. Агенты второго уровня видят записи о выставлении счётов и технические записи. Руководители видят полный профиль аккаунта.
Когда агент второго уровня создаёт статью базы знаний со скриншотом полного клиентского аккаунта, этот снимок становится виден каждому пользователю инструмента. Агенты первого уровня, которым не следует видеть записи о выставлении счётов, теперь могут их видеть. Подрядчики без системного доступа — тоже. Новые сотрудники при введении в должность — тоже.
Скриншот обходит RBAC-контроль системы клиентских аккаунтов. Персональные данные, которые RBAC был призван защищать, теперь открыты всем, у кого есть доступ к базе знаний.
Это не теоретический риск. Это закономерный результат рабочего процесса документирования. Снимок хранится без срока действия, без журнала доступа и без следственной цепочки.
Практические меры по устранению нарушений
Для команд, обнаруживших эту проблему в ходе аудита GDPR:
Ретроспективное устранение:
- Определите все страницы базы знаний с прикреплёнными изображениями
- Запустите обнаружение персональных данных для каждого вложения
- Проверьте помеченные изображения: файлы с высоким уровнем достоверности поступают в очередь проверки
- Для каждого помеченного изображения: замените его обезличенной версией или ограничьте доступ к странице
- Зафиксируйте действия по устранению нарушений в записях GDPR
Масштаб ретроспективных работ зависит от размера базы знаний. Для трёхлетней базы знаний команды поддержки из 50 человек количество изображений может достигать тысяч. Пакетная обработка изображений делает эту задачу выполнимой. Ручная проверка помеченных изображений — ключевое узкое место.
Превентивные меры:
- Обучите всех сотрудников поддержки обезличивать скриншоты перед публикацией в базе знаний
- Предоставьте инструменты: средства аннотирования скриншотов, размывающие имена клиентов перед вставкой
- Добавьте шаг проверки: назначенный рецензент проверяет статьи перед публикацией, специально проверяя наличие персональных данных клиентов в изображениях
- Проводите ежеквартальное пакетное сканирование всех вложений Confluence
Минимально жизнеспособная мера: Контрольный список при публикации: «Удалите или скройте все имена клиентов, адреса электронной почты и идентификаторы аккаунтов со скриншотов перед публикацией». Малотехнологично, без автоматизации, но создаёт задокументированную меру контроля. Для небольших команд это отправная точка.
Общая правовая база — в нашем обзоре соответствия GDPR, а о том, почему политика без технических средств контроля не работает — в статье «Политика без технических мер контроля не работает».
Почему проблема усугубляется со временем
Без системных мер контроля раскрытие персональных данных в базе знаний накапливается.
Объём: Каждая новая статья со скриншотом клиента увеличивает общий масштаб уязвимости. По мере роста команды поддержки и расширения базы знаний накопленный объём персональных данных тоже растёт. Именно те свойства, которые делают эти инструменты полезными, — лёгкость публикации, постоянство, широкий доступ — и усугубляют проблему с персональными данными.
Забытые статьи: Статьи о старых пограничных случаях, которые больше не встречаются, остаются доступными. В них хранятся персональные данные клиентов, которые с тех пор подали запросы на удаление. Никто не проверяет статью, обновлённую в последний раз в 2022 году.
Распространение между командами: Базы знаний нередко становятся кросс-функциональными. Статья поддержки со скриншотами клиентов может быть передана продуктовой команде, команде разработки или внешним подрядчикам для предоставления контекста по запросу на функцию или отчёту об ошибке. Каждая передача расширяет круг получателей персональных данных.
Накопление запросов на удаление: По мере накопления клиентских данных в базе знаний ответы на запросы об удалении становятся всё более сложными. Без системы нет надёжного способа подтвердить, что каждый экземпляр данных субъекта был найден и удалён. Команда не может дать достоверное подтверждение удаления.
Предотвратить проблемы с персональными данными в базе знаний проще, чем исправлять их. Меры контроля, внедрённые сейчас, позволяют избежать накапливающейся проблемы с устранением нарушений. Каждая статья, опубликованная без размытого скриншота, — это задача по устранению нарушений, отложенная на будущее.