Связаться с редакцией
Как обычно осуществляется подготовка к IdM-проектам и почему стандартный подход не всегда работает?
Какие этапы должна включать подготовка к внедрению IdM?
Что дает аудит перед стартом IdM-проекта?
В процессе реализации проектов нам приходится решать различные проблемы. При этом многие из них возникают из-за того, что на этапе подготовки проекта остаются неучтенными важные детали, о которых становится известно уже в процессе внедрения. Например, в крупном банке в ходе выполнения проекта по внедрению IdM выяснилось, что в автоматизированной банковской системе (АБС), которую требовалось подключить к IdM, не было механизма для взаимодействия — API. Произошло это, когда первый этап проекта уже был выполнен и стартовали работы по второму этапу. При этом управление учетными записями в АБС являлось основной целью внедрения IdM и ключевым требованием на проекте, а без API подключение этой системы не представлялось возможным. Банку пришлось привлечь разработчика АБС и приостановить проект по внедрению IdM — до реализации механизма. В результате бюджет проекта увеличился на сумму затрат на доработку системы, а сроки сдвинулись на 6 месяцев. Почему компании сталкиваются с подобными трудностями и как можно избежать неприятных сюрпризов при внедрении системы управления доступом, расскажем в статье.
В этой жизни определено только то, что нет ничего определенного.
Плиний Старший
Почему нельзя просто взять и внедрить IdM-решение
Как правило, компании подходят к внедрению IdM так же, как и к реализации любого другого проекта. Обычно данный подход состоит из нескольких этапов.
Этап 1. Формирование общих требований
Сначала компании формируют перечень требований к IdM-решению. В большинстве случаев это происходит следующим образом. Компании отправляют запрос подрядчику с просьбой оценить стоимость IdM-решения. Подрядчик в ответ присылает опросный лист, состоящий из типовых вопросов. Как правило, они касаются четырех факторов:
- количество пользователей (внутренних и внешних);
- подключаемые информационные системы;
- автоматизируемые процессы; разрабатываемые документы.
Далее компании формируют перечень требований. Такими требованиями могут быть:
- автоматизация процессов: прием на работу, перевод, увольнение;
- наличие штатного коннектора к системам MS AD, Exchange, 1C;
- запрос прав доступа по заявке;
- ведение справочника внешних пользователей.
Эти требования являются верхнеуровневыми и не отражают всех особенностей того, как это должно быть сделано в проекте. Так, в крупной металлургической компании одним из требований было ведение справочника внешних пользователей — работников подрядных организаций. Данный функционал был реализован в следующем объеме: куратор в IdM-системе регистрирует внешнего пользователя, после чего IdM-система предоставляет ему необходимый доступ в информационные системы. Однако в ходе промышленной эксплуатации системы выяснилось, что данного функционала недостаточно. Из компании уволился сотрудник, за которым было закреплено больше 50 внешних пользователей, и всех их потребовалось перевести на другого работника. Для этого компании пришлось создавать 50 отдельных заявок, так как в системе не было возможности массового переноса подрядчиков в рамках одной заявки. В результате решение пришлось дорабатывать, что привело к дополнительным расходам на реализацию проекта. Однако этого можно было избежать, добавив на начальном этапе требование реализовать массовый перенос внешних пользователей в рамках одной заявки.
Этап 2. Выбор платформы
На данном этапе компании ищут решение, которое бы соответствовало общим требованиям. При выборе они используют сведения из открытых источников, а так же запрашивают данные у вендоров и интеграторов. На основе этой информации компании формируют сравнительную таблицу, в которой отмечают наличие того или иного функционала, стоимость решения, количество внедрений, наличие решения в рейтингах аналитических агентств Gartner и Forrester. В большинстве случаев ключевыми критериями для выбора являются функционал и стоимость. Если провести сравнение представленных на российском рынке решений на основе общих требований, то можно прийти к выводу, что все они одинаковые. Соответственно, это приводит к тому, что зачастую выбор осуществляется на основе одного критерия — стоимости решения. На самом деле отличия в системах есть, только для их выявления требуется проводить более детальное сравнение.
Этап 3. Пилотный проект
Еще одним фактором, влияющим на окончательный выбор решения, является демонстрация его работы. Для этого вендор или интегратор выполняет пилотный проект. Как правило, для пилота создаются «лабораторные условия»: выделяются тестовая среда и тестовые данные в кадровой и информационных системах, а также выбирается наиболее простой для реализации и последующей демонстрации функционал (например, интеграция с системами AD и Exchange, управление учетными записями при приеме на работу и увольнении сотрудников). Однако зачастую «лабораторные условия» в корне отличаются от реальных данных и процессов. В ходе пилотного тестирования крайне сложно обнаружить ситуации, которые могут возникнуть при промышленной эксплуатации системы. Как это произошло в случае с внешними пользователями. В ходе пилотного проекта был продемонстрирован функционал по регистрации внешних пользователей, что соответствовало требованию к решению. А потребность в массовой заявке по переназначению внешних пользователей не была выявлена, так как в лабораторных условиях подобная ситуация едва ли может возникнуть.
Зачастую «лабораторные условия» в корне отличаются от реальных данных и процессов. В ходе пилотного тестирования IdM крайне сложно обнаружить ситуации, которые могут возникнуть при промышленной эксплуатации системы.
После проведения всех процедур компания уже может начать проект по внедрению IdM: сформированы общие требования, выбрано подходящее решение, подтвержденное пилотным тестированием. Осталось только найти подрядчика для выполнения проекта. С этой целью компании запускают процедуру сбора предложений RFP. В ответ на запрос они получают предложения от подрядчиков, стоимость работ в которых может варьироваться от миллиона до сотни миллионов рублей, а длительность — от нескольких месяцев до нескольких лет. Такую существенную разницу мы объясняем тем, что одни подрядчики учитывают в предложении выполнение дополнительных работ, которые могут возникнуть в ходе выполнения проекта, а другие этого не делают (см. рис. 1 и рис. 2). Рассмотрим пример одного из требований — автоматизации процесса приема сотрудника на работу. Если смотреть на него «в лоб», его реализация будет представлять процесс, состоящий из нескольких простых шагов. Несмотря на то что процесс будет автоматизирован, а требование формально выполнено, на практике может оказаться, что данный функционал окажется неудобным для использования. Произойдет это потому, что в таком варианте учитываются не все кейсы, возникающие при приеме на работу: совместительство, повторный прием на работу, отправка SMS-сообщения сотруднику с первоначальным паролем от учетных записей и т.д. Для решения проблемы в процесс нужно добавить дополнительные условия и действия. Это, в свою очередь, приводит к увеличению стоимости и сроков IdM-проекта.
Тем не менее компании считают разницу в стоимости и сроках парадоксальной: им кажется, что в предложения включены одинаковые работы. Поэтому в большинстве случаев делается выбор в пользу предложений с минимальной стоимостью услуг. Как результат — множество проблем на проекте. И дело не только в последующем увеличении бюджета и сроков проекта. Бывают случаи, когда подрядчик выполняет проект формально: «реализует систему строго по ТЗ», а не в соответствии с реальными требованиями компании. В итоге реализованной системой просто невозможно пользоваться.
Бывают случаи, когда подрядчик выполняет IdM-проект формально: «реализует систему строго по ТЗ», а не в соответствии с реальными требованиями компании. В итоге реализованной системой просто невозможно пользоваться.
Как мы пытались решить эти проблемы «по-простому»
Казалось бы, чтобы избежать перечисленных проблем, необходимо составлять более детальные требования и проводить пилотное тестирование наиболее сложного функционала с использованием реальных данных. Но, по нашему опыту, на практике такой сценарий не работает. Для составления детальных требований мы отправляли компаниям расширенные опросные листы, сгруппированные по тематикам: бизнес-процессы, интеграция с информационной системой, нефункциональные требования и т.д. Каждый из них содержал в среднем 70–80 вопросов. Однако мы ни разу не получили полностью и корректно заполненные опросные листы. Это связано с тем, что, во-первых, ответы на такое большое количество вопросов (для компании с 5 системами — около 800 вопросов) требуют много времени, а во-вторых, делать это должен опытный специалист, понимающий специфику работы IdM-системы и особенности ее внедрения.
Что касается пилотного проекта, то для его проведения в условиях, наиболее приближенных к реальным, необходимо выполнить большой объем подготовительных работ. В основном это обследование автоматизируемых процессов и подключаемых систем, доработка IdM-системы, создание копий продуктивных данных. В этом случае пилотный проект перерастает в полноценный проект по внедрению, что при водит к увеличению стоимости и срока его проведения. Поэтому в большинстве случаев ни компания, ни подрядчик не готовы брать на себя такие расходы.
Мы работаем на рынке IdM-решений с 2005 г. За это время наша команда реализовала более 30 проектов на базе 7 различных IdM-платформ в крупных организациях из различ- ных секторов экономики. Помимо реализации проектов, мы занимаемся исследованием рос- сийского рынка IdM-решений и в конце 2019 г. выпустили наш второй отчет. Он показывает, что за последние 5 лет интерес к теме IdM вырос: количество IdM-проектов в России увеличилось почти вдвое.
Правильный подход к подготовке IdM-проекта
Чтобы не столкнуться с вышеописанными проблемами, мы предлагаем использовать следующий подход при подготовке к проекту по внедрению IdM (см. рис. 3).
Шаг первый. Определение проблем
Сначала необходимо выяснить, какие проблемы должно решить внедрение IdM, и определить, подходит ли для этого подобный класс систем. Мы сталкивались с ситуациями, когда средствами IdM компании пытались решить задачи, для которых она не предназначена. Так, например, в одной компании ключевой задачей перед проектом по внедрению IdM было мгновенное оповещение специалистов ИБ о несанкционированном изменении прав доступа в информационных системах. Действительно, эту задачу можно решить и с помощью IdM, разработав модуль, реализующий такой функционал. Однако IdM не предназначена для выполнения подобного рода задач. Для этого целесообразно применять другой класс решений — SIEM. Поэтому на данном этапе важно определить, правильный ли инструмент компания планирует использовать для решения существующих проблем.
Мы сталкивались с ситуациями, когда средствами IdM компании пытались решить задачи, для которых она не предназначена.
Шаг второй. Аудит процессов и ИС
Как правило, IdM-проекты являются сложными и масштабными и затрагивают множество областей в компании. Поэтому на следующем этапе после определения проблем необходимо провести аудит, то есть обследовать те области, на которые влияет и от которых зависит внедрение IdM. Мы предлагаем аудит следующих областей (см. рис. 4).
В ходе обследования процессов управления доступом важно определить два основных момента. Во-первых, необходимо выяснить, как в действительности в компании осуществляются процессы управления доступом. Ведь зачастую процессы, описанные в регламентах или других документах компании, в жизни исполняются лишь частично либо по совершенно другому сценарию. Во-вторых, нужно оценить возможность автоматизации этих процессов. В случае, если текущие процессы автоматизировать невозможно, нужно определить необходимость и возможность их изменения. Бывают ситуации, когда текущие процессы изменить нельзя и это становится стоп-фактором для внедрения IdM. Например, в одной компании в начале каждого месяца существует 10-дневный таймаут по внесению информации о кадровых мероприятиях в кадровую систему, то есть в этот период IdM не сможет получать данные о кадровых мероприятиях и выполнять операции по управлению правами доступа. Изменение текущего процесса не представлялось возможным, поскольку это требовало изменений процедуры расчета заработной платы и работы кадровой системы. В результате кадровые процессы были автоматизированы частично.
На следующем шаге нужно провести аудит систем компании. Требуется сформировать их перечень, определить критичность, а также необходимость и целесообразность подключения к IdM. Кроме того, необходимо выявить внутреннюю логику управления доступом и выбрать способы подключения информационных систем к IdM. В случае, если у системы нет механизма для взаимодействия, рассматриваются варианты его разработки либо подключения системы как неуправляемой. После этого следует выяснить внутреннюю логику управления доступом в системах, то есть установить, какие объекты внутри них отвечают за предоставление доступа. Это делается, для того чтобы определить варианты переноса такой логики в IdM. Идеология работы IdM-решений основана на модели RBAC (Role Based Access Control). Это означает, что IdM управляет доступом только на основе ролей без управления атомарными полномочиями. Однако существуют системы, в которых, помимо ролей для управления доступом, используются дополнительные параметры. Это могут быть профили, группы, справочники и т.д. Для распространенных систем, например SAP, производители IdMрешений разработали коннектор, который позволяет управлять доступом, используя не только роли, но и дополнительные параметры. Однако это единичные примеры, и для нераспространенных или самописных систем есть два варианта подключения к IdM. Первый подразумевает, что IdM будет управлять доступом в этих системах только на уровне ролей, а второй — что вся внутренняя логика управления доступом будет перенесена в IdM. В последнем случае компании должны быть готовы к существенному увеличению стоимости подключения данной системы, а также к тому, что любое изменение логики управления доступом внутри системы потребует переработки функционала подключения этой системы.
Неуправляемая информационная система — система, управление правами доступа пользователей в которой автоматизируется посредством создания заявки на ее администратора в IdM. После этого он выполняет ее вручную.
Еще одна область, которую необходимо обследовать в рамках аудита, — кадровая система. Следует проанализировать текущие кадровые данные, чтобы выявить их специфику и определить полноту. Это нужно, для того чтобы оценить, достаточно ли текущих данных в кадровой системе для автоматизации процессов в IdM. Предположим, в компании 5000 сотрудников и десятой части из них не требуются рабочее место и доступ в системы. Создание учетных записей в IdM и информационных системах для них влечет за собой избыточный расход лицензий. Чтобы этого не произошло, IdM-решение должно получать информацию о том, что для этих сотрудников не требуется создавать учетные записи. Соответственно, нужно, чтобы в кадровой системе существовал признак необходимости рабочего места и его корректно заполняли специалисты кадрового учета.
Шаги третий и четвертый. Оценка возможности внедрения IdM и выполнение рекомендаций
После проведения аудита необходимо оценить, возможно ли в текущий момент внедрить IdM в компании и достичь поставленных целей. На данном этапе анализируются все данные, полученные в ходе аудита, проверяется, есть ли стоп-факторы, и определяются дальнейшие действия. Здесь может быть множество вариантов:
- старт проекта по внедрению IdM-решения в полном объеме;
- выполнение рекомендаций, доработка систем и изменение процессов, старт проекта после выполнения этих действий;
- разделение проекта по этапам, старт первого этапа, доработка систем и изменение процессов, подключаемых на дальнейших этапах;
- и др.
Cуть этапа наглядно продемонстрирована в табл. 1 и 2. В результате этих действий мы получаем перечень подключаемых систем, процессов и разделение работ по этапам.
Таблица 1. Оценка возможности подключения систем и автоматизации процессов
| Система | Количество пользователей | Критичность | Статус |
|---|---|---|---|
| Кадровая система 1С | - | Высокая | Подключение |
| Microsoft Аctive Directory | 5000 | Высокая | Подключение |
| Microsoft Exchange | 5000 | Высокая | Подключение |
| 1C Управляемая система | 300 | Средняя | Требуемая разработка механизма взаимодействия |
| Система бухгалтерского учета | 10 | Средняя | Подключение нецелесообразно |
| ITSM-система | 5000 | Средняя | Требуется доработка системы |
| Процесс | Статус |
|---|---|
| Прием на работу, перевод, увольнение | Возможна частичная автоматизация Отсутствует признак необходимости рабочего места |
| Прием на дополнительное трудоустройство | Полная автоматизация |
| Изменение учетной записи при изменении ФИО | Полная автоматизация |
| Добавление объекта в организационно-штатную структуру | Частичная автоматизация Неактуальная ОШС в кадровой системе |
| Удаление объекта из организационно-штатной структуры | Частичная автоматизация Неактуальная ОШС в каждой системе |
| Смена куратора для внешних пользователей | Автоматизация возможна Требуется доработка |
| Предоставление доступа к системе по заявке | Автоматизация возможна Требуется доработка |
Таблица 2. Оценка возможности внедрения IdM
| Процессы | Системы |
|---|---|
Этап 1
| Кадровая система 1С Microsoft Active Directory Microsoft Exchange |
Этап 2
| 1C Управляемая система ITSM-система |
Исходя из нашего опыта, мы можем сказать, что проведение оценки помогает снизить вероятность возникновения проблем на проекте. Так, в одной энергетической компании на начальном этапе требовалось за полгода внедрить централизованную IdM-систему в 40 юридических лицах компании и подключить к ней 16 информационных систем. После проведения аудита стало понятно, что в каждом юридическом лице был собственный кадровый источник, большинство информационных систем не имели механизмов взаимодействия и во многих из них управление происходило без использования ролей. Результаты оценки возможности внедрения показали, что IdM-проект можно запустить лишь после выполнения определенных действий. При этом проект по внедрению требовалось разделить на этапы: 1) сначала подключить системы, в которых есть механизмы для взаимодействия и используется ролевое управление доступом; 2) параллельно доработать другие информационные системы; 3) только после этого подключить оставшиеся системы. При таком сценарии первоначально запланированные 6 месяцев реализации превращаются в 3 года. Нетрудно представить, к каким проблемам привел бы запуск проекта без проведения аудита.
Шаг пятый. Формирование детальных требований
Удостоверившись в том, что рекомендованные действия выполнены и внедрение возможно, переходим к следующему этапу — формированию детальных требований. После проведения аудита подготовить этот документ не составит труда. По результатам аудита формируется детальный отчет, в котором отражается текущая ситуация по всем обследуемым системам и процессам. Информация из данного отчета упрощает процесс формирования требований, а сам отчет можно использовать в качестве приложения к RFP. К тому же еще один этап подготовки к проекту — выбор решения — будет происходить как бы в фоновом режиме, так как при наличии детальных требований сделать это гораздо проще: нужно лишь направить перечень требований вендору или интегратору, который ответит, удовлетворяет ли предлагаемый им продукт указанным требованиям.
Правильный подход: за и против
За почти 15 лет работы на рынке IdM-решений мы приняли участие в большом количестве конкурсов. На наш взгляд, в сравнении с подходом без аудита, предлагаемый нами подход к подготовке проектов по внедрению IdM выигрышно отличается тем, что позволяет существенно минимизировать риски и повысить вероятность достижения поставленных целей. Для подтверждения этого вывода приведем результаты сравнения двух вышеописанных подходов. Мы проанализировали данные об открытых конкурсах (см. табл. 3).
В проектах с аудитом количество участников было заметно меньше. При этом разница в стоимости предложений в таких проектах оказалась незначительной, в отличие от тысячекратного разброса, который мы видим в конкурсах, где подготовка происходила без аудита. Исходя из этих данных, можно предположить, что из меньшего числа участников с равными по стоимости предложениями вероятность выбрать подрядчика, который выполнит проект, существенно выше.
Несмотря на все преимущества, предлагаемый нами подход имеет и минусы. Первый и самый существенный из них — финансовый. Проведение аудита требует денег, времени и ресурсов независимо от того, будет ли он проводиться подрядчиком или силами компании. В последнем случае обязательным условием является наличие специалистов, обладающих экспертными знаниями и опытом внедрения IdM-решений. Как правило, стоимость аудита примерно равна стоимости этапа проектирования. Аудит не дает гарантии готовности компании к внедрению и возможности запуска проекта. Компания может потратить денежные средства на проведение аудита, а его результаты покажут, что на текущий момент внедрение idm не представляется возможным. Для компании это будет означать, что деньги и время потрачены впустую. С другой стороны, предположим, что компания запустила проект без проведения аудита и заложила десятки миллионов рублей и десятки месяцев на его выполнение. При этом после выполнения половины работ выявились стоп-факторы или проблемы, устранение которых потребовало дополнительных средств и времени. Получается, что во втором случае компания теряет значительно больше времени и средств.
Второй недостаток заключается в том, что после получения результатов аудита компании прекращают активность по подготовке к проекту по внедрению IdM. Многие руководители, узнав, какой объем работ требуется выполнить перед внедрением IdM-решения, «опускают руки» и отказываются от проекта.
В завершение отметим, что вы сами должны решить, какой подход выбрать. Готовы ли вы пойти на риск и сыграть по-крупному, поставив на кон все? Или для вас лучше сделать «проверочную ставку»?
Таблица 3. Сравнение конкурсов с использованием традиционного и предлагаемого нами подходов к подготовке к IdM-проекту
| Традиционный подход | Правильный подход | |
|---|---|---|
| Количество участников в конкурсе | 6—8 | 3—4 |
| Количество вендоров в конкурсе | 4—7 | 1—3 |
| Разброс по стоимости работ между участниками | До 1000% | 10—30% |
