Identity Fabric, или «фабрика идентичностей», представляет собой архитектуру, а не отдельный продукт. Она связывает поставщиков идентификации, приложения, API, облачные платформы, инфраструктуру и системы управления доступом в общий наблюдаемый слой. В него входят человеческие и нечеловеческие идентичности. Главная задача такой архитектуры — сопоставить замысел политики с реальным поведением учётной записи во время выполнения. Полномасштабный подход рассчитан прежде всего на крупные гибридные и мультиоблачные среды; небольшой организации с единым каталогом весь набор возможностей может попросту не понадобиться. Для подробного разбора базовых понятий иногда используется отдельное «руководство по Identity Fabric», но практический вопрос сводится к одному: где, кем и как доступ применяется на самом деле.
У идентичности есть два измерения. На этапе проектирования системы управления жизненным циклом задают права, выполняют подготовку учётных записей и обслуживают процессы Joiner-Mover-Leaver (JML): приём сотрудника, перевод и увольнение. На этапе выполнения работают аутентификация, авторизация, Single Sign-On (SSO) и проверки внутри приложений. Классические платформы identity and access management (IAM) умеют назначать доступ, но редко проверяют, как каждое приложение применяет его в коде и как пользователь или сервис распоряжается полномочиями. Расхождение порождает дрейф доступа, избыточные права, незамеченные атаки и учётные записи вне контроля. Эту невидимую часть среды называют identity dark matter, «тёмной материей идентичностей»: сюда попадают неохваченные приложения, обходящие центральные системы потоки аутентификации и действия, которых нет в журналах поставщика идентификации.
Identity sprawl, расползание идентичностей, начинается, когда новые аккаунты, разрешения, ключи и доверительные связи возникают быстрее, чем их успевают инвентаризировать. В Software as a Service (SaaS) одно приложение доверяет другому, API аутентифицируются перед API, облачные нагрузки принимают роли, а системы самообслуживания выпускают очередные реквизиты автоматически. Человек давно перестал быть единственным субъектом доступа. Многие машинные связи никто не документирует, и старый каталог их просто не видит. Здесь действует жёсткое правило: «Службы безопасности не могут управлять тем, чего они не видят». Следствием становятся бесхозные реквизиты, лишние разрешения и неучтённые маршруты доверия. Поверхность атаки растёт тихо, без обязательного сигнала в системе оповещения.
Одних журналов identity provider (IdP) для наблюдения недостаточно. Украденные действующие реквизиты создают внешне нормальные записи: вход успешен, политика формально соблюдена, multi-factor authentication (MFA) иногда уже пройдена владельцем сессии. Само злоупотребление при этом происходит внутри приложения, API или облачной службы. Конфигурация сообщает, что разрешено; поведенческая наблюдаемость показывает, что происходит. Сопоставление задуманного, выданного и реально используемого доступа обнаруживает дрейф политики, компрометацию и скрытое повышение привилегий. Телеметрия приложения даёт более точный сигнал, чем попытка восстановить всю картину по IdP: например, необычный вызов API после обычного SSO-входа может оказаться важнее самого входа.
Нечеловеческих идентичностей во многих компаниях уже больше, чем сотрудников. Service accounts обслуживают фоновые процессы и задания по расписанию, нередко сохраняя постоянные привилегии. Боты и идентичности robotic process automation (RPA) выполняют сценарии сразу в нескольких системах. Контейнеры, функции и виртуальные машины принимают облачные роли; API-ключи и токены связывают приложения, сервисы и AI-идентичности. Отдельно стоят идентичности плоскости управления, control-plane identities. Автоматизации инфраструктуры обычно нужны широкие права, поэтому захват такого аккаунта позволяет менять конфигурацию, расширять доступ, перестраивать рабочую среду, а порой отключать средства обнаружения атаки. Кадровые события к этим аккаунтам не привязаны, и обычный HR-цикл их не закроет.
Проблема машинной идентичности упирается во владельца. Если за сервисным аккаунтом, сертификатом, секретом или токеном не закреплены человек либо команда, некому сократить его права, заменить секрет, отследить применение и удалить аккаунт после остановки нагрузки. Избыточная идентичность даёт злоумышленнику готовые привилегии; спящая сохраняет незаметную точку входа; бесхозная накапливает дрейф настроек. Каждому реквизиту нужны заявленная цель, ограниченная область действия, владелец, срок окончания, расписание ротации и мониторинг отклонений. Зрелая модель работает непрерывно, реагирует на события и автоматизирует проверки там, где это возможно. Ручная сертификация раз в несколько месяцев оставляет слишком длинное окно между появлением риска и его обнаружением.
В гибридной и мультиоблачной среде Identity Fabric связывает идентичность с приложениями, API, облаками и инфраструктурой, где решение о доступе действительно исполняется. Это полезно для zero trust: ни один субъект не считается доверенным навсегда, а оценка меняется по его поведению. Особое внимание требуется облачному боковому перемещению, lateral movement. После развёртывания сервисов остаются лишние роли и IAM-связи доверия, по которым атакующий проходит между средами. Непрерывная оценка доступа сравнивает полномочия с фактическим использованием и помогает отзывать невостребованные права. Так принцип least privilege опирается на данные, а не на догадки. При инциденте единая временная шкала соединяет события приложений и инфраструктуры; карта доверия показывает вероятный blast radius, а поведенческие базовые линии отделяют привычную работу от тихого повышения привилегий.
AI identities добавляют менее предсказуемый класс риска. Обычный токен выполняет команду программы, тогда как AI-агент получает задачу и сам выбирает последовательность действий. Агенту, которому разрешили подготовить сводку, цепочка инструментов или манипулированный ввод может открыть путь к данным, которых он не должен был касаться. При data poisoning, отравлении данных, скомпрометированная информация меняет решения агента, и доверенная автоматизация невольно действует в интересах атакующего. Поэтому AI-идентичность рассматривают как наблюдаемого участника, а не только объект политики. Для неё задают допустимые ресурсы и условия доступа, наблюдают межсистемное выполнение и назначают ответственного человека. Статическая конфигурация ограничивает возможности на бумаге; расхождение между целью задания и фактическими действиями видно лишь во время выполнения.
Построение Identity Fabric проходит три стадии: ручное статическое управление, непрерывный автоматизированный контроль и поведенческая наблюдаемость. Начинают с каталогов, облачных IAM и менеджеров секретов, затем исследуют приложения, API, облачные службы и инфраструктуру. Принцип здесь второй и столь же прямой: «Нельзя управлять тем, что ещё не обнаружено». Особенно тщательно картируют доверительные связи, поскольку именно они становятся маршрутами атаки и вытаскивают на свет identity dark matter. Приоритет получают не все ошибки подряд, а сочетания, которые реально можно использовать: чрезмерные полномочия, доступность реквизитов из недоверенной сети, интернет-сервис с секретом, слабый протокол, отсутствие MFA, бесхозный ключ или выход к плоскости управления. Риск складывается из разрешений, сетевой достижимости и контекста выполнения; одна неверная настройка ещё не всегда означает практическую уязвимость.
Программу измеряют по охвату, сокращению риска и скорости реакции. Полезные показатели: доля идентичностей, обнаруженных вне IAM; процент нечеловеческих идентичностей с назначенным владельцем; сокращение числа аккаунтов с лишними правами; среднее время восстановления полной временной шкалы при расследовании. Та же телеметрия формирует audit-ready evidence, доказательства, готовые для аудита. Их надёжность не может быть выше видимости исходных систем. При выборе платформы подходы стоит разделять: governance-centric отвечает за управление, posture-centric — за состояние конфигурации, observability-centric — за фактическое поведение, detection-centric — за обнаружение атак. Единого победителя здесь нет: решение зависит от технологического стека, способа развёртывания и задач компании.
Orchid Security обнаруживает идентичности непосредственно в приложениях и инфраструктуре, сочетая поведенческую наблюдаемость с аудиторскими доказательствами из телеметрии. Microsoft Entra предлагает широкий IAM-набор, развитый каталог и управление доступом, особенно в экосистеме Microsoft. Okta сосредоточена на аутентификации и жизненном цикле на уровне IdP; Ping Identity — на корпоративном доступе, федерации и гибридном развёртывании. SailPoint закрывает жизненный цикл, сертификацию доступа и соответствие политикам. Saviynt объединяет управление идентичностями с контролем облачных полномочий и задачами комплаенса. CyberArk специализируется на привилегированном доступе и секретах, защищая наиболее ценные реквизиты. Различие, существенное в 2026 году, проходит между системами, которые только назначают доступ, и системами, способными увидеть его применение. В сопутствующей аналитической части встречаются LinkedIn partner ID 7024138, переменная _linkedin_partner_id, массив window._linkedin_data_partner_ids, функция window.lintrk и адрес ; также инициализируются window.dataLayer и gtag(). Фрагмент обрывается на function gtag(){dataLayer., поэтому полного кода Google-трекинга и оставшихся параметров в нём нет.
У идентичности есть два измерения. На этапе проектирования системы управления жизненным циклом задают права, выполняют подготовку учётных записей и обслуживают процессы Joiner-Mover-Leaver (JML): приём сотрудника, перевод и увольнение. На этапе выполнения работают аутентификация, авторизация, Single Sign-On (SSO) и проверки внутри приложений. Классические платформы identity and access management (IAM) умеют назначать доступ, но редко проверяют, как каждое приложение применяет его в коде и как пользователь или сервис распоряжается полномочиями. Расхождение порождает дрейф доступа, избыточные права, незамеченные атаки и учётные записи вне контроля. Эту невидимую часть среды называют identity dark matter, «тёмной материей идентичностей»: сюда попадают неохваченные приложения, обходящие центральные системы потоки аутентификации и действия, которых нет в журналах поставщика идентификации.
Identity sprawl, расползание идентичностей, начинается, когда новые аккаунты, разрешения, ключи и доверительные связи возникают быстрее, чем их успевают инвентаризировать. В Software as a Service (SaaS) одно приложение доверяет другому, API аутентифицируются перед API, облачные нагрузки принимают роли, а системы самообслуживания выпускают очередные реквизиты автоматически. Человек давно перестал быть единственным субъектом доступа. Многие машинные связи никто не документирует, и старый каталог их просто не видит. Здесь действует жёсткое правило: «Службы безопасности не могут управлять тем, чего они не видят». Следствием становятся бесхозные реквизиты, лишние разрешения и неучтённые маршруты доверия. Поверхность атаки растёт тихо, без обязательного сигнала в системе оповещения.
Одних журналов identity provider (IdP) для наблюдения недостаточно. Украденные действующие реквизиты создают внешне нормальные записи: вход успешен, политика формально соблюдена, multi-factor authentication (MFA) иногда уже пройдена владельцем сессии. Само злоупотребление при этом происходит внутри приложения, API или облачной службы. Конфигурация сообщает, что разрешено; поведенческая наблюдаемость показывает, что происходит. Сопоставление задуманного, выданного и реально используемого доступа обнаруживает дрейф политики, компрометацию и скрытое повышение привилегий. Телеметрия приложения даёт более точный сигнал, чем попытка восстановить всю картину по IdP: например, необычный вызов API после обычного SSO-входа может оказаться важнее самого входа.
Нечеловеческих идентичностей во многих компаниях уже больше, чем сотрудников. Service accounts обслуживают фоновые процессы и задания по расписанию, нередко сохраняя постоянные привилегии. Боты и идентичности robotic process automation (RPA) выполняют сценарии сразу в нескольких системах. Контейнеры, функции и виртуальные машины принимают облачные роли; API-ключи и токены связывают приложения, сервисы и AI-идентичности. Отдельно стоят идентичности плоскости управления, control-plane identities. Автоматизации инфраструктуры обычно нужны широкие права, поэтому захват такого аккаунта позволяет менять конфигурацию, расширять доступ, перестраивать рабочую среду, а порой отключать средства обнаружения атаки. Кадровые события к этим аккаунтам не привязаны, и обычный HR-цикл их не закроет.
Проблема машинной идентичности упирается во владельца. Если за сервисным аккаунтом, сертификатом, секретом или токеном не закреплены человек либо команда, некому сократить его права, заменить секрет, отследить применение и удалить аккаунт после остановки нагрузки. Избыточная идентичность даёт злоумышленнику готовые привилегии; спящая сохраняет незаметную точку входа; бесхозная накапливает дрейф настроек. Каждому реквизиту нужны заявленная цель, ограниченная область действия, владелец, срок окончания, расписание ротации и мониторинг отклонений. Зрелая модель работает непрерывно, реагирует на события и автоматизирует проверки там, где это возможно. Ручная сертификация раз в несколько месяцев оставляет слишком длинное окно между появлением риска и его обнаружением.
В гибридной и мультиоблачной среде Identity Fabric связывает идентичность с приложениями, API, облаками и инфраструктурой, где решение о доступе действительно исполняется. Это полезно для zero trust: ни один субъект не считается доверенным навсегда, а оценка меняется по его поведению. Особое внимание требуется облачному боковому перемещению, lateral movement. После развёртывания сервисов остаются лишние роли и IAM-связи доверия, по которым атакующий проходит между средами. Непрерывная оценка доступа сравнивает полномочия с фактическим использованием и помогает отзывать невостребованные права. Так принцип least privilege опирается на данные, а не на догадки. При инциденте единая временная шкала соединяет события приложений и инфраструктуры; карта доверия показывает вероятный blast radius, а поведенческие базовые линии отделяют привычную работу от тихого повышения привилегий.
AI identities добавляют менее предсказуемый класс риска. Обычный токен выполняет команду программы, тогда как AI-агент получает задачу и сам выбирает последовательность действий. Агенту, которому разрешили подготовить сводку, цепочка инструментов или манипулированный ввод может открыть путь к данным, которых он не должен был касаться. При data poisoning, отравлении данных, скомпрометированная информация меняет решения агента, и доверенная автоматизация невольно действует в интересах атакующего. Поэтому AI-идентичность рассматривают как наблюдаемого участника, а не только объект политики. Для неё задают допустимые ресурсы и условия доступа, наблюдают межсистемное выполнение и назначают ответственного человека. Статическая конфигурация ограничивает возможности на бумаге; расхождение между целью задания и фактическими действиями видно лишь во время выполнения.
Построение Identity Fabric проходит три стадии: ручное статическое управление, непрерывный автоматизированный контроль и поведенческая наблюдаемость. Начинают с каталогов, облачных IAM и менеджеров секретов, затем исследуют приложения, API, облачные службы и инфраструктуру. Принцип здесь второй и столь же прямой: «Нельзя управлять тем, что ещё не обнаружено». Особенно тщательно картируют доверительные связи, поскольку именно они становятся маршрутами атаки и вытаскивают на свет identity dark matter. Приоритет получают не все ошибки подряд, а сочетания, которые реально можно использовать: чрезмерные полномочия, доступность реквизитов из недоверенной сети, интернет-сервис с секретом, слабый протокол, отсутствие MFA, бесхозный ключ или выход к плоскости управления. Риск складывается из разрешений, сетевой достижимости и контекста выполнения; одна неверная настройка ещё не всегда означает практическую уязвимость.
Программу измеряют по охвату, сокращению риска и скорости реакции. Полезные показатели: доля идентичностей, обнаруженных вне IAM; процент нечеловеческих идентичностей с назначенным владельцем; сокращение числа аккаунтов с лишними правами; среднее время восстановления полной временной шкалы при расследовании. Та же телеметрия формирует audit-ready evidence, доказательства, готовые для аудита. Их надёжность не может быть выше видимости исходных систем. При выборе платформы подходы стоит разделять: governance-centric отвечает за управление, posture-centric — за состояние конфигурации, observability-centric — за фактическое поведение, detection-centric — за обнаружение атак. Единого победителя здесь нет: решение зависит от технологического стека, способа развёртывания и задач компании.
Orchid Security обнаруживает идентичности непосредственно в приложениях и инфраструктуре, сочетая поведенческую наблюдаемость с аудиторскими доказательствами из телеметрии. Microsoft Entra предлагает широкий IAM-набор, развитый каталог и управление доступом, особенно в экосистеме Microsoft. Okta сосредоточена на аутентификации и жизненном цикле на уровне IdP; Ping Identity — на корпоративном доступе, федерации и гибридном развёртывании. SailPoint закрывает жизненный цикл, сертификацию доступа и соответствие политикам. Saviynt объединяет управление идентичностями с контролем облачных полномочий и задачами комплаенса. CyberArk специализируется на привилегированном доступе и секретах, защищая наиболее ценные реквизиты. Различие, существенное в 2026 году, проходит между системами, которые только назначают доступ, и системами, способными увидеть его применение. В сопутствующей аналитической части встречаются LinkedIn partner ID 7024138, переменная _linkedin_partner_id, массив window._linkedin_data_partner_ids, функция window.lintrk и адрес ; также инициализируются window.dataLayer и gtag(). Фрагмент обрывается на function gtag(){dataLayer., поэтому полного кода Google-трекинга и оставшихся параметров в нём нет.