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) Політика мінімізації полів
C) Клауза з вендором (PbD-зобов'язання)
D) Відповідь на DSAR (витримка)
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