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

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

    image


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

    image

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

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

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


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

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

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

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

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

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

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

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

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

    image

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

    image

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

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


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

    image

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

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

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

    image

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

    Чеклист


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

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

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

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

    Комментарии 2

      0
      Пол года уже не можете нам вашу idm поставить.
      Тут что то не так.
      image
        0
        Прямо вся боль по внедрению собрана.
        Если бизнесу и ИТ идею IDM продать можно, то что делать с кадровиками?
        Зачастую им приходится серьезно менять свои операционные процессы, но они не понимают, что от этого выиграют. Кадровая система — это фундамент для IDM. Если не заставить работать кадровиков как надо, все начинает разваливаться. Вот и получается, что если не мотивировать их административно, положительный эффект от внедрения IDM будет невелик.
        Если говорим о холдинге, то придется договариваться с кадровиками других юрлиц и их ИТ службой насчет интеграции кадровых систем.
        А еще можно вспомнить об аутсорсерах, работающих в системах организации, ими кадровики вообще не хотят заниматься. В результате покрытие IDM по людям никогда не будет 100%, и придется часть персонала все равно «вести» руками.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое