Рольове делегування та доступи

(Розділ: Операції та Управління)

1) Навіщо рольове делегування

Мета - дати кожному учаснику (співробітнику, партнеру, сервісу) рівно стільки прав, скільки потрібно і рівно на стільки часу, скільки необхідно, при повній трассируемости дій. Це знижує ризики витоків і зловживань, прискорює онбординг і прохід аудитів.

2) Модель доступу: рівні та домени

Домени доступу: люди (консоль/панелі), сервіси (машинні токени), дані (таблиці/об'єкти), інфраструктура (хмара/K8s), контрагенти (зовнішні інтеграції), регіони/тенанти.
Рівні довіри: публічний → внутрішній → захищений (PII/фінанси) → особливо критичний (ключі/виплати).
Зони операцій: prod / staging / sandbox; правило «з «нижче» в «вище» - тільки через затверджені pipeline'и».

3) Моделі авторизації

RBAC: ролі прив'язані до завдань («Контент-редактор», «Оператор виплат»). Простий старт, легко перевіряти.
ABAC: політики щодо атрибутів суб'єкта/ресурсу/контексту (регіон, тенант, зміна, пристрій, ризик-скоринг).
ReBAC (relationship-based): права випливають зі зв'язків (власник проекту, член команди).
Гібрид: RBAC для базової матриці, ABAC для контекстних обмежень, ReBAC для володіння.

4) Мінімально необхідний доступ (Least Privilege)

Старт - мінімальні ролі-за-замовчуванням (read-only, без PII).
Підвищення - тільки через заявку з обґрунтуванням, терміном і власником.
Ліміт часу (TTL): права «тануть» автоматично; продовження - усвідомлено.
Контекстні гвард-рейли: регіон/тенант, години роботи, пристрій, гео.

5) Поділ обов'язків (SoD)

• «Заводить ліміти» ≠ «затверджує ліміти».
• «Готує виплату» ≠ «підписує виплату».
• «Пише код» ≠ «релізує в prod».
• «Адмін БД» ≠ «читає PII в аналітиці».
• Реалізуйте SoD в політиках і в самих процесах (двопідпис, M-of-N).

6) JML-процеси (Joiner/Mover/Leaver)

Joiner: авто-призначення базових ролей за посадою/командою/регіоном, чек-лист доступів за 24ч.
Mover: перегляд ролей при зміні команди/проекту; автоматичне зняття «старих» прав.
Leaver: відгук сесій, ключів, токенів; перевипуск секретів, transfer володінь артефактами.

7) Тимчасові привілеї: JIT / PAM

Just-In-Time (JIT): підняття прав за заявкою на 15-240 хвилин з MFA та обґрунтуванням тікетом.
PAM (Privileged Access Management): проксі/вхід «під обліком-оболонкою», запис сесій, командний журнал.
Break-glass: аварійний доступ з миттєвим алертом, коротким TTL і обов'язковим пост-мортемом.

8) Ідентичності сервісів і ключі

Service Accounts: окремі для кожного сервісу і середовища, ніяких shared-секретів.
Workload Identity: прив'язка токенів до поду/виру/функції; короткоживучі креди.
Секрети: KMS/Vault, ротація, двоконтурне шифрування, заборона потрапляння в логи.
Ключі підписів/виплат: threshold/MPC, апаратні HSM, рознесення по доменах довіри.

9) SSO/MFA/SCIM і життєвий цикл акаунтів

SSO: IdP (SAML/OIDC), єдиний вхід, централізовані політики паролів/пристроїв.
MFA: обов'язкова для адмінів/фінансів/PII; переважно FIDO2.
SCIM: автоматичне створення/видалення/зміна акаунтів і груп.
Device Posture: умовний доступ за станом пристрою (шифрування диска, EDR, актуальні патчі).

10) Політики-як-код і верифікація

OPA/Authorization service: політики у вигляді коду (Rego/JSON), рев'ю через PR, тести.
Дрифт-контроль: регулярні порівняння «задекларовано vs фактично».
Pre-flight перевірки: «чи дозволить політика таку операцію?» - тестуйте кейси до релізу.

11) Доступ до даних

Класифікація: паблік/внутр/обмежений/PII/фінанси.
Тиск «мінімуму»: агрегати/маски замість «сирих» даних; запити PII - тільки через затверджені джоби.
Tokenization/DE-ID: заміна ідентифікаторів, аудит запитів.
Шари: прод → репліки → вітрини → агрегати; прямий доступ в прод-БД - тільки JIT/PAM.

12) Хмара, K8s, мережі

