Внедряем IdM. Взгляд со стороны инженера внедрения

Продолжаем наш цикл статей о внедрении систем автоматизированного управления доступом (IdM), который мы некогда активно начали, но в последнее время как-то сбавили обороты. Исправляемся 🙂 Ранее мы рассказывали о том, что такое IdM, для чего он нужен, как финансово обосновать его внедрение и т.п. Сегодня речь пойдет о том, какие подводные камни могут возникнуть при внедрении системы, и как их обойти и не набить себе множество шишек.

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

Формулируем функциональные требования

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

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

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

• Прием нового работника (создание учетных записей с первичными правами, согласно должности и подразделению).
• Запрос новых полномочий для работников (согласование, автоматическое и полуавтоматическое исполнение заявок).
• Перевод работника по должности (выдача полномочий, соответствующих новой должности, подтверждение или отзыв старых полномочий).
• Увольнение работника (блокировка всех его учетных записей с отзывом всех ролей).

В Функциональных требованиях по процессу Прием нового работника стоит написать следующее: система считывает информацию о новом работнике из кадровой системы, создает учетную запись в Active Directory (AD), назначает группы, необходимые по должности, создает учетную запись в CRM, назначает профиль и роли также в соответствии с должностными обязанностями.

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

Рисуем схему взаимодействия компонентов системы

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

Итак, мы поняли, что для реализации перечисленных автоматизируемых процессов в рамках первого этапа нужно интегрироваться всего с тремя системами:

• с кадровой системой 1С: ЗУП,
• с Active Directory от компании Microsoft как основным провайдером полномочий пользователей в инфраструктуре предприятия,
• с основной бизнес-системой CRM, написанной и поддерживаемой сторонним вендором под заказ.

Нужно сразу представлять себе схему взаимодействия компонентов будущей системы.

Как видим, IdM – в центре, и это не случайно. Именно IdM после внедрения будет «альфой и омегой», содержащей в себе всю актуальную информацию о работниках компании, всех их учетных записях в интегрированных с IdM системах и о том, какими ролями, группами и полномочиями работники должны в этих системах обладать. Именно благодаря «щупальцам» IdM, пронизывающим все сопряженные с ним системы, зарегистрированный в кадровой ИС перевод Иванова Сергея Петровича из бухгалтерии в юридический отдел компании автоматически повлечет изменение групп и атрибутов его учетной записи в AD и изменение его ролей и профилей в других системах компании, с автоматическим запуском всех необходимых процессов согласований и уведомлений. Но все это будет работать только тогда, когда все компоненты системы будут хорошо и правильно интегрированы между собой. А чтобы это получилось, повторюсь, нужно тщательно все продумать и спроектировать.

С этим багажом выходим на покупку.

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

Создаем проектную команду и делаем предпроектное обследование

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

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

Здесь в полной мере потребуются те самые необходимые и достаточные полномочия участников проектной команды заказчика для сбора и предоставления исполнителю всей необходимой информации о внутреннем устройстве процессов компании. Именно о внутреннем устройстве процессов компании! Каждый автоматизируемый процесс, описанный в Функциональных требованиях, нужно тщательно исследовать от начала до конца. Кто осуществляет первичный сбор информации, ее состав и формат, в какую систему информация вводится, в какие передается, каким образом, по каким протоколам, с помощью какого ПО? Кому эта информация нужна для дальнейшей деятельности, и в каком виде она им нужна, где должны остаться следы о производимых операциях… Словом, всё, всё, всё, что касается каждого исследуемого процесса.

Пишем ТЗ

На выходе предпроектного обследования должен получиться еще один важный с точки зрения внедрения документ (даже важнее, чем Функциональные требования) – Техническое задание (ТЗ). Что в нем должно быть? Тут важно ничего не упустить и тщательно все продумать. Потому что упущение маленьких и, казалось бы, незначительных нюансов может вылиться в большие проблемы при реализации.

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

Например, кадровый процесс Прием нового работника в ТЗ будет выглядеть так:

1. Работник кадрового делопроизводства вводит информацию о новом работнике в кадровую систему 1С: ЗУП. В обязательном порядке заполняет следующие поля: … (перечисляется, какие именно).
2. IdM получает данные о новом работнике из кадровой системы 1С: ЗУП, определяет должность и подразделение нового работника. Создает профиль нового работника в IdM. Логин формируется по таким-то правилам, пароль по таким-то. Данные о логине пароле нового работника отправляются туда-то по таким-то каналам связи (указать, откуда IdM берет адресата).
3. IdM автоматически создает учетную запись в AD с атрибутами (перечисляем) в каталоге (OU – Organization Unit), соответствующем подразделению нового работника. Логин формируется по таким-то правилам, пароль по таким-то. Данные о логине и пароле нового работника отправляются туда-то по таким-то каналам связи (указать, откуда IdM берет адресата, и параметры канала связи).
4. Созданная учетная запись AD помещается в группы (перечисляем или указываем «согласно ролевой модели»). Ролевую модель также нужно будет продумать и описать в ТЗ отдельной главой. Назначение таких-то групп осуществляется по согласованию с теми-то лицами (перечисляем). Система формирует уведомления о назначении полномочий новому работнику (указываем алгоритм определения получателей; отдельно описываем маршруты согласования), а также напоминания согласующим о необходимости согласовать заявку (указываем алгоритмы определения получателей, начало, конец и периодичность напоминаний).
5. После создания учетной записи в AD IdM инициирует создание почтового ящика Exchange для нового работника. Информация о новом почтовом ящике сохраняется в IdM и отображается в карточке работника.

Примерно в том же ключе описываем взаимодействие системы с CRM…

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

Простой пример: при изменении ФИО работника в кадровой системе его ФИО должно поменяться в профилях всех остальных подключенных к IdM систем. Но может и не поменяться, потому что в некоторых системах ФИО просто не хранится.

Пример посложнее: выдвинуто требование, что учетная запись AD нового работника должна создаваться в OU, соответствующем его подразделению. Возникает вопрос, что делать, если в кадровой системе заведено новое подразделение, а в AD его еще не создали? Таким образом выявляется отдельный процесс воспроизведения оргштатной структуры, хранящейся в кадровой системе, в AD, который также стоит описать в ТЗ.

Интегрируемcя с системами

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

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

Поясню на примере. Чтобы связать электростанцию с утюгом в целях нагрева последнего ради выполнения им известных функций, нужно, чтобы у электростанции была розетка, а у утюга вилка. Розетка и вилка. 2 вещи. Не одна. С помощью розетки на стороне электростанции и вилки на стороне утюга происходит интеграция утюга с энергосистемой. В случае интеграции IdM с любой другой системой тоже нужно 2 вещи: коннектор на стороне IdM и API на стороне системы. Это важно! Иначе могут происходить разные неприятные казусы. Назначение коннектора состоит лишь в том, чтобы принимать от системы необходимые данные в том виде, в котором она их отдает, и передавать их в IdM в том виде, в котором IdM может их принять. То же самое коннектор делает и в обратном направлении: получает команду и набор данных от IdM в том виде, в котором их выдает IdM, и передает все это системе в том виде, в котором система поймет, что ей надо сделать. НО! Система должна в принципе уметь выдавать нужные для IdM данные и выполнять необходимые для работы в паре с IdM команды. В этом и заключается основное назначение API – предоставить интерфейс, на который IdM сможет воздействовать с помощью коннектора для выполнения различных операций в системе.

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

• Поиск всех учетных записей системы. Входных параметров нет. На выходе – список всех учетных записей со всеми их атрибутами.
• Поиск учетной записи по идентификатору. Входной параметр – идентификатор УЗ. Выход – учетная запись, удовлетворяющая условиям поиска, со всеми атрибутами.
• Создание учетной записи. Входные параметры – логин, пароль, ФИО… Выход – идентификатор новой УЗ.
• Блокировка учетной записи. Входные параметры – идентификатор УЗ. Выходных параметров нет.
• И т. д…

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

Далее у заказчиков, как правило, возникает вопрос, вызывающий ноющую зубную боль у инженера внедрения IdM: почему API к системе не может реализовать интегратор IdM’а своими силами?

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

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

