Чому Excel є вашим типом документа з найвищим ризиком
З усіх типів документів, що накопичують PII у бізнес-середовищах, електронні таблиці є одними з найбільш небезпечних з точки зору відповідності GDPR.
Не тому, що вони є найбільш конфіденційними — медичні записи та юридичні документи мають явно вищий ризик для окремих суб'єктів даних. Але тому, що електронні таблиці Excel мають характеристики, які роблять їх систематично недостатньо обробленими процесами відповідності:
Обсяг і поширення: Один файл XLSX може містити 50 000 рядків і 100 стовпців. Кожна комірка є потенційним місцем розташування PII.
Структурна різноманітність: На відміну від текстових документів (послідовних) або PDF (сторінкових), Excel має двовимірну структуру з контекстом, розподіленим горизонтально (заголовки стовпців) і вертикально (відносини рядків).
Бізнес-критичні дані, що не є PII, змішані з PII: Цифри зарплат, оцінки продуктивності, коди відділів та інші законні бізнес-дані існують в тій самій таблиці, що й SSN та адреси електронної пошти.
Тривале зберігання без огляду: Бази даних клієнтів, реєстри співробітників та списки постачальників накопичуються в файлах Excel і часто зберігаються роками без огляду відповідно до GDPR.
Технічні проблеми виявлення PII в електронних таблицях
Проблема SSN-як-числа
Номери соціального страхування США, що зберігаються в комірках Excel без тире (123456789), зберігаються Excel як числа, а не як текст. Текстовий аналіз, що шукає шаблон «###-##-####», пропустить їх.
Проблема дати-як-числа
Excel зберігає дати як серійні числа внутрішньо. Аналіз CSV, експортованого з Excel, може бачити «45329» у стовпці «Date of Birth» — число, а не дату.
Проблема виявлення за контекстом стовпця
Найбільш значне покращення у виявленні PII, специфічному для таблиць, — це аналіз контексту заголовку стовпця:
| Заголовок стовпця | Сигнал виявлення |
|---|---|
| SSN / Social Security / Tax ID | Контекст SSN — 9-значні числа розглядаються як SSN |
| Email / E-mail | Контекст email — перевіряє навіть часткові шаблони |
| Phone / Telephone / Mobile | Контекст телефону — приймає різне форматування |
| DOB / Date of Birth | Контекст дати — конвертує серійні числа в дати |
| First Name / Last Name | Контекст імені — знижує поріг для NER |
| Patient ID / MRN | Контекст healthcare ID — специфічні шаблони закладу |
Вимога до збереження: анонімізуйте PII, зберігайте структуру
Мета відповідності для більшості сценаріїв Excel GDPR — не знищити таблицю, а видалити персональні ідентифікатори, зберігши структуру даних, що робить таблицю корисною.
Для 15 000-рядкової таблиці записів співробітників:
Анонімізувати:
- Імена співробітників → токени PERSON_XXXX
- SSN → REDACTED
- Адреси електронної пошти → REDACTED
- Номери телефонів → REDACTED
Зберегти:
- Коди відділів, посади, шкали зарплат, оцінки продуктивності, дати початку роботи
Вимоги статті 5 GDPR, що задовольняються структурованою анонімізацією
- Мінімізація даних (ст. 5(1)(c)): Лише стовпці, необхідні для конкретної мети, передаються; ідентифікаційні стовпці анонімізуються.
- Обмеження зберігання (ст. 5(1)(e)): Вихідні файли зберігаються для встановлених законом термінів; анонімізовані версії створюються для контекстів обміну.
- Цілісність та конфіденційність (ст. 5(1)(f)): Ідентифікаційні дані видалено з усіх екземплярів обміну.
Джерела: