Журнал "Information Security/ Информационная безопасность" #4, 2025

Вадим Гусев, СберТех Достаточно базового: ФИО, GUID физ- лица или табельный номер, подразде- ление, должность, руководитель, даты приема и увольнения. Все остальное можно подтянуть позже. Главное, чтобы эти данные были качественными и акту- альными. Яков Фишелев, Octopus (входит в Группу "Индид") Обычно речь идет о типовых парамет- рах: ФИО, должность, дата начала рабо- ты, руководитель, принадлежность к отделу, локации или конкретной ком- пании в составе холдинга. Дополнитель- но в IDM могут использоваться специ- фические атрибуты из HR-систем – например, пройденные сотрудниками обучения и сертификации. Некоторые параметры могут быть динамическими: к примеру, данные о присутствии в поме- щении из СКУД-систем. Яков Фишелев, Octopus (входит в Группу "Индид") В случаях, когда в системе органи- зации мало пользователей, высокая текучесть кадров или возникают слож- ности с подключением через API, внедрение IDM целесообразно отло- жить. Тем не менее даже закрытые системы, так называемые черные ящики, можно подключать, например, через GUI-роботизированные коннек- торы. Однако и здесь важно предва- рительно оценить целесообразность такого шага. Вадим Гусев, СберТех Автоматизация не всегда оправдана. Например, если срок жизни системы год-два, или если нет поддержки API и интеграция обходится дороже ручного процесса. Еще бывают мелкие локаль- ные или теневые сервисы, которые проще контролировать через каталог учетных записей, чем тащить в IDM. Тут важно считать затраты и риски. Павел Супец, 1IDM Есть ряд факторов, при которых интег- рация с целевой системой может быть отложена. Например: l система заканчивает свой жизненный цикл (выводится из эксплуатации без замены, импортозамещается); l в системе происходят существенные изменения (изменяется структура и состав данных, внедряется иной end- point); l со стороны целевой системы отсут- ствуют специалисты, которые имеют экспертизу в эксплуатации интегрируе- мого продукта. Максим Тарасов, Avanpost При количестве сотрудников менее 300 использование IDM может быть дорогим и поэтому нецелесообразным. Вадим Гусев, СберТех Практические метрики: скорость про- цессов onboarding/offboarding; время соз- дания/блокировки учетной записи в УС; доля автоматизированных операций и доля ручных; число запросов на доступ через самообслуживание; количество инцидентов ИБ, связанных с доступами. Эти показатели понятны бизнесу и поз- воляют защитить инвестиции в проект. Павел Супец, 1IDM Чтобы понимать текущее состояние системы, необходимо видеть события самой предметной области и произво- дительности: l оценка интегральной производитель- ности системы по методике APDEX; l сведения о количестве и сроках активных задач бизнес-процессов, состав ошибок и предупреждений при взаимодействиях между целевыми системами, выявление несоответствий между согласованными данными и реальными, учет рисков; l учет дублирующих или избыточных движений/запросов системы. Яков Фишелев, Octopus (входит в Группу "Индид") В IDM ключевыми показателями можно считать два параметра: количество под- ключенных систем и количество реали- зованных процессов. Под процессами понимаются типовые сценарии – прием сотрудника, перевод, отпуск, увольнение, заявка на доступ, ресертификация. Необязательно сразу охватывать боль- шой объем систем и процессов. Эффек- тивность достигается уже при запуске одного процесса на нескольких системах. Такой подход позволяет двигаться посту- пательно, постепенно расширяя охват и снижая нагрузку на команду внедрения. Максим Тарасов, Avanpost Скорость предоставления доступа, количество уволенных сотрудников, имею- щих доступы, количество сотрудников, имеющих превышение полномочий. Павел Супец, 1IDM Первичный аудит проводится после интеграции управляемой системы с IDM, это снижает необходимость периодиче- ских аудитов, поскольку каждое кадро- вое движение по сотруднику провоциру- ет дополнительную аттестацию. Таким образом IDM поддерживает минимиза- цию избыточных прав в процессе реак- ций на повседневные кадровые события. Это не исключает необходимость перио- дического аудита, но заметно снижает его частоту. Планирование аудитов должно обеспечиваться правилами, кото- рые инициируются IDM по графику. Яков Фишелев, Octopus (входит в Группу "Индид") Существует два основных критерия, которые могут использоваться как по отдельности, так и совместно. Временной критерий – когда заранее задается периодичность проверки. Например, раз в полгода куратор роли обязан провести анализ ее состава и участников. Риско- вый критерий – когда система фиксирует накопление признаков рискованного совмещения прав. В этом случае приме- нение технологий искусственного интел- лекта помогает выделить наиболее прио- ритетные роли для пересмотра и избе- жать пиков нагрузки на согласующих. Вадим Гусев, СберТех Аудит ролей нужен минимум раз в год. Инициатор – служба ИБ, но ответ- ственность несут владельцы ролей. Триг- герами для внепланового аудита могут быть: реорганизация компании, смена информационных/управляемых систем, результаты расследований инцидентов. Автоматизированные (по триггеру/рас- писанию) кампании сертификации упро- щают процесс. Максим Тарасов, Avanpost Частота зависит от аудируемой систе- мы, ее критичности, количества ролей и пользователей: но не реже одного раза в месяц и не чаще одного раза в день. l В каких случаях лучше сознательно не подключать систему к IDM, и почему? Как часто стоит делать аудит ролей? Кто или что должно его инициировать? Какие метрики вы рекомен- дуете использовать, чтобы понять, что IDM работает эффективно? • 51 IDM www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru Рисунок: ГРОТЕК