Внедрение системы IdM за 10 шагов

Приведу пример: в одном из проектов инициатором и заказчиком системы являлась ИТ-служба компании, которой требовалась автоматизация процессов. Требования, цели, границы проекта они устанавливали самостоятельно, хотя и согласовывали их с сотрудниками службы информационной безопасности (ИБ). Когда проект уже подходил к сдаче, ИБ-шники решили расширить его цели – добавить соответствие контролей (Compliance). В итоге срок сдачи затянулся на 3 месяца, а изначальные требования были скорректированы. После согласования необходимых контролей специалисты ИБ решили дополнительно оптимизировать процессы назначения полномочий, что опять же не входило в изначальные цели. Проект был сдан с серьезным опозданием и деморализованной ИТ-службой, так как их задачи из-за дополнительных требований коллег и фиксированного бюджета были решены не полностью.

2

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

Рис. 1. Эффективное внедрение IdM-cистем

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

3

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

4

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

5

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

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

I Этап. Обследование, разработка технического задания, подключение основных информационных систем, автоматизация процессов управления правами доступа (автоматическое заведение учетной записи (УЗ) при приеме на работу, автоматический отзыв прав при увольнении или переводе сотрудника по должности). Этот этап очень важен для успешного внедрения, так как он позволяет выявить большое количество расхождений между регламентной документацией и фактическим состоянием дел. Если им пренебречь и сразу внедрить весь функционал, включая обработку заявок, сверку и т.д., есть риск, что решение будет неработоспособным и потребуются героические усилия на спешное исправление ситуации.

II Этап. Подключение дополнительных систем, реализация процессов согласования прав доступа, ролевая модель. На этом этапе разрабатываются коннекторы к оставшимся информационным системам, внедряются интерфейсы самообслуживания, ролевая модель, отчетность. Второй этап самый сложный в реализации и внедрении, так как именно в это время системой начинают пользоваться рядовые сотрудники. Осуществить его значительно проще, если к этому времени завершен предыдущий этап: в системе уже вычищены ошибки и недочеты кадровой информации, найдены владельцы большинства УЗ, удалены УЗ уволенных сотрудников. Если первый этап позволяет снизить издержки компании за счет автоматизации рутинных задач, то второй дает возможность использовать все преимущества IdM:

- отчеты позволяют соответст­во­вать необходимым контролям;

- информационная безопасность получает инструмент контроля над выданными полномочиями;

- администраторы систем получают возможность автоматического управления доступом.

III Этап. Расширение, доработки, пожелания. На третьем и последующих этапах система уже полностью настроена, требуются лишь различные улучшения работоспособности, доработки интерфейсной части, подключения оставшихся систем.

Отметим, что часто клиенты стараются совместить первый и второй этапы ради экономии бюджетов и времени, у некоторых это получается, но риск не всегда оправдан.

Рис. 2. Этапы внедрения IdM-системы

6

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

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

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

7

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

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

8

Обеспечить готовность информационных систем (необходимы интерфейсы взаимодействия между IdM и управляемыми системами).

Одной из основных работ в проектах внедрения IdM является интеграция с управляемыми системами. Прежде всего на стороне систем должны быть доступны внешние интерфейсы управления доступом (создание, блокирование учетной записи, назначение/отзыв прав и т.д.). Если система самописная, есть большая вероятность, что таких интерфейсов у нее нет, и их придется разрабатывать самостоятельно. Для этого нужно заранее уточнить, справятся ли с задачей собственные специалисты или потребуется привлечение сторонних экспертов. Кроме интерфейсов, в информационных системах могут быть еще две проблемы: гранулированный доступ и нестандартизированные названия ролей.

Гранулированный доступ является особенностью больших и сложных систем, таких как ERP, он выдается не одной ролью, а набором фильтров и галочек. Если каждый фильтр выделять в отдельную роль, это приведет к тому, что количество ролей, доступных для запроса, разрастется до 50 тыс. Понятно, что пользоваться такой системой невозможно. Чтобы этого избежать, из всех 50 тыс. выделяется 100–200 типовых ролей, обычно это покрывает 99% всех потребностей, а оставшийся процент заявок выполняется вручную, либо при запросе нестандартного доступа сначала формируется новая роль, а затем уже проходит сам запрос.

Отсутствие стандартов на название ролей в определённой системе приводит к невозможности автоматизации управления правами доступа в ней. Это происходит, например, в тех случаях, когда доступ в компании запрашивается в свободной форме, через письма или СЭД, а далее такие заявки разбираются администратором. Так, на одном из обследований мы были свидетелями того, как администратору пришла заявка с запросом полномочий: «Я хочу быть админом моего ноутбука». Обычно подобные обращения без вопросов отклоняют по причине их бессмысленности. Но администратор, даже не моргнув, поставил статус «Выполнено» и включил пользователя в группу локальных администраторов. В итоге присланная заявка и фактически назначенные права для непосвящённого человека (например, аудитора) никак друг с другом не согласуются, что в период пересмотра прав доступа или внешнего аудита может привести к появлению нежелательных вопросов и дополнительных проверок. Другая крайность, когда вместо человеческого: «Доступ к цветному принтеру HP в комнате 329», пользователь оформляет заявку: «Прошу включить мою учетную запись в группу CN=HPLaser12,OU=Маркетинг,DC=foo,DC=org». Отметим, что примеры взяты из практики.

9

Навести порядок с учётными записями. Одной из самых распространенных и болезненных проблем при внедрении IdM является отсутствие идентификаторов у УЗ и правил, по которым можно определить, какому сотруднику принадлежит учетная запись в подключаемой к IdM системе. Приведем пример: у одной компании в подключаемой системе было 12 тыс. активных учетных записей вида: ddd1, petrov.f.r, firewall_192 и т.д., из которых 8 тыс. принадлежали уволенным сотрудникам, а около сотни являлись «кем-то созданными» и «для чего-то нужными» технологическими УЗ, и не было ни одного опознавательного атрибута, по которому можно было бы определить владельцев. В итоге процесс поиска ответственных и блокировки уволенных занял больше месяца. Но даже после длительной и кропотливой работы остались несколько десятков УЗ, для которых не нашли хозяев, их заблокировали и восстановили те, по которым пришли жалобы, что пропал доступ или не работает сервис.

Кадровая информация для IdM является непогрешимым источником данных, и если в ней есть ошибки или неточности, они автоматически перейдут в IdM и далее распространятся по всем системам

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

10

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

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