GH GambleHub

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

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-фичи.
Картография (Data Map):
  • Источник → система → регион хранения → правовой статус → потребители → срок хранения → механизм удаления.
  • Обязательна визуальная карта потоков, включая кто/куда реплицируется и в каком виде (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», журналирование, обучение.
💡 В продукте: любое обращение службы поддержки, BI или разработчика к данным «вне региона» идет через проокси-слой, который: (a) вычищает PII, (b) прикладывает основание доступа, (c) логирует артефакты.

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` и направляет запросы в «домашний» кластер.

Policy-aware APIs: тег `data_class={PIIPCIANON}`, `region_scope={localglobal_anon}`, `transfer_basis_id`.
Ивенты:
`data_residency_asserted` (подтвержден регион),
`xborder_export_requested/approved/denied`,
`backup_completed_local`,
`dsar_fulfilled_local`.
Fail-Closed: при неопределенном регионе — запрет операций с PII.

14) Матрица «что где хранить» (пример)

КатегорияМесто храненияМожно ли реплицировать за рубежУсловия
KYC документы/биометрияЛокальный регионНетТолько агрегаты/вердикты «pass/fail» наружу
Платежные токеныРегион + PCI-зонаУсловноТокенизация, PCI-скоуп, договор с PSP
Игровые события (сырые)РегионУсловноПсевдоним → агрегаты в глобальный DWH
RG/SE статусыРегионНетРазрешены только флаги «anonymized» в глобальные системы
CRM-контактыРегионУсловноС разрешением и DPA; suppression-флаги локально
Логи/трейсыРегионТолько PII-freeМаскирование/удаление PII на сборщике

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) Клауза с вендором (локализация данных)

💡 Поставщик гарантирует хранение и обработку Заказных Данных Категорий {PII/RG/KYC} исключительно в регионе {…}. Любая трансграничная передача допускается только при наличии действующих правовых механизмов и письменного согласования. Изменение локации — с уведомлением ≥ 30 дней.

B) Политика экспорта (внутренняя заявка)

💡 Запрашиваю экспорт агрегатов по рынку {…} за период {…}. Категория данных: {ANON}. Основание: {отчет/аудит}. Риски оценены, PII отсутствует. Ответственный: {…}. Срок удаления выгрузки: {…}.

C) Текст в SLA с бизнесом

💡 Время реакции на DSAR — до X дней, удаление — каскадно, подтверждение — артефактом из регионального WORM-хранилища.

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»

Contact

Свяжитесь с нами

Обращайтесь по любым вопросам или за поддержкой.Мы всегда готовы помочь!

Начать интеграцию

Email — обязателен. Telegram или WhatsApp — по желанию.

Ваше имя необязательно
Email необязательно
Тема необязательно
Сообщение необязательно
Telegram необязательно
@
Если укажете Telegram — мы ответим и там, в дополнение к Email.
WhatsApp необязательно
Формат: +код страны и номер (например, +380XXXXXXXXX).

Нажимая кнопку, вы соглашаетесь на обработку данных.