Редакция журнала "Информационная безопасность", 10/10/25
Несмотря на зрелость рынка IDM, каждая попытка внедрения натыкается на старые противоречия: между ролевой моделью и реальной оргструктурой, между автоматизацией и человеческими исключениями, между безопасностью и скоростью доступа. Мы задали экспертам вопросы, ответы на которые можно использовать в качестве готовых рекомендаций в ваших проектах.
Эксперты:
- Вадим Гусев, сервис-архитектор, Platform V IDM, СберТех
- Павел Супец, руководитель отдела инженеров и разработчиков, 1IDM
- Максим Тарасов, руководитель отдела технической экспертизы, Avanpost
- Яков Фишелев, соучредитель Octopus (входит в Группу “Индид”)
Нужно ли проектировать IDM, отталкиваясь от оргструктуры, или наоборот, менять оргструктуру под картину, де-факто получающуюся в IDM?
Яков Фишелев, Octopus (входит в Группу "Индид")
IDM-решения можно использовать как в качестве отражения кадровой организационной структуры для профилирования доступа, так и для создания собственных бизнес-ролей и профилей на основе любой иерархии и логики. Эти структуры могут накладываться друг на друга, формируя матрицу доступа. При этом важно понимать, что привязка к оргструктуре служит лишь одним из атрибутов при назначении прав. Наряду с ней могут использоваться и другие параметры, влияющие на доступ, – например, срок работы в компании, факт прохождения обязательных обучений и т. д.
Павел Супец, 1IDM
Важно понимать, что организационная структура возникает не на пустом месте, она, как правило, тесно вплетается в чувствительные сферы предприятия. Ее трансформация может стать дорогостоящей авантюрой. Ключевой момент в том, что внедряя продукт класса IDM, важно внедрять и культуру IDM. В таком случае, что мы и видим на практике, инициатива и поиск решений по "сглаживанию неровностей" между организационной структурой и ролевой моделью начинает созревать и исходить уже от самого заказчика.
Вадим Гусев, СберТех
Начинать лучше с оргструктуры – это основа, без нее система не будет понятна бизнесу. Но по факту в каждом проекте всплывают нестандартные практики: где-то руководители совмещают функции, где-то подразделения работают не по регламенту. Тут важнее не ломать оргструктуру под IDM, а аккуратно подсветить эти места и предложить изменения. Обычно именно пилот помогает выровнять обе стороны.
Максим Тарасов, Avanpost
IDM проектируется, исходя из оргструктуры. Однако следует смотреть на его адекватность и, при необходимости, вносить в оргструктуру изменения.
Сколько собственников ролей нужно в организации, чтобы IDM оставался контролируемым? Есть ли готовая формула?
Максим Тарасов, Avanpost
Готовой формулы нет. Все зависит от уровня погруженности заказчика в эти процессы. Бывает, что в ИС у каждой роли свой владелец, например в АБС ЦФТ у заказчика может быть 200 ролей, которые сгруппированы по владельцам в зависимости от подразделений и направлениями бизнеса.
Вадим Гусев, СберТех
Формулы нет, все зависит от масштаба компании. Но правило простое: одна роль – один владелец из бизнеса. На практике перегибы в обе стороны вредны: если владельцев слишком много – решения зависают, если один на всё – роли превращаются в черный ящик. В среднем у заказчиков получается, что 5%–10% сотрудников имеют функцию владельцев ролей.
Яков Фишелев, Octopus (входит в Группу "Индид")
При внедрении IDM желательно избегать жесткой привязки конкретных сотрудников к ролям и обязанностям. Гораздо эффективнее использовать бизнес-роли: в этом случае при кадровых изменениях или перемещениях система автоматически назначит нового ответственного. Такой подход актуален и для внутренних задач IDM – например, при определении кураторов и владельцев ролей. Эти функции могут назначаться не вручную, а автоматически, с помощью алгоритмов ролевой модели.
Павел Супец, 1IDM
Необходимо осмыслить практику контроля доступа к ресурсам компании и общую тревожность собственников. Предложить или разработать отдельные методы, которые будут предполагать иную форму участия в этом процессе, – исключительно для того, чтобы снять нагрузку там, где это возможно. В целом нам видится, что архитектура продукта должна поддерживать любое количество собственников без снижения качества работы IDM-системы.
Какой минимальный набор атрибутов из HR-системы нужен в IDM?
Павел Супец, 1IDM
В отношении данных из внешних систем IDM должна быть аскетична, но не во вред комфортной работе. Рассматриваемый вопрос может создать впечатление каких-либо обязательных требований к составу передаваемых данных, но следует понимать и исходить из того, что IDM-системе нужно ровно столько атрибутов, сколько необходимо интегрируемым с ней целевым системам.
Максим Тарасов, Avanpost
Информация по работникам, информация по оргструктуре, информация по должностям.
Вадим Гусев, СберТех
Достаточно базового: ФИО, GUID физлица или табельный номер, подразделение, должность, руководитель, даты приема и увольнения. Все остальное можно подтянуть позже. Главное, чтобы эти данные были качественными и актуальными.
Яков Фишелев, Octopus (входит в Группу "Индид")
Обычно речь идет о типовых параметрах: ФИО, должность, дата начала работы, руководитель, принадлежность к отделу, локации или конкретной компании в составе холдинга. Дополнительно в IDM могут использоваться специфические атрибуты из HR-систем – например, пройденные сотрудниками обучения и сертификации. Некоторые параметры могут быть динамическими: к примеру, данные о присутствии в помещении из СКУД-систем.
В каких случаях лучше сознательно не подключать систему к IDM, и почему?
Octopus (входит в Группу "Индид")
В случаях, когда в системе организации мало пользователей, высокая текучесть кадров или возникают сложности с подключением через API, внедрение IDM целесообразно отложить. Тем не менее даже закрытые системы, так называемые черные ящики, можно подключать, например, через GUI-роботизированные коннекторы. Однако и здесь важно предварительно оценить целесообразность такого шага.
Вадим Гусев, СберТех
Автоматизация не всегда оправдана. Например, если срок жизни системы год-два, или если нет поддержки API и интеграция обходится дороже ручного процесса. Еще бывают мелкие локальные или теневые сервисы, которые проще контролировать через каталог учетных записей, чем тащить в IDM. Тут важно считать затраты и риски.
Павел Супец, 1IDM
Есть ряд факторов, при которых интеграция с целевой системой может быть отложена. Например:
- система заканчивает свой жизненный цикл (выводится из эксплуатации без замены, импортозамещается);
- в системе происходят существенные изменения (изменяется структура и состав данных, внедряется иной endpoint);
- со стороны целевой системы отсутствуют специалисты, которые имеют экспертизу в эксплуатации интегрируемого продукта.
Максим Тарасов, Avanpost
При количестве сотрудников менее 300 использование IDM может быть дорогим и поэтому нецелесообразным.
Какие метрики вы рекомендуете использовать, чтобы понять, что IDM работает эффективно?
Вадим Гусев, СберТех
Практические метрики: скорость процессов onboarding/offboarding; время создания/блокировки учетной записи в УС; доля автоматизированных операций и доля ручных; число запросов на доступ через самообслуживание; количество инцидентов ИБ, связанных с доступами. Эти показатели понятны бизнесу и позволяют защитить инвестиции в проект.
Павел Супец, 1IDM
Чтобы понимать текущее состояние системы, необходимо видеть события самой предметной области и производительности:
- оценка интегральной производительности системы по методике APDEX;
- сведения о количестве и сроках активных задач бизнес-процессов, состав ошибок и предупреждений при взаимодействиях между целевыми системами, выявление несоответствий между согласованными данными и реальными, учет рисков;
- учет дублирующих или избыточных движений/запросов системы.
Яков Фишелев, Octopus (входит в Группу "Индид")
В IDM ключевыми показателями можно считать два параметра: количество подключенных систем и количество реализованных процессов. Под процессами понимаются типовые сценарии – прием сотрудника, перевод, отпуск, увольнение, заявка на доступ, ресертификация. Необязательно сразу охватывать большой объем систем и процессов. Эффективность достигается уже при запуске одного процесса на нескольких системах. Такой подход позволяет двигаться поступательно, постепенно расширяя охват и снижая нагрузку на команду внедрения.
Максим Тарасов, Avanpost
Скорость предоставления доступа, количество уволенных сотрудников, имеющих доступы, количество сотрудников, имеющих превышение полномочий.
Как часто стоит делать аудит ролей? Кто или что должно его инициировать?
Павел Супец, 1IDM
Первичный аудит проводится после интеграции управляемой системы с IDM, это снижает необходимость периодических аудитов, поскольку каждое кадровое движение по сотруднику провоцирует дополнительную аттестацию. Таким образом IDM поддерживает минимизацию избыточных прав в процессе реакций на повседневные кадровые события. Это не исключает необходимость периодического аудита, но заметно снижает его частоту. Планирование аудитов должно обеспечиваться правилами, которые инициируются IDM по графику.
Яков Фишелев, Octopus (входит в Группу "Индид")
Существует два основных критерия, которые могут использоваться как по отдельности, так и совместно. Временной критерий – когда заранее задается периодичность проверки. Например, раз в полгода куратор роли обязан провести анализ ее состава и участников. Рисковый критерий – когда система фиксирует накопление признаков рискованного совмещения прав. В этом случае применение технологий искусственного интеллекта помогает выделить наиболее приоритетные роли для пересмотра и избежать пиков нагрузки на согласующих.
Вадим Гусев, СберТех
Аудит ролей нужен минимум раз в год. Инициатор – служба ИБ, но ответственность несут владельцы ролей. Триггерами для внепланового аудита могут быть: реорганизация компании, смена информационных/управляемых систем, результаты расследований инцидентов. Автоматизированные (по триггеру/расписанию) кампании сертификации упрощают процесс.
Максим Тарасов, Avanpost
Частота зависит от аудируемой системы, ее критичности, количества ролей и пользователей: но не реже одного раза в месяц и не чаще одного раза в день.
