Сообщить об ошибкеКороткий ответ
Нужно заранее спроектировать модель данных так, чтобы персональные данные были локализованы в ограниченном числе мест, а не размножены по кэшам, логам и аналитическим витринам без учёта этого, и предусмотреть явный процесс каскадного удаления/анонимизации по запросу пользователя, даже если это усложняет схему кэширования и снижает часть оптимизаций.
Как это работает подробнее
Право на удаление требует, чтобы при запросе пользователя система могла достоверно найти все места хранения его персональных данных — основную БД, резервные копии, кэши, аналитические агрегаты, логи — и либо удалить, либо анонимизировать данные там, где физическое удаление невозможно в разумный срок (например, в неизменяемых бэкапах) согласно политике хранения.
- Компромисс. Псевдонимизация и жёсткая локализация персональных данных снижают риск при compliance-аудите и упрощают удаление, но усложняют аналитические запросы (приходится джойнить данные через дополнительный слой) и могут снизить производительность некоторых горячих путей, оптимизированных на денормализованные данные; более свободное копирование данных между системами ради производительности увеличивает операционный риск при аудите и запросах на удаление. Критерии выбора — юрисдикция и строгость применимого регулирования, чувствительность конкретных данных и стоимость переработки уже существующей аналитической инфраструктуры.
Пример кода
example.txt
core_users (PII: email, phone, address) -- доступ строго ограничен, аудит обращений
analytics_events (user_pseudo_id, event_type, ts) -- без прямых PII, ссылка через псевдоним
cache:user_profile:{pseudo_id} TTL=1h -- не переживает политику хранения
Запрос на удаление пользователя:
1. удалить/анонимизировать запись в core_users
2. разорвать связь pseudo_id -> user_id (таблица маппинга)
3. дождаться истечения TTL кэша и ближайшей ротации бэкапов согласно политикеЧто использовать на практике
- Практика. Распространённый подход — хранить персональные данные в одном выделенном месте с жёстким контролем доступа и ссылаться на них по псевдонимизированному идентификатору из остальных систем (аналитика, кэши), чтобы удаление в одном месте автоматически «обесценивало» данные во всех производных системах; для горячих данных в кэше можно использовать TTL, не превышающий политику хранения.
Подводные камни
- Риск. Проектируют аналитику и кэши так, будто персональные данные можно свободно копировать между системами «для удобства», не оставляя способа отследить и удалить все копии; реализуют «мягкое» удаление (флаг is_deleted) без реальной очистки данных из активно используемых мест; не определяют явно срок хранения в бэкапах, оставляя его «как получится» по умолчанию инструмента резервного копирования.