Бедный Паша-программист – сотрудник интегратора IdM’а – пытается судорожно понять, какие приседания надо сделать, чтобы добиться от системы нормальных реакций. Изучает общедоступные источники, скупую, устаревшую документацию, разбирается в исходном коде неизвестной ему системы и обрывает вендору телефоны. Через пару недель мытарств он понимает, что одних приседаний недостаточно, нужны еще подпрыгивания, да еще и с сальто, и не факт, что и это поможет… И вот через месяц на свет появляется коннектор, какой-никакой, более-менее работающий. Слегка подглючивает, ну уж как получилось. Бедный Паша-программист в штате интегратора поседел, пока его писал. Волшебная система интегрируется, но вот незадача – учетки создаются не очень корректно, и админ системы должен вручную «докручивать» учетку до рабочего состояния. Пароли меняются через раз, а у «везучей» Марины Ивановны из бухгалтерии то и дело блокируется учетная запись. Работники «бизнеса» заваливают техподдержку злобными жалобами «Доколе???», «Невозможно работать!», «Сделайте, как было…» По началу заказчик требует все исправить и бьет по столу тапком так, что долетает до уже полысевшего Паши-программиста. Потом, из-за частых сбоев и растущего недовольства бизнес-подразделений, интеграция IdM с волшебной системой упраздняется.

И что тут сделаешь? Кто виноват? Если не вендор системы, то кто должен разобраться во всем наделанном им же хаосе из справочников, функций, табличек, триггеров, флагов и костылей? Интегратор IdM’а? Откуда он знает, как правильно реализовать функцию в системе, в которой не может разобраться сам вендор? А если и может, то за отдельные немалые деньги? Да, я сейчас сильно сгущаю краски; бывают исключения, когда система не очень сложная, и с ней можно интегрироваться без специального API. Но будьте благоразумны. Если цель все-таки – избежать ненужных проблем, помогать бизнесу развиваться и получать прибыль (а это, на мой взгляд, основная цель IT-подразделения в любой компании) и радоваться безотказной работе всех систем, задумайтесь о способах интеграции с системами. Заложите в бюджет необходимые затраты на исследование возможностей интеграции и грамотную реализацию недостающих компонентов. Скупой платит дважды, а то и трижды. Поберегите в конце концов Пашу-программиста :D. Он уже почти лысый. И не забудьте закрепить способы интеграции в ТЗ!

Строим ролевую модель компании

Еще отдельно хочется заострить внимание на формировании ролевой модели компании. Дело в том, что каждая система обладает своим эксклюзивным набором так называемых «полномочностных» сущностей – объектов, обеспечивающих полномочия пользователей в системе. К этой категории объектов могут быть отнесены всевозможные группы, роли, профили, назначения, каталоги, привилегии, типы операций и т. д… Грануляция прав может быть очень глубокой, в результате получаем необозримо огромное количество управляемых объектов. Например, одних групп безопасности в AD может быть несколько сотен, а то и тысяч. В некоторых системах управления финансами каждому пользователю можно назначить эксклюзивные права на каждый счет из миллиона содержащихся в плане счетов. А если интегрируемся с SAP’ом? Количество атомарных прав может измеряться сотнями тысяч и даже миллионами.

Кроме того, в системе может поддерживаться иерархическая вложенность и сложные связи между различными типами полномочных сущностей. Это само по себе уже тянет на отдельное исследование возможностей управления пользовательскими правами в системе. Поэтому прежде чем проектировать у себя внедрение IdM, нужно в обязательном порядке, исходя из задач проекта, определиться, какими именно правами и на каком уровне их гранулярности вы собираетесь управлять посредством IdM. Главное вовремя остановиться. Во всем должна быть необходимость и достаточность. Если вы захотите управлять в системе отдельными правами пользователей для каждого счета, приготовьтесь к соответствующим объемам работы по согласованию и отзыву прав пользователей при каждом изменении в плане счетов.

При работе над ролевой моделью необходимо определить:

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

В сухом остатке

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

Не стесняйтесь и главное не ленитесь разобраться во всем. А мы вам в этом поможем.

Автор Мария Тюрина, инженер внедрения Solar inRights