Я считаю Identity Security одной из самых недооценённых основ кибербезопасности. За привычной просьбой «дайте человеку доступ» стоит решение компании доверить ему свою информацию и разрешить работу с конкретными документами и системами. Для этого нужно понимать, что человек должен делать, какие сведения ему нужны и когда его полномочия заканчиваются. Можно вложиться в серьёзные средства защиты и при этом оставить уволенному сотруднику доступ к конфиденциальным документам. А новый сотрудник тем временем будет ждать доступа к системе, без которой он не может приступить к работе.

В этой теме особенно хорошо видно, насколько глубоко пересекаются функции ИТ и ИБ. Одни и те же службы каталогов, средства входа и управления доступом обеспечивают работу приложений и защищают информацию компании. Я рассматриваю сближение ИТ и ИБ как закономерный тренд, который усиливают курс на технологический суверенитет и требования современной кибербезопасности. При переходе на российские решения мы пересобираем эту общую основу: нужно сохранить рабочие процессы, проверить соответствие прав согласованным полномочиям и подготовиться к эксплуатации новой среды. Поэтому проект Identity Security требует совместной работы ИТ и ИБ уже при обследовании, а затем на пилоте и при приёмке результата.

Соблюдение правил доступа требует времени и денег на протяжении всей работы компании. После внедрения остаются интеграции, которые нужно сопровождать, и полномочия, которые нужно пересматривать при изменении бизнес-задач. Сам сотрудник тратит время на вход, подтверждения, восстановление доступа и ожидание согласований. Среду цифрового доверия приходится проектировать одновременно с точки зрения риска, экономики и удобства работы. Именно с этих позиций я предлагаю посмотреть на Identity Security — от бизнес-договорённостей до повседневной эксплуатации.

Цена ошибок в управлении доступом

Поводом вернуться к теме стала Identity Conf 2026, где представили исследование «Индид» и «Айдентити Клуба». В опросе участвовали представители 200 организаций с численностью от 100 работников, уже использующих хотя бы одно решение Identity Security. То есть речь шла о компаниях, которые уже начали вкладываться в это направление.

В отчёте исследования, в частности, 43,5% респондентов сообщили об ошибках ручного назначения прав, из-за которых посторонние временно получали доступ к конфиденциальным данным. 33,5% отметили доступ уволенных сотрудников. Это ответы участников о собственных организациях; доли нельзя механически относить в целом к ситуации на российском рынке. Но само сочетание вложений в защиту с такими сбоями хорошо показывает, где стоит искать проблему: изменения в работе людей не всегда доходят до настроек информационных систем.

У этой проблемы есть и обратная сторона. Илья Кулешов из Lamoda Tech рассказал в публикации «Индид» на РБК Компании, что до внедрения IdM создание учётной записи могло занимать три дня. Сотруднику склада доступ нужен утром первого рабочего дня, чтобы обрабатывать заказы. Такая задержка затрагивает основной процесс компании, поэтому её сокращение помогло обосновать инвестиции в Identity Security. Именно так я предлагаю ставить задачу проекта: выяснить, какие потери возникают из-за лишнего, отсутствующего или несвоевременно изменённого доступа, а затем определить, что мы собираемся исправить.

Проектируем защиту вместе с бизнес-процессом

Рабочий процесс и правила его защиты нужно проектировать совместно. В августе 2026 года NIST представил концепцию Human-Centered Cybersecurity (кибербезопасность, ориентированная на человека) — основу будущих рекомендаций. Авторы предлагают учитывать потребности, возможности и ограничения людей при разработке политик, процессов и технологий. Это касается каждого, кто пользуется защитой или обеспечивает её работоспособность.

Для Identity Security я бы применял этот подход ко всему пути от решения о полномочиях до выполнения рабочей задачи. Например, руководителю предлагают пересмотреть права сотрудника, а в списке указаны только непонятные названия технических ролей информационных систем. Формально компания организовала проверку, но руководитель не может понять, какие действия с информацией, значимой для бизнеса, он подтверждает. В таком случае нужно изменить способ представления запроса и дать ему необходимые объяснения или сведения для принятия решения. По тому же принципу следует проверять, может ли сотрудник получить нужный доступ и воспользоваться им, а ИТ-команда — поддерживать выбранный порядок управления правами в инфраструктуре компании.

Экономика проекта на всём жизненном цикле

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

Я бы отдельно оценивал улучшение работы и снижение риска. Изменение времени выполнения задач и трудозатрат можно измерить; ожидаемые потери приходится оценивать по сценариям и допущениям.

Для выбранного бизнес-процесса соберём исходные показатели, а после пилота сравним работу людей, затраты и способность ограничивать опасный доступ. Статистику чужих инцидентов и оценки окупаемости других проектов можно использовать как предварительный ориентир.

От человеческого доверия к полномочиям в системах

Чтобы определить, кому и для какой работы нужен доступ, начнём с отношений между людьми. Принимая сотрудника или договариваясь с подрядчиком, мы определяем, какую работу будем делать вместе, на каких условиях и за что отвечаем. Закрепляем договорённости в документах. Именно юридически оформленные отношения должны служить основанием для предоставления информации и доступа к рабочим системам.

Затем человеку предстоит занять своё место в бизнес-системе компании. Для определения полномочий нужно понимать его задачи, участие в процессах и потребность в информации. Архитектурные подходы, включая TOGAF, могут помочь описать это устройство, но модель для того и нужна, чтобы систематизировать и понятно описать реальные рабочие функции каждого сотрудника и внешнего исполнителя. Договор, должность и соответствующие инструкции сами по себе не объясняют, к каким сведениям нужен доступ. В одной компании существенны ограничения режима коммерческой тайны, в другой — медицинской или адвокатской тайны; требования к персональным данным также нужно соотнести с конкретными действиями и информационными ресурсами.

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

Эта связь важна и для доказательности цифровых действий. При споре компании потребуется восстанавливать по цифровым следам и событиям, кто совершил операцию, что именно подтвердил и какими полномочиями обладал на тот момент. Такую задачу нужно учитывать при проектировании систем, в том числе при использовании электронной подписи, причём любого вида: простой (ПЭП), усиленной неквалифицированной (НЭП) и усиленной квалифицированной (КЭП). Её недооценка создаёт существенный риск для бизнеса.

Полномочия должны успевать за изменениями в компании

После первоначальной настройки прав жизнь компании продолжается: меняются рабочие задачи, заканчиваются договоры, появляются новые приложения. Поэтому Identity Security — это процессы, это управляемая система, это жизненный цикл с обратной связью, которую я рассматриваю на трёх уровнях: быстрое ограничение конкретного опасного доступа, периодическая проверка фактических полномочий (мониторинг полномочий) и пересмотр правил всей системы (внутренние правила в форме положений и инструкций).

Содержание этих процессов удобно сверять с NIST SP 800-53 Rev. 5: AC-2 охватывает управление учётными записями, AC-6(7) — пересмотр привилегий, AU-6 — анализ записей аудита, IR-4 — реагирование на инциденты. NIST SP 800-137 связывает результаты непрерывного мониторинга с реагированием и изменением программы контроля. Эта опора позволяет обсуждать конкретные процессы и проверяемые результаты.

Схема показывает, как жизненный цикл одной учётной записи вписан в процессы компании. Назначенные права и их фактическое использование должны соотноситься между собой. Например, можно выявлять недокументированные, но использованные полномочия и права, которыми вообще не пользовались. Анализ событий — способ обнаружить опасные действия под действующими учётными записями. Повторяющиеся сбои в системе уже дают повод проверить юридические условия, устройство работы и техническое обеспечение в целом.

Жизненный цикл учётных записей и обратная связь

Авторская модель трёх уровней обратной связи. Результаты контроля влияют на конкретные полномочия, доступ и правила компании в целом.

В обратную связь следует включить и наблюдения людей, которые работают в системе. Сотрудник может заметить, что видит чужие документы или не имеет доступа к нужным. Повторяющиеся запросы на ручные исключения дают повод проверить, предусмотрены ли необходимые рабочие операции и понятен ли порядок их согласования. Если сотрудники ищут обходной путь, нужно выяснить причину и определить, что исправить в процессе или настройках. Эти наблюдения помогают пересматривать правила по результатам реальной работы.

В российском нормативном поле приказ ФСТЭК № 117 предусматривает минимально необходимые права и контроль привилегированных учётных записей в пункте 48, мониторинг ИБ — в пункте 49, со ссылкой на ГОСТ Р 59547-2021. Область обязательного применения приказа ограничена перечисленными в нём системами госсектора. Для коммерческой компании эти положения могут служить ориентиром при разработке собственных мер с учётом применимых к ней требований.

Как связать бизнес-полномочия с правами в приложениях

При централизованном управлении доступом нужно добиться, чтобы решения об изменении полномочий корректно исполнялись в каждом приложении. Я сталкивался с неудачной попыткой подключить информационную систему к действующей IdM: атрибуты, связи и детальные права настраивались только внутри приложения, а управлять ими через API-интеграции не удавалось. То есть создание учётной записи в IdM работало, но задача управления её полномочиями решалась только в админке ИС. Именно поэтому при предпроектном обследовании важно пройти от согласованного перечня бизнес-действий с информацией до их исполнения в конкретном приложении.

Чтобы полномочия оставались актуальными, нужно связать их согласование с назначением, изменением и проверкой прав в приложениях. IGA (Identity Governance and Administration) объединяет организационное руководство и контроль с администрированием ИС. IdM (Identity Management) позволяет связать кадровые сведения с учётными записями, назначать и отзывать права, сверять результат с согласованными полномочиями. Границы продуктов пересекаются; например, в исследовании ТеДо функции российских решений сравниваются по процессам и интеграциям.

Чтобы согласованные бизнес-полномочия исполнялись в приложениях, применяют модели разграничения доступа. RBAC (Role-Based Access Control) связывает разрешения с ролями. ABAC (Attribute-Based Access Control) определяет доступ по правилам, учитывающим атрибуты субъекта, ресурса, действия и условия обращения. Эти модели рассмотрены в ГОСТ Р 59383-2021. Одну бизнес-роль могут получать сотрудники с разными должностями, если им нужны одинаковые действия с информацией. Но целевое приложение или связанная с ним служба авторизации должны действительно применять переданные роли и атрибуты при разрешении конкретных операций.

Ещё интеграции приходится поддерживать в меняющемся ландшафте. До их настройки нужно сопоставить сведения о сотрудниках в кадровой системе и в приложениях; эту проблему подробно разбирает Евгений Бражников в BIS Journal. По оценке «Солара», внедрение в средней компании может занимать 10–12 месяцев. Это оценка производителя, зависящая от состава систем и готовности процессов; после запуска работа с интеграциями и правилами продолжается.

Часть операций можно автоматизировать скриптами и встроить в процессы управления ИТ-услугами, ITSM, через Service Desk. Существуют и совместные варианты, когда IdM ведёт согласование, а задания передаёт в Service Desk. Более сложная система оправдана, если при приемлемых затратах она позволяет связать права с бизнес-функциями, обеспечить их исполнение в приложениях и регулярно проверять соответствие.

Из каких средств собрать среду доверия

Российский рынок уже позволяет собирать среду Identity Security из нескольких классов зрелых отечественных решений. Примеры продуктов и ссылки на обзоры собраны в конце статьи. Схема FICAM от GSA показывает, как управление идентичностями, электронными удостоверениями и доступом связано с общим контролем и информационными ресурсами. Это пример для федеральных ведомств США; его состав нужно соотнести с задачами и инфраструктурой своей компании.

На схеме IdM (Identity Management) связывает сведения из кадровых и других систем с учётными записями, ролями и правами. Управление электронными удостоверениями (Credential Management) охватывает их выпуск, сопровождение и отзыв. Удостоверение связывает идентичность со средством аутентификации. AM (Access Management) отвечает за аутентификацию и разрешение доступа к ресурсам. В этой группе показаны единый вход SSO (Single Sign-On) и PAM (Privileged Access Management) — управление привилегированным доступом. В группе управления и контроля (Governance) собраны средства анализа, пересмотра прав и мониторинга.

