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 и офлайн-сценариев, с жесткими ограничениями и периодической проверкой.

Как сократить «взрыв ролей»?
Поднять гранулярность ресурсов, использовать ABAC/шаблоны, автоматизировать ревью и отказываться от неиспользуемых ролей.

Итог

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