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

1) Цели IGA и зона ответственности

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

• Персонал: штат, подрядчики, временные.
• B2B/вендоры/аффилиаты: внешние пользователи/интеграции.
• Сервисные/бот-аккаунты: 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/юрисдикции/класс данных проверены
• Маскирование/ABAC включены
• Одобрения получены (владелец/безопасность)
• Записаны журналы и дата пересмотра

Ежеквартально

• 100% ре-сертификация ролей
• Авто-отзыв неиспользуемых прав
• Проверка B2B/вендорских учеток
• Ротация ключей сервисных аккаунтов

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-ядро→провиженинг, роли/права как код, JML с быстрым оффбордингом, SoD+ABAC, JIT/PAM для привилегий, ре-сертификации и строгий аудит. Итог — меньше рисков и затрат, быстрее доступы, выше комплаенс и прозрачность.