Право на забвение в базе данных

Что это такое

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

Почему это важно

Системы редко строят с одним ключом на человека. Идентификатор пользователя встречается в одних таблицах, адрес электронной почты в других, IP-адрес в логах, идентификатор устройства в аналитике — и связи между ними не всегда где-то записаны. В итоге запрос на удаление превращается в неделю криминалистической работы, которая идёт, пока тикает срок. Проектирование под это стоит одного идентификатора и процедуры удаления; внедрение задним числом — дорогая версия той же работы.

Ключевые идеи

Держите один идентификатор, который достаёт до всего

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

users.id            идентификатор субъекта
orders.user_id      ссылайтесь, никогда не копируйте email
events.subject_id   тот же идентификатор в аналитике
logs.subject_id     структурное логирование несёт его рядом с IP

Копирование адреса почты или имени во вторую таблицу создаёт вторую вещь, которую надо найти и удалить, и забывают обычно именно копию.

Решайте по каждому полю: удалить, обезличить или сохранить

Удаление не означает удалить заказ. Заказ нужен для бухгалтерии; персональные поля внутри него — нет. Замените их надгробием, а агрегат сохраните.

удалить      строку профиля, email, телефон, адрес
обезличить   ссылку заказа на клиента -> "erased-<hash>"
сохранить    сумму заказа, дату, позиции (нормативное хранение)

Отделите идентификатор от человека

Хеш идентификатора пользователя позволяет сохранить связь для аналитики, не храня персональные данные, — при условии, что соответствие не лежит где-то ещё. Это проектное решение, которое нужно принять при написании схемы, а не после прихода запроса.

Планируйте неизменяемые копии

Резервные копии, журналы только для добавления и потоки событий нельзя править на месте. Обычный подход — сделать удаление действенным в момент восстановления: хранить список надгробий и применять его после восстановления — и ограничить время жизни копий.

Докажите один раз, потом повторяйте

Напишите процедуру удаления как скрипт с тестом, чтобы ответ на второй запрос был выполнением, а не проектом.

Практика

Проследите одного человека по системе

Возьмите тестовый аккаунт и найдите каждое хранилище, где есть данные о нём: основная база, логи, аналитика, очередь, поисковый индекс, резервные копии.

Готово, когда: у вас есть письменный список, называющий для каждого хранилище и поле, и вы знаете, какие из них нельзя править.

Напишите и проверьте процедуру удаления

Реализуйте скрипт, который принимает один идентификатор и выполняет решения удалить, обезличить и сохранить, затем запустите его на тестовом аккаунте.

Готово, когда: повторный проход по вашей карте не находит персональных данных, кроме строк, которые вы намеренно оставили, а процедура воспроизводима.

Частые ошибки

• Один запрос обработан вручную — второй запрос снова запускает криминалистическую работу; исправить: напишите и проверьте процедуру.
• Удаление заказа вместе с человеком — записи, нужные для бухгалтерии или разрешения споров, теряются; исправить: обезличьте ссылку и сохраните транзакцию.
• Пропущенные копии — логи, очереди, поиск и хранилище данных сохраняют данные; исправить: распространите один идентификатор на все хранилища и включите их в процедуру.
• Забытые неизменяемые резервные копии — после восстановления данные возвращаются; исправить: применяйте список надгробий при восстановлении и ограничьте срок хранения.
• Нет доказательства удаления — никто не может показать, что запрос выполнен; исправить: записывайте запуск, идентификатор и то, что было удалено или обезличено.

Что читать дальше

• Правовое основание, согласие и хранение (07-security/05-gdpr-data-privacy/01-lawful-basis-consent-and-retention) — запись, против которой выполняется эта процедура.
• GDPR и приватность данных (07-security/05-gdpr-data-privacy) — трек, который закрывает эта глава.
• Этика данных (07-security/07-data-ethics) — решение о том, что вообще стоило собирать.
• Управление секретами (07-security/03-secrets-management) — доступ к этим хранилищам только для тех, кому он нужен.