RBAC: управление ролями и разрешениями

1) Цели и принципы RBAC

Цель: сделать доступ управляемым, проверяемым и минимальным по объему для защиты денег/PII и соблюдения требований (GDPR/AML/PCI/ISO).
Принципы: Least Privilege · Need-to-Know · Separation of Duties (SoD) · Zero Trust · Revocability (быстрый отзыв) · Auditability (доказуемость).

2) Таксономия прав и роли

• Данные: `READ`, `WRITE`, `EXPORT`, `DELETE`, `MASKED_READ` (по умолчанию для PII).
• Операции: `APPROVE_WITHDRAWAL`, `CHANGE_FRM_RULE`, `KYC_DECISION`, `SANCTIONS_OVERRIDE`.
• Админ: `ROLE_UPDATE`, `USER_PROVISION`, `SECRET_ROTATE`, `BREAK_GLASS`.
• Интеграции: `API_CALL:`, `WEBHOOK_SIGN`, `SERVICE_CONFIG_UPDATE`.

• Core (сквозные): `employee_basic`, `viewer_internal`, `auditor_privacy`.
• Доменные: `support_agent`, `vip_manager`, `payments_ops`, `aml_officer`, `kyc_operator`, `fraud_analyst`, `rg_specialist`, `bi_analyst`.
• Системные/тех: `devops_admin`, `dba_admin`, `service_account_`, `read_only_prod`.
• Привилегированные (через PAM/JIT): `break_glass_admin`, `prod_db_jit_editor`.

3) Проектирование ролей (role engineering)

1. Инвентаризация ресурсов: системы/таблицы/эндпоинты, классы данных (Public/Internal/Confidential/Restricted/Highly Restricted).
2. User stories по функциям: кто что делает и зачем (purpose).
3. Маппинг задач → permissions: минимальный набор на каждую функцию.
4. Группировка в роли: одна роль = один домен ответственности; избегать «суперролей».
5. Тестирование SoD: проверка несовместимостей (напр., `payments_ops` ≠ `fraud_rule_admin`).
6. Пилот и измерение: выдаем временно ограниченной группе, собираем аудиторский след.
7. Версионирование: каждое изменение роли — через CAB с changelog.

4) Взаимодействие RBAC ↔ ABAC ↔ SoD

RBAC отвечает «кто в принципе может», ABAC — «в каких условиях» (среда, гео, устройство/MDM, время, уровень KYC, `purpose`).
SoD запрещает опасные сочетания ролей и требует 4-eyes для критичных действий.
Практика: по умолчанию роли дают MASKED_READ к PII; для немаскированного доступа требуется атрибут `purpose` + JIT и положительное решение политики ABAC.

5) Многоарендность и гео-контекст

Tenant-scope: роли привязываются к аренде/бренду/юрисдикции (`role:payments_ops@EEA`).
Geo-keys: отдельные ключи шифрования и сегменты доступа per регион (ЕС/UK/…).
Гранularity: фильтрация по столбцу `region_code` (RLS) и по юрисдикции игрока.

6) Row/Column-Level Security и маскирование

• RLS (строки): доступ только к записям своей страны/бренда/команды.
• CLS (столбцы): чувствительные поля доступны маскированно; немаскированно — только с привилегией `pii_unmask` + `purpose`.

sql
CREATE POLICY rls_tx
ON dwh. transactions
USING (region_code = current_setting('app. region'));

SELECT
CASE WHEN has_priv('pii_unmask') THEN email ELSE mask_email(email) END AS email_view
FROM dwh. users;

7) JIT, break-glass и PAM в RBAC

JIT: временная привилегированная роль (15–120 мин) под тикет; автоотзыв; полный аудит.
Break-glass: аварийный доступ с MFA + вторым подтверждением и записью сессии; пост-ревью с Security+DPO.
PAM: хранилище секретов, сессионный прокси, ротация паролей/ключей.

8) Жизненный цикл ролей (SOP)

SOP-1: Создание/изменение роли

1. Запрос владельца домена → список задач → маппинг permissions → SoD-чек → пилот → CAB → релиз + документация.

SOP-2: Запрос и выдача доступа

