Алексей Гусев, 02/10/25
В информационной безопасности есть темы, которые принято считать решенными. Управление доступом через роли – одна из них. Десятки стандартов, сотни реализаций, тысячи внедрений. Принято считать: если роль назначена, значит, сотрудник получил именно те права, которые ему нужны. Внутри IAM-системы все четко: группы, политики, процессы. На бумаге – порядок. Но если посмотреть внимательнее, окажется, что этот порядок – иллюзия.
Автор: Алексей Гусев, старший советник председателя правления банка “ЦентроКредит”, преподаватель РТУ РУДН и НИЯУ МИФИ
В организациях с развитой ИТ-инфраструктурой роли живут своей жизнью. Названия у них звучные – "менеджер отдела", "аналитик", "разработчик" – но что конкретно стоит за ними, не знает никто. Один и тот же ярлык в HR-системе, в каталоге пользователей и в IAM может означать совершенно разный уровень привилегий. В одном подразделении "менеджер" – это человек, который руководит командой. В другом – просто старший специалист. В третьем – внешний подрядчик, которому выдали нужные права для удобства.
Когда IAM-система получает роль "менеджер", она честно выдает доступ к почте, Jira, файловому хранилищу и CRM. Но она не проверяет, зачем все это нужно, соответствует ли это реальной функции сотрудника, и не дублирует ли он чужой набор прав. Так возникает первая трещина: название роли и ее содержимое не совпадают.
Уместно вспомнить, что согласно статистике Solar 4RAYS за I квартал 2025 г., вторым по распространенности способом первоначального проникновения (с нарастающей долей) остаются скомпрометированные учетные записи (40% случаев), а повышение привилегий — неизменный этап почти всех успешных атак.
Роль как кривое зеркало оргструктуры
В практической информационной безопасности модель RBAC проектируется по такому шаблону: каждая должность или должностная категория получает соответствующую роль. Архитекторы ИБ исходят из того, что должность – это прокси для бизнес-функции. Но это не так. Должность – это кадровая метка. Она может не меняться годами, даже если человек уже по факту выполняет другую работу. HR-система не знает, что сотрудник временно помогает другому отделу или ушел в проектную роль. А IAM продолжает ориентироваться на то, что есть в карточке сотрудника: роль "инженер", права инженера, никакого контекста.
Пытаясь выйти из этого замкнутого круга, компании добавляют атрибуты: подразделение, регион, уровень доступа. Так появляется ABAC – модель, в которой доступ определяется не названием роли, а совокупностью характеристик субъекта и объекта. Но и она не решает основную проблему: где гарантия, что набор атрибутов действительно отражает то, что человек делает? Или что в бизнес-подразделениях вообще согласованно описали, какие функции нужны?
Если в компании отсутствует единый реестр бизнес-функций и их связи с системами, то IAM-система работает по принципу: сегодня в HR карточке записано вот это – значит, и доступ будет такой. Таким образом IAM превращается в механизм автоматизации хаоса. Он быстро и точно выдает права – но по некорректной логике. Не потому, что сломан, а потому, что входные данные не имеют необходимой точности смысла.
Права накапливаются, роли множатся, никто не знает, какие из них еще актуальны. В IAM живут сотни забытых ролей, созданных под разовые проекты, сезонных сотрудников, пилотные группы. Они никем не удаляются – потому что никто не чувствует за них ответственности.
Роль как процесс, а не как ярлык
Чтобы выйти из этого тупика, нужно отказаться от восприятия роли как чего-то статичного. Роль не существует сама по себе, она – инструмент исполнения бизнес-функции в ограниченном контексте. Сегодня человек работает в проекте, ему нужен один набор прав. Через месяц – возвращается в штат и должен автоматически потерять доступ к проектным ресурсам. Через три месяца уходит в отпуск – зачем тогда сохранять ему все привилегии?
Эта логика требует, чтобы роль воспринималась не как ярлык в пользовательском каталоге, а как динамическая сущность с жизненным циклом.
- Инициация – бизнес заявляет, какая функция требуется, кто ее выполняет и какие системы участвуют.
- Проектирование – архитекторы описывают роль: какие права нужны, какие риски возникают, кто ее владелец.
- Реализация – IAM получает шаблон и привязывает его к источникам данных (HR, CMDB, LDAP).
- Применение – система назначает роль при наступлении триггера (прием, перевод, заявка).
- Мониторинг – IGA анализирует использование: применяется ли роль, есть ли неиспользуемые права.
- Изъятие – роль автоматически отзывается, если функция завершена, сотрудник переведен или увольняется.
- Архивация – роль сохраняется как версия, с обоснованием и логами, но не используется без ревизии.
Пять характеристик зрелой роли
Чтобы роль была управляемой, ее недостаточно просто создать. Она должна иметь:
- владельца – человека или подразделение, которое отвечает за актуальность содержания роли;
- срок действия – дату, после которой роль должна быть пересмотрена или удалена;
- историю изменений – кто и когда добавил доступ, с каким обоснованием;
- метрику риска – какие последствия возможны при компрометации роли (влияние на КИИ, ПДн, финансы);
- порог доверия – допустимый уровень отклонений (например, количество неиспользуемых прав).
Без этих элементов роль становится ничейной и превращается из инструмента управления в источник риска.
Почему это важно?
ИБ часто рассматривает IAM как проект ИТ-службы: настроить роли, подружить с HR, пройти аудит. Но если роли в системе не отражают бизнес-функции – никакой IAM не спасет. Будут корректные логины, согласованные заявки и ежедневные отчеты, но все они будут работать поверх ложной логики. В случае инцидента выяснится, что человек получил доступ по роли, которая давно не соответствует его фактической функции. И тогда уже никто не вспомнит, кто ее утвердил и почему она еще активна.
Зрелость IAM определяется не числом коннекторов и не скоростью создания учетных записей, а соответствием выданных прав реальной бизнес-логике. Это достигается не только технологиями, но и архитектурным подходом: нужен слой описания бизнес-функций, который связывает HR, ИБ и ИТ. Только тогда IAM перестает быть системой раздачи прав и становится системой управления доступом по смыслу, а не по ярлыку.
Но есть еще права вне поля зрения IAM
Есть одна проблема, о которой в разговоре про роли обычно забывают. Всё, о чем говорилось выше, – про то, как роль описана, кем утверждена, как живет и когда должна быть отозвана. Но что, если человек получает доступ, не имея роли вообще?
Случается, что доступ к системам появляется не через IAM, не через HR и даже не через ИТ. Сотрудник получает ссылку на сервис, проходит по ней, система автоматически создает ему учетную запись. Или его кто-то добавляет по приглашению, без согласования. Или он получает права как "владелец формы", "создатель отчета", "админ по умолчанию". И таких случаев становится все больше – потому что компании все активнее используют облачные платформы, инструменты автоматизации, внутренние порталы. Все это ускоряет бизнес, но при этом размывает контроль.
Мы думаем, что доступ – это то, что проходит через IAM. На практике – это лишь часть картины. Все остальное уходит в тень: права выдаются на лету, в интерфейсе приложений, по инициативе самих сотрудников. Никто не оформлял роль, никто не запускал заявку – но доступ уже есть. И часто – с куда большими возможностями, чем предполагалось.
Чтобы сохранить контроль, недостаточно просто правильно проектировать роли. Нужно признать, что роль – это уже не вся картина. И подумать: как менять подход к управлению доступом в ситуации, где права появляются быстрее, чем их успевают оформить.
API-ключи от ворот в вашу инфраструктуру
В корпоративной инфраструктуре формируется слой прав и полномочий, который живет вне поля зрения даже самой продвинутой IAM. Это API-ключи, сервисные учетные записи, интеграции "система–система", Low-Code и RPA-сценарии, дающие доступ к данным и функциям в обход классической ролевой модели. Ключи нередко создаются в тестовых проектах или под конкретные интеграции, но продолжают существовать годами, без пересмотра прав и без владельца. Их привилегии часто превышают то, что получают пользователи с формальными ролями: полный доступ к базам, конфигурациям, отчетам, без привязки к контексту "кто" и "зачем".
Каскадные интеграции создают еще более сложный слой рисков: вход в одну систему автоматически открывает цепочку доверенных сервисов, о существовании которых конечный пользователь может даже не подозревать. Добавьте к этому облачные коннекторы и токены доступа, выдаваемые прямо из SaaS-интерфейсов, – и станет понятно, что значительная часть прав формируется и исчезает без какого-либо отражения в централизованном каталоге. IAM в этом случае управляет лишь витриной доступа, а в подвале системы множатся каналы, которые никто не инвентаризирует и не отзывает.
Эта теневая зона прав растет по мере внедрения SaaS, RPA и сервисных API, и все больше реальных инцидентов начинается именно отсюда. Проблема в том, что, даже идеально выстроив ролевую модель, компания может не контролировать значительную часть реальных полномочий. И пока этот слой остается вне инвентаризации и мониторинга, он будет оставаться удобной и почти незаметной точкой входа для атакующих.
Выводы
Роль – это не ярлык, не группа в каталоге и не элемент интерфейса IAM. Это временное право на выполнение конкретной функции в конкретной ситуации. Она должна быть описана, согласована, зафиксирована в IAM как структурированный объект, иметь жизненный цикл и быть удалена, когда теряет актуальность. Иначе система управления доступом будет автоматизировать не безопасность, а старые ошибки. А ИБ, полагаясь на структуру без логики, потеряет главное – управляемость и ответственность.
