Удаление и анонимизация данных

1) Цель и область

Обеспечить законное, безопасное и доказуемое удаление/анонимизацию данных игроков, транзакций и операционных журналов во всех системах (продукт/кошелек, KYC/AML, RG, маркетинг/CRM, аналитика/DWH, логи/APM), включая вендоров/провайдеров и бэкапы, с учетом локализации по юрисдикциям.

2) Принципы

1. Политика прежде практики. Ретенция, цели и места хранения определены до сбора.
2. Минимизация и разделение. Отдельные хранилища для PII, токенизация в событиях.
3. Удаление = событие с доказательством. Любое удаление подтверждается артефактом.
4. Fail-Closed. Неизвестный статус/регион → запрет операций с PII.
5. Backups-aware. Бэкапы подчиняются тем же правилам, что боевые данные.
6. «Анонимизация вместо бессрочного хранения». Если закон не требует PII — переводим в агрегаты.

3) Роли и RACI

DPO/Compliance (Owner) — политика ретенции/удаления, исключения, аудит. (A)

Security/Infra — шифрование, ключи, крипто-стирание, бэкапы/DR. (R)

Data Platform/Analytics — де-PII пайплайны, агрегаты, DWH/DL. (R)

Product/Engineering/SRE — API удаления, каскады, тесты, наблюдаемость. (R)

Legal — локальные сроки и ограничения (AML/лицензионные). (C)

Privacy Ops/DSAR Team — пользовательские удаления/исправления. (R)

Vendor Manager — обязательства вендоров, подтверждения исполнения. (R)

Internal Audit — выборки, CAPA. (C)

4) Таксономия данных и стандарт ретенции

5) Технические методы

5.1 Удаление

Каскадное логическое/физическое: soft-delete → job на физическое удаление.
Крипто-стирание (crypto-shredding): уничтожение ключа шифрования сегмента/тенанта; применяется к бэкапам/архивам.
Revocation токенов: отзыв платежных/трекерных токенов у провайдеров.
Nullify/Mask: для полей, требующих формального сохранения записи (например, бухгалтерия).

5.2 Псевдонимизация

Замена первичных идентификаторов токенами; таблица соответствий хранится отдельно с отдельным KMS.

5.3 Анонимизация

Агрегирование/кохортирование, k-анонимность/ℓ-diversity, биннинг, обрезка редких значений, дифференциальная приватность в отчетах.

5.4 Маскирование логов

Агент редактирует PII на сборе (e.g., e-mail → hash/partial), запрет «сырых» идентификаторов в APM.

6) Жизненный цикл удаления

1. Триггер: срок ретенции, DSAR-erase, закрытие аккаунта, отзыв согласия, завершение договора/цели.
2. Оценка: есть ли юридические блоки? (AML/легал-холд/лицензия).
3. Оркестрация: формируется erasure-пакет по системам/вендорам.
4. Исполнение: каскады, токены revoke, крипто-wipe для архивов.
5. Валидация: сверка записей, контроль остатков (orphaned data).
6. Артефакт: отчет с хэшами партиций/ключей, временем и объемом.
7. Репортинг: дашборд KPI, журнал для аудита/регулятора.

7) Особые зоны внимания

7.1 Бэкапы/архивы/DR

Бэкапы в том же регионе, шифрование и каталогизация ключей.
Реалистично: физическое удаление из immutable-backup сложно → применяем crypto-shredding сегмента при достижении срока.

7.2 Логи и телеметрия

Политика PII-free by default; если PII неизбежны — локальные логи, короткие сроки, маскирование на агенте.

7.3 DWH/аналитика

Только де-PII данные; при необходимости историки — анонимизировать и разорвать связь с исходной PII.

7.4 Вендоры и провайдеры

DPA/допсоглашения: сроки, механизмы удаления, подтверждение исполнения (Certificate of Destruction/Erase Evidence).

7.5 Локализация по юрисдикциям

Удаление осуществляется в региональном периметре, экспорт PII за его пределы запрещен; глобальные отчеты — только агрегаты.

8) API/ивенты и модель данных

• `retention_due_detected`, `erasure_job_started`, `erasure_job_completed`, `crypto_shred_done`, `vendor_erasure_ack_received`, `erase_validation_failed`, `dsar_erase_linked`, `audit_artifact_saved`.

