Журнал "Information Security/ Информационная безопасность" #4, 2025

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