Чому Excel — ваш найризикованіший тип файлів
Файли Excel є одним із найбільших ризиків GDPR у більшості компаній. Медичні записи можуть містити більше конфіденційних даних у кожному рядку. Але таблиці накопичують PII стрімко — і команди відповідності часто їх пропускають.
Три речі ускладнюють управління файлами Excel.
Обсяг: Один файл XLSX може містити 50 000 рядків і 100 стовпців. Це п'ять мільйонів клітинок. Жодна ручна перевірка не може охопити їх усі.
Сіткова структура: Текст іде в одному напрямку. Excel розподіляє дані по рядках і стовпцях. Персональні дані можуть ховатися будь-де в цій сітці.
Змішаний вміст: Діапазони оплати, коди відділів та посадові категорії знаходяться в одному файлі з ІПН та адресами електронної пошти. Видалення всього робить файл марним.
Тривале зберігання: Списки персоналу та записи клієнтів роками зберігаються в Excel. Стаття 5(1)(e) GDPR вимагає зберігати дані «не довше, ніж необхідно». Файли, що «можуть знадобитися», часто зберігаються значно довше за цей строк.
Чому стандартне сканування тексту не працює для таблиць
Інструменти аналізу тексту створені для документів. На таблицях вони дають збій кількома типовими способами.
Проблема ІПН-як-числа
Excel зберігає ідентифікаційні номери без дефісів як звичайні числа, а не текст. Сканер, налаштований на пошук формату ###-##-####, їх пропустить. Хороший інструмент повинен розуміти, що 9-значне число в стовпці «ІПН» — це ідентифікаційний номер.
Проблема дати-як-числа
Excel зберігає дати як порядкові номери. 6 лютого 2024 року зберігається як 45329. CSV-експорт покаже «45329» у стовпці «Дата народження». Сканер має конвертувати це число в реальну дату, перш ніж позначити значення.
Проблема часткового ІПН
Деякі системи показують лише останні чотири цифри номера (*--1234). Повний номер знаходиться в захищеному стовпці. Часткове значення все одно потребує анонімізації — навіть якщо воно не схоже на повний номер.
Проблема PII у формулах
Деякі клітинки формують PII з інших клітинок. Клітинка з =CONCATENATE(B2;" ";C2) показує повне ім'я. Якщо очистити стовпці B та C, це повне ім'я все одно буде видно у клітинці з формулою. Інструмент, що читає лише збережені значення, а не зв'язки формул, залишить PII на місці.
Проблема кількох аркушів
Велика книга може мати п'ять аркушів: Список клієнтів, Замовлення, Запити підтримки, Виставлення рахунків та Аналітика. Імена клієнтів з'являються на всіх п'яти. «Іван Петренко» на одному аркуші повинен стати тим самим токеном — «PERSON_0047» — на кожному іншому аркуші. Два різних токени порушують зв'язки записів.
Заголовки стовпців як сигнал
Найкраще покращення у виявленні PII в таблицях — аналіз заголовків стовпців.
Стовпець із назвою «ІПН» повідомляє інструменту, що всі значення в цьому стовпці є ідентифікаційними номерами. Це працює навіть якщо значення часткові, нестандартно відформатовані або збережені як числа.
| Заголовок стовпця | Що він сигналізує |
|---|---|
| ІПН / Ідентифікаційний номер / Податковий ІД | Вважати 9-значні числа ідентифікаційними номерами |
| Email / Е-пошта / Адреса ел. пошти | Позначати навіть часткові шаблони електронної пошти |
| Телефон / Мобільний | Приймати будь-який формат телефону |
| Дата народження / День народження | Конвертувати порядкові номери в дати |
| Ім'я / Прізвище / Повне ім'я | Знижувати поріг виявлення імен |
| Адреса / Вулиця / Місто / Індекс | Об'єднувати суміжні поля місцезнаходження |
| ID пацієнта / Номер картки | Застосовувати шаблони медичних ідентифікаторів |
Контекст стовпця не замінює сканування вмісту — він його доповнює. У стовпці «ІПН» зі 100 значеннями сканування вмісту знаходить 99 добре відформатованих. Контекст стовпця знаходить те, що виглядає нестандартно.
Зберегти структуру, видалити імена
Мета у більшості випадків GDPR з Excel — не знищити файл, а вилучити персональні дані, зберігаючи те, що робить файл корисним.
Для файлу кадрових записів з 15 000 рядків спеціаліст із відповідності потребує:
Видалити:
- Імена співробітників → токени PERSON_XXXX
- ІПН → REDACTED
- Адреси електронної пошти → REDACTED
- Номери телефонів → REDACTED
- Домашні адреси → REDACTED
Зберегти:
- Коди відділів
- Посади (лише загальні ролі)
- Діапазони оплати (широкі категорії)
- Оцінки ефективності (групові дані)
- Дати початку роботи (для статистики стажу)
- Коди менеджерів (якщо псевдонімізовані)
Інструмент, що розрізняє «дані, що ідентифікують людей», і «дані, що описують посади», дає файл, придатний для HR-аналізу — і відповідний вимогам GDPR щодо мінімізації даних.
Реальний випадок: передача кадрових даних при злитті та поглинанні
Компанія-покупець отримує кадрові записи від цільової компанії: файл XLSX з 15 000 рядків і 40 стовпців. Файл потрібно передати зовнішній HR-фірмі для планування пільг. GDPR дозволяє передавати лише дані, необхідні для цього завдання.
До обробки: 40 стовпців з повними іменами, ІПН, адресами електронної пошти, домашніми адресами, контактами для екстрених ситуацій та банківськими реквізитами.
Після обробки з контекстом стовпців:
- 12 стовпців безпосередньо ідентифікують людей (імена, ІПН, електронна пошта, телефон, адреси, банківські дані): замінено послідовними токенами
- 3 стовпці опосередковано ідентифікують людей (ІД співробітника, код менеджера, код посади): замінено псевдонімними токенами, що збігаються в межах файлу
- 25 стовпців є агрегованими даними (діапазон оплати, відділ, стаж, рівень): залишено без змін
Час обробки: 8 хвилин для 600 000 клітинок
Результат: Той самий макет XLSX, 40 стовпців, 15 анонімізованих, 25 без змін
Журнал аудиту: Запис на рівні клітинок кожної дії з типом сутності, оцінкою впевненості та використаним сигналом стовпця
HR-фірма отримує повний набір даних для роботи — без імен та ідентифікаторів. Запис відповідності отримує доказ того, що передані лише правильні дані.
Ця проблема не унікальна для Excel. Кожен формат файлів дає збій по-своєму. Дивіться як фрагментація форматів впливає на виявлення PII для огляду різних типів файлів.
Три правила Статті 5 GDPR, один процес
Структурована анонімізація таблиць відповідає трьом правилам одночасно.
Мінімізація даних (ст. 5(1)(c)): Одержувачу надходять лише стовпці, необхідні для завдання. Ідентифікуючі стовпці очищуються.
Обмеження зберігання (ст. 5(1)(e)): Оригінальний файл зберігається для законного утримання. Для передачі створюється чиста копія — з коротшою потребою зберігання або без неї.
Цілісність та конфіденційність (ст. 5(1)(f)): Ніякі ідентифікуючі дані не виходять за межі зони контролю. Поширюються лише чисті копії.
Журнал аудиту з процесу — також доказ за Статтею 5(2). Він показує, як кожне правило виконано для кожного файлу.
Якщо ваша команда обробляє DSAR або великі експорти даних, та сама логіка застосовується на рівні API. Дивіться як мінімізація даних GDPR працює в API реального часу.
Для команд, що працюють з великими обсягами в стислі терміни, дивіться пакетну обробку GDPR DSAR у масштабі для відповідних шаблонів робочого процесу.