IAM без иллюзий: почему управление доступом начинается не с Zero Trust

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

На практике такой подход часто и ломает проект. Компания пытается разом описать все роли, все системы, все исключения, все сценарии и все права, накопленные за годы. В результате IAM превращается не в инструмент управляемости, а в длинный проект инвентаризации хаоса.

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

Именно с этих вопросов начинается реальный результат.

Главный эффект IAM - убрать ручную выдачу доступов

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

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

Самый очевидный риск - забытые доступы. Человек уже не работает в компании, перешел на другую должность или завершил проект, но часть прав осталась. Второй риск - избыточные привилегии. Сотруднику выдали доступ «на время», а потом забыли убрать. Третий - отсутствие прозрачной истории: кто запросил право, кто согласовал, почему оно было нужно и когда должно быть пересмотрено.

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

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

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

Начинать нужно не со всего контура

Распространенная ошибка - пытаться подключить к IAM сразу все системы. AD, кадровый контур, система на базе 1С, корпоративный портал, CRM, ERP, ServiceDesk, почта, хранилища, внутренние приложения, внешние сервисы, технологические системы. На бумаге это выглядит логично: если уж внедрять IAM, то сразу как единую точку управления доступами.

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

Если попытаться автоматизировать все это сразу, IAM начнет воспроизводить старую неуправляемую модель. Только быстрее и в большем масштабе.

Поэтому разумнее начинать с ограниченного, но значимого контура. Кадровая система как источник данных о сотрудниках. AD как основной каталог. Несколько ключевых бизнес-приложений, где доступы действительно важны для работы и ИБ. Затем - SSO как удобный и управляемый слой аутентификации.

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

IAM не заменяет AD и кадровую систему

Еще одно заблуждение - воспринимать IAM как замену уже существующей инфраструктуры. На самом деле IAM не приходит вместо AD, кадрового контура, корпоративного портала или бизнес-приложений. Он встраивается поверх них как управляющий слой.

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

Это важное отличие. Без IAM каждая система часто живет своей логикой. В одном месте пользователь уже уволен, в другом его учетная запись активна. В одной системе должность изменилась, в другой остались старые права. В одном приложении доступ убрали, в другом забыли. IAM позволяет привести эти изменения к единому процессу.

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

Для ИТ это означает меньше разрозненных операций. Для ИБ - более понятную модель контроля. Для бизнеса - меньше задержек при подключении сотрудников и меньше рисков при их увольнении или переводе.

SSO дает быстрый эффект, но не решает всю задачу

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

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

Если компания внедрила SSO, но не навела порядок в жизненном цикле учетных записей, проблема доступа остается. Уволенный сотрудник может быть заблокирован в точке входа, но в отдельных системах могут остаться локальные учетные записи. Пользователь может входить удобно, но иметь избыточные права. Руководитель может не знать, кто из его команды сохранил доступ к старым приложениям.

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

Обычный пользователь и администратор - разные уровни риска

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

Администраторы, сервисные аккаунты, технические пользователи, учетные записи интеграций и владельцы критичных систем имеют гораздо более сильные права. Их компрометация может привести не к локальному нарушению, а к контролю над инфраструктурой, отключению защитных средств, удалению журналов, изменению конфигураций, массовой утечке или подготовке ransomware-атаки.

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

IAM отвечает на вопрос, кому в принципе положен доступ. PAM отвечает на вопрос, как безопасно использовать самый опасный доступ.

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

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

IAM не должен автоматизировать хаос

Самая частая ошибка при внедрении IAM - начать автоматизацию до наведения хотя бы минимального порядка. В системах накоплены устаревшие учетные записи, неочевидные группы, дубли пользователей, временные права, роли с непонятными названиями, исключения без владельцев и сервисные аккаунты, которые никто не хочет трогать.

Если подключить IAM к такой среде без предварительной очистки, он не исправит проблему. Он просто начнет быстрее воспроизводить существующий хаос. Права будут выдаваться автоматически, но не обязательно правильно. Роли будут назначаться централизованно, но их смысл останется мутным. Отчеты станут красивее, но доверия к модели доступа не прибавится.

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

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

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

Zero Trust без IAM остается лозунгом

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

В строгом виде такая модель встречается редко, особенно в российских реалиях. Большинство компаний живет с унаследованными системами, сложной инфраструктурой, разными поколениями приложений, локальными учетными записями, промышленными сегментами, внешними подрядчиками и ограничениями импортозамещения.

Поэтому Zero Trust чаще выглядит не как готовая архитектура, а как постепенное усиление контроля доступа. Убрать постоянные лишние права. Ввести MFA для критичных систем. Сегментировать доступ. Пересматривать права. Контролировать привилегированные учетные записи. Проверять не только факт входа, но и условия, в которых он происходит.

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

Но IAM не строит Zero Trust в одиночку. Ему нужны MFA, PAM, мониторинг, контроль устройств, сетевые политики, аналитика поведения, сегментация и процессы реагирования. IAM отвечает за идентичность и права. Остальная архитектура проверяет условия, контекст и поведение.

Passwordless уже реален, но пароли не исчезнут завтра

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

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

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

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

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

IAM - это не проект установки, а проект порядка

Главная ценность IAM не в том, что в компании появляется новая платформа. Ценность в том, что доступ перестает быть набором ручных решений в разных системах. Учетные записи, роли, кадровые события, согласования и права начинают связываться в единую управляемую модель.

Но это происходит только в том случае, если IAM внедряется вокруг процессов. Кто является источником данных о сотруднике. Какие системы подключаются первыми. Кто владелец приложения. Какие роли действительно нужны. Как выдаются временные доступы. Кто пересматривает права. Как закрываются исключения. Что происходит при увольнении. Как контролируются администраторы.

Без этих ответов IAM становится еще одной системой, куда переносят старые проблемы. С ними - инструментом, который снижает ручной труд, уменьшает избыточные доступы, ускоряет подключение сотрудников и дает ИБ нормальную точку контроля.

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

Начинать стоит не с идеальной ролевой модели и не с лозунга Zero Trust. Начинать стоит с самого практичного: кто имеет доступ, почему, на какой срок и что произойдет с этим доступом при первом же кадровом событии. Если компания не может ответить на эти вопросы быстро и по данным, IAM ей нужен не в будущем, а уже сейчас.