Identity & Access Management

Коротке резюме

IAM - це сукупність процесів, політик та інструментів, які забезпечують хто отримує доступ до чого, на яких умовах і як це контролюється. Цілі: мінімізація надлишкових прав, зниження поверхні атаки, прискорення онбордингу і аудиту, відповідність вимогам (PCI DSS, GDPR тощо) і вимірна надійність доступу.

Базові поняття

Ідентичність (Identity): людина (співробітник, підрядник), сервіс/додаток, пристрій.
Автентифікація (AuthN): перевірка «хто» (пароль → MFA → безпарольні схеми FIDO2/passkeys).
Авторизація (AuthZ): рішення «що дозволено» (RBAC/ABAC/ReBAC, політики).
Облікові дані (Credentials): паролі, ключі, токени, сертифікати (mTLS).
Секрет-менеджмент: KMS/HSM/Vault, ротації, короткі TTL, динамічні секрети.
Життєвий цикл: Joiner-Mover-Leaver (JML) - створення, зміна ролей, відгук.

Цільова архітектура IAM

Площини і ролі:

IdP (провайдер ідентичності): SSO, MFA, каталог, федерація (OIDC/SAML), політики ризику.
PDP/PEP: Decision/Enforcement - рушій політик (OPA/Cedar) + точки застосування (API-шлюзи, проксі, сервіс-меш).
Каталоги/HR-система: джерело правди по співробітниках і ролях.
Провіжінінг: SCIM/Automation для створення/зміни/відкликання доступів.
Аудит: централізовані логи, UEBA, звіти по ролях і доступах.

Потік доступу (user→app):

SSO (+ MFA) → випуск токена (OIDC/JWT/SAML) → PEP перевіряє токен/контекст → PDP вирішує по політиці (роль/атрибути/ризик) → додаток видає/відмовляє доступ.

Автентифікація: від паролів до passkeys

Паролі: тільки з менеджерами паролів, мінімум 12-14 символів, без ротації «за календарем», але з обов'язковою при інциденті.
За замовчуванням MFA: TOTP/WebAuthn/Push; уникати SMS як основного фактора.
Безпарольний вхід: FIDO2/passkeys для критичних доменів.
Адаптивна AuthN: враховуйте сигнал ризику (гео, ASN, пристрій, аномалії) → вимагати додатковий фактор/блокувати.

Авторизація: RBAC, ABAC, ReBAC

RBAC: ролі, що відповідають функціям (Support, Finance, DevOps). Проста і зрозуміла, але «розростається».
ABAC: правила по атрибутах (відділ, рівень ризику, час, зона, мітки ресурсів). Масштабовано.
ReBAC: ставлення «хто до чого відноситься» (власники проектів, учасники команд). Зручно для багатотенантних сценаріїв.

Кращі практики:

Комбінувати RBAC (базова сітка) + ABAC/ReBAC (контекст/межі).
JIT (Just-In-Time): видача тимчасових привілеїв через запит/апрув, автоматичний відгук.
JEA (Just-Enough Access): мінімально достатні права на операцію.
PAM: ізольовані «сильні» доступи (адміни БД/хмари) з брокером сесій, записом екрану/команд і видачею короткоживучих кредів.

Федерація та SSO

Протоколи: OIDC (JWT-токени), SAML 2. 0 (XML assertions) - для зовнішніх провайдерів/партнерів.
SSO: єдина точка входу з MFA, зниження фішингу, централізований відгук.
B2B/B2C: федерація з партнерами, обмеження областей, доменні політики.
mTLS/m2m: для сервісів використовуйте короткоживучі x.509 (SPIFFE/SVID) або OAuth2 Client Credentials.

Життєвий цикл (JML) і провіжінінг

