Access Control & IAM

В сентябре 2022 атакующий вошёл во внутреннюю сеть Uber через MFA fatigue: заваливал подрядчика запросами на подтверждение входа, пока тот не нажал «approve». Дальше началась обычная прогулка по корпоративной сети. В ней нашёлся скрипт на PowerShell с захардкоженными учётными данными администратора для системы Privileged Access Management, а через PAM открылось сразу всё — AWS, GCP, Slack admin, HackerOne. Один обход MFA — и всё.

Это не история про «MFA не работает». Это история про пустой второй рубеж: после первичной компрометации модель доступа обязана была сузить blast radius, а не выдать ключи от всего. Грамотный IAM строится ровно против такого сценария — устойчивый к фишингу MFA (FIDO2/WebAuthn) на критичных доступах, наименьшие привилегии с регулярным access review, повышение прав по запросу и на время (JIT) вместо постоянных прав администратора, явное разделение human identity и workload identity. IAM — не «список пользователей», а операционная дисциплина: модель, контроль её дрейфа, мониторинг аномального доступа, повторяемая процедура break-glass.

Что должен уметь

Главный навык на уровне L5 — спроектировать модель IAM под конкретный профиль угроз, а не «как у всех». RBAC хорошо работает для команды в 20 человек с пятью ролями; ломается на 500 человек с пересечениями (аналитик данных плюс дежурство плюс согласование расходов). ABAC вывозит масштаб, но требует дисциплины с атрибутами: откуда они берутся и кто их проверяет. Модель в духе Zanzibar красива для multi-tenant SaaS, где пользователи сами раздают доступ друг другу. Выбор не доктринёрский — производный от модели угроз и операционных ограничений команды.

Различает аутентификацию (кто это) и авторизацию (что разрешено); знает базовые потоки OAuth 2.0 / OIDC / SAML на уровне «что куда передаётся».
Использует MFA для своей учётной записи; понимает разницу между TOTP, push и устойчивым к фишингу фактором (FIDO2/WebAuthn).

Применяет принцип наименьших привилегий — запрашивает минимальный нужный набор прав, повышение только по необходимости, а не «попроси у админа прав на всё, потом разберёмся».
Настраивает RBAC в Kubernetes и облачном IAM для своего сервиса: явные роли, явные привязки, никаких * в правах на production.
Внедряет SSO через корпоративный IdP для всех прикладных сервисов; локальные учётные записи — исключение с задокументированным основанием.

Проектирует модель IAM для команды или организации: RBAC, ABAC или гибрид, состав ролей, владение ролями, жизненный цикл (выдача при найме, отзыв при уходе или смене роли).
Внедряет доступ по запросу и на время (JIT) для привилегированных операций — повышение прав через процедуру согласования (Teleport, StrongDM, session policies в AWS IAM Identity Center); постоянные права администратора остаются только у break-glass.
Координирует ежеквартальный access review — владелец группы подтверждает или отзывает доступ участников; осиротевшие права (ушедшие люди, смена роли) вычищаются. Без регулярного ритма privilege creep набегает гарантированно.
Внедряет устойчивый к фишингу MFA (FIDO2/WebAuthn, аппаратные ключи) для административного доступа и доступа в production; TOTP и SMS — для низкорисковых операций, не для критичных.

L6+

Проектирует стратегию на уровне организации: федерация identity купленных компаний, архитектура с несколькими IdP (сотрудники, подрядчики, клиенты), политика break-glass, ритм аудита, интеграция с HRIS для автоматической выдачи и отзыва доступов.
Взвешивает компромиссы: централизованный IAM (один IdP, всё под ним) против федеративного (несколько IdP с доверием между ними), единая модель против доменной, собственная разработка против покупки для fine-grained authorization в духе Zanzibar.

Материалы

Книги

Lee Brotherston, Amanda Berlin — Defensive Security Handbook (O’Reilly, 2-е изд., 2024). Главы про IAM, MFA и боковое перемещение атакующего — практическое руководство для небольшой команды безопасности, без академической нагрузки.
Heather Adkins et al. — Building Secure and Reliable Systems (O’Reilly, 2020), главы 5 (Identity), 6 (Authorization), 8 (Access). Взгляд Google на zero-trust, workload identity и BeyondCorp.

Статьи и доклады

