Контроль доступу до даних

1) Навіщо це iGaming

Ризик і регуляторика: PII/фінанси, транскордонність, RG/AML-вимоги.
Швидкість і довіра: безпечне самообслуговування аналітики і ML без ручних «роздач».
Аудит і відповідальність: «хто що бачив і навіщо», доказовість принципу мінімальних прав.

2) Базові принципи

1. Least Privilege - тільки потрібне і на потрібний термін.
2. Segregation of Duties (SoD) - розробник ≠ який схвалює доступ; аналітик ≠ власник даних.
3. Just-in-Time (JIT) - тимчасові, автоматично відкликані права.
4. Defense in Depth - багаторівневий захист: мережа → сервіс → таблиця → колонка → рядок → комірка.
5. Policy-as-Code - доступи і маски в коді/репозиторії, рев'ю через PR.
6. Provenance-aware - рішення спираються на каталог, лінійдж, класифікацію та контракти.

3) Класифікація даних

Класи: Public/Internal/Confidential/Restricted (PII/фінанси).
Мітки в схемах і каталозі: `pii`, `financial`, `tokenized`, `masking`, `rle` (row-level), `cle` (column-level), `geo=EU/TR/…`, `tenant`.

• Restricted: токени/маски скрізь; детокенізація тільки в «чистій зоні» за заявкою.
• Confidential: доступ з масками за замовчуванням; зняття масок - через обґрунтування і JIT.
• Internal/Public: за ролями домену, без PII.

4) Моделі авторизації

RBAC (роль-базир.) : швидкий старт, каталоги ролей («Marketing-Analyst», «Risk-Ops»).
ABAC (атрибут-базир.) : країна, бренд, середовище (prod/stage), проект, мета обробки, час, ризик-рівень.
ReBAC (за відносинами): «власник набору», «стeward домену», «рев'юер».
Hybrid: RBAC як каркас, ABAC уточнює межі.

5) Гранулярність доступу

Мережа/інгрес: mTLS, allow-list, private links.
Сервіс/кластер: IAM-ролі, service account з мінімумом привілеїв.
Сховища: каталоги/схеми/таблиці (GRANT), Row-Level Security (RLS), Column-Level Security (CLS).
Маскування/токенізація: динамічні маски в SQL/BI; токени замість PII.
Фічестор/ML: доступ тільки до агрегатів/дозволених фічів; політика ознак (allow/deny).
Файли/об'єкти: пре-підписані посилання з TTL, шифрування і політика скачувань.

6) Патерни для ключових доменів

KYC/AML: CLS (видно тільки токени), RLS по країні оператора; детокенізація - DPO/Legal по JIT.
Платежі: Restricted, FLE + токени, доступ Risk/Payments-Ops через JIT; аудіруемие вивантаження.
Ігрові події: Internal/Confidential, RLS по бренду/регіону/тенанту, CLS для user_id.
Responsible Gaming: доступ RG-команди до агрегатів; індивідуальні кейси - за заявкою.
BI/ML: «золоті» вітрини без PII; ML - список дозволених фіч, журнал виправдань для спірних.

7) Процедури доступу

7. 1 Запит → узгодження → провізія

Форма заявки: мета, обсяг, термін, роль, атрибути ABAC, власник набору.
Автоперевірка: клас даних, SoD, навчання пройдено? конфлікт інтересів?
RACI: Owner (R), Steward (C), DPO/Sec (A/C), IT/IAM (R).

7. 2 JIT и break-glass

JIT: 15 хв/2 години/1 день з авто-відгуком; продовження - за новою заявкою.
Break-glass: для інцидентів; окремі ролі/ключі, посилений аудит, пост-мортем обов'язковий.

7. 3 Регулярні рев'ю

Квартальний access review: власники доменів підтверджують ролі/атрибути.
Авто-деактивація «забутих» доступів (no-use 30/60 днів).

8) Технічні механізми

Catalog & Contracts: джерело істини про власників, класи, маски.
Policy Engine: ОРА/еквівалент для ABAC/Row/Column-політик.
Data Masking: динамічні маски в DWH/BI; формат-сейф маски для телефонів/email.
Tokenization: vault/FPE; детокенізація тільки в «чистій зоні».
Secrets & PAM: секрет-менеджер, JIT-сесії, запис екранів для адмін-доступів.
Audit & SIEM: незмінні логи (WORM), кореляція подій доступу з сесіями і вивантаженнями.
Geo/tenant-ізолятори: фіз/логічне розділення (схеми, каталоги, кластери, ключі шифрування).

