UDV Group: IAM нужно начинать не с идеальной ролевой модели, а с жизненного цикла доступов

IAM в 2026 году уже нельзя рассматривать как модный слой поверх корпоративной инфраструктуры. Для CISO это базовый инструмент управляемости: кто работает в компании, какие доступы у него есть, почему они выданы, когда должны измениться и кто отвечает за их отзыв. Без ответов на эти вопросы организация не управляет идентификацией, а вручную поддерживает набор учетных записей в разных системах.

Мы в UDV Group считаем, что внедрение IAM нужно начинать не с попытки сразу охватить весь ИТ-контур и построить идеальную ролевую модель. Быстрый и понятный результат дает управление жизненным циклом учетных записей: прием сотрудника, перевод, изменение должности, уход в отпуск, увольнение, подключение подрядчика, завершение проекта. Именно на этих событиях чаще всего возникают «забытые» доступы, избыточные права и учетные записи без актуального владельца.

Первый практический шаг- связать IAM с кадровым контуром, каталогом пользователей и несколькими ключевыми бизнес-системами. Кадровая система дает исходное событие: человек принят, переведен или уволен. Каталог пользователей остается точкой, где живут учетные записи. Приложения остаются местом фактического доступа к сервисам. IAM связывает эти элементы и задает правило: кому, когда и на каком основании положены конкретные права.

Это важно потому, что в большинстве компаний доступы годами выдавались разрозненно. Где-то по заявке, где-то письмом администратору, где-то через руководителя подразделения, где-то напрямую в приложении. В результате у службы ИБ нет единой картины: один и тот же сотрудник может иметь разные роли в каталоге, учетной системе, портале, файловом ресурсе и внутреннем приложении. IAM должен не заменить всю инфраструктуру, а стать управляющим слоем над ней.

Для бизнеса быстрый эффект появляется там, где исчезает ручная рутина. Новый сотрудник получает доступы по согласованному сценарию. При переводе права меняются, а не накапливаются поверх старых. При увольнении учетные записи блокируются вовремя. Для CISO это не только удобство, но и снижение риска: меньше неактуальных учетных записей, меньше избыточных прав, меньше возможностей для использования старого доступа после ухода человека из компании.

Отдельный эффект дает SSO. Для пользователя это меньше паролей и проще вход в корпоративные сервисы. Для ИБ — единая точка контроля аутентификации, возможность усилить MFA, быстрее отключить доступ и видеть, какие сервисы использует конкретная идентичность. Но SSO само по себе не решает задачу управления правами. Оно упрощает вход, а IAM должен отвечать за то, куда именно пользователь получает доступ и почему.

Важно разделять IAM и PAM. IAM отвечает за массовое управление пользователями и их доступами. PAM нужен для привилегированных учетных записей: администраторов, сервисных аккаунтов, технических пользователей, учетных записей с доступом к инфраструктуре, базам данных, резервным копиям и критичным системам. Риск здесь другой: компрометация обычной учетной записи может привести к локальному инциденту, а компрометация привилегированной — к контролю над значимой частью инфраструктуры.

Поэтому для привилегированных доступов обычно нужен отдельный класс решений. PAM помогает убрать постоянные административные привилегии, выдавать доступ на ограниченное время, фиксировать действия, контролировать сессии и снижать риск использования общих администраторских паролей. IAM и PAM не конкурируют. Они закрывают разные уровни одной задачи: первый управляет идентичностями в масштабе организации, второй защищает самые опасные права.

Мы в UDV Group видим, что частая ошибка при внедрении IAM — попытка сделать слишком много сразу. Компания хочет подключить все приложения, все филиалы, все роли, все согласования и все исключения. Проект становится тяжелым, сроки растут, пользователи продолжают работать по старым схемам, а ИБ не получает результата. Гораздо эффективнее начать с базового цикла учетной записи и постепенно расширять охват.

Вторая ошибка — автоматизировать хаос. Если в системах уже накоплены дубли учетных записей, устаревшие группы, непонятные роли, временные доступы без срока действия и права, выданные «на всякий случай», IAM не исправит это автоматически. Он просто начнет быстрее воспроизводить существующий беспорядок. Поэтому перед внедрением нужно привести к минимальному порядку источники данных, владельцев систем, правила выдачи и отзыва прав.

Третья ошибка — строить идеальную ролевую модель до запуска. На бумаге она выглядит убедительно: должность, подразделение, набор прав. Но в реальности доступы зависят от проектов, временных задач, регионов, замещений, команд, подрядчиков и исторически сложившихся процессов. Многие реальные паттерны использования становятся понятны только после сбора фактических данных. Поэтому ролевую модель лучше развивать итерационно: сначала базовые роли, затем анализ отклонений и постепенное уточнение.

Для CISO IAM важен еще и как основа Zero Trust. Полноценная модель Zero Trust в строгом виде встречается редко, особенно в сложных российских инфраструктурах с унаследованными системами, разными контурами и неоднородными приложениями. Но практические принципы Zero Trust внедрять можно: минимальные привилегии, регулярная проверка прав, MFA, отказ от постоянного доверия к пользователю или устройству, контроль контекста доступа.

Без IAM поддерживать такую модель в масштабе невозможно. Нельзя регулярно проверять права, если нет единого источника данных о пользователях и доступах. Нельзя применять минимальные привилегии, если неизвестно, какие права действительно нужны для работы. Нельзя быстро отозвать доступ, если учетные записи живут отдельно в каждой системе. IAM не реализует Zero Trust в одиночку, но без него Zero Trust остается набором принципов без операционной основы.

Тренды IAM тоже нужно оценивать прагматично. Passwordless уже не теория: компании постепенно уходят от паролей к push-подтверждениям, аппаратным ключам, сертификатам, SSO и другим способам аутентификации. Но полный отказ от паролей пока редко возможен. В инфраструктуре остаются унаследованные системы, технологические учетные записи, старые приложения и резервные сценарии, где пароль все еще используется.

Биометрия тоже применяется, но чаще как дополнительный фактор, а не как универсальная замена логину и паролю. Основные ограничения здесь не только технические. Есть вопросы хранения биометрических данных, доверия к ним, регуляторных требований, сценариев отказа и восстановления доступа. Для CISO биометрия должна быть частью модели риска, а не просто удобной функцией входа.

ИИ в IAM пока полезнее как инструмент анализа, чем как самостоятельный администратор прав. Он может помогать выявлять аномальные входы, нетипичные запросы доступа, подозрительное поведение пользователей, избыточные права и отклонения от нормальных паттернов. Но полностью автоматическое управление доступами на основе ИИ пока рискованно. Цена ошибки слишком высока: неправильный отзыв прав может остановить бизнес-процесс, а неправильная выдача — открыть путь к критичной системе.

Для нас в UDV Group направление развития IAM выглядит так: меньше паролей, больше контекстной проверки, регулярный пересмотр прав, автоматизация типовых операций и более точная оценка риска при доступе. Но это не отменяет базовой дисциплины. Если в компании не выстроен жизненный цикл учетных записей, не определены владельцы систем и не очищены права, продвинутые механизмы не дадут ожидаемого эффекта.

Главный вопрос для CISO звучит не так: какое IAM-решение выбрать. Вопрос глубже: понимает ли компания, как у нее появляется, меняется и исчезает доступ. Если этот процесс завязан на письма, ручные заявки и память администраторов, риск будет накапливаться независимо от размера бизнеса. Если жизненный цикл доступов управляется централизованно, IAM становится не просто ИТ-системой, а основой контроля идентичностей, снижения избыточных прав и движения к более зрелой модели безопасности.