Data retention: где ломается хранение персональных данных
Избыточные данные появляются не из-за наплыва пользователей, а из-за отсутствия решения о сроках. Логи приложения, транзакционные таблицы, выгрузки в аналитический контур, снапшоты и копии бэкапов пишутся разными сервисами и остаются лежать до тех пор, пока место на диске не кончится. Формально это хранение персональных данных, фактически — свалка без владельца и без даты.
Разрастание хранилищ почти никогда не связано с нагрузкой: один и тот же набор полей дублируется в основной базе, в реплике, в кэше и в отчёте, который собирается раз в сутки. Срок хранения если и зафиксирован, то в регламенте на бумаге, а не в конфигурации — поэтому просроченное хранение выявляется в момент проверки или запроса субъекта на удаление, а не заранее.
Удалить нужное оказывается сложнее, чем хранить. Запись живёт в нескольких местах, связана внешними ключами, попадает в предрасчитанные витрины и в неизменяемые архивы; точечная очистка ломает ссылочную целостность, а полная остановка продукта ради миграции недопустима. Дальше выбор невелик: либо ручная вычистка на проде, либо отложенное удаление с риском накопить ещё больше.
Причина обычно одна — политика data retention не была спроектирована как часть схемы данных, её прикрутили сверху, когда вопрос задал регулятор. Разбираем, как это закрывается: где провести границу между «нужно для работы» и «пора удалять», как привязать правила к конкретным полям, а не к сервисам целиком, и как встроить удаление в обычный цикл эксплуатации без остановки продуктов.
Что даёт управляемая политика хранения персональных данных
Когда у каждого набора данных есть владелец, срок жизни и триггер удаления, хранилище перестаёт быть свалкой «на всякий случай». Политика хранения (data retention) описывает не только сам срок, но и что происходит по его истечении: безвозвратное удаление, обезличивание или перевод в архив с ограниченным доступом. Именно после этого минимизация данных перестаёт быть декларацией и превращается в работающее правило.
Первый измеримый эффект — сокращение объёма активного контура. Записи с истёкшим сроком уходят из горячих таблиц по расписанию, а не по памяти инженера: индексы и резервные копии уменьшаются, восстановление после сбоя укладывается в меньший интервал, плановое обслуживание перестаёт растягиваться на ночь.
Второй — предсказуемый ответ на запрос субъекта. Карта данных связывает идентификатор человека с конкретными таблицами, файловыми хранилищами и очередями, поэтому выборка, исправление и удаление идут по ней, а не поиском по всей базе. Обращение закрывается за часы вместо дней ручного обхода сервисов.
Третий — снятый класс замечаний регулятора. Требования GDPR, 152-ФЗ и HIPAA расходятся в деталях, но сходятся в одном: срок хранения должен быть обоснован, а удаление — подтверждено. Утверждённые сроки вместе с журналом удалений закрывают вопрос «почему эти данные всё ещё у нас» без переписывания систем под каждый свод правил.
Способы реализации политики хранения: сравнение подходов
Выбор слоя определяет, сработает ли правило, когда сервис переписали или когда запись связана с десятком таблиц. Для GDPR, 152-ФЗ и HIPAA важен не сам факт настройки очистки, а доказуемость: проверяющий видит, что запись исчезла в срок.
| Подход | Когда подходит | Ограничения |
|---|---|---|
| Уровень хранилища | Данные однородны по сроку: журналы, метрики, архивы, копии. Правила жизненного цикла объектов работают независимо от кода сервиса | Не различает юридические исключения — удалит то, что обязано храниться. Часть полей внутри объекта не вычистить |
| Уровень приложения | Срок зависит от типа субъекта, согласия или статуса сделки; нужна точечная очистка связанных записей | Требует дисциплины в каждом сервисе: новый обработчик легко забывает про удаление, остаются связанные таблицы и кэши |
| Гибридная схема | Основной сценарий: хранилище держит грубую границу по сроку, приложение закрывает исключения | Удаление размазано по двум слоям, нужна регулярная сверка, иначе расхождение накапливается |
| Ручные регламенты | Единичные системы и разовые запросы субъектов, где автоматику негде закрепить | Не масштабируется, зависит от человека, след остаётся в переписке, а не в журнале |
Рабочая схема почти всегда гибридная: автоматические задания очистки идут по расписанию, помечают записи к удалению, а уровень хранилища добивает остаток по сроку. Каждое срабатывание пишет в журнал идентификатор, правило и время — это и есть доказательство для проверки.
Внедрение data retention: этапы инженерной работы
Внедрение retention — это не переключатель в панели, а последовательность работ: сначала нужно понять, где данные лежат и куда копируются, и только потом настраивать удаление. Иначе правило сработает в основной базе, а копия останется в реплике, поисковом индексе или ночном бэкапе. Порядок, по которому мы ведём такие проекты, — ниже.
-
Аудит потоков данных. Составляем карту: какие сервисы пишут персональные данные и где они оседают — основная база, реплики, объектное хранилище, очереди, кэши, выгрузки в аналитику, журналы приложений, бэкапы. По каждому хранилищу фиксируем владельца, категорию данных и срок жизни. Результат — реестр, по которому видно скрытые копии, о которых обычно никто не помнит.
-
Согласование сроков. По каждому набору данных определяем срок и основание: требование закона, условие договора, срок жизни учётной записи, отзыв согласия. Сводим в одну таблицу с действием по истечении — удалить, обезличить или перенести в архив.
-
Проектирование схемы. Решаем, где живёт правило: политика жизненного цикла на стороне хранилища, задание по расписанию, каскадное удаление на уровне приложения, маскирование. Продумываем, как правило переживёт смену схемы и переезд сервиса.
-
Настройка правил удаления. Правила ведём как код в репозитории: изменения проходят ревью, а не вносятся руками в панели. Параллельно включаем журнал — кто, когда и по какому правилу удалил запись.
-
Проверка на тестовом контуре. Наполняем песочницу похожими данными и прогоняем сценарии: истечение срока, отзыв согласия, восстановление из бэкапа, повторный запуск правила. Смотрим, что удаление не задевает связанные записи и не ломает отчётность.
-
Передача в эксплуатацию. Отдаём дежурной команде регламент, мониторинг и алерты на сбои правил, порядок обработки запроса субъекта данных. Через оговорённый интервал возвращаемся и сверяем политику с реальными потоками — они меняются быстрее, чем документ.
Что остаётся у вас после внедрения политики хранения
Политика хранения — это не один подписанный документ, а комплект артефактов, по которому систему можно проверить, передать другой команде и показать проверяющему. Ниже — что именно остаётся у вас на руках после внедрения.
- Матрица сроков хранения — таблица по категориям данных: учётные записи, заявки, история операций, резервные копии, выгрузки в аналитику. Для каждой строки указаны срок, основание для него и владелец, который согласует изменение.
- Схема потоков данных — от точки появления записи до архива и удаления: в каких хранилищах данные копируются, какие сервисы их читают, где остаются промежуточные слепки.
- Конфигурации заданий очистки — версионированные файлы с расписанием, условиями отбора, размером порции и поведением при сбое. Изменение правила проходит ревизию, а не правится руками на сервере.
- Журналирование операций — отдельный поток, защищённый от правки: что удалено, когда, по какому правилу и кто инициировал. Журнал хранится дольше самих данных, иначе удаление нечем подтвердить.
- Регламент удаления — пошаговые сценарии: удаление по обращению пользователя, экстренная очистка, порядок согласования и подтверждения результата.
- Отчёты о прогонах — сколько записей подпадало под правило, что удалено, что пропущено и по какой причине. Расхождения видно сразу, а не на этапе проверки.
- Документация и роли — кто отвечает за категорию, как добавить новое правило, где зафиксированы исключения.
Комплект проверяется на копии данных: прогон правил, сверка отчёта с матрицей, разбор пропусков. Опишите задачу — вернёмся с оценкой и планом по вашему набору хранилищ.
Кейс: приведение хранения к требованиям трёх регуляторов
Клиент — сервис с пользователями в ЕС, России и США: к одним и тем же данным применялись требования GDPR, 152-ФЗ и HIPAA, причём сроки расходились — где-то хранение ограничено сроком договора, где-то задан фиксированный период. Часть данных жила в PostgreSQL, часть — в объектном хранилище и логах приложений, и у каждой системы были свои «правила», описанные в вики.
На старте доля просроченных записей в основных наборах держалась на уровне 18–23%: скрипты удаления падали на связанных строках, а часть задач отключали во время инцидентов и не включали обратно. Запрос субъекта на доступ готовили вручную — выгрузки из трёх систем, сверка, — на ответ уходило 6–9 рабочих дней. Плановая проверка регулятора принесла семь замечаний, четыре из них — про сроки хранения и отсутствие доказательств удаления.
Что изменили
Сначала собрали реестр: тип данных, правовое основание, срок, действие по его истечении — удалить, анонимизировать или перенести в архив. Затем правила перестали быть документом и стали конфигурацией: декларативные политики в репозитории, привязка к таблицам и полям, проверка при сборке — набор данных без назначенного правила не проходит развёртывание.
Удаление перевели на партиционирование и каскады вместо построчных обходов, каждое действие пишется в неизменяемый журнал — из него формируется отчёт для проверяющего. Для аналитики собираются копии с маскированием персональных полей: отчёты строятся, но в рабочий контур персональные данные не попадают.
После внедрения доля просроченных записей — меньше 1%, остаток приходится на спорные дела с открытым сроком. Ответ на запрос субъекта собирается автоматически по идентификатору и укладывается в один рабочий день. Повторная проверка не дала ни одного замечания по хранению: журнал подтверждает и срок, и факт удаления.
Чем отличается GDPR от 152-ФЗ и HIPAA по срокам хранения
Короткий ответ: ни GDPR, ни 152-ФЗ, ни HIPAA не задают срок хранения в днях. Они определяют, из чего срок выводится — цель обработки, правовое основание и обязанность прекратить обработку, когда цель достигнута. Поэтому одна и та же выгрузка в разных режимах живёт разное время, а сравнивать режимы корректно по четырём осям.
| Что сравниваем | GDPR | 152-ФЗ | HIPAA |
|---|---|---|---|
| Основание хранения | Согласие, договор, законный интерес | Согласие субъекта или требование закона | Цели лечения, оплаты, операций |
| Кто задаёт срок | Оператор, из минимизации данных | Оператор, по достижении цели | Закон — минимум для медкарт |
| Удаление по требованию | Ответ в течение месяца | Уничтожение в срок до 30 дней | Доступ и исправление по своей политике |
| Что проверяют первым | Обоснованность срока | Согласия и факт уничтожения | Журналы доступа |
Практический вывод: срок — не константа в коде, а свойство категории данных. В политике хранения (data retention) у каждой категории есть метка срока, расписание автоудаления и отдельный путь для запросов субъекта — удаление по требованию идёт по нему, а не через ручную правку баз. Журнал удалений пишется сразу в неизменяемое хранилище: именно он закрывает первую проверку.
Технические вопросы по срокам хранения данных
Сроки хранения редко сводятся к одной цифре: транзакционные записи, логи, вложения и обезличенная статистика живут по разным правилам. Политика становится рабочей только тогда, когда она одинаково исполняется в основной базе, в объектном хранилище и в резервных копиях — иначе удаление превращается в разовую ручную операцию, которую через месяц никто не повторит.
Данные удалены из базы, но остались в резервных копиях — это нарушение?
Формально да, если срок ротации копий превышает срок хранения категории. Поэтому правило жизненного цикла копий мы привязываем к самому длинному сроку среди данных, которые в них попадают, и фиксируем это в матрице категорий. Если копии неизменяемы и защищены от перезаписи, срок их хранения задаётся короче остальных — тогда запись выпадает из всех копий естественным образом, без вмешательства в архив.
Можно ли не удалять данные, а обезличить их?
Да, если данные нужны для аналитики и отчётности. Обезличивание работает только при необратимости: убираются прямые идентификаторы, а таблица сопоставления не хранится. Псевдонимизация с ключом на стороне приложения удалением не считается — доступ к записи восстанавливается, значит, срок хранения продолжает действовать.
Что делать с накоплениями, которые появились до политики?
Их разбирают отдельным проходом: инвентаризация хранилищ, классификация по категориям, затем решение по каждой группе — удалить, обезличить или оставить с обоснованием. Дальше записи разносятся по партициям с привязкой к дате, чтобы удаление шло по границе партиции, а не построчным сканированием тяжёлых таблиц.
Как убедиться, что политика действительно работает?
Настраиваем автоматические проверки: отчёт о объёме записей, вышедших за срок, сравнение фактического срока хранения с заявленным и контроль журнала удалений. Отдельно проверяем логи — если в них попадают идентификаторы, для них действует свой, более короткий срок, и это тоже попадает в проверку.
Если по вашим данным остаются открытые вопросы по совместимости сроков и способов удаления — опишите задачу, вернёмся с оценкой и планом.Обсудим вашу задачу по хранению данных
Чтобы вернуться с оценкой и планом, а не с общими словами, нам нужен минимум вводных по вашей инфраструктуре. Хранение затрагивает базы, объектные хранилища, резервные копии, журналы и выгрузки в аналитику — по каждому контуру сроки и основания для удаления свои. Пришлите то, что есть под рукой, остальное уточним на созвоне.
- Перечень систем и хранилищ — базы, файловые и объектные хранилища, очереди, архивы резервных копий, а также внешние сервисы, куда уходят данные (аналитика, рассылки, поддержка).
- Категории данных и основания обработки — где персональные данные, где медицинские сведения, где платёжные и технические журналы; для каждой категории — требование, из которого вытекает срок хранения.
- Текущие регламенты — что уже описано: сроки, порядок удаления по запросу субъекта, кто отвечает за исполнение и как фиксируется факт удаления.
- Ограничения по простоям и нагрузке — окна, когда допустимы миграции схемы и прогон массовых удалений, пиковые часы, требования к доступности сервисов.
- Контур проверки — есть ли отдельное окружение, близкое к продуктивному, где можно отработать правила ретенции и откат без риска для живых данных.
- Текущие схемы резервного копирования — глубина хранения копий и то, как удаление в основной системе отражается на архивах, иначе данные остаются жить в бэкапе.
По этим вводным готовим аудит хранения, затем план работ и правила ретенции, проверяем их на пилотном контуре и остаёмся на сопровождении — правила придётся пересматривать при изменении состава систем. Опишите задачу в удобном виде, и вернёмся с оценкой и планом.
