Identity Fabric: как связать разрозненные учетные записи в единую систему

Что такое Identity Fabric?

В современной крупной компании цифровые процессы неизбежно ведут к появлению множества разрозненных учетных записей для каждого сотрудника или отдела. Такой подход традиционно закрепился в организациях с классической моделью IAM (Identity and Access Management). Обычно сценарий таков: работник появляется в кадровой системе — для него создают запись в Active Directory, затем отдельно заводят учетку в электронной почте, корпоративных мессенджерах, CRM-системах, Jira, внутренней вики и ряде внешних облачных сервисов. Каждая новая система требует либо отдельного пароля, либо ручной интеграции через заявки и тикеты, что усложняет работу ИТ-отдела и увеличивает риски ошибок или утечек. В результате пользователь может иметь дюжину разрозненных аккаунтов, которые администрируются по-разному, защищаются с разным уровнем строгости и подчиняются различным политикам безопасности.

В этих условиях появляется архитектурный паттерн под названием Identity Fabric. Это не продукт и не единая система, а набор принципов и подходов, объединяющий разные источники и механизмы идентификации, авторизации и учета пользователей в гибкую “ткань” цифровых идентичностей. Concept Fabric предполагает, что на предприятии могут coexistить локальные серверы, облачные инфраструктуры, сторонние SaaS-сервисы, устаревшие приложения, IoT-устройства и даже внешние партнеры. Задача fabric — не централизовать все учетные записи, а сделать возможным их согласованное и контролируемое использование, позволяя системно авторизовать доступ к ресурсам и управлять правами на основе единого контекста.

Identity Fabric особенно актуален для компаний с распределенной структурой, активной цифровой трансформацией, а также там, где требуется соответствовать строгим регуляторным требованиям по обработке персональных данных, включая 152-ФЗ, а также стандартам ФСТЭК и Роскомнадзора, не жертвуя при этом гибкостью и скоростью интеграции новых решений.

[ИЗОБРАЖЕНИЕ: Схема с центром Identity Fabric и стрелками к кадровой системе, Active Directory, облакам, веб-приложениям, контейнерам, внешним партнерам; иллюстрации механизмов авторизации и синхронизации.]

Архитектура и механизм работы

Ключевая особенность архитектуры Identity Fabric — модульность и компонентная интеграция. В отличие от монолитных IAM, Fabric строится на принципах распределенной обработки запросов, открытых API и механизмах федерации. Компоненты Fabric взаимодействуют друг с другом через стандартизированные протоколы, обеспечивая необходимый уровень доверия между всеми участниками процесса управления идентичностями.

Интеллектуальный брокер доступа (PDP, Policy Decision Point): центр принятия решений, который анализирует все входящие запросы к ресурсам — будь то внутренние приложения, облачные сервисы или внешние API. PDP сверяет контекст запроса (кто, что, когда, откуда, через какое устройство), сравнивает с актуальными политиками безопасности, политиками доступа по ролям и аттрибутами, нормами ФСТЭК и требованиями бизнеса. Только после этого выдает решение: разрешить, требовать дополнительную аутентификацию, или заблокировать доступ.
Источники идентификационных данных (PIP, Policy Information Point): интеграция с разными реестрами и каталогами: кадровая система, Active Directory или LDAP, базы партнеров, сервисы контроля доступа и наружные базы IoT-устройств. Эти компоненты обеспечивают актуальность данных о пользователе, уровне его прав, результатах предыдущих аутентификаций, группах доступа и индивидуальных атрибутах.
Агенты и прокси (PEP, Policy Enforcement Point): это интерфейс между пользователем/приложением и системой управления доступом. PEP не хранит решений, а реализует то, что приказал PDP. В техническом плане — это может быть веб-прокси, плагин для локального сервиса, агент на сервере приложений либо шлюз для защиты API-интерфейсов.
Сервисы IGA (Identity Governance & Administration): автоматизация всего жизненного цикла идентичности — заведением, изменением, делегированием, удалением учетных записей, настройкой временных доступов, протоколированием и аудитом событий. IGA несет важную нагрузку для минимизации человеческого фактора, устранения “висящих” и невостребованных аккаунтов, а главное — для аудита ИБ и ответов регуляторам при проверках.

