Контроль доступа к данным

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: OPA/эквивалент для 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 это основа доверия к метрикам, устойчивости к инцидентам и скорости принятия решений.