28 августа 2026 года The Hacker News выпустил большой разбор о том, почему Identity Fabric из красивого термина для презентаций превращается в практический минимум для корпоративной ИБ. Для русскоязычных команд это сигнал вполне приземлённый: если доступы у вас давно расползлись по SaaS, облакам, API и ботам, классический IAM уже не даёт полной картины, а Identity Fabric пытается собрать её в одном слое наблюдаемости.
Как пишет The Hacker News, речь не о новом отдельном продукте, а об архитектурном подходе. Identity Fabric связывает провайдеров идентификации, системы управления доступом, приложения и инфраструктуру так, чтобы служба безопасности видела не только то, какие права выдали на бумаге, но и то, как эти права используются в реальной работе. Авторы делят задачу на два измерения. Первое — design time: жизненный цикл учёток, provisioning, процессы joiner-mover-leaver и политики доступа. Второе — runtime: аутентификация, авторизация, SSO и реальные проверки доступа внутри приложений. Самая неприятная зона лежит ровно между ними: политика говорит одно, а приложение, API или сервисный аккаунт в проде ведёт себя уже немного по-своему.
Именно здесь появляется то, что в материале называют identity dark matter, то есть «тёмная материя» идентичностей. Это учётки, токены, приложения и потоки аутентификации, которые формально существуют, но выпадают из централизованной видимости. Для многих компаний проблема давно вышла за рамки пользовательских аккаунтов сотрудников. Теперь существенную часть ландшафта составляют API, контейнеры, виртуальные машины, функции, RPA-боты, сервисные аккаунты и ключи интеграций. Они создаются быстрее, чем их успевают описывать в регламентах, а иногда и быстрее, чем кто-либо успевает понять, кому они вообще принадлежат. Отсюда и главный тезис статьи: защищать идентичности по конфигурации уже недостаточно, нужна наблюдаемость за поведением в рантайме.
Отдельный акцент сделан на том, что многие организации по-прежнему смотрят в основном на логи identity provider, а значит видят только входную дверь, но не то, что происходит внутри здания. Это опасный перекос, потому что заметная часть атак на идентичности уже не выглядит как грубый взлом с шумными индикаторами. Злоумышленники всё чаще используют валидные учётные данные, а в логах такие действия выглядят почти легитимно. На уровне IdP всё может быть спокойно, а вот внутри приложений уже идёт тихое расширение привилегий, нетипичный доступ к данным или боковое перемещение через доверительные связи IAM. Для разработчиков и платформенных команд это неприятная, но полезная новость: если приложение не отдаёт качественную телеметрию о том, кто, куда и зачем ходил, оно автоматически создаёт слепую зону для безопасности.
Самый практичный фрагмент материала касается non-human identities — нечеловеческих идентичностей. В статье прямо сказано, что во многих предприятиях их уже больше, чем человеческих аккаунтов, хотя внимания им достаётся заметно меньше. Сервисные учётки работают годами с постоянными привилегиями, боты выполняют рутинные операции сразу в нескольких системах, облачные workload’ы получают роли на лету, а API-ключи и токены живут дольше, чем память о задаче, ради которой их когда-то создали. Проблема тут не философская, а очень бухгалтерская по сути: у каждой такой сущности должен быть владелец, понятная цель, срок жизни и контроль использования. Если владельца нет, никто не сужает права, не ротирует секреты и не удаляет доступ, когда исходная нагрузка давно исчезла. В результате копятся три классических риска: избыточные привилегии, спящие учётки и бесхозные машинные идентичности. Ещё хуже, когда речь идёт о control-plane identities, то есть доступах, способных менять саму инфраструктуру или выключать защитные механизмы.
На уровне практики рецепт выглядит без магии. The Hacker News перечисляет четыре базовых шага: назначить ответственного за каждый сервисный аккаунт, сертификат и токен; ограничить права под конкретную задачу, а не «с запасом»; задать ротацию и жёсткий срок истечения; следить за использованием и ловить отклонения от заявленного назначения. Важная оговорка: авторы прямо противопоставляют такой подход ручным периодическим ревизиям. Раз в квартал открыть Excel, посмотреть список учёток и снова закрыть его — это уже не governance, а историческая реконструкция. В гибридной и мультиоблачной среде контроль должен быть непрерывным и событийным, иначе дрейф доступа успевает стать нормой раньше, чем команда ИБ увидит проблему.
Дальше статья логично подводит Identity Fabric к zero trust и incident response. Если компания действительно хочет жить по модели «не доверяй никому по умолчанию», ей недостаточно просто описать политику. Нужна постоянная проверка того, соответствует ли фактическое поведение выданным правам. Здесь Identity Fabric обещает сразу несколько выгод: единую картину по гибридным и мультиоблачным средам, более реалистичное внедрение least privilege и ускорение расследований. Вместо ручной склейки событий из разрозненных систем аналитики получают связанную шкалу активности по приложениям, API и инфраструктуре. Для бизнеса это означает не только меньше красивых слов про zero trust, но и более короткий путь от обнаружения инцидента к пониманию его радиуса поражения.
Есть и ещё одна причина, почему тема всплыла именно в 2026 году. Материал отдельно выделяет AI identities как один из самых быстрорастущих классов нечеловеческих идентификаторов. Логика понятна: агенту ставят задачу, а дальше он сам определяет последовательность действий, и эта последовательность может разойтись с исходным намерением сильнее, чем у обычного скрипта или сервисного аккаунта. Отсюда новый угол риска: контролировать приходится не только список разрешений, но и контекст исполнения. Для компаний, которые автоматизируют внутренние процессы ИИ-агентами, вывод довольно жёсткий: учётку агента нельзя считать просто ещё одним токеном. Ей нужен владелец, наблюдаемое поведение и понятные границы доступа, иначе автоматизация быстро превращается в новую форму бесконтрольного lateral movement.
На этом фоне главный вопрос для рынка звучит уже не «нужен ли нам Identity Fabric», а где именно проходит граница между обычным IAM, управлением привилегиями и полноценной наблюдаемостью за идентичностями. Пока одни вендоры продолжают продавать контроль доступа как настройку, а другие — как телеметрию и анализ поведения, у заказчиков остаётся вполне прикладная задача: научиться видеть не только то, что доступ выдан, но и то, что он делает после выдачи. В 2026 году это уже не избыточная зрелость, а базовая санитария для любой компании, у которой инфраструктура давно живёт за пределами одного каталога и пары внутренних приложений.