В описаниях современных решений встречаются и другие обозначения. IdP (Identity Provider) обеспечивает аутентификацию и передаёт подключённым приложениям сведения о пользователе. ITDR (Identity Threat Detection and Response) охватывает обнаружение угроз, связанных с идентичностями, и реагирование на них. IdP и ITDR отдельно на этом рисунке не выделены. При выборе продуктов я бы проверял, как эти функции связаны с остальной средой и работают вместе в конкретных сценариях.

Архитектура FICAM: управление идентичностями, удостоверениями и доступом

Открыть схему в полном размере.

На схеме FICAM (GSA) показаны источники сведений, системы управления идентичностями, удостоверениями и доступом, а также средства общего контроля. Это пример архитектуры федерального ведомства США. Русская адаптация по лицензии CC0.

В состав этой среды входит также инфраструктура каталогов и средств аутентификации. LDAP — протокол доступа к каталогу; доменная инфраструктура решает более широкий круг задач. PKI, инфраструктура открытых ключей, включает компоненты и процедуры работы с сертификатами; CA, центр сертификации, отвечает за их выпуск и сведения о статусе. Программные криптопровайдеры, аппаратные модули защиты ключей HSM и пользовательские аутентификаторы выполняют свои функции. Свести всё это к взаимозаменяемым «средствам входа» при подготовке проекта не получится.

В каком направлении развивается Identity Security

Платформы Identity Security развиваются в сторону более тесной связи управления доступом с обнаружением угроз и реагированием. В мае 2026 года Forrester изменил название своей аналитической категории на Workforce Identity Security Platforms. В публичном анонсе контроль состояния защищённости идентичностей и обнаружение угроз с реагированием отнесены к ключевым функциям таких платформ. Аналитики также выделяют устойчивую к фишингу аутентификацию, предоставление привилегий на время необходимой работы и управление доступом с учётом контекста. При этом Forrester подчёркивает: аналитика не компенсирует слабое управление жизненным циклом учётных записей. Средства защиты должны использовать сведения об угрозах, чтобы ограничивать доступ или прекращать опасные действия.

Gartner в публичной аннотации Hype Cycle for Digital Identity, 2026 также выделяет ИИ-агентов, видимость идентичностей и связанные с ними угрозы. Практические задачи агентской среды рассмотрим дальше.

Удобство входа — часть качества защиты

Единую среду доверия человек оценивает по тому, как в ней проходит его обычный рабочий день. SSO (Single Sign-On, единый вход) уменьшает число повторных процедур аутентификации в связанных приложениях. MFA (Multi-Factor Authentication, многофакторная аутентификация) усиливает аутентификацию за счёт факторов разных типов. В NIST SP 800-63B-4, раздел 8 удобство рассматривается по всему жизненному циклу аутентификации, включая редкие сложные события. Я считаю это существенным требованием к пилоту: наряду с обычной работой нужно проверить сценарии потери носителя, замены устройства и восстановления доступа. Все испытания стоит проводить с будущими пользователями: наблюдать, где возникают затруднения, какая помощь требуется и понятны ли им сообщения системы защиты.

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

При выборе технологии важно также отдельно проверить устойчивость к фишингу. Отсутствие пароля само по себе ничего не гарантирует, к сожалению, как и простое наличие нескольких факторов. Тут необходимо снова анализировать живые сценарии и возникающие угрозы. В NIST SP 800-63B-4, §3.2.5 это свойство означает защиту от поддельной проверяющей стороны без расчёта на внимательность пользователя. Например, вручную вводимый одноразовый код может попасть на фишинговую страницу. FIDO2/WebAuthn и passkeys позволяют организовать устойчивую к такому сценарию аутентификацию; выбор исполнения нужно соотнести с корпоративными требованиями и поддержкой приложений.

Восстановление доступа и эксплуатация

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

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

Доступ из доверенной и недоверенной среды

Сотрудник или подрядчик может иметь законные полномочия и подключаться из среды, которую компания контролирует лишь частично. Доверенной средой подключения здесь назовём среду, соответствие которой требованиям конкретного доступа организация подтвердила. Для недоверенной среды такое соответствие неизвестно либо требования не выполнены. При этом устройство, сеть и сеанс нужно оценивать отдельно: защищённый канал сам по себе не подтверждает состояние конечного устройства.

