Сегментація привілеїв

1) Навіщо потрібна сегментація

Сегментація привілеїв - ключ до зниження «blast radius» помилок та інсайдерських зловживань. Вона дозволяє точно обмежувати, хто і де може виконувати які дії з якими даними, при цьому зберігати швидкість операцій і відповідність вимогам регуляторів.

• менше інцидентів через «зайві права»;
• прискорення розслідувань: доступи прозорі і зрозумілі;
• відповідність SoD/комплаєнс, доказовий аудит;
• безпечні експерименти і швидкі релізи без ризику для прод-ядра.

2) Принципи

Zero Trust: кожна дія перевіряється контекстно; немає «довірених зон».
Least Privilege: мінімальні права, видані на мінімальний термін (в ідеалі - JIT).
Context over Role: права залежать не тільки від ролі, але і від атрибутів (тенант, регіон, оточення, ризик).
Segregation of Duties (SoD): поділяємо ініціювання, схвалення, виконання та аудит.
Policy-as-Code: політики в коді з версіонуванням, тестами і рев'ю.

3) Модель зрілості доступу

1. RBAC (roles): старт - фіксовані ролі (Support, Risk, Payments, Trading, Ops, SRE, Compliance).
2. ABAC (attributes): додаємо атрибути: тенант, регіон, юрисдикція, продукт, канал, оточення (prod/stage/dev), час, ризик-клас операції, KRI-сигнали.
3. PBAC (policy-based): централізовані політики «хто/що/де/коли/навіщо» + умови (наприклад, «в проді - тільки по JIT і з тікетом»).

4) Домени сегментації (вісь за віссю)

4. 1 Тенант/клієнт

Доступ і операції обмежені конкретним брендом/оператором/афіліатом.
Крос-тенантні дії заборонені, крім строго певних агрегацій без PII.

4. 2 Регіон/юрисдикція

Політики враховують місцеві ліцензійні та KYC/AML-правила.
Операції з даними гравця обмежені географією зберігання і обробки.

4. 3 Оточення (dev/stage/prod)

Prod ізольований: окремі креди, мережі, Bastion/PAM, «read-only за замовчуванням».
Доступ в prod тільки JIT, з тікетом і вікнами змін.

4. 4 Клас даних

PII/фінанси/ігрова телеметрія/техлоги - різні рівні доступу та маскування.
Експорт PII - тільки через затверджені воркфлоу з шифруванням і TTL.

4. 5 Критичність операцій

Класи P1/P2/P3: публікація коефіцієнтів, ручні заліки, висновки, зміна PSP-роутингу - вимагають dual control.
Низькоризикові операції можуть бути авто-апрувнуті політикою.

5) Рівні привілеїв (tiers)

Viewer: тільки читання агрегатів і маскованих даних.
Operator: виконання процедур по ранбуках без зміни конфігурацій.
Contributor: зміна конфігурацій в не-критичних доменах.
Approver: схвалення заявок і high-risk операцій (не поєднується з виконанням - SoD).
Admin (JIT): короткострокове підвищення для рідкісних завдань під dual control і запис сесії.

6) SoD і несумісні ролі

• Ініціювати висновки ≠ схвалювати ≠ фінально проводити.
• Створювати бонусну кампанію ≠ активувати в проді ≠ змінювати ліміти.
• Розробляти фічу ≠ апрувати реліз ≠ викат в прод.
• Запитувати вивантаження PII ≠ схвалювати ≠ розшифровувати.

Для кожної пари - формалізована політика заборони і виключення з датою перегляду.

7) JIT-доступ і PAM

Elevation за запитом: вказується мета/тікет/термін; після закінчення - авто-відгук.
Dual control: P1/P2 дії - два апрувери з різних функцій.
Session control: запис критичних сесій, алерти аномалій, заборона копіпасти при роботі з PII.
Break-glass: аварійний доступ з жорсткими лімітами і обов'язковим пост-аудитом.

8) Сервісні акаунти та API-скоупи

Мінімальні скоупи; поділ за завданнями/мікросервісами; короткоживучі токени/сертифікати.
Ротація секретів, заборона shared-секретів; заборона «god-scope».
Ліміти на rate/quotas, idempotency-ключі, підпис вебхуків (HMAC).