Joiner: автоматичний SCIM-провіжінінг обліків і базових ролей з HR/каталогу.
Mover: ролі змінюються автоматично за атрибутами (підрозділ, проект, локація).
Leaver: негайний відгук SSO, ключів, токенів, доступів до репозиторіїв/хмар/CI/CD.
Процеси: заявки на доступ (ITSM), матриця SoD (поділ обов'язків), періодичні access review.

Секрети, ключі та ротації

KMS/HSM: зберігайте кореневі/критичні ключі, включайте аудит операцій.
Vault/Secrets-менеджери: динамічні креди (БД, хмари), авто-ревок при завершенні TTL.
Ротації: токени OAuth, ключі підпису JWT, паролі служб - за розкладом і при інцидентах.
mTLS: короткоживучі сертифікати (години/дні), автоматичний перевипуск.

Політики і рушій рішень

Декларативність: зберігайте політики в Git; перевіряйте в CI (policy-tests).
Контекст: час/локація/ASN/рівень ризику/стан пристрою (MDM/EDR).

Приклад (Rego, спрощено):

rego package authz. payments default allow = false

allow {
input. user. role == "finance"
input. device. compliant == true input. action == "read"
input. resource. type == "report"
time. now_hh >= 8 time. now_hh <= 20
}

Моніторинг, SLO та аудит

Метрики:

Успішність AuthN/AuthZ (%), p95 часу логіна/рішення, частка MFA/безпарольних входів.
Кількість ескалацій JIT/PAM, середня тривалість привілеїв.
Покриття compliant-пристроїв, частка короткоживучих секретів.

SLO (приклади):

Доступність SSO/IdP ≥ 99. 95% на місяць.
p95 AuthZ decision ≤ 50 мс.
100% відключення облікового запису ≤ 15 хвилин після offboarding.
Аудит та UEBA: централізовані незмінні логи (доступи, зміни ролей, невдалі входи, рішення PDP), поведінкова аналітика і тривоги за аномаліями.

Інцидент-респонс в IAM

Компрометація токенів/ключів: негайний відгук, примусовий logout, ротація ключів підпису, re-issue короткоживучих секретів.
Зловживання правами: призупинити обліковий запис, заблокувати JIT/JEA, провести access review по сусідніх сутностях.
IdP недоступний: офлайн-режими (тимчасова кеш-валідація токенів з коротким TTL), пріоритетні процедури відновлення.
Фішинг: обов'язкова MFA, ризик-перевірки сесій, повідомлення користувачам, навчання.

Хмари і Kubernetes (патерни)

Public Cloud IAM: використовуйте нативні ролі з принципом least privilege; замість «вічних» ключів - робочі навантаження з OIDC-федерацією до хмари (IRSA/Workload Identity).
Kubernetes: RBAC по неймспейсам/ролям, обмежити'cluster-admin'; секрети - через зовнішні менеджери; сервіс-меш + OPA для L7-політик; Admission-контролери (підписані образи, заборона ":latest»).
API-шлюзи: перевірка JWT/mTLS, обмеження швидкостей, підписи запитів (HMAC) для чутливих ендпоінтів.

Практика для iGaming/фінтех

Домени доступу: платежі, антифрод, PII, контент-провайдери - ізолювати ролями і мережевими сегментами.
SoD: заборона поєднання конфліктуючих ролей (наприклад, створення промо + затвердження виплат).
PAM и JIT: для доступу до PSP/банків і прод-БД - тільки через брокера сесій, із записом і авто-відгуком.
Комплаєнс: PCI DSS - MFA, мінімальні привілеї, сегментація CHD-зони; GDPR - принцип мінімізації даних і точкові логи доступу до PII.
Партнери та провайдери контенту: федерація та per-tenant політики; короткоживучі токени та IP/ASN allow-list.

Типові помилки

«Вічні» ключі та токени: відсутні ротації і TTL → високий ризик витоків.
Ручний offboarding: затримки у відкликанні прав → «примарні» доступи.
Ролі-моноліти: одна «супер-роль» замість композиції та атрибутів.
MFA тільки в адмінці: MFA має бути для всіх входів і критичних операцій.
Логи «в нікуди»: відсутня централізація і UEBA → пізніше виявлення інцидентів.

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

1. Інвентаризація користувачів/сервісів/ресурсів; карта даних і чутливості.
2. SSO + MFA для всіх, включити phishing-resistant фактори.
3. Модель ролей: базове RBAC + атрибути (ABAC) для контексту; матриця SoD.
4. Провіжінінг SCIM: автосоздание/зміна/відкликання прав з HR/каталогу; заявки та апрути в ITSM.
5. PAM и JIT/JEA: для привілейованих доступів; запис сесій, короткі TTL.
6. Секрет-менеджмент: відмова від статичних ключів; динамічні секрети, ротації, mTLS з короткими сертифікатами.
7. Політики в Git + CI: тести правил, контроль змін, канарські розгортання політик.
8. Спостережуваність і SLO: дашборди AuthN/AuthZ, алерти, регулярні access review.

Приклади артефактів

AWS IAM Policy (мінімум на читання звітів S3)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ReadOnlyReports",
"Effect": "Allow",
"Action": ["s3:GetObject","s3:ListBucket"],
"Resource": [
"arn:aws:s3:::reports-bucket",
"arn:aws:s3:::reports-bucket/"
],
"Condition": {
"IpAddress": { "aws:SourceIp": "203. 0. 113. 0/24" }
}
}]
}