В NIST SP 800-207 на этом построен подход Zero Trust: решение о доступе учитывает пользователя, устройство и условия обращения. Российский приказ ФСТЭК № 117 рассматривает удалённый доступ и подключения подрядчиков в пунктах 46 и 58 в пределах своей области применения. В проекте всё это превращается в конкретную задачу: определить допустимые условия подключения и обеспечить возможность ограничить его при изменении обстоятельств.

На рисунке 7 NIST показывает, какие сведения нужны для решения о доступе. Для проекта это означает, что данные об учётных записях нужно связывать с актуальными сведениями об устройствах, требованиями к ресурсам и результатами наблюдения. Схема задаёт состав входных данных, а не выбор конкретного продукта.

Какие сведения нужны для решения о доступе — схема NIST

Открыть схему в полном размере.

Перевод и адаптация рисунка 7 «Trust Algorithm Input» из NIST SP 800-207, §3.3, с. 18–19. Пять групп входных данных и два исхода сохранены; конкретный алгоритм оценки здесь не задаётся.

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

Технологический суверенитет и среда доверия

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

Российская практика уже даёт содержательные ориентиры. В Т-Банке замене Microsoft CA на SafeTech CA предшествовал четырёхмесячный пилот, во время которого проверяли сценарии и дорабатывали продукт под требования заказчика. Затем два месяца заняло промышленное внедрение. По рассказу архитектора банка Артёма Мульдиярова, переход завершился без перебоев для пользователей. Этот результат потребовал около полугода совместной работы.

При миграции каталогов состав проекта также может измениться после обследования. В описанном «Базальт СПО» переходе энергетической компании на «Альт Домен» обнаружилась необходимость сначала перенести файловые ресурсы, сохранив связь учётных записей с правами на файлы. Только затем планировался перенос самих записей. Такой пример показывает, почему стоимость и порядок миграции нужно уточнять по реальным зависимостям приложений.

Поддерживать новую среду придётся во время перехода и после него. Поэтому обучение команды, способы восстановления и разбор несовместимостей следует включать в проект заранее; необходимость ранней подготовки администраторов подчёркивают и участники экспертного обсуждения Anti-Malware. Если продукт быстро меняется, инженеру придётся повторно проверять рабочие сценарии после доработок. На эту работу нужны компетенции и время. Готовность команды стоит проверять на практическом восстановлении доступа после сбоя, чтобы в проектный план попали реальные трудозатраты и потребность в поддержке производителя. Для технологического суверенитета компании нужны собственные компетенции по эксплуатации выбранных решений.

ИИ-агенты получают доступ к той же информации

Сервисные учётные записи давно участвуют в работе компаний; их относят к нечеловеческим идентичностям, NHI (Non-Human Identities). С появлением ИИ-агентов значение этой темы растёт: программа сама выбирает последовательность действий в пределах поручения и доступных инструментов. Компания при этом должна знать, от чьего имени она действует, какие операции ей разрешены и как прекратить доступ.

Предположим, агенту поручено подготовить отчёт по проекту. Для этого нужны чтение документов и сохранение результата. Если выдать ему все права сотрудника, среди них могут оказаться изменение исходных данных и отправка материалов вовне. А посторонняя инструкция в прочитанном документе (один из сценариев prompt injection) способна направить агента к нежелательному действию под действующими полномочиями. В материалах NIST об идентичностях агентов рассматривается привязка доступа к поручению; в сводке предложений NCCoE — независимый от рассуждений агента контроль полномочий.

Полномочия агента и контроль доступа

Разрешённые действия определяет компания. Проверка запроса и прекращение доступа должны работать независимо от того, как агент истолковал документ.

Отдельное применение ИИ в проектах Identity Security — помощь специалисту при настройке прав. В анонсе Indeed IGX он заявлен как интерфейс взаимодействия с системой; автоматическое применение сгенерированных политик там не описано. Я бы оценивал подобный интерфейс по тому, помогает ли он специалисту увидеть последствия решения. Если сложные изменения скрыты за уверенным ответом ИИ, управлять риском становится труднее.