erasure_job {
id, subject_id_hash    scope{cohort    partition}, trigger{retention    dsar    contract_end    consent_withdrawn},
market, region, systems[], vendors[],
started_at_utc, completed_at_utc, status{ok    partial    failed},
method{cascade    crypto_shred    nullify    token_revoke},
counts{records, tables, bytes}, checksum{before, after},
keys_destroyed[{kms_key_id, destroyed_at_utc, evidence_id}],
validation{orphan_scan:passed    failed, sample_checks[]},
linked_cases{dsar_case_id?}, owner, approvers{dpo, security}, audit_artifacts[]
}

9) Контроль и наблюдаемость

Erasure Coverage — доля систем, покрытых автоматическим удалением.
Time-to-Erase — медиана времени от триггера до завершения.
Orphaned Data Rate — обнаруженные «осиротевшие» записи.
Backup Crypto-Shred SLA — вовремя уничтоженные ключи.
Vendor Ack Rate — доля подтверждений удалений от вендоров в срок.
DSAR Erase SLA — соблюдение сроков по пользовательским удалениям.
Auditability Score — наличие артефактов по выборкам.

10) Чек-листы

A) Политика и дизайн

• Реестр ретенции по категориям/рынкам утвержден Legal/DPO.
• Карта систем/вендоров с указанием PII/регионов/ключей.
• Определены методы: каскад/крипто-wipe/де-PII для аналитики.
• DPA/контракты обновлены (SLA удаления, подтверждения).

B) Техника и операции

• API удаления и оркестратор заданий включены.
• PII-free логи/агенты маскируют чувствительные поля.
• Бэкапы зашифрованы, ключи сегментированы по рынкам.
• Автотесты: DSAR-erase, cron ретенции, orphan-скан.
• Панель мониторинга KPI/алерты.

C) Аудит и улучшения

• Квартальные выборки систем/вендоров с артефактами удаления.
• Тест DR/восстановления с учетом удаленных сегментов.
• CAPA по найденным остаткам/нарушениям.

11) Шаблоны (быстрые вставки)

A) Клауза с вендором (удаление/ретенция)

B) Решение по анонимизации (внутренняя форма)

C) Ответ пользователю (DSAR-erase завершен)

12) Частые ошибки и профилактика

Удаление из боевой БД, но не из бэкапов. → Crypto-shredding и реестр ключей.
PII в логах/APM. → Маскирование на агенте, короткая ретенция.
Орфанные записи (кросс-сервисы). → Orphan-сканы и контрактные каскады.
DWH с PII-хвостами. → Де-PII пайплайны перед экспортом, запрет сырых идентификаторов.
Нет артефактов. → Обязательная генерация отчетов и WORM-хранилище.
Вендор не удалил. → SLA и санкции/hold платежей до подтверждения.

13) 30-дневный план внедрения

Неделя 1

1. Утвердить реестр ретенции и матрицу методов (каскад/крипто/де-PII).
2. Составить карту систем/вендоров/ключей, отметить региональные периметры.
3. Специфицировать модель артефактов и дашборд KPI.

Неделя 2

4) Реализовать оркестратор удалений, API и события; подключить DSAR-линки.
5) Включить маскирование логов и правила «PII-free by default».
6) Настроить crypto-shred для бэкапов, сегментацию KMS по рынкам.

Неделя 3

7) Де-PII конвейер для DWH (кохорты/k-анонимность/биннинг).
8) Пилотные удаления: 20 кейсов DSAR + 2 партиции по ретенции; закрыть CAPA.
9) Обновить DPA с ключевыми вендорами (SLA/подтверждения).

Неделя 4

10) Полный релиз; запустить дашборд и алерты (Time-to-Erase, Vendor Ack).
11) DR-тест с сегментом удаленных ключей.
12) План v1.1: дифф. приватность в отчетах, авто-orphan-сканы по расписанию.

14) Взаимосвязанные разделы

GDPR: управление согласием пользователей

Политика cookies и CMP-системы

Privacy by Design: принципы проектирования

Локализация данных по юрисдикциям

DSAR: запросы пользователей на данные

Шифрование At Rest / In Transit, KMS/BYOK/HYOK

Дашборд комплаенса и мониторинг / Внутренний и внешний аудит