Identity Fabric сводит IAM-политику с реальным поведением доступа
Identity Fabric — архитектурный подход, который связывает провайдеры идентификации, системы управления доступом, приложения и инфраструктуру в единый наблюдаемый слой. В материале The Hacker News он назван особенно актуальным для гибридных и мультиоблачных сред 2026 года: такой слой сопоставляет замысел IAM-политик с тем, как учётные записи, API и рабочие нагрузки реально используют доступ.
Почему одной конфигурации IAM недостаточно
Традиционное управление идентичностями работает в двух плоскостях. На этапе проектирования определяются жизненный цикл учётной записи, выдача прав, процессы joiner-mover-leaver и политики. Во время работы систем происходят аутентификация, авторизация, единый вход и проверки доступа внутри приложений.
Между этими плоскостями возникает разрыв. IAM-платформа может создать и назначить доступ, но не всегда способна подтвердить, как именно он реализован в каждом приложении. Неучтённые учётные записи, приложения и потоки аутентификации авторы называют «тёмной материей идентичностей».
Проблема усиливается ростом SaaS-сервисов, облачных платформ, API и автоматизированных нагрузок. Если число учётных записей, секретов и путей доступа растёт быстрее инвентаризации, накапливаются устаревшие креденшелы и избыточные привилегии. При этом мониторинг только журналов IdP не показывает часть действий, происходящих на уровне приложений.
Машинные и AI-идентичности требуют отдельного контроля
К нечеловеческим идентичностям относятся сервисные аккаунты, боты автоматизации, контейнеры, функции, виртуальные машины, ключи API и токены. Они часто создаются средствами инфраструктурной автоматизации, а не HR-процессами, поэтому могут обходить обычные процедуры жизненного цикла.
Наибольший риск несут не принадлежащие никому, неактивные и чрезмерно привилегированные учётные записи. Особенно чувствительны идентичности плоскости управления: их права могут позволять менять инфраструктуру или отключать защитные механизмы. Связь рисков поддельных и машинных учётных записей показывает риски поддельных и машинных учётных записей, когда у таких субъектов нет ясного владельца и контролируемого жизненного цикла.
Для секретов, сертификатов и токенов авторы предлагают назначать ответственного человека или команду, фиксировать назначение и область прав, задавать ротацию и жёсткий срок действия, а также отслеживать отклонения от заявленной цели. Такой контроль должен быть непрерывным и событийным, а не ограничиваться редкими ручными ревизиями.
Что даёт наблюдаемость в инциденте
Единый слой видимости связывает идентичность с приложениями и инфраструктурой, где фактически проверяется доступ. Это позволяет увидеть доверительные связи, по которым возможно перемещение между ресурсами, и сопоставить выданные права с реально используемыми.
В ходе расследования коррелированная хронология действий в приложениях, API и инфраструктуре сокращает ручную сборку контекста. Понимание доверительных связей помогает оценить возможный радиус дальнейшего перемещения, а поведенческие базовые линии — отличить нормальную активность от тихого повышения привилегий.
С чего начать команде безопасности
Первый шаг — составить инвентарь каталогов, облачных IAM, менеджеров секретов, API, приложений и инфраструктуры, а затем отобразить доверительные отношения между ними. В приоритете должны оказаться идентичности с избыточными правами, доступные из недоверенных сетей, использующие слабую аутентификацию или способные менять инфраструктуру.
Практический результат стоит измерять долей обнаруженных вне IAM идентичностей, долей машинных учётных записей с назначенными владельцами, сокращением избыточных прав и временем восстановления хронологии идентичности при инциденте. Для бизнеса ключевой вывод состоит в том, что управление доступом нужно дополнять наблюдением за его фактическим использованием: только так политика и исполнение становятся проверяемыми.