Взаимодействие компонентов возможно за счет поддержки открытых стандартов: аутентификация пользователя — через SSO на базе SAML 2.0, OpenID Connect, безопасная авторизация — через OAuth 2.0, асинхронная синхронизация между системами — протокол SCIM, безопасная транспортировка событий и событий доступа — через защищенные вебхуки и брокеры сообщений.

[ИЗОБРАЖЕНИЕ: Блок-схема взаимодействия PDP, PEP, PIP, IGA и различных источников данных.]

Практическая реализация может включать смешение подходов: например, корпоративный портал использует централизованный SSO на базе Fabric, а некоторые внешние партнеры подключаются по API с аттрибутным контролем через брокер доступа, а инженерные системы подключены через легкие прокси-агенты.

Отличие от классической IAM

В традиционной IAM модель строится вокруг концепции единого, “железного” источника истины — централизованной базы пользователей, где контролируется рождение, изменение и “смерть” каждого аккаунта. Такой подход несёт преимущества — простая инвентаризация, жесткий аудит и управление паролями и группами доступа. Но по мере внедрения облаков, гибридной инфраструктуры, контейнеризации, микросервисов и связи с внешними контрагентами класcическая IAM сталкивается с ограничениями:

Интеграция новых сервисов требует ручной настройки, дублирования атрибутов, многоступенчатых процедур или написания кастомных коннекторов.
Невозможно “разруливать” сценарии с динамическим контекстом доступа: к примеру, делегирование на уровне групп, выдачу временного или разового доступа и учет сложных бизнес-правил.
Слабо работают гибридные сценарии: облака, мобильные клиенты, внешние B2B-партнеры часто остаются вне традиционного perimetra IAM.

Identity Fabric, напротив, не стремится сделать все идентичности одинаковыми. В его логике каждый источник (корпоративная AD, облачный сервис, реестр партнеров, IoT-система) остается автономным, но Fabric берет на себя функцию “разведчика” и координатора — знает, у кого, где и какие атрибуты спросить, как согласовать их между системами и какая единая политика действует на уровне всей организации.

Такое разделение обязанностей позволяет строительству архитектуры с поддержкой гетерогенных конфигураций:

Связывание аккаунта сотрудника в AD, HRM и облаке с единой логикой доступа;
Интеграция учетных записей инженеров в OT-системах или IoT-устройствах с матчинговыми атрибутами;
Выдача прав B2B-партнерам “на лету” через federatsiyu;
Гибкое управление гостевыми и временными идентичностями (например, для подрядчиков).

[ИЗОБРАЖЕНИЕ: Таблица-сравнение — слева: Классическая IAM («централизованный контроль, монолит, фокус на интранете»), справа: Identity Fabric («брокер, агрегатор, компонентная и API-архитектура, поддержка гибридных и облачных сценариев, IoT, интеграция внешних партнеров»).]

И главное: в российских реалиях, где одновременное наличие устаревших и современных систем — обычная вещь, Fabric предоставляет уникальную возможность плавной эволюции IAM-инфраструктуры без разрушения существующих бизнес-процессов.

Практическая ценность: зачем нужна Identity Fabric

Для бизнеса и ИТ-департаментов Fabric — не просто способ “объединить учётки”. Это платформа для гибкого управления цифровой идентичностью, отвечающая нуждам безопасности, удобства и комплаенса. Ключевые преимущества включают:

