Управління ідентичностями

1) Цілі IGA і зона відповідальності

IGA - управляє хто має який доступ, чому, на скільки і як це довести.
Цілі: мінімальні права (Least Privilege), відсутність «осиротілих» доступів, контроль SoD, регуляторна доказовість (GDPR/ISO/AML/PCI при застосовності), швидке надання/відкликання прав.

• Персонал: штат, підрядники, тимчасові.
• В2В/вендори/афіліати: зовнішні користувачі/інтеграції.
• Сервісні/бот-акаунти: API/інтеграції, машини.
• Високий ризик: адміни, платежі, AML/KYC, DPO, DevOps/SRE.
• (Опц.) CIAM: гравці - в окремій системі; в IGA фіксуються інтеграційні ролі і межі.

2) Архітектура і джерела істини

Authoritative source: HRIS/кадрова система (для персоналу) + реєстр вендорів (для зовнішніх).
IdP/SSO: OIDC/SAML, групи ↔ ролі (SCIM-провиженінг).
IGA-ядро: каталог ролей/прав (entitlement catalog), SoD-правила, workflow заявок, кампанії ре-сертифікації, звіти.
Провиженінг: конектори до цільових систем (адмін-панелі, DWH/BI, KYC/AML, PSP, Git/CI, Jira/Confluence, хмара, K8s).
Identity Warehouse/метадиректорія: агрегація атрибутів (департамент, роль, регіон, рівень довіри, тип співробітника).
PAM/JIT: для привілейованих сесій і короткострокових підвищень.

3) JML - життєвий цикл ідентичності

Joiner (онбординг)

Створення облікового запису з HRIS → призначення birthright-ролей (SSO, пошта, базові тулзи).
Доменні ролі по позиції/команді/локації/тенанту; первинний SoD-чек.
MFA/WebAuthn, менеджер паролів, навчання.

Mover (переміщення)

Автоматична ревізія прав при зміні посади/проекту/локації; зняття старих ролей (no accumulation).
Переоцінка SoD, оновлення ABAC-атрибутів (регіон/тенант), JIT-шаблони.

Leaver (оффбординг)

Блокування SSO ≤ 15 хв, відгук токенів/API-ключів, закриття сесій, відкликання доступу до DWH/адмінок, переклад володіння артефактами, видалення/архів з політики.

4) Каталог прав і модель ролей

Entitlement Catalog: нормалізовані права (CRUD/операції/експорти/адмін), власник, ризик-рівень, система, SoD-конфлікти, маскування PII за замовчуванням.

• Core: `employee_basic`, `viewer_internal`.
• Доменні: `payments_ops`, `aml_officer`, `kyc_operator`, `fraud_analyst`, `vip_manager`, `bi_analyst`.
• Системні: `devops_admin`, `dba_admin`, `read_only_prod`.
• Привілейовані (JIT/PAM): `prod_db_jit_editor`, `break_glass_admin`.
• Ролі як код: YAML/JSON в репозиторії + CI-валідатори + CAB-чейнджлог.

yaml role: payments_ops@EEA description: "EEA payment transactions"
entitlements:
- FIN:APPROVE_WITHDRAWAL
- FIN:VIEW_TX_MASKED constraints:
region: EEA data_class: <= Confidential sod_conflicts:
- FRAUD:RULE_ADMIN masking: default owner: head_of_payments

5) Запити доступу та схвалення (workflow)

IDM/ITSM-портал: заявка з'purpose', терміном (TTL), системами/ролями.

• Низький ризик: авто-схвалення власником домену.
• Високий ризик/PII/гроші: власник + Security/Compliance (+ DPO при PII unmask).
• JIT для підвищень прав (15-120 хв), автоматичний відгук, повний запис сесії (PAM).
• SoD-чек синхронно, блокує конфліктні комбінації.

6) SoD і ABAC в IGA

SoD-правила: несумісні пари ролей/прав (напр.,'payments _ ops'↔'fraud _ rule _ admin').
ABAC-атрибути: середовище (prod/stage), регіон/тенант, пристрій (MDM), час/зміна, ризик пристрою, рівень KYC,'purpose'.
Політики демаскування: 'pii _ unmask'тільки JIT + підтвердження + аудит полів.

7) Ре-сертифікація та кампанії

Щоквартальні огляди: власники підтверджують доступи співробітників/вендорів.
Подієві кампанії: при реорганізації, зміні власника системи, виведенні продукту.
Авто-відгук «висячих» прав (невикористувалися> 30/60 днів).

8) Вендори та зовнішні ідентичності (B2B)

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

9) Сервісні/бот-акаунти та секрети

Реєстрація в IGA з власником/метою/терміном, no-login; аутентифікація по mTLS/OIDC client-creds/підписані вебхуки.
Ключі в секрет-менеджері; ротація за розкладом/подією; журнал викликів.

