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 регіон (EC/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 + жорсткий аудит і ре-сертифікація. Це знижує ризик витоків/зловживань, прискорює аудит і тримає платформу в межах вимог приватності і комплаєнсу.