Google — Zanzibar: Google’s Consistent, Global Authorization System (USENIX ATC 2019). Основополагающая работа для модели ReBAC; на Zanzibar живут проверки доступа в Drive, Calendar, Cloud, Maps, Photos и YouTube — то есть модель проверена на масштабе, который вам почти наверняка не понадобится. Понимать обязательно, если строите multi-tenant SaaS, где доступ раздают сами пользователи.
Google — BeyondCorp: A New Approach to Enterprise Security (серия статей 2014–2018). Каноническая реализация zero-trust; убрали VPN и заменили его решением на каждый запрос, которое учитывает пользователя, устройство и контекст.
Uber’s official statement (сентябрь 2022). Главный кейс про MFA fatigue → lateral movement; официальная версия короткая, детали механики разошлись по разборам в отраслевой прессе.
Microsoft — Analysis of Storm-0558 techniques for unauthorized email access (июль 2023). Компрометация ключа подписи и подделка токенов доступа на нём. Иллюстрация того, что скомпрометировать можно и саму криптографию, на которой держится identity. Разбор своего же провала от самой Microsoft — читать вместе с их сентябрьским отчётом о том, как ключ вообще утёк.
Twitter — An update on our security incident (инцидент 15 июля 2020, отчёт от 30 июля). Телефонный фишинг сотрудников и админские инструменты: никаких эксплоитов, только дырявая модель доступа и отсутствие MFA на административных действиях. 130 атакованных аккаунтов, 45 из которых успели написать твиты.
Серия краж данных у клиентов Snowflake (июнь 2024). Атакующие заходили в клиентские аккаунты, где не был включён MFA, — иллюстрация того, что облачный провайдер не отвечает за гигиену доступов на стороне клиента, а обязанность включить второй фактор лежит на том, кто заводит аккаунт.

Стандарты

NIST SP 800-63B — Digital Identity Guidelines, Authentication. Канонический документ про уровни AAL, требования к паролям и к MFA. Стандарт правительства США, индустрия берёт его за базовый уровень.
OAuth 2.0 (RFC 6749) + OIDC Core spec. Канонические спецификации федерации. PKCE (RFC 7636) обязателен для публичных клиентов.

Инструменты

Cloud IAM: AWS IAM + IAM Identity Center (бывший AWS SSO), GCP IAM + Cloud Identity, Microsoft Entra ID (бывший Azure AD). Здесь не выбирают — берут то, что даёт облако.
Identity Providers (workforce): Okta (доминирует в enterprise), Microsoft Entra ID, JumpCloud, OneLogin. По моим наблюдениям, в компаниях до 200 человек чаще берут JumpCloud или identity от Google Workspace; дальше стандартом становится Okta.
Open-source IdP: Keycloak (Red Hat, старая школа), Authentik (на Python, поновее), ZITADEL (на Go, multi-tenant). Берут, когда нужен self-hosted или встроенная аутентификация клиентов.
Fine-grained authorization (Zanzibar-style): AuthZed/SpiceDB, OpenFGA (CNCF, выросла из реализации Zanzibar в Auth0), Permify, Topaz. Нужны там, где RBAC и ABAC не покрывают доступ через связи между объектами: шаринг, иерархии.
AuthZ libraries / PDP: Cerbos, Casbin, Open Policy Agent (общий движок политик, чаще для admission control в Kubernetes). Авторизация на OPA — частый выбор в командах, которые живут в Kubernetes.
PAM / JIT access: Teleport, StrongDM, HashiCorp Boundary, CyberArk (enterprise). По моим наблюдениям, в cloud-native командах Teleport чаще, чем CyberArk; CyberArk доминирует там, где осталась старая инфраструктура: Windows AD, базы на своём железе.
MFA, устойчивый к фишингу: YubiKey (аппаратный FIDO2/WebAuthn), Google Titan, встроенные в платформу аутентификаторы (Touch ID, Windows Hello). Программный FIDO2 (passkeys) хорош для массового пользователя, сотрудникам чаще выдают железные ключи.
HRIS integration / SCIM: интеграция Okta / Entra ID с HRIS (BambooHR / Workday / Rippling) через SCIM даёт автоматическую выдачу и отзыв доступов. Выдача руками через год начинает копить осиротевшие учётные записи.

Best practices

Главный публичный кейс — Uber 2022 (см. начало листа). Проход вглубь сети через учётные данные PAM, забытые в скрипте, — это провал IAM, а не провал MFA. Урок отсюда простой. Первичная компрометация случится: вопрос не «если», а «когда», — и в этот момент модель доступа либо сжимает атакующего в узкий сектор, либо открывает ему всю организацию. Защита в глубину применительно к IAM выглядит так: устойчивый к фишингу MFA, узко нарезанные роли, повышение прав на время вместо постоянного администратора, сегментация сети как последний рубеж. Когда MFA — единственная линия, всё за ней лежит нараспашку.

Три вещи из этого списка окупаются раньше остального. Первая — устойчивый к фишингу MFA на административных доступах и на доступах в production. FIDO2/WebAuthn (аппаратные ключи, встроенные аутентификаторы) — единственная форма второго фактора, которую нельзя выудить фишингом: криптографическая привязка к домену не даёт вклиниться посреднику. TOTP так не умеет, SMS пробивается через SIM swap. Для низкорисковых операций TOTP нормален. Для админа — нет.

Вторая — повышение прав по запросу и на срок вместо постоянного администратора. Постоянный админ — это одновременно вечная цель для атакующего и вечный источник случайных ошибок. Механика: заявка через approval workflow (Teleport, StrongDM, session policies в AWS IAM Identity Center), права на час, запись в audit log на каждое использование, подтверждающий — отдельный человек, не сам заявитель. Break-glass account живёт как исключение, и каждое его использование подсвечивается мониторингом.

