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