Політики зберігання даних

1) Навіщо потрібні політики зберігання

Політики зберігання визначають як довго і навіщо ви зберігаєте кожен тип даних, де він розміщений, хто відповідає і як дані видаляються або анонімізуються. Без них неможливо дотримати приватність, мінімізацію і відтворюваність звітності, особливо в iGaming з чутливими PII/фінансами, регуляторикою і розслідуваннями.

• Відповідність законам/ліцензіям та договорам з провайдерами/PSP.
• Мінімізація ризиків витоків і штрафів.
• Передбачуваність витрат на зберігання і продуктивність платформи.
• Підтримка процесів DSAR, Legal Hold, аудиту та версійності.

2) Базові принципи

1. Цільове зберігання (purpose limitation): термін прив'язаний до конкретної мети обробки.
2. Мінімізація: не зберігати «про всяк випадок»; після закінчення мети - видаляти/анонімізувати.
3. Прозорість і доказовість: кожен запис повинен мати власника, клас, термін і підставу.
4. Поділ середовищ: прод/стейдж/пісочниці з різними термінами і наборами полів.
5. Policy-as-Code: політика як конфігурація в репозиторії + CI-перевірки.
6. Defense in Depth: зберігання + бекапи + журнали аудиту + Legal Hold узгоджені між собою.

3) Класифікація та правові підстави

Класи: Public/Internal/Confidential/Restricted (PII/фінанси) з тегами: `pii`, `financial`, `tokenized`, `backup`, `legal_hold`, `wip`, `dsar_subject`.

• Юридичний обов'язок/ліцензування (наприклад, звітність і AML).
• Виконання договору (транзакції/виплати).
• Законний інтерес (безпека, антифрод) - з оцінкою балансу.
• Згода (маркетинг/персоналізація) - з окремими термінами і відкликанням.

4) Матриця термінів зберігання (референс для iGaming)

5) Legal Hold і заморозка

Legal Hold тимчасово скасовує видалення/TTL для наборів, пов'язаних з розслідуванням/спором.
Джерело істини - реєстр Legal Hold: власник, дата, підстава, діапазон даних, дата зняття.
Зняття - за схваленим процесом; всі затримані видалення запускаються як відкладені джоби.

6) DSAR і «право на видалення»

Зберігайте токени суб'єктів (а не PII) для пошуку по графу.
Підтримуйте відмінність між видаленням, псевдонімізацією та анонімізацією.
Не видаляйте записи, які зобов'язані зберігатися за законом - позначайте обмеження обробки; пояснюйте суб'єкта.
У бекапах - видалення на майбутніх ротаціях + позначки «subject erased» в активному шарі.

7) Бекапи, архіви та WORM

3-2-1: три копії, два типи носіїв/хмар, одна - офлайн/air-gapped.
Шифрування ключами KMS/HSM, незалежними від провайдера.
WORM для аудиту/регуляторної звітності.
Політика ротації бекапів: термін зберігання бекапів не повинен перевищувати термінів активних даних, якщо немає обов'язкових винятків.
Тест відновлення за розкладом.

8) Транскордонність і гео-локалізація

Geo-scoping: дані і ключі шифрування прив'язані до регіону/ліцензії.
Реплікації поважають локальні терміни зберігання і обмеження передачі.
Контракти з провайдерами/PSP/KYC зобов'язані відображати місця зберігання і терміни.

9) Архітектура зберігання та автоматизація

• Raw/Bronze (мінімальний термін, без PII по можливості).
• Silver (очищені факти з TTL і маскуванням).
• Gold (агрегати/вітрини з довгим терміном).
• Feature Store/Model Registry (версіонування і time-travel без PII).

• Lifecycle policies/TTL в об'єктах/таблицях/темах.
• Політика як код: YAML/JSON с `purpose`, `retention_period`, `post_expiry_action`, `legal_hold_override`.
• CI-лінтер: блокує PR, якщо новий набір без'retention _ policy'.
• Scheduler: щоденна перевірка «що закінчується завтра/на тижні».
• Deletion jobs: м'яке видалення → перевірка залежностей → тверде видалення/криптостирання.

10) Видалення, анонімізація, псевдонімізація

Hard delete - фізичне видалення (враховуйте каскади і лінійдж).
Soft delete - мітка'deleted _ at', приховування, план подальшого hard delete.
Crypto-erase - видалення ключів для недоступності даних.
Анонімізація - незворотна трансформація; допускається зберігання агрегатів.
Псевдонімізація - заміна токенами; обов'язкова політика ключів/pepper і заборона оборотності поза «чистою зоною».

11) Метрики та SLO