9) Сегментація на рівні інфраструктури

Мережі: ізоляція сегментів (per-domain/per-tenant), заборона egress за замовчуванням, mTLS.
Kubernetes/Cloud: неймспейси/проекти per-оточення і домен, Gatekeeper/OPA для заборони небезпечних шаблонів.
БД/Кеші: брокер доступу (DB proxy/IAM), read-only за замовчуванням, заборона DDL в проді поза вікном.
Сховища: різні ключі/бакети per-клас даних з політиками TTL і WORM для аудиту.

10) Політики як код (PaC)

Політики в репозиторіях (Rego/YAML), PR-рев'ю, авто-тести (unit/e2e), диф-аудит.
Динамічний контекст: час доби, локація, рівень KRI, ризик-скоринг операції.
Пояснюваність рішення allow/deny і посилання на політику в аудиті.

11) Журнали та аудит

Повнота: хто/що/де/коли/навіщо, перед/пост-значення, ID тікету.
Непідмінюваність: централізований збір, WORM/immutable, підпис записів.
Зв'язність: ланцюжок з адмін-консолі → API → БД → зовнішні провайдери.
SLA аудиту: швидкість відповіді на запити контролю/регулятора.

12) Дашборди та метрики (KPI/KRI)

KPI доступу: частка JIT vs постійних прав, середня тривалість привілею,% покритих SoD, час обробки заявок, покриття ресертифікацій.
KRI зловживань: сплески чутливих операцій, масові вивантаження, нетипові локації/години, послідовності «zayavka→deystviye→otkat».
Exec-дашборд: трек статусу високоризикових ролей, break-glass події, тренди.

13) Приклади політик (ескізи)

Prod-операції: `allow if role in {Operator, Admin} AND env=prod AND jit=true AND ticket!=null AND sod_ok AND time in ChangeWindow`.
Експорт PII: `allow if data_class=PII AND purpose in ApprovedPurposes AND ttl<=7d AND encryption=ON AND approvers>=2`.
PSP-роутинг: `allow if action=UpdateRouting AND dual_control AND risk_assessment_passed AND rollback_plan_attached`.

14) Дорожня карта впровадження (8-12 тижнів)

Нед. 1–2: інвентаризація операцій/ролей/даних, матриця SoD, класифікація даних і домени сегментації.
Нед. 3–4: RBAC-базис, каталог ролей, JIT для прод-консолей, старт PaC (OPA/Gatekeeper).
Нед. 5–6: ABAC: атрибути тенант/регіон/оточення/клас даних; поділ неймспейсів/проектів.
Нед. 7–8: PAM (JIT-elevation, запис сесій, break-glass), заборона DDL і брокер БД, політики експорту PII.
Нед. 9–10: PBAC для високоризикових операцій (висновки, бонуси, PSP), dual control, KRI-алерти.
Нед. 11–12: квартальна ресертифікація, покриття 100% high-risk операцій PaC, звітність і навчання.

15) Артефакти

Role Catalog: ролі, мінімальні привілеї, власники.
SoD Matrix: несумісні ролі/операції, винятки, процес override.
Policy Pack: набір PaC-політик з тестами і прикладами deny/allow.
Access Request Form: мета, термін, об'єкт (тенант/регіон/оточення), ризик-оцінка, аппрувери.
Sensitive Ops Register: перелік P1/P2 дій, вікна, критерії dual control.
Audit Playbook: збір і надання журналів, SLA відповіді, ролі.

16) Антипатерни

Постійні адмін-права та загальні обліки.
Крос-тенантні доступи «для зручності».
Відсутність ізоляції prod/stage/dev.
Політики на папері без enforce в коді/консолях.
Експорт PII за ручною домовленістю без шифрування і TTL.
Відсутність ресертифікацій і «завислі» права.

17) Підсумок

Сегментація привілеїв - це не просто «правильні ролі». Це багатовимірна ізоляція (тенант, регіон, оточення, дані, критичність) + динамічний контекст (ABAC/PBAC) + процеси (SoD, JIT, ресертифікація) + технічний примус (PaC, PAM, мережі/БД). Такий контур різко знижує ризик помилок і зловживань, прискорює безпечні зміни і робить платформу стійкою до вимог масштабу і регуляторів.