GH GambleHub

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

1) Навіщо це потрібно (мета і область)

PbD гарантує, що приватність вбудована в продукт за замовчуванням, а не «наклеєна» зверху. Для iGaming це знижує регуляторні ризики (GDPR/ePrivacy/локальні закони), захищає вразливих користувачів, підвищує довіру і знижує вартість інцидентів. Охоплення: веб/мобайл, KYC/AML/RG, платежі, маркетинг/CRM, аналітика/DWH, логи/АРМ, партнери/вендори.

2) Сім принципів (і як їх приземлити в операціях)

1. Проактивність, не реактивність

Threat modeling (LINDDUN/STRIDE) на етапі discovery.
Privacy-acceptance критерії в Jira/PR шаблонах.

2. Приватність за замовчуванням (Privacy by Default)

Всі тумблери маркетингу/персоналізації - off, поки немає згоди.
Збір тільки «строго необхідних» ідентифікаторів за замовчуванням.

3. Приватність вбудована в дизайн

PII зберігається в регіональному контурі (data residency), control plane - без PII.
Токенізація/псевдонімізація ключів у сервісних подіях.

4. Повна функціональність (win-win)

Режими «анонімної аналітики» і «персоналізації зі згодою».
Рівний UX без дискримінації тих, хто відмовився від трекінгу.

5. Безпека крізь життєвий цикл

Шифрування at rest/in transit; BYOK/HYOK; сегментація мереж; секрет-менеджмент.
WORM-журнали для доказів і аудиту.

6. Прозорість

Короткі політики і «summary box» ключових умов; панель приватності в профілі.
Звітність: хто/що/коли/навіщо доступався до даних.

7. Орієнтація на користувача

Прості тексти, відсутність темних патернів, доступність WCAG AA +.
Легкий відгук згоди і зручні канали DSAR.

3) Ролі та RACI

DPO/Head of Compliance - політика PbD, DPIA/TRA, контроль ризиків. (A)

Security/Infra Lead - криптографія, доступи, журнали, вендори. (R)

Product/UX - privacy-вимоги у фічах, відсутність dark patterns. (R)

Engineering/Architecture - токенізація, ізоляція tenant/region, API-контракти. (R)

Data/Analytics - де-PII конвеєри, PETs, агрегування. (R)

Legal - правові підстави, тексти і локалі. (C)

Marketing/CRM - згоди/suppression, чесні комунікації. (R)

Internal Audit - вибірки артефактів, CAPA. (C)

4) Класифікація і таксономія даних

PII базові: ПІБ, e-mail, телефон, адреса, дата народження, IP/ID пристрої.
Чутливі PII: біометрія (селфі/жвавість), KYC-документи, платіжні реквізити, RG/SE статуси.
Операційні: ігрові події, логи/трейси (PII-free за замовчуванням).
Маркетинг/аналітика: ідентифікатори cookies/SDK (за згодою).

Правила: мінімізація, роздільне зберігання, явна мета і термін зберігання.

5) Життєвий цикл даних (Data Lifecycle)

1. Збір - тільки необхідні поля; СМР/згоди; перевірки віку.
2. Передача - TLS 1. 2 +/mTLS, підпис вебхуків, регіональний роутинг.
3. Зберігання - шифрування, токенізація, ротація ключів, ізоляція по ринках.
4. Використання - RBAC/ABAC, «need-to-know», PETs для аналітики.
5. Обмін - DPA/SCC, мінімальні набори, аудіруемие канали.
6. Ретенція/видалення - термін по категорії; каскадні delete jobs; крипто-видалення архівів.
7. Звітність/аудит - логи доступу та експорту, артефакти DPIA/DSAR.

6) DPIA/TRA (як робити коротко)

Тригери: нові категорії PII, особливі категорії, нові вендори, транскордонні передачі, високі ризики RG/біометрії.
Шаблон DPIA: мета → категорії даних → правова підстава → потоки/карта → ризики → заходи (тех/орг) → залишковий ризик → рішення.
Артефакти: діаграма потоків, список полів, таблиця ризиків, протокол узгоджень.

7) Архітектурні патерни PbD

Tenant/Region Isolation: фізична/логічна сегрегація БД, ключів і секретів.
Control vs Data Plane: глобальний контроль - без PII; PII тільки локально.
De-PII Pipeline: перед експортом в DWH - хеш/сіль, усічення, k-анонімність/кохортування.
Tokenization Gateway: токени замість первинних ідентифікаторів в сервіс-шині.
Edge без PII: CDN/edge-кеш - тільки публічний контент.
Fail-Closed: невідомий'player _ region'→ заборону операцій з PII.

8) Технічні заходи та стандарти

Шифрування: AES-256/GCM at rest; TLS 1. 2+/1. 3; PFS.
Ключі: KMS, BYOK/HYOK, ротація, доступ за HSM-ролями, журнал ключових операцій.
Доступ: RBAC/ABAC, JIT-доступи, роздільні адмін- та аудит-ролі.
Журнали: незмінні (WORM), хеш-ланцюжки, зберігання в регіоні.
DevSecOps: секрети в Vault, SAST/DAST, лінтер PII-полів, privacy-тести в CI.
Тест-дані: синтетика за замовчуванням; якщо дані - де-ідентифікація і коротка ретенція.

9) PETs (Privacy-Enhancing Technologies)

Псевдонімізація: заміна ID на токени; ключ-мап зберігається окремо.
Анонімізація: агрегати, k- anonimnost/ℓ -diversity, бінінг/кохорти.
Диференціальна приватність: шум на звітах, «privacy budget».
Федеративна аналітика: локальні моделі, експорт тільки ваг/агрегатів.
Маскування/редакція: видалення EXIF, затирка полів у KYC-документах.