Третья — квартальный access review. Без регулярного ритма privilege creep набегает гарантированно: владелец каждой группы подтверждает или отзывает участников, ушедшие сотрудники вычищаются по фиду из HRIS, смена роли запускает пересмотр доступов. SOC 2 CC6.3 требует этого прямым текстом. Но дело не в аудиторе. Это операционная гигиена.

RBAC, ABAC или ReBAC — выбор по угрозам и масштабу, не по доктрине. В команде 20 человек с пятью ролями RBAC простой, понятный и проверяемый на аудите. От 200 человек он начинает разваливаться: роли плодятся под каждую комбинацию прав, права протекают через вложенные группы, и на вопрос «почему у пользователя X доступ к ресурсу Y» ответить уже нечем. ABAC вывозит масштаб через атрибуты (подразделение, уровень допуска, проект), но требует дисциплины с ними: откуда атрибут берётся, кто его проверяет, что происходит, когда он протух. ReBAC (Zanzibar) ложится на multi-tenant SaaS, где доступ раздают сами пользователи («у X есть доступ к документу Y, потому что владелец документа его туда добавил»), и стоит отдельной базы разрешений. Я регулярно вижу команды, которые переусложняют модель авторизации в первый год, — RBAC хватило бы ещё на пару лет. И вижу обратное: в 300 человек всё ещё RBAC, и команда тонет в аудите ролей, потому что менять собирались «потом, когда будет нужно».

Service identity ≠ human identity. Это два разных домена IAM. Учётные записи людей требуют MFA, SSO, ротации пароля, регулярного access review. Сервисные (CI/CD, вызовы между приложениями, задачи по расписанию) живут иначе: workload identity, федерация через OIDC, mTLS, короткоживущие учётные данные (см. Workload Identity — отдельный лист). Смешивать опасно: долгоживущий пароль сервисной учётки в IdP означает, что атакующему достаточно выудить фишингом человека, чтобы получить права сервиса. У них разный жизненный цикл, разная политика ротации, разный мониторинг аномалий.

Break-glass policy — отрепетирована, не «runbook есть». IdP лёг, у Okta авария, администратор уволился без передачи дел — во всех трёх случаях остаётся ровно один путь вернуть себе доступ. Break-glass выглядит так: аппаратный ключ в физическом сейфе у CISO или CTO, пароль отдельно в запечатанном конверте, мониторинг на каждое использование с вызовом команды безопасности. Раз в полгода — game day: симулируем отказ IdP и смотрим, за сколько команда вернёт себе доступ к критичной системе, не подглядывая в чат с теми, кто уже уволился. Без репетиции это идея в Confluence, а не процедура.

SSO для всего, исключения — задокументированы. Каждая локальная учётная запись, заведённая прямо в приложении в обход SSO, — тёмный угол. Аудит SOC 2 или ISO 27001 его найдёт. Но настоящая причина держаться SSO не в аудите, а в offboarding: уволили человека, отозвали в IdP — и доступ во все двести SaaS пропал одним движением. Без SSO на этом месте чеклист из двухсот пунктов, который целиком не выполняется никогда.

Связанные листья

Secrets Management — IAM решает «кто», secrets решают «чем»; вместе — единая модель authentication + authorization для humans и workloads.
Workload Identity — identity для вызовов между сервисами без общих секретов; частный случай IAM для нечеловеческих субъектов.
Threat Modeling — IAM как часть границ доверия; категория elevation of privilege в STRIDE — основной источник требований к IAM.
Vulnerability Management — IAM сам по себе — поверхность уязвимостей (лишние права, осиротевшие учётки); сканеры давно умеют искать ошибки в его конфигурации.
Compliance Frameworks — SOC 2 CC6.x — большой блок про контроль доступа; реализация IAM ложится на конкретные пункты.
Service Ownership — владелец сервиса — он же владелец политики доступа к нему; access review идёт по сервисам.
Incident Response — утёкшие учётные данные запускают playbook по IAM: отозвать, ротировать, поднять логи доступа, проверить, куда атакующий успел уйти вбок.

Открытые вопросы

Customer IAM (CIAM) — соседний домен с совсем другими ограничениями: десятки миллионов пользователей, вход через соцсети, восстановление аккаунта как продуктовая задача, другой набор инструментов (Auth0, Cognito, Stytch). Отдельный лист напрашивается, но не в первую очередь. Туда же просится Privileged Access Management: у Teleport, StrongDM и CyberArk хватает глубины на самостоятельный текст, пока всё это живёт внутри абзаца про JIT здесь.

Федерация workload identity в multi-cloud частично закроется в Workload Identity, но нюансы вроде cross-cloud trust и проверки OIDC issuer туда пока не помещаются. Отдельно интересна объяснимость доступа — вопрос «почему пользователь X получил доступ к ресурсу Y» в разросшейся модели. Платформы ReBAC на него отвечают, в RBAC и ABAC ответ приходится собирать руками.

Я не уверен, что есть хорошая публичная модель для «когда переходить с RBAC на ABAC/ReBAC». Обычно решение принимают по боли — аудит стал невозможен, модель шаринга не помещается, — а не заранее по проекту. Если у вас был такой переход, был бы интересен опыт PR’ом.