Политики хранения данных

1) Зачем нужны политики хранения

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

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

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

1. Целевое хранение (purpose limitation): срок привязан к конкретной цели обработки.
2. Минимизация: не хранить «на всякий случай»; по окончании цели — удалять/анонимизировать.
3. Прозрачность и доказуемость: каждая запись должна иметь владелецa, класс, срок и основание.
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 и операционные процессы.