Розподіл обов'язків і рівні доступу

1) Цілі та принципи

• виключити одиночний контроль над критичними операціями (гроші/PII/комплаєнс),
• знизити ризик шахрайства/помилок,
• забезпечити перевіряємість для регуляторів і внутрішніх аудитів.

Принципи: Zero Trust· Least Privilege· Need-to-Know· SoD (4-eyes)· Traceability· Revocability (швидкий відгук).

2) Класифікація даних та рівні доступу

3) Модель прав: RBAC + ABAC

RBAC: ролі по доменах (Support, VIP, Payments, AML, KYC, FRM, BI, DevOps, DPO, Legal).
ABAC: контекстні атрибути (середовище, географія, клас даних, пристрій/MDM, час, рівень KYC, мета доступу'purpose', ризик пристрою).

Приклад ABAC-умови: аналітик BI може читати'events _'тільки без PII, тільки з корпоративної мережі/MDM, в будні 08:00–21:00, при наявності активного тренінгу з приватності.

4) SoD - матриця несумісних функцій

Будь-яка операція, що впливає на гроші/PII/санкції, проходить двоконтурне схвалення (ініціатор ≠ стверджує).

5) Рівні та типи доступу

Read-only / Masked Read: за замовчуванням для BI/Support.
Scoped Write: зміни в межах сервісу/регламенту (напр., введення приміток по кейсу).
Privileged Admin: тільки через PAM (парольний сейф, сесійний проксі, запис сесії, ротація секретів).
API/Service Accounts: мінімальні скопи, окремі ключі per інтеграція, mTLS.

6) JIT и break-glass

JIT (Just-in-Time): тимчасові підвищення прав (15-120 хв) під конкретний тікет, автоматичний відгук, обов'язковий'purpose'.
Break-glass: екстрений доступ з MFA + другим підтвердженням, запис сесії, пост-рев'ю Security + DPO, автосоздание інциденту при порушеннях.

7) Процеси (SOP)

7. 1 Запит/зміна доступу (IDM/ITSM)

1. Заявка з'purpose', терміном і власником даних.
2. Автоперевірка SoD/класу даних/юрисдикції.
3. Схвалення доменного власника + Security (для Restricted +).
4. Видача JIT/постійного доступу (мінімальний скоуп).
5. Запис до реєстру прав (дата перегляду, SLA відкликання).

7. 2 Ре-сертифікація прав

Щокварталу власники підтверджують права груп/користувачів.
Автоотзив невикористовуваних прав (> 30/60 днів).

7. 3 Експорт даних

Тільки через схвалені вітрини/пайплайни; маскування за замовчуванням; білі списки адресатів/форматів; підпис/хеш; журнал вивантажень.

8) Контроль вендорів/партнерів

Окремі B2B-тенанти, мінімальні API-скоупи, allow-list IP, вікна часу.
DPA/SLA: логи доступів, терміни зберігання, географія, інциденти, субпроцесори.
Оффбординг: відкликання ключів, підтвердження видалення, акт закриття.

9) Інтеграція з безпекою та комплаєнсом

Audit trails: `READ_PII`, `EXPORT_DATA`, `ROLE_UPDATE`, `PAYMENT_APPROVE`, `BREAK_GLASS`.
SIEM/SOAR: алерти на аномальні обсяги/доступ без'purpose '/вихід за вікно/гео.
GDPR/AML/PCI: Need-to-Know, DSAR-сумісність, сегрегація платіжного периметра, WORM для журналів.

10) Політики прикладів (фрагменти)

10. 1 Політика VIP-менеджера

Маскований перегляд профілю, заборона експортів, JIT на одиничний перегляд KYC через тікет.

10. 2 Політика для аналітика маркетингу

Тільки агрегати без PII; доступ за наявності згоди (CMP прапор), з MDM-пристрою, в робочі години.

10. 3 Псевдо-YAML ABAC

yaml policy: read_transactions_masked subject: role:bi_analyst resource: dataset:tx_
condition:
data_class: in [Confidential]
network: in [corp_vpn, office_mdm]
time: 08:00-21:00 workdays purpose: required effect: allow masking: on logging: audit_access + fields_scope

11) RACI

12) Метрики та KRIs/KPIs

Coverage ABAC: ≥ 95% критичних наборів під атрибутними правилами.
JIT-rate: ≥ 80% підвищень прав ідуть як JIT.
Offboarding TTR: відкликання доступу ≤ 15 хв з моменту звільнення/деактивації.
Аномальні доступи без'purpose': = 0 (KRI).
Quarterly recertification: 100% ролей/груп підтверджені.
Export compliance: 100% експортів підписані/зажурналені.

13) Чек-листи

13. 1 Перед видачею доступу

• Визначено'purpose', термін, власник даних
• Перевірка SoD/юрисдикцій/класу даних пройдена
• Мінімальний скоуп + маскування включені
• MFA/MDM/мережеві умови дотримані
• Налаштовані журнали і дата перегляду

13. 2 Щоквартальна ревізія

• Звірити групи/ролі з оргструктурою
• Відкликати невикористовувані права
• Перевірити break-glass і великі експорти
• Підтвердити навчання (privacy/security)

14) Типові сценарії та заходи

A) Інженеру потрібен тимчасовий доступ до prod-БД

JIT 30-60 хв, записана сесія через PAM, пост-рев'ю, CAPA при порушеннях.

B) Новий афіліат просить вивантаження гравців

Тільки агрегати/анонімізація; якщо PII - договір, правова підстава, білий список полів, журнал/підпис, обмежений термін посилання.

C) Менеджер VIP хоче бачити KYC-документи

Заборона прямого доступу; запит через AML/KYC, одинична видача через JIT, повний лог полів.

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

Тижні 1-2: інвентаризація систем/даних, класифікація, базова RBAC-матриця, первинна SoD-таблиця.
Тижні 3-4: впровадження ABAC (середовище/гео/клас/MDM), JIT і break-glass, запуск PAM, журнали експортів.
Місяць 2: сегментація КУС/платіжного периметра, окремі ключі/KMS, SOAR-алерти на порушення SoD/ABAC.
Місяць 3 +: квартальні ре-сертифікації, розширення атрибутів (ризик пристрою/час), автоматизація маскування, регулярні tabletop-навчання.

TL; DR

Надійна модель доступу = класифікація даних → RBAC + ABAC → SoD з 4-eyes → JIT/PAM і жорсткий аудит → регулярна ре-сертифікація і контроль експортів. Це знижує ймовірність зловживань і прискорює проходження аудитів/регуляторних перевірок.