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) Класифікація та картографія даних

Категорії:
  • КУС/Вік: документи, селфі, біометрія, результати перевірок.
  • Платежі/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

Політика зберігання: КУС/фінанси/ігрові/логи - окремі терміни (часто 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, налаштувати локальні логи/АРМ.
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).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.