Внедрение IdM. Подготовка к внедрению со стороны заказчика

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

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

Учитывая, что процесс автоматизации доступа затрагивает две основные стороны – кадровые данные и данные информационных систем, интеграцию с которыми предстоит провести, рассмотрим шаги, необходимые для того, чтобы внедрение IdM прошло гладко и не вызвало отторжения:

1. Анализ кадровых процессов и оптимизация сопровождения БД сотрудников в кадровых системах.
2. Анализ данных о пользователях и правах, а также актуализация способов управления доступом в целевых системах, которые планируется подключить к IdM.
3. Организационные мероприятия и вовлечение персонала в процесс подготовки к внедрению IdM.

Кадровые данные

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

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

Часто бывает так, что не все кадровые события отмечаются в кадровом источнике (а еще чаще они отмечаются несвоевременно и не совсем корректно). Вот несколько типичных примеров:

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

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

• Старший менеджер
• старший менеджер
• ст.менеджер
• ст. менеджер…

Нередко приходится сталкиваться и с различиями в написании ФИО:

• ШмелЁва НаталЬя ГеннадЬевна,
• ШмелЕва НаталИя ГеннадИевна…

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

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

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

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

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

Целевые системы

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

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

Ролевая модель

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

Ролевое управление доступом имеет ряд неоспоримых преимуществ:

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

Ролевая матрица сначала выстраивается отдельно в каждой из систем организации, а затем масштабируется на весь ИТ-ландшафт, где из ролей каждой системы формируются глобальные Бизнес-роли. Например, Бизнес-роль «Бухгалтер» будет включать в себя несколько отдельных ролей по каждой из информационных систем, использующихся в бухгалтерии предприятия.

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

Роли в информационной системе, как правило, распределяются для должностей и подразделений по штатной структуре, но могут быть созданы и для определённых бизнес-процессов. Например, в финансовой организации несколько сотрудников отдела расчётов занимают одинаковую должность – оператор. Но внутри отдела есть ещё и распределение на отдельные процессы, по разным видам операций (внешние или внутренние, в разной валюте, с разными сегментами организации). Для того, чтобы каждому из бизнес-направлений одного отдела предоставить доступ в информационной системе по нужной специфике, необходимо включить права в отдельные функциональные роли. Это позволит предоставить минимально достаточный набор полномочий, не включающий избыточных прав, для каждого из направлений деятельности.

Кроме того, для больших систем с сотнями ролей, тысячами пользователей и миллионами разрешений хорошей практикой является использование иерархии ролей и наследования привилегий. Например, родительская роль Администратор будет наследовать привилегии дочерних ролей: Пользователя и Читателя, так как Администратор может делать все то же, что Пользователь и Читатель, плюс будет иметь дополнительные администраторские права. С использованием иерархии нет необходимости повторно указывать одинаковые права в нескольких ролях одного модуля или системы.

На первом этапе можно создать роли в тех системах, где возможное количество комбинаций прав не очень большое и, как следствие, несложно управлять малым количеством ролей. Это могут быть типовые права, необходимые всем сотрудникам компании, в общедоступные системы, такие как каталог Active Directory (AD), почтовые системы, Service Manager и подобные. Затем, созданные ролевые матрицы по информационным системам можно будет включить в общую ролевую модель, объединяя их в Бизнес-роли.

Используя такой подход, в дальнейшем при внедрении IdM-системы будет несложно автоматизировать весь процесс предоставления прав доступа на основе созданных ролей первого этапа.

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

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

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

Организационные мероприятия

Не стоит сбрасывать со счетов и организационные моменты. В некоторых случаях они могут играть решающую роль, потому что от эффективного взаимодействия между подразделениями зачастую зависит результат всего проекта. Для этого мы обычно советуем создать в организации команду участников процесса, в которую войдут все задействованные подразделения. Поскольку для людей это дополнительная нагрузка, постарайтесь заранее разъяснить всем участникам будущего процесса их роль и значимость в структуре взаимодействия. Если «продать» коллегам идею IdM на этом этапе, можно будет избежать многих сложностей в дальнейшем.

Часто «владельцами» проекта внедрения IdM в компании выступают подразделения информационной безопасности или ИТ, а мнение бизнес-подразделений не учитывается. Это большая ошибка, ведь только они знают, каким образом и в каких бизнес-процессах используется каждый ресурс, кому надо давать к нему доступ, а кому нет. Поэтому на этапе подготовки важно обозначить, что именно бизнес-владелец отвечает за функциональную модель, на основании которой разрабатываются наборы прав (ролей) пользователей в информационной системе, а также за то, чтобы эти роли поддерживались в актуальном состоянии. Ролевая модель – это не статичная матрица, которую один раз выстроили и можно на этом успокоиться. Это «живой организм», который должен постоянно меняться, обновляться и развиваться, следуя за изменениями структуры организации и функционала сотрудников. Иначе либо начнутся проблемы, связанные с задержками в предоставлении доступа, либо возникнут риски информационной безопасности, связанные с избыточными правами доступа, что ещё хуже.

Как известно, «у семи нянек дитя без глазу», поэтому в компании должна быть разработана методология, описывающая архитектуру ролевой модели, взаимодействие и ответственность конкретных участников процесса за поддержание её в актуальном состоянии. Если в компании много направлений бизнес-деятельности и, соответственно, множество подразделений и департаментов, то по каждому направлению (например, кредитованию, операционной работе, дистанционным услугам, комплаенс и другим) в рамках процесса ролевого управления доступом необходимо назначить отдельных кураторов. Через них можно будет оперативно получать информацию об изменениях в структуре подразделения и правах доступа, необходимых для каждой роли.

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

N.B. Хорошим начинанием для повышения уровня осведомлённости будет обучение персонала. Подробное изучение функционирования будущего процесса, роли каждого участника в нем позволит минимизировать трудности перехода на новое решение.

Чеклист

Подводя итог, резюмируем основные шаги, которые следует сделать организации, планирующей внедрение IdM:

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

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

Внедрение IdM-решения – непростой и ответственный шаг, и для успешной его реализации важны как усилия каждой стороны в отдельности – сотрудников бизнес-подразделений, ИТ и ИБ-служб, так и взаимодействие всей команды в целом. Но усилия стоят того: после внедрения IdM в компании снижается число инцидентов, связанных с избыточными полномочиями и несанкционированными правами в информационных системах; исчезают простои сотрудников по причине отсутствия/долгого ожидания необходимых прав; за счет автоматизации снижаются трудозатраты и повышается производительность труда ИТ- и ИБ-служб.

Источник: habr.com