Защо Excel е вашият най-рисков тип документ
От всички видове документи, които натрупват PII в бизнес среди, електронните таблици са сред най-опасните от гледна точка на съответствието със GDPR.
Не защото са най-чувствителни - медицинските досиета и правните документи очевидно са с по-висок риск за отделните субекти на данни. Но тъй като електронните таблици Excel имат характеристики, които ги правят систематично недостатъчно третирани от процесите на съответствие:
Обем и разпространение: Един файл XLSX може да съдържа 50 000 реда и 100 колони. Всяка клетка е потенциално местоположение на PII. Никой процес на ръчен преглед не се мащабира надеждно до този обем.
Структурно разнообразие: За разлика от текстови документи (последователни) или PDF файлове (базирани на страници), Excel има двуизмерна структура с контекст, разпределен хоризонтално (заглавки на колони) и вертикално (връзки на редове). PII може да се появи навсякъде.
Критични за бизнеса не-PII данни, смесени с PII: Цифрите на заплатите, резултатите от работата, кодовете на отделите и други законни бизнес данни съществуват в същата електронна таблица като SSN и имейл адресите. Безразборното анонимизиране, което замъглява данните, които не са PII, прави електронната таблица безполезна.
Дълго задържане без преглед: Базите данни с клиенти, регистрите на служителите и списъците с доставчици се натрупват във файлове Excel и често се съхраняват с години без преглед на GDPR. Принципът на GDPR за ограничаване на съхранението (член 5(1)(e)) изисква данните да се съхраняват „не по-дълго, отколкото е необходимо“ — но електронните таблици, които „може да са полезни“, са склонни да се съхраняват за неопределено време.
Техническите предизвикателства при откриването на PII в електронни таблици
Стандартните подходи за анализ на текст се провалят при електронни таблици по предвидими начини:
Проблемът със SSN като номер
Социалноосигурителните номера на САЩ, съхранявани в Excel клетки без тирета (123456789), се съхраняват като числа от Excel, а не като текст. Текстовият анализ, който сканира за модела "###-##-####", ще пропусне тези. Разпознаването на формата трябва да разпознае, че 9-цифрен номер в колона с надпис „SSN“ е социалноосигурителен номер дори без тирета.
Проблемът с датата като число
Excel съхранява вътрешно датите като серийни номера (1 януари 1900 г. = 1; 6 февруари 2024 г. = 45329). Клетка, показваща „02/06/2024“, се съхранява като „45329“. Анализът на експортиран CSV от Excel може да види „45329“ в колона „Дата на раждане“ — число, а не дата. Откриването, съобразено с контекста, трябва да се справи с това преобразуване.
Проблемът с частичния SSN
Някои работни потоци за съответствие съхраняват SSN само с последните четири цифри, видими за оперативна употреба (*--1234). Пълният SSN се съхранява в отделна заключена колона за оторизирани потребители. Изисква се анонимизиране на частичната стойност, въпреки че тя не съответства на пълни SSN модели.
Проблемът с изчислените лични данни
Някои клетки съдържат формули, които произвеждат PII стойности от други клетки. Клетка с =CONCATENATE(B2," ",C2) може да създаде пълно име от колони със собствено и фамилно име. Анонимизирането на колоните за име и фамилия (B и C) е правилно; клетката за конкатенация също трябва да се актуализира. Инструментите, които анализират стойностите на клетките, без да вземат предвид препратките към формулите, могат да създадат електронни таблици, в които PII се появява в изходните данни на формулата дори след като клетките източник са анонимизирани.
Проблемът с консистенцията на няколко листа
Голяма работна книга Excel може да има 5 листа: „Списък на клиенти“, „Поръчки“, „Билети за поддръжка“, „Таксуване“, „Аналитика“. Имената на клиентите се появяват във всичките пет листа. Последователното анонимизиране изисква един и същи клиент да получава един и същ токен за анонимизиране във всички листове — така че „Джон Смит“ в списъка с клиенти и „Джон Смит“ в билетите за поддръжка да стават последователно „PERSON_0047“, а не два различни токена, които нарушават връзката на записа.
Контекст на колона като сигнал за откриване
Най-значимото подобрение в специфичното за електронна таблица откриване на PII е анализът на контекста на заглавката на колоната.
Принципът: колона с етикет „SSN“ или „Social Security Number“ сигнализира на системата за откриване, че всички стойности в тази колона трябва да се третират като номера на социална осигуровка, дори ако отделните стойности са частични, форматирани по различен начин или съхранени като числа.
Сигнали за контекст на колона, които подобряват точността на откриване:
| Заглавие на колона | Сигнал за откриване |
|---|---|
| SSN / Социално осигуряване / Данъчен номер | SSN контекст — 9-цифрени номера, третирани като SSN |
| Имейл / Имейл / Имейл адрес | Контекст на имейл — валидира дори частични модели |
| Телефон / Телефон / Мобилен / Мобилен | Телефонен контекст — приема различни формати |
| DOB / Date of Birth / Birthday | Контекст на датата — преобразува серийните номера в дати |
| Име / Фамилия / Пълно име | Контекст на името — понижава прага за откриване на NER |
| Адрес/Улица/Град/Пощенски код | Контекст на адреса — комбинира географски полета |
| ID на пациента / MRN / Номер на запис | Контекст на ID на здравеопазването — специфични за лечебното заведение модели |
Анализът на контекста на колоната не замества анализа на съдържанието - той го допълва. Колона с етикет „SSN“ със 100 стойности ще открие 99-те добре форматирани SSN чрез анализ на съдържанието; контекстът на колоната помага за откриване на 1 неправилно форматирана или частична стойност.
Изискването за запазване: Анонимизиране на PII, запазване на структурата
Целта за съответствие за повечето сценарии на Excel GDPR не е да се унищожи електронната таблица — тя е да се премахнат личните идентификатори, като същевременно се запази структурата на данните, която прави електронната таблица полезна.
За електронна таблица със записи на служители от 15 000 реда служителят по съответствието GDPR се нуждае от:
Анонимизиране:
- Имена на служители → PERSON_XXXX токени
- SSN → REDACTED
- Имейл адреси → REDACTED
- Телефонни номера → REDACTED
- Домашни адреси → REDACTED
Запазване:
- Кодове на отдели (не лични идентификатори)
- Job titles (general roles, not individually identifying)
- Групи на заплатите (обобщени категории, а не конкретни суми в някои реализации)
- Резултати от ефективността (статистически данни)
- Начални дати (за анализ на владението без идентифициране на лица)
- Кодове на мениджъри (ако мениджърите са псевдонимизирани последователно)
Инструмент, който запазва разграничението между „неща, които идентифицират индивидите“ и „неща, които описват моделите на заетост“, създава електронна таблица, която остава полезна за целите на HR анализа, като същевременно отговаря на изискванията за минимизиране на данните и псевдонимизация.
Случай на използване: Трансфер на данни за човешки ресурси за сливания и придобивания
Придобиваща компания получава записи на служители от придобитата компания: 15 000 реда XLSX с 40 колони. Данните трябва да бъдат споделени с външен консултант по човешки ресурси за планиране на интегрирането на предимствата. GDPR изисква да се споделят само данните, необходими за планиране на доходите — групи на заплатите, кодове на отдели, мандат, длъжностни степени — не идентифициращата информация.
Преди анонимизация: 40 колони × 15 000 реда, включително пълни имена, SSN, имейл адреси, домашни адреси, контакти при спешни случаи и информация за банкова сметка за заплати.
Обработка с откриване на контекст на колона:
- 12 колони, идентифицирани като директно идентифициращи (имена, SSN, имейли, телефон, адрес, банкова сметка): замяна клетка по клетка с последователни токени
- 3 колони, идентифицирани като индиректно идентифициращи (идентификационен номер на служител, код на мениджър, уникален код на работа): заменени с псевдонимни токени (последователни във файла, без препратки към външни записи)
- 25 колони, идентифицирани като неидентифициращи статистически данни (група на заплатите, отдел, мандат, степен): запазени непроменени
Време за обработка: 8 минути за 600 000 клетки Изход: XLSX в оригинален формат, 40 колони непокътнати, 15 колони анонимизирани/псевдонимизирани, 25 колони непроменени Доклад за одит: Регистър на ниво клетка на всички 200 000+ анонимни действия с използван тип обект, увереност и контекст на колона
За консултанта по човешки ресурси: пълен набор от данни за планиране на доходите без идентифицираща информация. За записа за съответствие на GDPR: одитен доклад, демонстриращ ограничение на целта — споделени са само данните, необходими за конкретната задача.
GDPR Изисквания на член 5, удовлетворени от структурираната анонимност
Анонимизирането, специфично за електронни таблици, отговаря едновременно на три принципа на член 5:
**Минимизиране на данните (чл. 5, параграф 1, буква в)): ** Споделят се само колоните, необходими за конкретната цел; идентифициращите колони са анонимизирани.
Ограничение на съхранението (чл. 5(1)(e)): Оригиналните файлове се запазват (с идентифициращи данни) за законоустановените периоди на съхранение; анонимизираните версии се създават за споделяне на контексти с по-кратки или никакви изисквания за задържане.
Почтеност и поверителност (чл. 5(1)(f)): Идентификационните данни са премахнати от всички случаи на споделяне; само анонимизирани версии напускат контролната среда.
Одитната пътека от процеса на анонимизиране предоставя документацията за отчетност по член 5(2) — демонстрираща съответствие с всеки принцип за всяка обработена електронна таблица.
Източници:
- [GDPR член 5: Принципи, свързани с обработката на лични данни] (https://gdpr-info.eu/art-5-gdpr/)
- ICO: Практически кодекс за анонимизиране
- EDPB: Указания за псевдонимизиране