Cloud IAM: ролі per-аккаунт/проект; заборона «Admin» за замовчуванням; обмеження дій щодо тегів/папок.
Kubernetes: RBAC по неймспейсам, PSP/подібні політики без «privileged», образ-allowlist, секрети через CSI, сервісні акаунти per-под.
Мережа: Zero-Trust (mTLS, identity-aware), доступ до jump-host - тільки JIT, запис SSH-сесій.

13) Зовнішні партнери та інтеграції

Ізольовані тенанти/ключі, мінімум скоупів OAuth2, короткі TTL токенів.
Вебхуки: підпис (HMAC/EdDSA),'nonce + timestamp', вузьке вікно прийому.
Ротація ключів за розкладом, відгук при компрометації, статус-ендпоінти для «health».

14) Аудит, рецертифікація, звітність

Immutability: WORM-журнали, підписи релізів політик, Merkle-зрізи.
Рецертифікація: щоквартальна перевірка критичних ролей, щомісяця - адмін-прав.
Карантин прав: «невикористовувані 60 днів» → авто-зняття.
Evidence pack: вивантаження матриці ролей, SoD-спрацьовувань, JIT-заявок, запис PAM-сесій.

15) Метрики та SLO

TTG (Time-to-Grant): медіана видачі доступу за стандартною заявкою (мета ≤ 4ч).
Частка JIT-доступів серед «привілейованих» (мета ≥ 80%).
SoD-violations: 0 в prod, час усунення ≤ 24ч.
Орфанні права: % користувачів з надлишковими правами (мета → 0. 0x%).
Ротація секретів: середній вік секрету (мета ≤ 30 днів для чутливих).
Аудит-покриття: 100% привілейованих дій з артефактами (записи, квитанції).

16) Дашборди

Access Health: активні ролі, орфанні права, JIT vs постійні.
PAM & Sessions: число привілейованих сесій, тривалість, успішність MFA.
SoD & Incidents: статистика блокувань, причини, MTTR.
Secrets & Keys: вік, майбутня ротація, «червоні» ключі.
JML: SLA онбордингу/оффбордингу, прострочені заявки.
Audit Evidence: статус щоквартальної рецертифікації, completeness 100%.

17) Плейбуки інцидентів

Компрометація токена/ключа: негайний відгук, глобальний пошук використання, ротація залежностей, ретро-аудит за N днів.
Порушення SoD: блок операції, тимчасове відключення ролі, пост-мортем і зміна політики.
Неавторизований доступ до PII: ізоляція, повідомлення DPO, інвентаризація витоку, юридичні процедури.
Escalation abuse: заморожування JIT для суб'єкта/команди, аналіз заявок/обґрунтувань, коригування лімітів TTL.

18) Операційні практики

Чотири очі на видачу/зміну критичних прав.
Каталог ролей з описом завдань, ризиків і допустимих операцій.
Тестові оточення з анонімізованими даними та іншими ролями.
Policy dry-run: симуляція наслідків змін перед застосуванням.
GameDays за доступами: «втрата IdP», «відмова PAM», «витік секрету».

19) Чек-лист впровадження

• Сформувати таксономію ролей і матрицю SoD за ключовими процесами.
• Включити SSO + MFA для всіх, SCIM-потоки для JML.
• Розгорнути PAM/JIT, налаштувати break-glass з алертами і коротким TTL.
• Ввести політики-як-код (OPA), ревізії через PR і автотести.
• Окремі сервіс-акаунти та workload-identity; заборона shared-секретів.
• Vault/KMS, регулярна ротація секретів і ключів, заборона секретів в коді/логах.
• Розділити середовища і регіони, закріпити правила крос-регіональних доступів.
• Запустити дашборди і SLO, щомісячні звіти по рецертифікації.
• Провести SoD-скан графа прав і усунути шляхи ескалації.
• Регулярні навчання і пост-мортеми з action items.

20) FAQ

RBAC або ABAC?
RBAC - базовий шар читаності, ABAC - контекст і динаміка. Використовуйте гібрид.

Чи потрібен PAM, якщо є JIT?
Так: PAM дає запис сесій і керовані канали привілейованого доступу.

Як зменшити «залипання» прав?
TTL на ролі, авто-зняття невикористовуваних, щомісячна рецертифікація і SoD-алерти.

Що робити з зовнішніми підрядниками?
Виділені тенанти/групи, обмежені скоупи, короткі TTL, обов'язкові звіти і рецертифікація.

Резюме: Рольове делегування і доступи - це не «набір галочок», а життєвий цикл прав: мінімально необхідні ролі, SoD, JIT/PAM, політики-як-код, спостережуваність і регулярна рецертифікація. Такий контур дає швидку роботу командам і передбачувану безпеку для бізнесу і аудиту.