Если ИИ-помощник использует RAG (Retrieval-Augmented Generation), он готовит ответ с учётом найденных материалов, но всё ещё может ошибаться. Для таких проектов нужны актуальные сведения о реальном ландшафте, полномочиях и использовании доступа, которые постоянно сверяются с инфраструктурой. Сначала компания должна обеспечить качество этих сведений и контроль изменений — тогда появится основание оценивать, какую работу действительно упрощает ИИ.

Как подготовить проект и проверить результат

При подготовке проекта Identity Security нужно определить, какую проблему компании решаем и какие изменения потребуются в бизнес-процессах и инфраструктуре. Я бы выяснял это вместе с ИТ, ИБ и владельцами процессов, прежде чем выбирать решения. Пилот можно построить вокруг одного значимого рабочего сценария, включив в проверку общие службы и приложения, от которых зависит доступ. Чтобы пройти путь от обследования до эксплуатации, предлагаю следующий чек-лист.

До выбора решения

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

☐ Согласовать полномочия и основания доступа. Определить полномочия участника с учётом его бизнес-функций, юридических оснований сотрудничества и ограничений на работу с информацией. Установить, какие сведения нужны для восстановления обстоятельств значимых цифровых действий, включая электронное подписание.

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

На пилоте

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

☐ Пройти рабочий путь пользователя. Выполнить реальные задачи с назначенными правами, проверить вход, смену устройства и восстановление доступа. Зафиксировать непонятные процедуры, ошибки, затраченное время и обращения в поддержку.

☐ Проверить доступ из разных сред подключения. Пройти сценарии подключения сотрудников, подрядчиков и сервисов из доверенной и недоверенной среды с учётом допустимых устройств и сроков полномочий. Проверить, кто отвечает за такой доступ. Для ИИ-агентов сопоставить разрешённые действия с поручением.

☐ Проверить изменение и прекращение доступа. Установить, когда изменения достигают приложений и как прекращаются уже открытые сеансы. Отдельно измерить время ожидания и трудозатраты на выполнение процедуры.

☐ Проверить возможность быстрого реагирования. На согласованном сценарии измерить время от обнаружения опасного доступа до ограничения операций, включая привилегированные подключения.

При приёмке и в эксплуатации

☐ Организовать наблюдение и пересмотр полномочий. Установить порядок регулярной сверки фактических прав с текущими задачами. По повторяющимся нарушениям и затруднениям разбирать причины и пересматривать решения на юридическом, бизнес- и техническом уровнях.

☐ Подготовить сопровождение и проверить экономику. Определить, кто будет сопровождать систему, подготовить команду к эксплуатации и выделить ресурсы для поддержки интеграций. Сопоставить результаты пилота с исходными показателями, учесть постоянные затраты и остаточный риск; продолжать такую оценку после ввода системы в работу.

Для меня зрелость Identity Security проявляется в реальной работе: человек может выполнить свою задачу с нужными полномочиями, а компания — объяснить, почему ему предоставлен доступ, своевременно изменить права и проверить их соответствие согласованным полномочиям. При этом компания понимает стоимость сопровождения и проверяет, справляется ли ИТ-команда с этой работой. На такой основе можно строить среду цифрового доверия, которой удобно пользоваться. Если же изменения бизнеса расходятся с техническими полномочиями, даже исправные средства защиты продолжают разрешать действия, для которых у компании уже нет оснований. Поэтому инвестиции в Identity Security стоит оценивать через качество и устойчивость самой работы бизнеса.

Материалы для дальнейшего чтения

Удобство, затраты и устойчивость входа

• NIST: Stronger Cybersecurity Programs Start with People. Авторы объясняют замысел Human-Centered Cybersecurity; концептуальный документ от 12 августа 2026 года описывает направление будущих рекомендаций.

• NIST SP 800-63B-4. Раздел 8 — удобство аутентификации, §3.2.5 — устойчивость к фишингу, §4.2 — восстановление доступа. Международный ориентир для проектирования, не российская обязательная норма.

• High Assurance Enterprise FIDO Authentication — FIDO Alliance. Корпоративные сценарии применения FIDO и выбор между синхронизируемыми и привязанными к устройству ключами.