10) Журнали, аудит і звітність

Обов'язкові події: `ACCOUNT_PROVISION/DEPROVISION`, `ROLE_ASSIGN/REVOKE/UPDATE`, `ACCESS_REQUEST/APPROVE/DENY`, `JIT_GRANT`, `BREAK_GLASS`, `SOD_BLOCK`, `RECERT_START/END`, `EXPORT_DATA`, `PII_UNMASK`.

WORM-копія, хеш-ланцюжки, підпис пакетів,'ts _ utc '/' trace _ id '/' actor _ id '/' purpose'.
Звіти: покриття ре-сертифікацією, SoD-порушення, orphaned-доступи, SLA JML, JIT-статистика.

11) Метрики (KPI/KRI)

Time-to-Provision (Joiner): медіана ≤ 2 год (ключові системи).
Time-to-Deprovision (Leaver): ≤ 15 хв (SSO/критичні), ≤ 4 год (другорядні).
SoD Violations: = 0 (спроби - авто-блок).
Recertification Completion: 100% вчасно.
Orphaned Accounts: = 0; Dormant Access Cleanup ≥ 98%/24 ч.
JIT Rate: ≥ 80% підвищень прав - JIT.
Masked Reads Ratio: ≥ 95% звернень до PII - масковані.

12) SOP (процедури)

12. 1 Створення ролі/зміна каталогу прав

1. Запит власника домену → формалізація завдань → мапінг на entitlements → SoD-чек → пілот → CAB → реліз (YAML) → оголошення.

12. 2 Запит доступу

1. Заявка з'purpose '/TTL → SoD/ABAC-чек → маршрут схвалень → видача (часто masked-read) → логування → дата перегляду.

12. 3 Оффбординг

1. Подія з HRIS/порталу → блок SSO/сесій → відгук груп/ролей/ключів → перенесення володінь → звіт.

12. 4 Ре-сертифікація

1. Запуск кампанії → нагадування → ескалація прострочення → авто-відгук непідтверджених прав → звіт.

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

13. 1 Birthright и SoD

yaml birthright:
roles:
- employee_basic
- viewer_internal sod:
conflicts:
- [payments_ops, fraud_rule_admin]
- [kyc_operator, support_agent]

13. 2 Правила JIT

yaml jit:
roles:
- prod_db_jit_editor
- pii_unmasker ttl_minutes: 30 approvals:
- owner
- security session_recording: required

13. 3 Кампанія ре-сертифікації

yaml recertification:
frequency: quarterly scope: [payments_ops, aml_officer, devops_admin]
auto_revoke_unused_days: 60

14) Безпека та відповідність

GDPR/Privacy: Need-to-Know, маскування, DSAR-сумісність, аудит PII.
AML/KYC: ролі тільки для навчених; журнал рішень, ретеншн логів.
ISO/ISMS: політика IGA обов'язкова; щорічні аудити, тест-навчання.
PCI (якщо застосовується): сегрегація платіжної зони; окремі ключі та хостинг.

15) Інциденти IGA (швидкий playbook)

Виявлено доступ без'purpose '/SoD-порушення → блокування ролі/обліки, відкриття інциденту, ретро-аудит дій, повідомлення DPO/Compliance, CAPA (правки ролей/політик/навчання).
Компрометація облікового запису → відгук сесій/токенів, зміна секретів, аналіз журналів, повідомлення при необхідності.

16) Чек-листи

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

• Вказані'purpose'і TTL
• SoD/юрисдикції/клас даних перевірені
• Маскування/АВАС включені
• Схвалення отримані (власник/безпека)
• Записані журнали і дата перегляду

Щоквартально

• 100% ре-сертифікація ролей
• Авто-відгук невикористовуваних прав
• Перевірка В2В/вендорських обліків
• Ротація ключів сервісних акаунтів

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

Тижні 1-2: інвентаризація систем, підключення HRIS/IdP, базові birthright-ролі, каталог прав, SoD-матриця.
Тижні 3-4: SCIM-провиженінг, портал заявок, JIT/PAM, YAML-репозиторій ролей, перші кампанії ре-сертифікації.
Місяць 2: розширення конекторів (KYC/AML/PSP/DWH), ABAC-атрибути (регіон/MDM/час), звітність і KRIs.
Місяць 3 +: автоматизація SoD-аналізів, role mining/рекоммендації, UEBA-сигнали, регулярні навчання та аудит вендорів.

TL; DR

Ефективне IGA = HRIS→IdP→IGA - yadro→provizhening, ролі/права як код, JML з швидким оффбордингом, SoD + ABAC, JIT/PAM для привілеїв, ре-сертифікації і строгий аудит. Підсумок - менше ризиків і витрат, швидше доступи, вище комплаєнс і прозорість.