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