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) у кожної категорії є мітка строку, розклад авто видалення та окремий шлях для запитів суб'єкта — видалення на вимогу йде за ним, а не через ручне редагування баз. Журнал видалень пишеться одразу в незмінне сховище: саме він закриває першу перевірку.
Технічні питання щодо строків зберігання даних
Строки зберігання рідко зводяться до однієї цифри: транзакційні записи, логи, вкладення та знеособлена статистика живуть за різними правилами.
Політика стає робочою лише тоді, коли вона однаково виконується в основній базі, в об'єктному сховищі та в резервних копіях — інакше видалення перетворюється на разову ручну операцію, яку через місяць ніхто не повторить.
Дані видалено з бази, але вони залишилися в резервних копіях — це порушення?
Формально так, якщо строк ротації копій перевищує строк зберігання категорії. Тому правило життєвого циклу копій ми прив'язуємо до найдовшого строку серед даних, які в них потрапляють, і фіксуємо це в матриці категорій.
Якщо копії незмінні та захищені від перезапису, строк їх зберігання задається коротшим за інші — тоді запис випадає з усіх копій природним чином, без втручання в архів.
Чи можна не видаляти дані, а знеособити їх?
Так, якщо дані потрібні для аналітики та звітності. Знеособлення працює лише за необоротності: прибираються прямі ідентифікатори, а таблиця зіставлення не зберігається.
Псевдонімізація з ключем на боці застосунку видаленням не вважається — доступ до запису відновлюється, отже, строк зберігання продовжує діяти.
Що робити з накопиченнями, які з'явилися до політики?
Їх розбирають окремим проходом: інвентаризація сховищ, класифікація за категоріями, потім рішення по кожній групі — видалити, знеособити або залишити з обґрунтуванням.
Далі записи розносяться за партиціями з прив'язкою до дати, щоб видалення йшло за межею партиції, а не построковим скануванням важких таблиць.
Як переконатися, що політика справді працює?
Налаштовуємо автоматичні перевірки: звіт про обсяг записів, що вийшли за строк, порівняння фактичного строку зберігання із заявленим і контроль журналу видалень.
Окремо перевіряємо логи — якщо в них потрапляють ідентифікатори, для них діє свій, коротший строк, і це теж потрапляє в перевірку.
Якщо за вашими даними залишаються відкриті питання щодо сумісності строків і способів видалення — опишіть задачу, повернемося з оцінкою та планом.Обговоримо вашу задачу зі зберігання даних
Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібен мінімум ввідних щодо вашої інфраструктури. Зберігання зачіпає бази, об'єктні сховища, резервні копії, журнали й вивантаження в аналітику — за кожним контуром строки та підстави для видалення свої. Надішліть те, що є під рукою, решту уточнимо на дзвінку.
- Перелік систем і сховищ — бази, файлові та об'єктні сховища, черги, архіви резервних копій, а також зовнішні сервіси, куди йдуть дані (аналітика, розсилки, підтримка).
- Категорії даних і підстави обробки — де персональні дані, де медичні відомості, де платіжні та технічні журнали; для кожної категорії — вимога, з якої випливає строк зберігання.
- Поточні регламенти — що вже описано: строки, порядок видалення за запитом суб'єкта, хто відповідає за виконання і як фіксується факт видалення.
- Обмеження щодо простоїв і навантаження — вікна, коли допустимі міграції схеми та прогін масових видалень, пікові години, вимоги до доступності сервісів.
- Контур перевірки — чи є окреме середовище, близьке до продуктивного, де можна відпрацювати правила ретенції та відкат без ризику для живих даних.
- Поточні схеми резервного копіювання — глибина зберігання копій і те, як видалення в основній системі відображається на архівах, інакше дані залишаються жити в бекапі.
За цими ввідними готуємо аудит зберігання, потім план робіт і правила ретенції, перевіряємо їх на пілотному контурі й залишаємося на супроводі — правила доведеться переглядати при зміні складу систем. Опишіть задачу в зручному вигляді, і повернемося з оцінкою та планом.
