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

Зрелость IAM опреде- ляется не числом коннекто- ров и не скоростью созда- ния учетных записей, а соот- ветствием выданных прав реальной бизнес-логике. Это достигается не только технологиями, но и архитек- турным подходом: нужен слой описания бизнес-функ- ций, который связывает HR, ИБ и ИТ. Роль – это не ярлык, не группа в каталоге и не эле- мент интерфейса IAM. Это временное право на выпол- нение конкретной функции в конкретной ситуации. 1. Инициация – бизнес заявляет, какая функция тре- буется, кто ее выполняет и какие системы участвуют. 2. Проектирование – архи- текторы описывают роль: какие права нужны, какие риски воз- никают, кто ее владелец. 3. Реализация – IAM получает шаблон и привязывает его к источникам данных (HR, CMDB, LDAP). 4. Применение – система назначает роль при наступлении триггера (прием, перевод, заявка). 5. Мониторинг – IGA анали- зирует использование: приме- няется ли роль, есть ли неис- пользуемые права. 6. Изъятие – роль автомати- чески отзывается, если функция завершена, сотрудник переве- ден или увольняется. 7. Архивация – роль сохра- няется как версия, с обоснова- нием и логами, но не использу- ется без ревизии. Пять характеристик зрелой роли Чтобы роль была управляе- мой, ее недостаточно просто создать. Она должна иметь: l владельца – человека или подразделение, которое отве- чает за актуальность содержа- ния роли; l срок действия – дату, после которой роль должна быть пере- смотрена или удалена; l историю изменений – кто и когда добавил доступ, с каким обоснованием; l метрику риска – какие последствия возможны при ком- прометации роли (влияние на КИИ, ПДн, финансы); l порог доверия – допустимый уровень отклонений (например, количество неиспользуемых прав). Без этих элементов роль ста- новится ничейной и превраща- ется из инструмента управления в источник риска. Почему это важно? ИБ часто рассматривает IAM как проект ИТ-службы: настроить роли, подружить с HR, пройти аудит. Но если роли в системе не отражают бизнес- функции – никакой IAM не спа- сет. Будут корректные логины, согласованные заявки и еже- дневные отчеты, но все они будут работать поверх ложной логики. В случае инцидента выяснится, что человек получил доступ по роли, которая давно не соответствует его фактиче- ской функции. И тогда уже никто не вспомнит, кто ее утвер- дил и почему она еще активна. Зрелость IAM определяется не числом коннекторов и не ско- ростью создания учетных запи- сей, а соответствием выданных прав реальной бизнес-логике. Это достигается не только тех- нологиями, но и архитектурным подходом: нужен слой описания бизнес-функций, который свя- зывает HR, ИБ и ИТ. Только тогда IAM перестает быть систе- мой раздачи прав и становится системой управления доступом по смыслу, а не по ярлыку. Но есть еще права вне поля зрения IAM Есть одна проблема, о кото- рой в разговоре про роли обыч- но забывают. Всё, о чем гово- рилось выше, – про то, как роль описана, кем утверждена, как живет и когда должна быть ото- звана. Но что, если человек получает доступ, не имея роли вообще? Случается, что доступ к систе- мам появляется не через IAM, не через HR и даже не через ИТ. Сотрудник получает ссылку на сервис, проходит по ней, система автоматически создает ему учетную запись. Или его кто-то добавляет по приглаше- нию, без согласования. Или он получает права как "владелец формы", "создатель отчета", "админ по умолчанию". И таких случаев становится все больше – потому что компании все активнее используют облачные платформы, инструменты авто- матизации, внутренние порта- лы. Все это ускоряет бизнес, но при этом размывает контроль. Мы думаем, что доступ – это то, что проходит через IAM. На практике – это лишь часть кар- тины. Все остальное уходит в тень: права выдаются на лету, в интерфейсе приложений, по инициативе самих сотрудников. Никто не оформлял роль, никто не запускал заявку – но доступ уже есть. И часто – с куда боль- шими возможностями, чем предполагалось. Чтобы сохранить контроль, недостаточно просто правильно проектировать роли. Нужно при- знать, что роль – это уже не вся картина. И подумать: как менять подход к управлению доступом в ситуации, где права появляют- ся быстрее, чем их успевают оформить. Выводы Роль – это не ярлык, не группа в каталоге и не элемент интер- фейса IAM. Это временное право на выполнение конкрет- ной функции в конкретной ситуации. Она должна быть опи- сана, согласована, зафиксиро- вана в IAM как структурирован- ный объект, иметь жизненный цикл и быть удалена, когда теряет актуальность. Иначе система управления доступом будет автоматизировать не без- опасность, а старые ошибки. А ИБ, полагаясь на структуру без логики, потеряет главное – управляемость и ответствен- ность. l • 45 IDM www.itsec.ru API-ключи от ворот в вашу инфраструктуру В корпоративной инфраструктуре формируется слой прав и полномочий, который живет вне поля зрения даже самой продвинутой IAM. Это API-ключи, сервисные учетные запи- си, интеграции "система–система", Low-Code и RPA-сценарии, дающие доступ к данным и функциям в обход классической ролевой модели. Ключи нередко создаются в тестовых проектах или под конкретные интеграции, но продолжают существовать годами, без пересмотра прав и без владельца. Их привилегии часто превышают то, что получают пользователи с формальными ролями: полный доступ к базам, конфигурациям, отчетам, без привязки к контексту "кто" и "зачем". Каскадные интеграции создают еще более сложный слой рисков: вход в одну систему автоматически открывает цепочку доверенных сервисов, о существовании которых конечный пользователь может даже не подозревать. Добавьте к этому облачные коннек- торы и токены доступа, выдаваемые прямо из SaaS-интерфейсов, – и станет понятно, что значительная часть прав формируется и исчезает без какого-либо отражения в центра- лизованном каталоге. IAM в этом случае управляет лишь витриной доступа, а в подвале системы множатся каналы, которые никто не инвентаризирует и не отзывает. Эта теневая зона прав растет по мере внедрения SaaS, RPA и сервисных API, и все боль- ше реальных инцидентов начинается именно отсюда. Проблема в том, что, даже идеаль- но выстроив ролевую модель, компания может не контролировать значительную часть реальных полномочий. И пока этот слой остается вне инвентаризации и мониторинга, он будет оставаться удобной и почти незаметной точкой входа для атакующих. Ваше мнение и вопросы присылайте по адресу is@groteck.ru