Identity and Access Management (IAM) — это не просто «форма входа» в приложение, а фундамент безопасности. Без нее любая IT-система — как офисное здание, где по обычному пропуску можно не только пройти за турникет, но и открыть сейф с зарплатами.
В статье мы разберем, что такое IAM и IDM, чем отличается управление идентификацией от контроля привилегий. Поговорим о том, какие модели авторизации актуальны в 2026 году и как встроить системы управления идентификацией и доступом в архитектуру приложения, не снизив производительность бэкенда.
Что такое IAM и IDM: в чем разница
Аббревиатуры IAM и IDM часто используют как синонимы, но между ними есть важная смысловая разница.
IDM — это Identity Management (управление идентификацией). Это цифровой аналог отдела кадров: система управления учетными записями создает профили, обновляет данные при смене должности и блокирует их при увольнении сотрудника.
Identity and Access Management — понятие более широкое. IAM-система включает все процессы IDM, но добавляет к ним строгий контроль привилегий. Если IDM выдает пропуск, то IAM решает, какие двери этот пропуск открывает, в какое время суток и при каких условиях. Вместе они образуют единую систему управления доступом.
Простыми словами, IDM отвечает на вопрос «кто ты и существует ли твоя учетная запись», а IAM — на вопрос «что именно тебе разрешено делать».
Зачем бизнесу внедрять системы класса IDM и IAM
Без надежного контроля компания рискует столкнуться с классическими проблемами информационной безопасности:
- уволенный сотрудник сохраняет доступ к внутренним системам и базам данных;
- права накапливаются годами и не соответствуют текущей должности;
- подрядчики и сервисные профили получают избыточные привилегии;
- аудит показывает, что никто не знает, у кого есть доступ к критичным данным.
Современные системы класса IDM и IAM решают эти проблемы. Они автоматизируют управление пользовательскими и служебными учетными записями, помогают соблюдать принцип наименьших привилегий (PoLP) и упрощают прохождение комплаенс-проверок.
Как работает система управления правами доступа
Любая современная IAM-система строится на четырех опорах.
1. Идентификация и аутентификация
- Идентификация — субъект заявляет о своей идентичности. Например, вводит логин или email.
- Аутентификация — система просит доказать это утверждение.
Раньше главным доказательством был пароль. Сегодня индустрия движется к беспарольной аутентификации с passkeys на базе WebAuthn. Пароли не исчезают полностью, но постепенно уступают место passkeys.
Для авторизации и аутентификации в современных приложениях часто используют следующие инструменты:
- OAuth 2.0 — фреймворк делегированной авторизации. В его Authorization Code Flow для защиты кода авторизации используют PKCE. Стоит учесть, что сейчас разрабатывается проект OAuth 2.1 (пока имеющий статус Internet-Draft), где PKCE планируют сделать обязательной частью этого потока.
- OpenID Connect (OIDC) — самостоятельный слой аутентификации, который может разворачиваться поверх OAuth 2.0. Он возвращает ID-токен в формате JWT и позволяет приложению получить подтвержденные данные о пользователе.
Важно различать: OAuth отвечает за авторизацию доступа, OIDC — за аутентификацию; они могут применяться независимо друг от друга. При этом JWT — это лишь формат токена, а не самостоятельный протокол.
2. Авторизация: управление доступом к информационным ресурсам
Это сердце управления доступом к информационным ресурсам. Основных моделей три:
- RBAC (Role-Based Access Control) — доступ на основе ролей. «Админ» может все, «пользователь» — только читать. Модель проста и предсказуема, но перестает быть достаточной, когда правило зависит не от роли, а от связи с объектом: например, «редактировать документ может только его автор».
- ABAC (Attribute-Based Access Control) — доступ на основе атрибутов. Система проверяет контекст: «Разрешить, если отдел сотрудника совпадает с отделом владельца файла и запрос идет из корпоративной сети». Модель гибкая, но ее сложнее реализовать.
- ReBAC (Relationship-Based Access Control) — доступ на основе связей. Так, например, устроен доступ к файлам в Google Drive: права пользователя определяются его связью с конкретным ресурсом и назначенной ролью.
3. Управление жизненным циклом: Joiner, Mover, Leaver
Процессы JML (прием, перемещение, увольнение) критичны для безопасности:
- Joiner — создание учетной записи и выдача стартовых прав.
- Mover — изменение прав при смене должности или отдела.
- Leaver — своевременная блокировка всех доступов.
Забытая учетная запись уволенного сотрудника — классическая причина утечек. Поэтому JML-процессы необходимо автоматизировать.
4. Учет и аудит
Логирование действий позволяет восстановить цепочку событий: кто, когда и к какому ресурсу обратился. Без аудита сложно расследовать инциденты и проходить проверки регуляторов.
Архитектура IAM: монолит, микросервисы и облако
Подход к реализации зависит от архитектуры приложения. Например, система централизованного управления доступом пользователей к информационным системам в монолите устроена иначе, чем в микросервисной или облачной архитектуре.
В монолите проще жить с централизованной авторизацией. В микросервисах важно не превратить каждый запрос в синхронный вызов центрального сервиса авторизации: это повышает задержку и создает единую точку отказа. В облаке доступ нужно контролировать и на уровне приложения, и на уровне инфраструктуры.
Лучшие практики и оптимизация: Zero Trust, PostgreSQL RLS и OPA
Принцип Zero Trust: «Никогда не доверяй, всегда проверяй». Но проверка прав для каждой строки в коде приложения, например в циклах Python, может стать узким местом и снизить производительность.
Один из вариантов — перенести часть логики на уровень базы данных или вынести ее в отдельный слой.
Контроль доступа через PostgreSQL RLS
В PostgreSQL есть механизм Row-Level Security (RLS). Он позволяет задать политики доступа прямо на уровне таблиц. База отфильтровывает строки, к которым у текущего пользователя нет прав, до того, как приложение получит результат запроса. В этом примере приложение должно заранее записать ID текущего пользователя в параметр app.user_id.
-- 1. Приложение устанавливает текущего пользователя в рамках транзакции SELECT set_config('app.user_id', '00000000-0000-0000-0000-000000000001', true);
-- 2. Включаем RLS для таблицы документов ALTER TABLE documents ENABLE ROW LEVEL SECURITY;
-- 3. Создаем политику: владелец или читатель CREATE POLICY documents_owner_or_reader ON documentsUSING ( owner_id = current_setting('app.user_id')::uuid OR EXISTS ( SELECT 1 FROM document_access WHERE document_access.document_id = documents.id AND document_access.user_id = current_setting('app.user_id')::uuid ));
RLS добавляет дополнительный уровень защиты: если запрос выполняется ролью, для которой действуют политики, PostgreSQL отфильтрует недоступные строки даже при ошибке в фильтрации на уровне приложения. При этом superuser, роли с BYPASSRLS и обычно владелец таблицы могут обходить RLS.
Параметр app.user_id приложение устанавливает само — например, через set_config с флагом is_local = true. В этом случае значение действует только в текущей транзакции, что безопасно при работе с пулом соединений: следующая транзакция на том же соединении не увидит чужой user_id.
Делегирование через Open Policy Agent (OPA)
Для микросервисов хорошим дополнением становится Open Policy Agent (OPA). Он позволяет вынести правила авторизации из бизнес-логики приложения и описывать их декларативно на языке Rego. OPA можно развернуть по-разному: как централизованный сервис, как sidecar рядом с приложением или как локальный демон. В любом случае бизнес-логика остаётся чистой и не засоряется сотнями if-else проверок прав.
Как внедрить IAM за 8 шагов
- Определите, какие системы и данные нужно защищать в первую очередь.
- Опишите роли и права: что именно может делать каждая группа сотрудников.
- Выберите модель авторизации: RBAC, ABAC или ReBAC (в зависимости от сложности связей).
- Настройте JML-процессы: прием, перемещение, увольнение.
- Настройте аутентификацию с учетом требований к защите: используйте MFA, passkeys или их сочетание.
- Настройте сквозной аудит и логирование действий.
- Проверьте производительность: возможно, часть проверок стоит вынести в PostgreSQL RLS или OPA.
- Проведите пилотный запуск на одном сервисе и только потом масштабируйте решение.
IAM — коротко о главном
- Identity and Access Management (IAM) и IDM охватывают управление идентификацией, жизненным циклом учетных записей и привилегиями, а не только вход по логину и паролю.
- IDM отвечает за создание и блокировку профилей, а IAM добавляет строгий контроль доступа к информационным ресурсам.
- Для беспарольной аутентификации используют passkeys на базе WebAuthn.
Для делегированной авторизации применяют OAuth 2.0 (развивающийся проект OAuth 2.1 пока остается Internet-Draft).
Для аутентификации может использоваться слой OpenID Connect, однако его не стоит рассматривать как обязательную единую связку с OAuth. - Для сложных систем с динамичными правилами рассмотрите ABAC или ReBAC.
- Чтобы проверки доступа не тормозили высоконагруженную систему, рассмотрите PostgreSQL RLS, OPA или вынос авторизации в отдельный архитектурный слой.
- К важным принципам безопасности относятся наименьшие привилегии (PoLP), автоматизация JML и полный аудит.
