Сквозная идентификация пользователей. От учётной записи к реальному человеку

Сквозная идентификация пользователей. От учётной записи к реальному человеку

Когда сотрудник увольняется, в идеале должно произойти одно простое действие — блокировка его учетных записей во всех системах. На практике это работает не всегда так, потому что никто достоверно не знает, где этот человек существует в IT-инфраструктуре организации.

HR-система зафиксировала увольнение. Active Directory — нет. В 1С:ERP/SAP его учетная запись активна. В финансовой системе «живет» привилегированная учетная запись admin_fin_03, созданная «временно» пару лет назад, и чья она, уже никто не помнит.

Это не редкость и не халатность. Это системный результат одной структурной проблемы: в инфраструктуре большинства организаций отсутствует единое понятие субъекта/физического лица.

 
ОДИН ЧЕЛОВЕК — ДЕСЯТКИ ИДЕНТИФИКАТОРОВ

Один субъект — сотрудник, подрядчик или администратор — в реальной корпоративной среде, как правило, имеет одновременно:

• запись в HR-системе с табельным номером;
• учетную запись в корпоративном Active Directory с идентификатором по sAMAccountName;
• технические учетные записи для работы с базами данных;
• учетные записи с обезличенными именами: admin_1c, postgres_fin_rw и т. п.;
• аккаунты на внешних платформах, зарегистрированные на личную почту.

Каждый из этих идентификаторов корректен в контексте своей системы. Но как только возникает вопрос «кто это сделал» в масштабах всей организации, дать однозначный ответ не получается. Связать журналы аудита из разных систем без заранее выстроенных правил сопоставления крайне сложно.

ПОЧЕМУ СИСТЕМЫ НЕ ПОНИМАЮТ ДРУГ ДРУГА

В каждой системе своя логика идентификации, и она принципиально различается.

Active Directory использует SID (Security Identifier) как неизменяемый эталон и sAMAccountName как оперативный идентификатор. Второй может меняться при переводах и переименованиях.

ERP-системы (1С:ERP, SAP) используют собственные табельные номера, никак не связанные с корпоративной схемой идентификации.

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

Проблема возникает на стыках при попытке сопоставить событие из журнала одной системы с событием в другой.

К ЧЕМУ ЭТО ПРИВОДИТ

Неспособность обеспечить сквозную идентификацию — не теоретическая проблема. Это источник конкретных операционных и регуляторных рисков.

Слепые зоны для SOC. Инцидент, начавшийся в одной системе и продолжившийся в другой, невозможно расследовать как единую цепочку событий. Security Information and Event Management (SIEM)–система собирает события, но не может коррелировать их по субъекту, если нет связующего слоя над разрозненными идентификаторами. Аналитик видит два несвязанных события вместо одной атаки.

«Мертвые души» и избыточный доступ. Без сквозного отслеживания жизненного цикла перевод или увольнение не влечет автоматической блокировки учетных записей сотрудника. По данным отраслевых исследований, значительная часть активных учетных записей в организациях фактически не имеет владельца.

Атрибутный дрейф. Без единого источника истины ФИО, должность, подразделение, контактные данные расходятся в разных системах. Сотрудник, сменивший фамилию, через год присутствует в разных каталогах под разными именами, и автоматическая корреляция становится невозможной.

КАК ВЫСТРАИВАЕТСЯ РЕШЕНИЕ

Единая идентификация субъектов — это не готовое решение, которое покупается и включается. Это архитектурный слой, надстраиваемый над существующими системами без их замены. Он держится на нескольких принципах.

Мастер-идентификатор субъекта. Каждое физическое лицо получает единственный неизменяемый ключ, не зависящий ни от имени, ни от табельного номера, ни от email. Этот ключ не меняется при смене фамилии, переводе или реорганизации. Он становится осью, вокруг которой выстраиваются все локальные идентификаторы.

Корреляционная матрица. Identity Management (IDM)-система строит и поддерживает в актуальном состоянии карту соответствий: мастер-идентификатор ↔ множество локальных идентификаторов во всех подключенных системах. Новая учетная запись, обнаруженная при реконсиляции, либо автоматически привязывается к существующему субъекту, либо помечается как неопознанная и передается на ручной разбор.

