GDPR Article 32: шифрование и псевдонимизация как технические меры защиты ПДн

После того как в феврале мы разобрали аудит ПДн по GDPR, несколько клиентов задали логичный следующий вопрос: хорошо, организационная часть понятна, а что конкретно делать технически? Статья 32 GDPR называет шифрование и псевдонимизацию первыми в списке «подходящих технических мер». Вот чем мы занимались последние несколько недель.

Что говорит статья 32

Формулировка там намеренно неконкретная: регламент не предписывает конкретный алгоритм или продукт, а требует «принять соответствующие технические и организационные меры с учётом уровня риска». Перечень - шифрование, псевдонимизация, обеспечение постоянной конфиденциальности и целостности, возможность восстановления доступа. Из этого нужно выбрать то, что реально снижает риск в конкретной инфраструктуре. Регулятор смотрит не на чекбоксы, а на обоснование выбора.

На практике для большинства наших клиентов актуальны два направления: шифрование данных в базах и псевдонимизация в аналитике. С ними и работаем.

TDE: шифрование на уровне хранилища

Transparent Data Encryption - самый прямолинейный способ закрыть сценарий «утащили файлы базы данных». TDE шифрует файлы данных и журналы транзакций на диске; приложение с базой работает как обычно через авторизованное соединение.

Из того, с чем имеем дело в проектах прямо сейчас:

• PostgreSQL. Нативного TDE в PostgreSQL нет - есть pgcrypto для шифрования отдельных колонок и шифрование на уровне файловой системы (dm-crypt / LUKS). Для продакшн-деплоя под GDPR обычно выбираем LUKS: прозрачно для приложения, управление ключами через LUKS keyfile или TPM, аудит - через стандартные средства ОС.
• Microsoft SQL Server. TDE здесь есть из коробки начиная с версии 2008. Включается в несколько команд: создать master key, создать сертификат, создать encryption key для базы, включить шифрование. Ключевой момент - резервная копия сертификата хранится отдельно от бэкапов базы. Если забыть об этом, восстановление станет очень увлекательным опытом.
• MySQL / MariaDB. InnoDB tablespace encryption появилась в MySQL 5.7.11. Управление ключами через keyring-плагин; для продакшн лучше использовать keyring_vault с HashiCorp Vault, а не keyring_file, который хранит ключ рядом с данными - смысл шифрования при этом сомнителен.

Что TDE не закрывает: данные в памяти во время обработки, данные в транзите (это отдельно - TLS на соединениях), и главное - несанкционированный доступ легитимного пользователя базы. TDE защищает от физической кражи носителя и от того, что кто-то скопирует файлы базы без доступа к ключам. Это важно зафиксировать в документации по рискам - чтобы не возникало иллюзий.

Псевдонимизация в аналитических витринах

Второй большой фронт - аналитика. Типичная история: в продакшн-базе живут полные ПДн с именами, email-адресами, идентификаторами; аналитическая витрина или DWH собирается из этих данных, и в итоге в BI-инструменте у аналитиков видны те же прямые идентификаторы. Иногда это нужно - иногда нет.

Псевдонимизация по GDPR - это замена прямых идентификаторов на псевдонимы так, чтобы без отдельного ключа соответствия нельзя было вернуться к исходному субъекту. При этом псевдонимизированные данные всё ещё считаются персональными по GDPR - просто с пониженным уровнем риска и, соответственно, меньшими требованиями к мерам защиты для слоя аналитики.

Что делаем на практике:

Первое - инвентаризация прямых идентификаторов. Проходим по всем таблицам витрины и помечаем колонки: прямой идентификатор (имя, email, телефон, ИНН), косвенный (IP, cookie_id, device_id), не-ПДн. Без этой карты дальнейшее - гадание.

Второе - замена на суррогатные ключи. Для аналитических задач, где важна возможность связать события одного пользователя между собой, но не нужно знать кто он, заменяем прямой идентификатор на детерминированный хеш с солью. HMAC-SHA256 с секретным ключом - соответствие сохраняется, обратное восстановление без ключа невозможно. Ключ хранится отдельно от витрины.

Третье - сегрегация витрин. Аналитики, которым нужна демографическая сегментация, работают с одним слоем; те, кому нужно привязать событие к имени клиента - через отдельный интерфейс с логированием доступа. Не всегда организационно удобно, но именно это соответствует принципу минимизации данных из GDPR.

Техническая реализация сейчас чаще всего делается на уровне ETL-пайплайна: при загрузке в витрину функция хеширования применяется к идентификаторам, оригинальные значения в витрину не попадают. Таблица соответствия - отдельная, с жёстким контролем доступа.

Что не работает

Часто видим попытку закрыть требование «шифрованием» через application-level encryption отдельных полей без продуманного управления ключами: ключ шифрования лежит в конфиге рядом с приложением, которое обращается к той же базе. Технически это шифрование, юридически это мера с сомнительной эффективностью - и грамотный аудитор это увидит.

Аналогично с псевдонимизацией: MD5 от email без соли - не псевдонимизация, а rainbow table за пять минут.

Где сейчас

Параллельно с этими двумя направлениями клиенты работают над документацией: технические меры нужно описать в Record of Processing Activities (статья 30) и в Privacy Impact Assessment там, где он требуется. Хорошая техническая реализация без документирования - неполный ответ регулятору.

До 25 мая - чуть больше двух месяцев. По части технических мер прогресс есть; организационная сторона у большинства ещё догоняет. О том, как идёт работа по аудиту, расскажем по ходу.