Исследования и практика управления доступом

• Hype Cycle for Digital Identity, 2026 — Gartner. Публичная аннотация от 6 июля 2026 года обозначает направления изменений; полный отчёт и положение отдельных технологий на кривой в статье не рассматриваются.

• Workforce Identity Security Platforms — Forrester, 21 мая 2026 года. Публичный анонс изменения аналитической категории и её основных функций; полный отчёт Wave по этой ссылке не предоставлен.

• Исследование рынка Identity Security 2026 — «Индид» и «Айдентити Клуб». Методология опроса, проблемы эксплуатации и отдельные разделы о PAM, IdM/IGA и средствах входа. В выборку вошли организации, уже использующие хотя бы одно решение Identity Security.

• «Созвездие IDM» — ТеДо. Функциональное сравнение российских решений и критерии, которые можно адаптировать к задачам своей компании.

• «IDM в действии: опыт, ошибки и метрики зрелых проектов» — ITSec. Обсуждение исходных данных, бизнес-ролей и сложностей внедрения с представителями разработчиков.

• «IGA, PAM и серая зона между ними» — ITSec. Практические разрывы между пересмотром полномочий и контролем действующих сеансов.

• Обзор российского рынка PAM — Anti-Malware, редакция 2025 года. Назначение класса и примеры продуктов. Год в адресе страницы отличается от даты редакции материала.

• Замена Microsoft CA в Т-Банке — ITSec. Рассказ участника проекта о пилоте, совместимости и переносе службы сертификатов.

• Три примера перехода с Microsoft AD на «Альт Домен» — «Базальт СПО». Кейсы производителя с разными зависимостями приложений и порядком перехода.

• Российские аналоги Active Directory — Anti-Malware. Обзор направлений замены доменной инфраструктуры.

Стандарты и рекомендации

• FICAM Architecture v3.3 — GSA. Функциональная архитектура Identity, Credential and Access Management; позволяет сопоставить процессы и компоненты. Разработана для федеральных организаций США.

• IAM Reference Architecture, версия 2 — IDPro Body of Knowledge. Эталонная архитектура профессионального сообщества: идентичности, авторизация, управление полномочиями, аудит и контекст риска.

• ГОСТ Р 70262.1-2022 и ГОСТ Р 70262.2-2025 — уровни доверия к идентификации и аутентификации. ГОСТ Р 58833-2020 содержит общие положения.

• ГОСТ Р 59383-2021 — основы управления доступом, в том числе модели на основе ролей и атрибутов.

• NIST SP 800-53 Rev. 5 — меры управления учётными записями, минимальных привилегий, аудита и реагирования. Для этой статьи особенно полезны AC-2, AC-6, AU-6 и IR-4.

• NIST SP 800-207 — архитектура Zero Trust и условия принятия решений о доступе. NIST SP 800-137 — организация непрерывного мониторинга.

• Приказ ФСТЭК России № 117 — требования для перечисленных в приказе систем госсектора. Вопросы удалённого доступа, привилегий и подключения подрядчиков разобраны в пунктах 46, 48 и 58.

Примеры компонентов среды Identity Security

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

• Учётные записи и полномочия: Avanpost IDM, Solar inRights, Ankey IDM.

• Вход и привилегированный доступ: Avanpost FAM, BI.ZONE PAM, Indeed PAM.

• Каталоги и доменная инфраструктура: ALD Pro, РЕД АДМ, Avanpost DS.

• Центры сертификации: Aladdin eCA, SafeTech, КриптоПро УЦ.

• Криптографические средства: КриптоПро CSP, КриптоПро HSM.

• Средства аутентификации и их обслуживание: каталог «Аладдин Р.Д.», Рутокен, JaCarta Management System, Indeed Certificate Manager.

Идентичности ИИ-агентов

• NIST: зачем агентным системам нужна основа управления идентичностями. Экспертный материал о полномочиях и жизненном цикле идентичностей агентов.

• NCCoE: итоги сбора комментариев об идентичностях ИИ-агентов. Обсуждаемые задачи и предложения участников; документ отражает подготовительную работу над рекомендациями.