Содержание
Читайте в Telegram
|
В российских компаниях управление доступами долго оставалось задачей, которую можно было решать полуручным способом.
Новый сотрудник выходит на работу - ему создают учетные записи. Перешел в другое подразделение - часть прав меняют. Уволился - доступы должны заблокировать. Где-то это делает ИТ-служба, где-то администраторы отдельных систем, где-то руководители через заявки, где-то все держится на переписке и памяти ответственных.
Пока компания небольшая, такой порядок кажется терпимым. Все знают друг друга, систем немного, администраторы быстро реагируют, а ошибки воспринимаются как рабочие накладки. Но с ростом бизнеса, числа приложений, филиалов, ролей, подрядчиков и требований ИБ ручное управление доступами превращается в риск.
Главная проблема не в том, что учетную запись сложно создать. Главная проблема в том, что компания перестает понимать, у кого какие права есть на самом деле, почему они выданы, соответствуют ли они текущей роли человека и кто отвечает за их своевременное удаление.
Именно здесь IAM перестает быть «еще одной системой для ИТ» и становится элементом управляемости бизнеса.
Доступы ломаются на жизненном цикле сотрудника
Самый быстрый эффект от IAM обычно появляется там, где у компании больше всего повторяющихся операций: прием, перевод и увольнение сотрудников. Эти события кажутся кадровыми, но в ИТ они запускают целую цепочку изменений.
Новому сотруднику нужно выдать доступы к домену, почте, корпоративному порталу, бизнес-приложениям, файловым ресурсам и системам, связанным с его ролью. При переводе часть прав должна измениться. При увольнении - доступы должны быть заблокированы без задержки и без зависимости от того, кто вспомнил отправить заявку.
Если этот процесс остается ручным, появляются типовые проблемы. Уволенные сотрудники сохраняют доступ к части систем. Переведенные специалисты продолжают видеть данные прежнего подразделения. Новичкам выдают права «как у коллеги», не разбираясь, какие из них действительно нужны. Сервисные и временные учетные записи живут дольше, чем планировалось. Подрядчики остаются в системах после завершения работ.
В момент проверки или инцидента такие мелочи становятся серьезным вопросом: почему у человека был доступ, кто его согласовал и почему он не был отозван вовремя.
«Начать внедрение IAM лучше с базовых процессов, которые одновременно дают видимый результат и снижают ИБ-риски. В первую очередь - это управление жизненным циклом учетных записей: создание, изменение и блокировка доступов при приеме, переводе и увольнении сотрудников. Автоматизация этих операций быстро убирает типовые проблемы вроде “забытых” доступов и избыточных прав», - говорит Дмитрий Бабич, ведущий инженер отдела сопровождения информационных систем UDV Group.
Поэтому первое внедрение IAM не должно начинаться с попытки охватить все. Практичнее взять кадровую систему, AD и несколько ключевых бизнес-приложений, где ошибки с доступами особенно заметны. Уже этого достаточно, чтобы компания перестала управлять учетными записями только через заявки и ручные действия администраторов.
IAM не заменяет AD, 1С и порталы
Одна из частых ошибок - воспринимать IAM как систему, которая должна заменить уже существующую инфраструктуру. На практике она не вытесняет AD, кадровую систему, корпоративные порталы и прикладные решения. Она связывает их в управляемый процесс.
Кадровая система остается источником сведений о сотрудниках: кто принят, кто переведен, кто уволен, какая должность, подразделение и руководитель. AD остается каталогом пользователей и технической основой для многих корпоративных доступов. Бизнес-приложения остаются точками, где сотрудники выполняют свою работу.
IAM добавляет поверх этого управляющий слой. Он определяет, какие права должны появиться при конкретной роли, какие должны измениться при переводе, какие нужно отозвать при увольнении и какие действия требуют согласования.
Без IAM каждая система живет отдельно. В одной права изменили, во второй забыли, в третьей осталась старая роль, в четвертой доступ выдан вручную и нигде не отражен. С IAM появляется единая логика: событие в кадровом контуре запускает изменение доступов в ИТ-системах.
Это особенно важно для компаний с распределенной инфраструктурой. Чем больше филиалов, подразделений и приложений, тем выше риск, что права начнут расходиться с реальной организационной структурой. IAM нужен именно для того, чтобы связать кадровую реальность с технической реальностью.
SSO дает не только удобство
Single Sign-On часто воспринимают как пользовательскую функцию: сотруднику не нужно помнить много паролей, он входит один раз и получает доступ к нужным системам. Для бизнеса это действительно удобство. Меньше забытых паролей, меньше обращений в поддержку, быстрее вход в рабочие приложения.
Но для ИБ SSO важен еще и как единая точка контроля аутентификации. Компания получает возможность централизованно управлять правилами входа, применять MFA, отслеживать подозрительные попытки, видеть аномалии и быстрее отключать доступ при риске.
Если у каждого приложения своя учетная запись, свой пароль, свой жизненный цикл и свои журналы, контроль становится разрозненным. Один сотрудник может быть заблокирован в домене, но сохранять доступ в отдельной системе. В одном приложении MFA включена, в другом нет. В одном месте парольная политика строгая, в другом - устаревшая.
SSO не решает все вопросы управления доступом, но резко снижает фрагментацию. Оно превращает вход в корпоративные системы из набора локальных процедур в единый управляемый процесс.
Обычные пользователи и администраторы - разные классы риска
IAM хорошо решает массовую задачу: управлять доступами обычных пользователей. Создать учетную запись, назначить роль, изменить права при переводе, заблокировать доступ при увольнении, провести периодическую проверку и убрать лишнее.
Но привилегированные учетные записи требуют отдельной логики. Администратор домена, администратор базы данных, инженер инфраструктуры, владелец сервисной учетной записи или специалист, имеющий доступ к критичным системам, несет другой уровень риска. Компрометация такой учетной записи может дать атакующему контроль над значительной частью инфраструктуры.
Обычная пользовательская ошибка может привести к утечке или нарушению локального процесса. Ошибка или компрометация привилегированной учетной записи может привести к масштабному инциденту: отключению систем, удалению данных, изменению конфигураций, распространению вредоносного ПО, созданию новых учетных записей и попытке скрыть следы.
Поэтому для привилегированных доступов используют PAM - Privileged Access Management. Такие решения ограничивают постоянные права, выдают доступ на время, контролируют сессии, фиксируют действия и помогают убрать ситуацию, когда администраторская учетная запись существует постоянно и используется без достаточного контроля.
«Управление обычными и привилегированными учетными записями отличается прежде всего уровнем риска и последствиями ошибок. Обычные пользователи работают с ограниченными правами, и здесь IAM решает в основном операционные задачи: автоматическое создание и удаление учеток, назначение доступов, поддержание актуальных прав. Привилегированные учетные записи дают расширенный или полный контроль над системами. Их компрометация может привести к серьезному инциденту на уровне всей инфраструктуры», - отмечает Дмитрий Бабич, ведущий инженер отдела сопровождения информационных систем UDV Group.
Из этого следует простой вывод: IAM и PAM не конкурируют. IAM отвечает за массовое управление идентификацией и доступами. PAM - за наиболее опасные административные и сервисные права. В зрелой модели они должны дополнять друг друга.
IAM не должен автоматизировать хаос
Самая частая ошибка при внедрении IAM - попытка сразу подключить весь ИТ-контур. Компания хочет быстро получить централизованное управление доступами во всех системах, для всех сотрудников, со всеми ролями, согласованиями и исключениями. На презентации это выглядит логично. В реальном проекте часто превращается в затяжную и плохо управляемую программу.
Проблема в том, что IAM не исправляет беспорядок автоматически. Если в системах уже накоплены дубли учетных записей, устаревшие роли, лишние права, неочевидные исключения и непонятные владельцы доступов, система просто перенесет этот хаос на новый уровень.
До автоматизации нужно хотя бы минимально привести права к порядку. Понять, какие системы подключаются первыми. Какие роли действительно существуют. Кто владелец приложения. Какие доступы типовые. Какие требуют согласования. Какие учетные записи нужно закрыть до запуска. Какие исключения являются легитимными, а какие появились потому, что когда-то было быстрее дать человеку лишние права.
Вторая ошибка - попытка сразу построить идеальную ролевую модель. В теории все выглядит стройно: у каждой должности есть набор доступов, у каждого подразделения - понятные сценарии, у каждого бизнес-процесса - свои роли. На практике реальные паттерны доступа часто становятся видны только после запуска. Люди совмещают функции, работают в проектных командах, временно закрывают задачи соседних подразделений, используют системы не так, как было описано в регламентах.
Поэтому ролевую модель нужно развивать итерационно. Сначала базовые роли и критичные доступы, затем расширение, анализ фактического использования, корректировка и регулярная ревизия. IAM должен помогать наводить порядок, а не фиксировать в цифровом виде все исторические исключения.
Zero Trust начинается не с лозунга
Zero Trust часто звучит как новая универсальная модель безопасности. Никому не доверять по умолчанию, проверять пользователя, устройство, контекст, сессию, права и риск. В реальности полноценный Zero Trust в строгом виде встречается редко, особенно в российских компаниях с унаследованными системами, сложной ИТ-структурой, разными поколениями приложений и ограничениями по импортозамещению.
Но это не значит, что концепция бесполезна. Практический Zero Trust начинается с конкретных шагов: минимальные привилегии, регулярная проверка прав, отказ от вечных доступов, MFA для критичных систем, сегментация, контроль устройств, мониторинг аномалий и оценка риска при аутентификации.
IAM здесь играет базовую роль. Невозможно строить модель недоверия по умолчанию, если компания не знает, кто пользователь, какую роль он занимает, какие права ему положены, какие права он фактически имеет и когда они должны быть отозваны.
«Полноценный Zero Trust в строгом виде встречается редко - особенно в российских реалиях, где часто приходится работать с унаследованными системами и сложной ИТ-структурой. Чаще это не готовая модель, а постепенное усиление контроля доступа через практические меры: минимальные привилегии, регулярную проверку прав, сегментацию доступа и отказ от постоянного доверия к пользователю или устройству. IAM здесь выступает базовым слоем», - подчеркивает Дмитрий Бабич, ведущий инженер отдела сопровождения информационных систем UDV Group.
Но IAM не реализует Zero Trust в одиночку. Он работает вместе с MFA, мониторингом, контролем устройств, сетевой сегментацией, PAM, журналированием, анализом поведения и процессами реагирования. Это фундамент, а не вся конструкция.
Passwordless уже реален, но пароли еще останутся
Развитие IAM в 2026 году идет не через одну большую революцию, а через постепенное усиление и автоматизацию уже существующих механизмов. Passwordless - хороший пример. Это уже не теория. Во многих корпоративных средах компании постепенно уходят от паролей в пользу push-уведомлений, аппаратных ключей, сертификатов, SSO-схем и контекстной аутентификации.
Для ИБ это важный сдвиг. Пароли остаются слабым местом: их фишат, переиспользуют, сохраняют в небезопасных местах, передают коллегам, подбирают и крадут с зараженных устройств. Чем меньше критичных операций зависит от статического пароля, тем ниже часть рисков.
Но полностью отказаться от паролей пока сложно. Унаследованные системы, старые приложения, отдельные промышленные контуры, сервисные учетные записи и резервные сценарии еще долго будут использовать парольную модель. Поэтому passwordless чаще внедряется не как одномоментная замена всего, а как постепенный переход для наиболее важных и массовых сценариев.
Биометрия тоже уже используется, но точечно. Чаще она выступает дополнительным фактором, например на уровне устройства или в составе MFA. Ограничения здесь не только технические. Есть вопросы хранения биометрических данных, доверия к ним, регуляторных требований, сценариев отказа и готовности пользователей.
ИИ в IAM пока находится в роли помощника. Он может анализировать аномалии, выявлять подозрительные входы, оценивать риск доступа, находить нетипичные права и подсказывать, какие роли стоит пересмотреть. Но полностью автоматическое управление доступами на основе ИИ пока выглядит рискованно. Цена ошибки слишком высока: можно выдать лишние права или, наоборот, заблокировать критичный бизнес-процесс.
Доступ становится динамическим
Старый подход к доступам строился вокруг статичной модели: есть пользователь, есть роль, есть набор прав. Если человек работает в должности, он получает определенный доступ и сохраняет его до следующего изменения.
Современная модель движется к динамическому управлению. Важно не только кто входит, но и откуда, с какого устройства, в какое время, к какой системе, с каким уровнем риска и соответствует ли эта операция нормальному поведению пользователя.
Один и тот же сотрудник может безопасно входить в портал из корпоративной сети с управляемого устройства, но тот же вход из другой страны, с нового устройства и после нескольких неудачных попыток должен требовать дополнительной проверки или блокироваться. Это уже не просто IAM в узком смысле, а риск-ориентированное управление доступом.
Для компаний это означает, что роли остаются важными, но становятся недостаточными. Нужны контекст, MFA, мониторинг, поведенческий анализ и регулярная ревизия прав.
Главный эффект IAM - не удобство, а управляемость
Для пользователей IAM часто заметен через удобство: меньше паролей, единый вход, быстрее выдается доступ, меньше заявок и ожидания. Для ИТ - через снижение ручной нагрузки. Для ИБ - через централизованный контроль и меньшее число забытых учетных записей.
Но для руководства главный эффект глубже. IAM дает возможность ответить на вопросы, которые без него становятся болезненными. Кто имеет доступ к критичным системам. Почему эти права выданы. Когда они пересматривались. Какие доступы остались после перевода сотрудника. Какие учетные записи принадлежат подрядчикам. Какие права избыточны. Кто согласовал исключение. Как быстро компания блокирует доступ после увольнения.
Если на эти вопросы нельзя быстро ответить, доступы управляются не процессом, а привычкой. А привычка плохо выдерживает масштаб, проверки и инциденты.
В 2026 году IAM в России будет развиваться именно в этой логике. Не как модный инструмент для крупных компаний, а как базовый слой управления цифровой организацией. Сначала жизненный цикл учетных записей, AD, кадровая система и ключевые приложения. Затем SSO, регулярная ревизия прав, интеграция с PAM, MFA, риск-ориентированная аутентификация и движение к практическим элементам Zero Trust.
Хороший IAM-проект не обещает сразу идеальную модель доступа. Он делает важнее другое: убирает ручной хаос, связывает кадровые события с техническими правами и превращает доступы из набора локальных настроек в управляемый процесс.
А это уже вопрос не только ИБ, но и зрелости всей компании.
