Слепата точка на DLP која не сте ја ревидирале
DLP алатките ги надгледуваат мрежниот сообраќај, датотеките на е-поштата и трансферот на датотеки. Ги фаќаат табелите со колони за ЕМБГ. Ги обележуваат е-поштите со списоци на клиенти. Ги блокираат поставувањата со медицински записи.
Не ги фаќаат снимките на екранот.
Снимката на екранот е сликовна датотека. Личните податоци во неа се нацртани како пиксели. Не се зачувани како текст. DLP-моторите кои скенираат за шаблони на лични податоци не наоѓаат ништо.
Секој ден, вработените ги залепуваат снимките на екранот во Slack, Jira, Teams и ланци на е-пошта. Не се испаќаат DLP-предупредувања.
Како снимките на екранот ги шират личните податоци на работното место
Далечинскиот и хибридниот начин на работа ги направи снимките на екранот вообичаени. Внатрешните алатки се полни со нив секој ден.
Членовите на тимот споделуваат снимки за брз контекст:
- Агентите за поддршка ги снимаат прегледите на сметките на клиентите за да ги споделат со тим-лидерите.
- Програмерите споделуваат евиденции за грешки кои вклучуваат податоци внесени од корисникот.
- Менаџерите на сметки испраќаат CRM записи за да дадат контекст на финансиските тимови.
- IT-администраторите снимаат системски прегледи за да ги документираат поставките за изведувачите.
- Производствените тимови споделуваат прегледи на контролната табла во ажурирањата за засегнатите страни.
Секој прилог може да содржи лични информации. Снимката на сметката на клиентот содржи ime, е-пошта, статус и адреса за наплата. Датотека со евиденција за грешки може да вклучи имиња, адреси или телефонски броеви внесени од корисниците. Снимката на CRM запис ја содржи целосната слика на сметката. Датотека на контролна табла може да покаже кориснички ID-броеви во ознаките на графиконите.
Проблемот со контролата на пристап
Сpoделувањето снимки на екранот исто така создава проблем со контролата на пристап.
Повеќето организации спроведуваат контроли на пристап засновани на улоги на производствените системи. Агентот за поддршка гледа само записи од неговата опашка. Изведувачот гледа само доделени проектни датотеки.
Кога агентот ќе снима запис на клиент и ќе го залепи во Slack-канал со изведувачи, контролата на пристап е заобиколена. Изведувачот добива лични податоци до кои не може да стигне преку нормалните патишта. DPA за работата на изведувачот можеби не го опфаќа овој трансфер. Правата на клиентот согласно GDPR можеби не важат за тој изведувач.
Ова заобиколување е прашање согласно член 5(1)(ж) на GDPR. Тој ги опфаќа интегритетот и доверливоста. Може исто така да создаде проблеми со усогласувањето според член 28 ако изведувачите добијат лични податоци без соодветни DPA. Видете го нашиот водич за усогласеност со GDPR за контролна листа на обврски согласно член 28.
Откривање лични податоци во слики како техничка заштитна мерка
Техничката заштитна мерка за изложеност на лични податоци преку снимки е OCR плус NLP откривање. Чекорите се едноставни.
- Вработениот снима екран на кориснички интерфејс.
- Пред споделување: ја поставува снимката во алатка за откривање.
- Алатката извлекува видлив текст преку OCR.
- NLP наоѓа ентитети со лични податоци во текстот.
- Вработениот гледа извештај: "Оваа снимка содржи: [ime на клиентот], [адреса за е-пошта], [ID на сметката]."
- Вработениот потоа ги редактира личните податоци, го стеснува опсегот на споделување или продолжува со пишано образложение.
Ова не ги блокира сите споделувања. Ги покажува личните информации пред да се преместат. Луѓето потоа можат да донесуваат информирани одлуки. Видете како ова се вклопува во вашиот стек за заштита на страницата за заштитни мерки.
Случај на употреба: Политика за снимки во 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 се справува со ова за вашиот тим? Посетете ја нашата страница за планови или прочитајте ја изјавата на основачот за деидентификација.
Извори
- GDPR член 5: Принципи за обработка на податоци. VERIFIED-EXTERNAL.
- GDPR член 32: Безбедност на обработката. VERIFIED-EXTERNAL.
- ICO: Заштита на податоците по дизајн и стандардно. VERIFIED-EXTERNAL.