Слепото петно на DLP, което не сте одитирали
DLP инструментите следят мрежовия трафик, имейл файловете и прехвърлянията. Хващат електронни таблици с колони ЕГН. Маркират имейли с клиентски списъци. Блокират качвания с медицински досиета.
Те не хващат снимки на екрана.
Снимката на екрана е файл с изображение. Личните данни в нея са нарисувани като пиксели. Те не се съхраняват като текст. DLP двигателите, които сканират за шаблони на лични данни, не намират нищо.
Всеки ден служителите поставят снимки на екрана в Slack, Jira, Teams и имейл вериги. Нито един DLP сигнал не се задейства.
Как снимките на екрана разпространяват лични данни на работното място
Дистанционната и хибридната работа направи споделянето на снимки ежедневно. Вътрешните инструменти се запълват с тях всеки ден.
Членовете на екипа споделят снимки за бърз контекст:
- Служителите в поддръжката хващат изгледи на клиентски акаунти, за да ги споделят с ръководители на екипи.
- Разработчиците споделят дневници с грешки, съдържащи данни, въведени от потребители.
- Мениджърите по акаунти изпращат CRM записи, за да дадат контекст на финансовите екипи.
- ИТ администраторите снимат системни изгледи, за да документират конфигурации за изпълнители.
- Продуктовите екипи споделят изгледи на табла в актуализации за заинтересованите страни.
Всеки прикачен файл може да съдържа лична информация. Снимката на клиентски акаунт съдържа име, имейл, статус и адрес за фактуриране. Файл с грешки може да включва имена, адреси или телефони, въведени от потребители. Снимка на CRM запис съдържа пълния профил на акаунта. Файл с табло може да показва потребителски идентификатори в етикети на диаграми.
Проблемът с контрола на достъпа
Споделянето на снимки на екрана създава и проблем с контрола на достъпа.
Повечето организации прилагат ролеви контрол на достъпа (RBAC) в производствените системи. Служителят в поддръжката вижда само собствените си записи от опашката. Изпълнителят вижда само назначените му файлове по проекта.
Когато служителят хване снимка на клиентски запис и я постави в Slack канал с изпълнители, контролът на достъпа е заобиколен. Изпълнителят получава лични данни, до които не би могъл да достигне по нормални пътища. Споразумението за обработка на данни за работата с изпълнители може да не обхваща това прехвърляне. Правата по GDPR на клиента може да не важат за този изпълнител.
Това заобикаляне е проблем по член 5(1)(f) от GDPR. Той обхваща цялостност и поверителност. Може да създаде и проблеми по член 28, ако изпълнители получат лични данни без надлежни DPA. Вижте нашето ръководство за съответствие с GDPR за контролен списък на задълженията по член 28.
Засичане на лични данни в изображения като техническа защитна мярка
Техническата защитна мярка срещу разкриването на лични данни чрез снимки е 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 hook: Засичане, което работи преди файловете да достигнат до тикети. Работи като сканиране за вируси преди качване на файл.
Slack бот: Бот, получаващ качванията на снимки в избрани канали. Изпълнява засичане на лични данни. Публикува отговор в нишката с откритите обекти. Прави личната информация видима, без да блокира работния процес.
Екипна норма плюс извадково тестване: Седмична автоматична проверка. Вземете извадка от 10 процента от снимките в инструментите за сътрудничество. Изпълнете засичане. Докладвайте констатациите на ръководителя на екипа. Това изгражда отчетност без блокиране на работния процес.
За GDPR записи: контролът на лични данни в снимките се счита за "организационна мярка" по член 32. Документирайте защитната мярка -- политика плюс технически инструмент. Добавете доказателство за използване. Това отговаря на правилото за отчетност по член 5(2). Вижте нашата страница за съответствие и записа в речника за член 32.
Искате да видите как anonym.legal се справя с това за вашия екип? Посетете страницата ни с планове или прочетете изявлението на основателя за деидентификация.
Източници
- GDPR член 5: Принципи за обработка на данни. VERIFIED-EXTERNAL.
- GDPR член 32: Сигурност на обработването. VERIFIED-EXTERNAL.
- ICO: Защита на данните чрез проектиране и по подразбиране. VERIFIED-EXTERNAL.