Единый авторитетный источник. Вопрос «кому верить» решается один раз: HR-система является истиной для персональных данных, и только она инициирует изменения в остальных системах. Если данные расходятся, приоритетом становится HR-система, а не та система, в которой что-то поменяли вручную в последний раз.

Разделение IDM и IdP. IDM-система управляет тем, кем является субъект: ведет жизненный цикл учетных записей, синхронизирует данные между системами, обнаруживает аномалии. IdP (Identity Provider) отвечает за то, что субъекту разрешено: политики доступа, Single Sign-On (SSO), выдача токенов. Это не дублирующие инструменты, а смежные слои одной архитектуры. Смешивать их задачи в одной из систем — лишиться преимуществ обоих.

Сквозной аудит. Любое событие в любой системе, попадающее в SIEM или Security Operations Center (SOC), несет тег с мастер-идентификатором субъекта. Аналитик видит не набор несвязанных логинов, а единого человека, чьи действия прослеживаются сквозь всю экосистему.

КАК ЭТО ВЫГЛЯДИТ НА ПРАКТИКЕ

Опыт пилотных проектов и внедрений показывает три закономерности, с которыми сталкивается каждый проект.

Инвентаризация всегда удивляет. Прежде чем строить корреляции, нужно ответить на вопрос, сколько субъектов вообще существует в организации. Пересечение данных HR-системы, Active Directory и нескольких бизнес-систем выявляет от сотен до тысяч аномалий — дублей, «мертвых душ», учетных записей с неустановленной принадлежностью. Единственное, в чем сходятся все участники проекта на этом этапе, — результаты не совпадают с ожиданиями. Зрелые IDM-решения автоматизируют этот этап через механизм реконсиляции. Например, в Platform V IDM при первом сканировании подключенных систем формируется полная карта учетных записей, каждой из которых присваивается статус: привязана к субъекту, помечена как неизвестная или выделена в очередь на ручной разбор. Это не разовая процедура: реконсиляция запускается по расписанию или по событию и непрерывно фиксирует любые отклонения от ожидаемого состояния.

Закон сохранения легаси. В каждом реальном проекте найдется система, чья единственная форма выгрузки — CSV-файл, по расписанию попадающий в сетевую папку на отдельном файловом сервере, а рядом — интеграционная шина, получающая кадровые события по схеме, зафиксированной при первом запуске и не менявшейся с этого момента. Это не исключение, а норма. IDM-системы как Platform V IDM дают возможность адаптировать коннектор под такие источники самостоятельно, без привлечения вендора. Схема атрибутов определяется при подключении, а изменения в источнике обрабатываются по мере поступления в очередь брокера, не дожидаясь следующего сеанса реконсиляции.

Серая зона корреляции. Алгоритмы сопоставления по ФИО, дате рождения, email и табельному номеру дают высокий процент совпадений, но всегда оставляют записи, которые нельзя привязать автоматически. Большинство систем на этом останавливаются. Выход — многоступенчатая корреляция: каждое правило сопоставления получает числовой коэффициент уверенности, правила комбинируются с настраиваемыми весами, итоговый балл определяет исход. Такой подход реализован, в частности, в механизме корреляции решения для централизованного управления учетными записями сотрудников, их правами и доступом к информационным ресурсам организации Platform V IDM. Пороговые значения настраиваются под требования организации, а каждое решение, автоматическое и принятое оператором, фиксируется в аудите.

ЗАКЛЮЧЕНИЕ

Сквозная идентификация субъекта — это не технологический тренд, а базовая необходимость управляемой ИТ-среды, позволяющая в любой момент и в любой системе ответить на вопрос «кто это».

Организации, которые выстраивают этот слой, получают не просто порядок в каталогах. Они получают фундамент для работающего SOC, прозрачного аудита и реального управления доступом. Те, кто игнорирует проблему, продолжают жить в среде, где admin_fin_03 — это чья-то учетная запись, владельца которой знал только IT-специалист, уволившийся неделю назад.