Контекстный контроль доступа: Fabric поддерживает “гибкое взвешивание” множества факторов при авторизации: физическое местоположение, время суток, тип устройства, роль пользователя, наличие признаков компрометации или устаревших паролей. Так, если у обычного сотрудника попытка получения доступа к критическим данным приходится на ночное время, система сразу применяет дополнительные меры — требует дополнительные факторы аутентификации (MFA), инициирует уведомление безопасников или может заблокировать доступ вовсе вплоть до разбирательств.
Автоматизация аудита и отчетности: Все действия по авторизации, выдаче, изменению или удалению прав фиксируются в централизованном хранилище событий. Такие журналы — основа для контроля внутреннего злоупотребления, анализа инцидентов и формирования отчетностей для внешних проверок (особенно если затрагиваются категории персональных данных по 152-ФЗ, гостайне, либо коммерческой тайне).
Оперативный отзыв всех доступов: Организации часто сталкиваются с кейсом “висящего” доступа: сотрудник уволился, но аккаунты в облаках, сервисах поддержки, даже соцсетях продолжают существовать. Identity Fabric автоматически отслеживает смену статуса пользователя (например, по данным из HRM или кадровой системы) и запускает процедуры отзыва по всем связанным системам — вплоть до автоматизированных удалений с внешних платформ.
Поддержка сложных сценариев: Гибкая архитектура Fabric позволяет включать в орбиту защиты не только сотрудников, но и B2B-клиентов, сторонних подрядчиков, временных исполнителей, а также “цифровые идентичности” устройств и сервисных роботов. Это открывает путь к быстрому запуску партнерских каналов, интеграции клиентских кабинетов, построению сложных цепочек авторизации между разными юридическими лицами.
Разделение ответственности и делегирование: Fabric “понимает”, кто владелец конкретного атрибута, какую часть прав может делегировать руководитель подразделения, позволяет выдавать временные разрешения без перманентного расширения полных прав (например, для внештатных аудиторов или консультантов).

Дополнительный эффект — упрощение прохождения ИТ и ИБ-аудитов (в том числе в рамках оценки соответствия требованиям ФСТЭК и Роскомнадзора), поскольку все события централизованно хранятся, а политика доступа становится прозрачной для ревизоров и руководства.

Сложности внедрения и российский контекст

Хотя Identity Fabric во многом построен на технологиях и стандартах, успех проекта внедрения зависит прежде всего от организационной зрелости и согласованности процессов управления идентичностями. К ключевым вызовам и особенностям российского IT относятся:

Четкая модель данных и процессов: Необходима формализация атрибутов идентичности: какие данные обязательны для каждого типа пользователя, какие — для внешних партнеров, кто и как отвечает за их верификацию. Без этой основы интеллектуальный брокер не сможет принимать корректные решения, а автоматизация будет “спотыкаться” на неустранимых конфликтах данных.
Сертификация СЗИ по требованиям ФСТЭК и ФСБ: Если Fabric контролирует доступ к информации, относящейся к государственной тайне, персональным данным, или защищаемой в интересах национальной безопасности, потребуется использование сертифицированных продуктов и компонентов. Хотя в коммерческом секторе этот пункт не всегда жестко обязателен, при проверке со стороны регуляторов наличие сертификатов и адаптация архитектуры под российские стандарты становится несомненным плюсом и оптимизирует “разбор полетов” при возможных инцидентах.
Локализация и импортозамещение: Законодательство о хранении персональных и критических данных на территории РФ обязывает размещать критичные компоненты и хранилища данных в отечественных защищённых ЦОДах. При построении Fabric рекомендуется изначально планировать архитектуру с учетом требований закона о персональных данных, сценариев работы из-за рубежа или с зарубежными партнерами (например, через выделенные шлюзы или многоуровневую модель хранения данных).
Доступность решений и дефицит готовых продуктов “под ключ”: Уход западных вендоров стимулировал развитие отечественных интеграторов и разработчиков. На российском рынке появляется все больше решений на основе открытых стандартов (например, OpenID, SAML, SCIM), постепенно сертифицируются IGA и SSO-системы. Но до сих пор “волшебной кнопки” для быстрой миграции на Fabric не существует: нужны проекты с адаптацией под специфику организации и учет всех юридических нюансов работы с персональными данными.
Сопротивление изменениям: Любая трансформация, затрагивающая процессы доступа сотрудников, сразу может встретить непонимание и даже сопротивление со стороны конечных пользователей (“зачем мне еще одна точка входа?”), ИТ-служб (“новый уровень сложности”), бизнеса (“риск сбоев при миграции”). Успешные внедрения опираются на внедрение через пилоты, последовательное обучение и вовлечение всех стейкхолдеров в проект.