Retention Coverage: % наборів із затвердженою політикою.
On-time Deletion: частка вилучень, виконаних вчасно.
Zero-PII in Logs: покриття логів маскуванням.
Legal Hold Accuracy: збіг реєстру з фактичними заморозками.
Backup Restore-Rate: успішні тест-відновлення.
DSAR SLA: середній час виконання запитів (за типами).
Cost vs Retention: економія від агрегації/TTL.

12) RACI (приклад)

Політика та стандарти: CDO/DPO (A), Governance Council (R/A), Legal (C), Security (C).
Каталог та мітки: Data Stewards (R), Domain Owners (A), Platform (C).
Автоматизація/TTL: Platform/SRE (R), Sec (C).
Legal Hold/DSAR: DPO/Legal (A/R), Домени (C).
Аудит і бекапи: SecOps/SRE (R), Internal Audit (C).

13) Шаблони (готово до використання)

13. 1 Політика зберігання (ескіз)

Область: перерахування доменів і винятків.
Підстави: юридичний обов'язок/договір/згода/законний інтерес.
Терміни: таблиця'dataset → period → action'.
Legal Hold: процес включення/зняття.
DSAR: порядок пошуку/видалення/обмеження.
Бекапи/WORM: терміни, ключі, тест відновлення.
Контроль: метрики, рев'ю щорічно, власник політики.

13. 2 Картка набору з retention

Dataset: `payments. transactions`

Клас: Restricted (фінанси)

Підстава: юридичний обов'язок/облік

Термін: N років з дати операції

Дія після терміну: анонімізація агрегатів, hard delete деталей

Legal Hold override: так

Відповідальні: Owner/Steward, DPO

Теги/контракти: `pii`, `tokenized`, `retention:N', посилання на контракт

13. 3 YAML-політика (policy-as-code, фрагмент)

yaml dataset: payments. transactions purpose: accounting_and_aml class: restricted retention_period: P{N}Y    # ISO 8601 duration post_expiry_action: anonymize_then_delete legal_hold_override: true geo_scope: EU backups:
retention_period: P{N}Y worm: true audit:
enabled: true destination: worm://audit/payments

13. 4 Чек-лист запуску

• У кожного датасета є картка і YAML-політика
• Включені TTL/lifecycle правила в сховищах
• У каталозі відображаються терміни/підстави/власники
• Налаштовані алерти закінчення і звіт On-time Deletion
• Реєстр Legal Hold синхронізований зі storage-прапорами
• Проведено «table-top» сценарій DSAR/видалення в бекапах

14) Дорожня карта впровадження

0-30 днів (MVP)

1. Інвентаризація наборів і класифікація; призначити власників.
2. Додати поле'retention'в контракт/каталог; завести картки топ-наборів.
3. Увімкнути TTL/lifecycle для логів і raw-шару; заборона PII в логах.
4. Реєстр Legal Hold і процеси; базові звіти Coverage/On-time Deletion.

30-90 днів

1. Розкатати policy-as-code (YAML) і CI-лінтер; блок PR без'retention'.
2. Впровадити анонімізацію/псевдонімізацію пост-терміну; автоматизувати deletion jobs.
3. Привести бекапи у відповідність термінам; включити WORM для аудиту.
4. Зв'язати DSAR з ретеншном і токенізацією; звіти по SLA.

3-6 місяців

1. Гео-локалізація наборів і ключів; Транскордонні політики.
2. Розширена аналітика вартості зберігання та ефекту TTL.
3. Щоквартальні рев'ю термінів з Legal/Домени; Зовнішній аудит.
4. Масштабування на партнерів/провайдерів (контрактні вимоги до ретеншну).

15) Анти-патерни

«Зберігаємо все вічно» - без підстав і плану видалення.
Непослідовність: актив видалений, а в бекапах - назавжди.
Відсутність Legal Hold: стирання доказів.
Єдині терміни для всіх доменів «для простоти».
DSAR без реального видалення в похідних вітринах/фічах.
Пісочниці з копіями прод-PII і нескінченним терміном.

16) Пов'язані розділи

Управління даними, Контроль доступу, Токенізація даних, Безпека і шифрування, Походження і шлях даних, Аудит і версійність, Legal Hold і DSAR, Конфіденційне ML.

Підсумок

Політики зберігання перетворюють «хаотичний склад» в керований архів: кожне поле знає свій термін, підставу і долю. Для iGaming це фундамент комплаєнсу, економії та довіри до даних: ви зберігаєте достатньо, але не зайве, вмієте швидко видаляти і доводити, і при цьому не ламаєте звіти, ML і операційні процеси.