Локализация данных по юрисдикциям
1) Цель и область
Обеспечить соответствие требованиям локализации/резидентности данных во всех целевых юрисдикциях при сохранении доступности, безопасности и производительности продукта. Охват: продукт (веб/мобайл), KYC/AML/RG, платежи (PCI), маркетинг/CRM, аналитика/логирование, бэкапы/DR, провайдеры игр/агрегаторы, аффилиаты, облачные вендоры.
2) Базовые понятия
Резидентность данных (Data Residency): где данные физически хранятся.
Суверенитет данных (Data Sovereignty): право государства регулировать данные, находящиеся на его территории или относящиеся к его субъектам.
Трансграничная передача: доступ, репликация или обработка за пределами «домашней» юрисдикции.
Персональные данные (PII) / чувствительные PII: KYC-документы, платежные реквизиты, RG/SE-статусы, биометрия.
Агрегаты/псевдонимизация/анонимизация: техники минимизации риска при аналитике и обмене.
3) Принципы
1. Local-first: персональные данные хранятся и обрабатываются в «домашнем» регионе игрока, если этого требуют правила.
2. Минимизация и изоляция: хранить только необходимое, четкая сегрегация тенантов/регионов.
3. Правомерная передача: только с действующим правовым механизмом и оценкой рисков.
4. Криптографическое обеспечение: шифрование at rest/in transit, управление ключами на стороне региона («bring/hold your own key» по возможности).
5. Доказуемость: карты данных, DPIA/TRA, логи доступов и подтверждения местоположения хранения.
6. Fail-safe: бэкапы и DR соответствуют тем же правилам резидентности, что и боевые данные.
4) Роли и RACI
Head of Compliance / DPO — политика, DPIA, юридические механизмы, аудит. (A)
Security/Infra Lead — архитектура регионов, ключи/шифрование, контроль доступа. (R)
Data Platform / Analytics — модели анонимизации/псевдонимизации, конвейеры. (R)
Engineering / SRE — развертывание регионов, репликации, DR/BCP. (R)
Legal — трансграничные соглашения, договоры с вендорами, DPA/SA. (C)
Procurement/Vendor Mgmt — оценка поставщиков, локации дата-центров. (R)
Internal Audit — выборки, контроль артефактов, CAPA. (C)
Product/CRM/BI — соблюдение ограничений в фичах/кампаниях/отчетах. (R)
5) Классификация и картография данных
Категории:- KYC/Возраст: документы, селфи, биометрия, результаты проверок.
- Платежи/PCI: PAN/токены, 3DS/AR, PSP-идентификаторы.
- Игровая активность: сессии, ставки, выигрыши/потери, RG/SE/RC-события.
- Маркетинг/CRM: контакты, предпочтения, suppression-флаги.
- Логи/теле-метрия: события приложений, ошибки, трассировки.
- Аналитика/репорты: агрегаты, кубы, ML-фичи.
- Источник → система → регион хранения → правовой статус → потребители → срок хранения → механизм удаления.
- Обязательна визуальная карта потоков, включая кто/куда реплицируется и в каком виде (RAW/PII-free/анонимизировано).
6) Архитектурные паттерны локализации
Regional Tenancy: отдельные кластеры (EU, UK, TR, BR, CA, AU и т.д.) с изоляцией БД/секретов/ключей.
Data Sharding по региону/рынку: префикс `tenant_region` в ключах, роутинг запросов через Geo-Router/API Gateway.
Control Plane vs Data Plane: глобальная панель управления без PII; PII — только в региональных дата-плейнах.
Edge-кэш без PII: кэшировать только публичный/неперсональный контент.
Аналитика через De-PII Pipeline: экспорт в DWH только агрегатов/псевдонимов; «чистые» PII — запрещены вне региона.
DR в рамках региона: «горячая» реплика в той же стране/региональном блоке (или разрешенный кросс-регион с аналогичной защитой и юр. основанием).
BYOK/HYOK: ключи шифрования под контролем региона/заказчика; KMS со сквозным аудитом.
7) Трансграничные передачи: правовые механизмы (каркас)
Договорные:- Стандартные контрактные положения / местные аналоги (SCC/IDTA/доп. соглашения).
- Допсоглашения о передаче в третьи страны (DPA, SSA, Schrems-совместимые оценки рисков).
- Оценки рисков: TIA/TRAs (Transfer/Third-Country Risk Assessments).
- Технические меры: шифрование, разделение ролей, токенизация, минимизация.
- Оргмеры: политика доступа «need-to-know», журналирование, обучение.
8) Региональные профили (шаблон)
Для каждого рынка поддерживайте карточку:
Юрисдикция: ______
Требования к резидентности: (обязательная/рекомендуемая/нет)
Запреты на трансграничность: (полный/условный/нет)
Разрешенные механизмы передачи: (SCC/IDTA/локальное соглашение)
Особые категории: (биометрия/финансы/RG)
Бэкапы/DR: (где, частота, шифрование)
Логи/телеметрия: (можно ли выводить за рубеж, в каком виде)
Сроки хранения: (KYC, платежи, игровые, RG/SE)
Удаление/DSAR: (SLA, подтверждения)
Вендоры/облака: (разрешенные регионы)
9) Локализация бэкапов, логов, аналитики
Бэкапы: шифрованные, в том же регионе, каталог доказательств местоположения (ид провайдера/бакап-вулт/ретенция).
Логи/трейсы: PII-free по умолчанию; если PII неизбежны — локальные хранилища логов, с редактированием/маскированием.
Аналитика/DWH: только псевдонимизированные ключи; агрегаты с k-анонимностью; запрет на выгрузку «сырых» событий за пределы региона без основания.
10) Поставщики и облака
Регистр вендоров с полями: страна регистрации, регионы дата-центров, сертификаты (ISO/PCI/SOC), подписи DPA/SCC/IDTA, режим ключей, суб-процессоры.
Процедура «pre-flight»: оценка юрисдикций, DPIA/TIA, тест отказоустойчивости в рамках региона, проверка «data at rest» региона.
Контрактные клаузы: уведомление о смене суб-процессора/локации, право аудита, сроки устранения, штрафы.
11) Удаление, ретенция и DSAR
Политика хранения: KYC/финансы/игровые/логи — отдельные сроки (часто 5–7 лет для комплаенса; в маркетинге — короче).
Технически принудимое удаление (erasure): каскадные delete jobs с отчетами; крипто-удаление (удаление ключей) для архивов.
DSAR/Subject Rights: обработка запросов на доступ/исправление/удаление только в региональном периметре; артефакты ответа — в локальном WORM.
12) Контрольные процедуры и аудит
Data Lineage: происхождение полей, маршрут трансграничных потоков, хэш-подпись экспорта.
Access Reviews: ежеквартальные ревью прав доступа, отчеты по кросс-региональным запросам.
Логи передач: кто/что/когда/куда/основание/вид данных/PII-маска/результат.
Проверка вендоров: ежегодные отчеты и пентесты/аттестации.
CAPA: исправления по находкам, дедлайны и ответственные.
13) Требования к продукту и API
Geo-router: резолвит `player_region` и направляет запросы в «домашний» кластер.
14) Матрица «что где хранить» (пример)
15) KPI/дашборд комплаенса локализации
Residency Coverage: % субъектов, чьи PII находятся в правильном регионе.
X-Border Request Rate: доля запросов на трансграничный доступ (по ролям/подразделениям).
Anonymized Export Share: доля экспортов в глобальный DWH, прошедших De-PII.
Backup Locality SLA: % бэкапов, подтвержденных в локальном регионе.
Vendor Region Drift: инциденты смены локаций/суб-процессоров.
DSAR SLA: медиана выполнения в региональном периметре.
Audit Findings (repeat): повторяющиеся несоответствия.
16) Чек-листы
Перед выходом в новую юрисдикцию
- Карта данных и классификация по категориям.
- Карточка юрисдикции (требования, бэкапы, логи, сроки хранения).
- Архитектурный план региона (VPC/кластер/БД/KMS).
- DPIA/TIA, договоры (DPA/SCC/локальные аналоги).
- Вендор-ассессмент (локации DC, суб-процессоры).
- Набор политик: доступ/удаление/экспорт.
В операциях
- Ежедневная валидация «residency assertions» по новым записям.
- Мониторинг кросс-региональных запросов и отклонений.
- Проверка локальности бэкапов/журналов.
- DSAR-очередь в пределах региона.
Аудит/улучшения
- Квартальная ревизия вендоров/регионов.
- Тест DR в каждом регионе (1/квартал).
- CAPA по нарушениям (сроки/ответственные).
17) Шаблоны (быстрые вставки)
A) Клауза с вендором (локализация данных)
B) Политика экспорта (внутренняя заявка)
C) Текст в SLA с бизнесом
18) Частые ошибки и профилактика
Бэкапы в «удобном» соседнем регионе. → Запрет; только локальные бэкапы.
Логи с PII улетают в глобальный APM. → Маскирование на уровне агента, локальные синки.
Глобальные отчеты с сырыми идентификаторами. → Только агрегаты/псевдонимы.
Смешение control/data planes. → Глобальный control plane — без PII.
Отсутствие доказательств резидентности. → Хранить артефакты: id-ресурсов, снимки конфигов, отчеты провайдера.
19) 30-дневный план внедрения
Неделя 1
1. Утвердить политику локализации и модель классификации данных.
2. Построить первичную карту потоков по действующим рынкам.
3. Определить региональные boundary-сервисы и требования к ключам (BYOK/HYOK).
Неделя 2
4. Развернуть региональные кластеры приоритета №1 (EU/UK/…); включить Geo-Router.
5. Включить De-PII конвейеры в DWH, настроить локальные логи/APM.
6. Подписать/обновить DPA/SCC/IDTA с ключевыми вендорами.
Неделя 3
7. Миграция PII в региональные БД; локальные бэкапы и DR-план.
8. Ввести процесс заявок на трансграничный экспорт (портал + журнал).
9. Обучить команды (Prod/BI/CS/Legal) по новым правилам.
Неделя 4
10. Провести тест DR и выборочный аудит резидентности.
11. Включить дашборд KPI (Residency Coverage, Backup Locality SLA).
12. CAPA по найденным расхождениям; план v1.1 (следующие рынки).
20) Взаимосвязанные разделы
KYC-процедуры и уровни проверки / Проверка возраста
AML-политика и контроль транзакций
Ответственная игра и лимиты / SE / Reality Checks
Регуляторные отчеты и форматы данных
Дашборд комплаенса и мониторинг
Внутренний/внешний аудит и аудиторские чек-листы
BCP/DRP и «Шифрование At Rest / In Transit»