Kubernetes RBAC (namespace-scoped розробник)

yaml apiVersion: rbac. authorization. k8s. io/v1 kind: Role metadata:
name: dev-read-write namespace: app-prod rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments","services","configmaps"]
verbs: ["get","list","watch","create","update","patch","delete"]
apiVersion: rbac. authorization. k8s. io/v1 kind: RoleBinding metadata:
name: dev-bind namespace: app-prod subjects:
- kind: User name: alice@example. com roleRef:
kind: Role name: dev-read-write apiGroup: rbac. authorization. k8s. io

OIDC: твердження для ABAC (приклад)

json
{
"sub": "d81f0b5c-...",
"email": "bob@example. com",
"dept": "finance",
"role": "analyst",
"device_compliant": true,
"tenant": "casino-eu"
}

Політика може вимагати'device _ compliant = true'і'tenant'збігається з ресурсом.

Контрольний список (check-list)

SSO включений для всіх додатків; MFA за замовчуванням, passkeys в пріоритеті.
RBAC визначений; ABAC/ReBAC додають контекст; реалізовані JIT/JEA.
PAM захищає привілейовані доступи; ведеться запис сесій.
SCIM-провіжінінг від HR; offboarding повністю автоматизований.
Секрети динамічні, з коротким TTL; ротації автоматизовані.
Політики версіонуються в Git, тестуються в CI; є канарні викладки.
Дашборди і SLO по AuthN/AuthZ; централізовані логи і UEBA.
Періодичні access review і SoD-перевірки; звіти для комплаєнсу.

FAQ

Чи потрібен ReBAC всім?
Ні, ні. Для простих середовищ достатньо RBAC + ABAC. ReBAC корисний при складній ієрархії володіння ресурсами і багатотенантності.

Чи можна залишити локальні обліки?
Тільки для break-glass і офлайн-сценаріїв, з жорсткими обмеженнями і періодичною перевіркою.

Як скоротити «вибух ролей»?
Підняти гранулярність ресурсів, використовувати АВАС/шаблони, автоматизувати рев'ю і відмовлятися від невикористовуваних ролей.

Підсумок

Зріла IAM-архітектура - це SSO + MFA, мінімально необхідні права, автоматизований JML, централізовані політики і спостережуваність. Комбінуючи RBAC з атрибутними і реляційними моделями, застосовуючи JIT/JEA і PAM, а також автоматизуючи провіжінінг і ротації секретів, ви отримуєте керований, перевіряється і масштабований доступ, що відповідає вимогам безпеки і бізнесу.