1. Заявка (IDM/ITSM) с `purpose` и сроком → авто-проверка SoD/юрисдикции → одобрение владельца данных + Security (для Restricted+) → выдача (часто JIT) → запись в реестр.

SOP-3: Отзыв/оффбординг

Триггеры: увольнение, смена роли, отсутствие активности >30/60 дней, истек JIT.
Автоматический отзыв и журнал.

SOP-4: Ре-сертификация

Ежеквартально владельцы подтверждают, что роли пользователей все еще нужны; система снимает «висячие» права.

9) Пример матрицы ролей (фрагмент)

10) Инструменты и реализация (паттерны)

Каталог ролей как код: YAML/JSON в репозитории + CI-валидаторы, changelog.
Центральный IdP/SSO: SCIM-провиженинг, групповые маппинги `group → role`.
Policy decision point: движок политик (ABAC) с атрибутами контекста.
Secrets/KMS: изоляция ключей per среда/регион/тенант.
Data gateway: единый слой маскирования/аудита для DWH/BI/экспортов.
SIEM/SOAR: корреляция `ROLE_UPDATE`/`READ_PII`/`EXPORT_DATA`, авто-тикеты.

11) Аудит и журналирование

Обязательные события: `ROLE_ASSIGN`, `ROLE_REVOKE`, `ROLE_UPDATE`, `BREAK_GLASS`, `JIT_GRANT`, `READ_PII`, `EXPORT_DATA`, `PAYMENT_APPROVE`, `KYC_DECISION`.
Требования: WORM-копия, хэш-цепочки, подпись пакетов, `purpose`/`ticket_id` в каждом событии, тайм-синхронизация.

12) Метрики и KPI/KRI

Coverage: % систем под RBAC ≥ 95%.
SoD violations: = 0; попыток присвоения несовместимых ролей — авто-блок.
JIT rate: ≥ 80% повышений идут как JIT.
Offboarding TTR: отзыв прав ≤ 15 мин.
Masked reads ratio: ≥ 95% обращений к PII — маскированы.
Recertification: 100% ролей подтверждены ежеквартально.
Exports signed: 100% экспортов с подписью/журналом.

13) RACI (укрупненно)

14) Чек-листы

Перед созданием роли

• Описаны user-stories и `purpose`
• Перечень ресурсов и классов данных
• Маппинг минимальных permissions
• SoD-проверка/конфликты
• Политика маскирования и RLS/CLS
• План ре-сертификации и владельцы

Перед выдачей доступа

• Фиксирован `purpose` и срок
• SoD/юрисдикции/MDM/MFA выполнены
• Маскирование по умолчанию, JIT при повышении
• Журнал и дата пересмотра включены

15) Частые ошибки и анти-паттерны

«Суперроли» с широкими правами вместо мелких доменных.
Прямой доступ к PII без маскирования и `purpose`.
Отсутствие SoD/четвертых глаз для `PAYMENT_APPROVE`/`KYC_APPROVE`.
Продление временных прав «навсегда».
Копирование prod-данных в dev/stage.
Непрозрачные экспорты без подписи и журнала.

16) Дорожная карта внедрения

Недели 1–2: инвентаризация ресурсов/классификация данных; черновая матрица ролей; SoD-таблица.
Недели 3–4: RBAC как код (репозиторий), IdP-группы/SCIM, ABAC-движок (базовые атрибуты: среда/гео/MDM/время), JIT/PAM, слой маскирования для DWH/BI.
Месяц 2: ре-сертификация, автоматизация offboarding, SOAR-алерты на нарушения RBAC/SoD/ABAC, журналы экспортов/WORM.
Месяц 3+: расширение атрибутов (риск устройства, KYC-уровень), bias-аудиты доступов, оптимизация стоимости и регулярные tabletop-учения.

TL;DR

Сильный RBAC = мелкие доменные роли + атрибутные условия (ABAC) + SoD и JIT/PAM + маскирование и RLS/CLS + жесткий аудит и ре-сертификация. Это снижает риск утечек/злоупотреблений, ускоряет аудит и держит платформу в границах требований приватности и комплаенса.