В российских реалиях с пестрой ИТ-инфраструктурой, множеством “наследованных” сервисов и особыми требованиями к хранению данных, Fabric становится инструментом эволюции, а не революции: он позволяет минимизировать разрывы между современными и устаревшими решениями, обеспечивая стабильность бизнес-процессов при жестком соблюдении регуляторики.

Как начать внедрение Identity Fabric

Переход к Fabric-архитектуре — это шаги поэтапной трансформации, требующие синхронизации ИТ, ИБ, HR и sometimes юридического блока. Основные этапы внедрения:

Аудит идентичностей: Первый шаг — составить исчерпывающий перечень всех учетных записей и систем, где существуют пользовательские идентичности (AD, Exchange, облака, SaaS-платформы, внутренние базы, внешние порталы и пр.). Для аттестации систем необходимо определить жизненный цикл каждой учетной записи: кто, где и как их создает, какие атрибуты заполняются, как осуществляется отзыв и передачу прав. Составляется матрица взаимосвязей — кто с кем и на каких условиях интегрирован.
Пилотирование SSO: Следующий шаг — внедрение пилотного проекта единой аутентификации (SSO) для нескольких критических систем. Обычно выбирают внутренний портал, облако (например, корпоративная почта) и один из облачных сервисов. SSO на базе SAML или OpenID Connect позволяет сразу “почувствовать” преимущества федерации и упростить последующую интеграцию других систем.
Автоматизация процессов IGA: На этом этапе автоматизируются ключевые кадровые процессы: приём, увольнение, перевод, временное делегирование — с передачей необходимых событий в IGA-модуль Fabric. Кадровая система становится правдивым и единственным источником информации для синхрона всех связанных систем, что минимизирует “висящие” или неактуальные учетные записи.
Контекстный контроль доступа: Внедрение модулей PDP и PEP для хотя бы одного “ключевого” критического приложения. Это позволяет уже в пилоте применить сценарии контроля не по простому наличию учетной записи или группе AD, а на основе углубленных аттрибутов, включая местоположение пользователя, тип устройства, аномальные паттерны входа (например, ночная активность или множественные смены IP).
Планомерное масштабирование: По мере успеха пилота и роста зрелости процессов, включаются следующие системы, добавляются внешние интерфейсы, расширяются политики доступа для разных типов пользователей, производится интеграция с SIEM, сервисами аудита, системами защиты от внутренних угроз (DLP).
Адаптация архитектуры под требования регуляторов: Проведение соответствия схем внедрения 152-ФЗ, проверка возможности использования сертифицированных компонентов по ФСТЭК, интеграция сплит-контуров для локализации данных российских пользователей.

[ИЗОБРАЖЕНИЕ: Диаграмма перехода от классической IAM к Identity Fabric: поэтапная интеграция и автоматизация, показаны блоки аудита, пилота, автоматизации, расширения индикаторов доступа.]

Особенно важно — вся логика внедрения строится на принципе “не сломать существующее”. Fabric позволяет внедрять новые механизмы по принципу “Prospective integration”: новые системы проходят через Fabric, старые интегрируются по мере завершения инвентаризации и проработки процессов.

Дополнительно, Fabric упрощает взаимодействие с внешними аудиторами и регуляторными органами: благодаря структурированной записи событий, контролю за актуальностью данных и централизованному управлению атрибутами доступов, ревизии сводятся к формальным процедурам проверки наличия политик и соответствия действующим требованиям.

Таким образом, Identity Fabric становится современным ответом на вызовы усложняющейся цифровой среды. Компании, внедряющие Fabric, получают четкий и управляемый ландшафт идентичностей, гибкость для ИТ-инноваций, автоматизированный аудит, поддержку сценариев B2C/B2B/IoT и опору на актуальные российские стандарты и регуляции — от локализации до обязательных процедур сертификации.