10) UX без темних патернів

Рівна помітність «Відхилити все «/« Прийняти все «/« Налаштувати ».
Зрозумілі тексти цілей і приклади використання даних.
Відмова від персоналізації не погіршує базовий досвід.
Панель приватності в 1-2 кліка звідусіль; доступність AA +.

11) Вендори і передача даних

Реєстр вендорів: юрисдикції DC, суб-процесори, сертифікація, регіони зберігання, DPA/SCC/IDTA.
Політика «мінімального набору»: тільки потрібні поля, заборона вільного експорту.
Повідомлення та перегляд при зміні локацій/суб-процесорів.

12) Дані та події (мінімальна модель)


data_asset{id, category{KYC    PCI    RG    CRM    LOG    ANON}, region, owner, retention_days, lawful_basis, pii{yes/no}}
processing_event{id, actor, purpose, lawful_basis, started_at, ended_at, records_count, export{yes/no, basis_id}}
access_log{id, subject_id_hash, actor, action{read/write/export/delete}, ts_utc, reason, ticket_id}
erasure_job{id, subject_id_hash, scope, started_at, completed_at, evidence_id}

13) KPI/KRI і дашборд PbD

PII Minimization Index (середнє число PII-полів на фічу).
Residency Coverage (% записів у правильному регіоні).
Export Justification Rate (скільки експортів з посиланням на підставу).
DSAR SLA (медіана виконання/точність).
Tag Firing Violations (теги без згоди).
Auditability Score (% кейсів з повним пакетом артефактів).
Incidents/Findings (повторювані зауваження аудиту/регулятора).

14) Чек-листи

A. перед розробкою фічі (Design)

  • Визначені цілі та правові підстави обробки.
  • Карта даних і список полів з позначкою PII/чутливі.
  • DPIA/TRA виконані; залишкові ризики прийняті.
  • Продуманий «анонімний режим» або режим з мінімумом даних.

B. перед релізом (Build/Release)

  • Секрети в менеджері, ключі/шифрування налаштовані.
  • Логи без PII; події та аудит включені.
  • Регіональний роутинг і політика retention активні.
  • Тести: consent-гейти, deny-by-default для тегів, erasure-шлях.

C. в операціях

  • Квартальні рев'ю доступів і експортів.
  • Моніторинг firing-порушень і транскордонних запитів.
  • DSAR/видалення виконуються в термін; артефакти зберігаються.

15) Шаблони (швидкі вставки)

A) Шаблон DPIA (короткий)

💡 Мета: ____
Категорії даних: ____ (PII: так/ні)
Підстава: ____
Потоки/локації: ____
Ризики/вплив: ____
Заходи: тих (шифр ./токени/ізоляція), орг (RBAC/навчання)
Залишковий ризик: ____ Рішення: схвалити/переробити

B) Політика мінімізації полів

💡 Для {функції} допустимі поля: […]. Будь-яке нове поле вимагає DPIA update і Legal review.

C) Клауза з вендором (PbD-зобов'язання)

💡 Постачальник реалізує Privacy by Design/Default, зберігає дані в {регіон}, застосовує шифрування at rest/in transit, надає логи доступів, повідомляє про зміну суб-процесорів і локацій ≥30 днів.

D) Відповідь на DSAR (витримка)

💡 Ми надали відомості про ваші дані, цілі обробки та джерела. Видалення виконано каскадно; підтвердження додано (evidence #...).

16) Часті помилки і як їх уникнути

Збір «про всяк випадок». → Політика мінімізації + код-рев'ю схем.
Сирі логи з PII в APM. → Маскування/редакція на агенті, локальні сховища.
Глобальний DWH з PII. → Тільки де-PII агрегати/псевдоніми.
Відсутність артефактів DPIA/consent. → WORM-репозиторій, авто-знімки UI/текстів.
Невраховані вендори/SDK. → Щоквартальний реєстр, заборона «сірих» підключень.

17) 30-денний план впровадження

Тиждень 1

1. Затвердити PbD-політику і шаблони DPIA/TRA.
2. Побудувати карту даних/потоків за ключовими зонами (KYC/PCI/RG/CRM/Логи).
3. Виділити регіональні периметри (EU/UK/...); визначити модель ключів (BYOK/HYOK).

Тиждень 2

4) Включити токенізацію/де-PII конвеєри і deny-by-default для тегів.
5) Налаштувати WORM-журнали (доступи/експорти/consent/видалення).
6) Оновити договори з вендорами (DPA/SCC, локації, суб-процесори).

Тиждень 3

7) Впровадити privacy-тести в CI (лінтер PII, скрін-фіксація CMP, erasure-E2E).
8) Реліз панелі приватності в профілі; поліпшити тексти і локалі.
9) Провести навчання команд (Product/Eng/Data/CS/Legal).

Тиждень 4

10) Провести DPIA-рев'ю топ-фіч, закрити CAPA.
11) Запустити дашборд KPI/KRI (Residency, Exports, DSAR SLA).
12) План v1. 1: Дифф. приватність для звітів, федеративні пайплайни.

18) Взаємопов'язані розділи

GDPR: управління згодою користувачів/Політика cookies і CMP

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

Перевірка віку та вікові фільтри

AML/KYC та зберігання артефактів

Дашборд комплаєнсу та моніторинг/Регуляторні звіти

Внутрішній/зовнішній аудит та аудиторські чек-листи

BCP/DRP/Шифрування At Rest & In Transit

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Telegram
@Gamble_GC
Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

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