9) Consent & DSAR

Доступи враховують згоди гравця (marketing = off → приховати маркетингові атрибути).
DSAR-кнопки: знайти/вивантажити/видалити по токену; лог всієї операції; Legal Hold враховується.

10) Моніторинг та SLO

Access SLO: p95 часу видачі JIT-доступу (напр., ≤ 30 хв).
Zero-PII in logs: 100% подій без PII.
Anomaly rate: алерти при сплеску SELECT або нетипових JOIN до Restricted.
Review Coverage: ≥ 95% ролей рев'юиться вчасно.
Mask Hit-Rate: частка запитів, де спрацювала маска/токен.
Detokenization MTTR: середній час обробки валідної заявки.

11) Шаблони

11. 1 Політика доступу (фрагмент)

Принцип: least privilege + SoD + JIT.
Ролі: каталог ролей з описом завдань/вітрин.
Атрибути ABAC: `country`, `brand`, `env`, `purpose`, `retention`.
Маски/токени: за замовчуванням активні на Confidential/Restricted.
Рев'ю: квартально; авто-відгук «забутих» доступів.
Порушення: блокування, розслідування, навчання.

11. 2 Форма заявки

Хто: ПІБ/команда/менеджер.
Що: набір/таблиця/вітрина/фічі.
Навіщо: мета, очікуваний результат/метрики.
Як довго: термін/графік.
Клас даних: (автозаповнюється з каталогу).
Підписи: Owner/Steward, DPO або Sec (якщо Restricted).

11. 3 Каталог ролей (приклад)

Marketing-Analyst: Internal/Confidential вітрини маркетингу; без детокенізації; RLS по бренду.
Risk-Ops: Restricted платежі з масками; JIT на детокенізацію; експорт тільки через «білі» шаблони.
RG-Team: агрегати RG, доступ до кейсів за заявкою.
DS/ML: фічестор (allow-list фіч), sandbox без PII.

12) Дорожня карта впровадження

0-30 днів (MVP)

1. Класифікація даних і мітки в схемах.
2. Каталог ролей + базові ABAC-атрибути (країна/бренд/env).
3. Маскування/токенізація за замовчуванням для Confidential/Restricted.
4. JIT-процес і журнал аудиту; break-glass регламент.
5. RLS/CLS для платежів, KYC, ігрових подій; заборона'SELECT'для Restricted.

30-90 днів

1. Policy-as-Code в CI (лінтер запитів, блоки при порушеннях).
2. Інтеграція з Consent/DSAR; звіти по SLO доступу.
3. Квартальний access review; авто-деактивації.
4. PAM для адмін-доступів; запис сесій; Тайм-бокс.

3-6 місяців

1. Geo/tenant-ізоляція, окремі ключі шифрування по юрисдикціях.
2. Авто-рекомендації ролей на основі фактичних запитів (usage-based).
3. Поведінкова аналітика доступу (анти-аномалії), SOAR-плейбуки.
4. Сертифікація процесів і зовнішній аудит.

13) Анти-патерни

«Суперкористувач» для всіх - без SoD і JIT.
Розшарування даних через файли/скріншоти поза контрольованими каналами.
RLS/CLS тільки «на папері» - маски вимкнені в BI.
Немає рев'ю прав і авто-відкликання; «вічні» доступи.
Каталог/контракти не оновлюються - правила доступу застарівають.
Детокенізація в додатках «для зручності» без аудиту.

14) RACI (приклад)

Політики/архітектура: CDO/CISO (A), DPO (C), SecOps (R), Data Platform (R).
Видача доступів: IAM/IT (R), Owners (A/R), Stewards (C), Менеджери (I).
Аудит/рев'ю: Owners (R), DPO/Sec (A), Internal Audit (C).
Інциденти: SecOps (R), Legal/PR (C), Домени (R).

15) Пов'язані розділи

Управління даними, Токенізація даних, Безпека даних і шифрування, Походження і шлях даних, Етика/DSAR, Конфіденційне ML, Federated Learning.

Підсумок

Контроль доступу - це система з політик, атрибутів і автоматизації, яка дає командам потрібні дані рівно в потрібному обсязі і часі, залишаючи повну трассируемость. У iGaming це основа довіри до метриків, стійкості до інцидентів і швидкості прийняття рішень.