Как организовать проект создания корпоративной системы управления правами доступа к информационным ресурсам, часто обозначаемой аббревиатурой IAM (Identity and Access manager) или IDM (Identity manager)? Автор подробно рассматривает конкретные аспекты и последовательность реализации такого проекта, не затрагивая архитектурные особенности обсуждаемых решений. И хотя речь идет исключительно об IDM, большинство из предлагаемых подходов применимы к проектированию и других сложных систем.

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

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

Бизнес-аргументы и поиск союзников

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

• доступ к информационным ресурсам (ИР) предоставляется автоматически, а потому исключено проявление «человеческого фактора»;
• доступ пересматривается по определенному сценарию, как только из источника кадровых данных поступают сведения об изменении позиции пользователя;
• обеспечивается автоматизированный контроль над конфликтами полномочий (SoD-конфликтами) как при формировании ролей в виде совокупности других ролей, так и при назначении пользователю новых ролей;
• для разных ролей, пользователей или групп можно задать индивидуальные режимы пересмотра рисков, и IDM автоматически запускает их по заранее определенной логике;
• истории согласования электронных заявок на изменение доступа в IDM можно хранить вечно и индексировать, что позволяет мгновенно находить любую из них;
• безопасность электронного согласования в IDM значительно выше, чем при использовании сканированного образа.

Правда, эти «плюсы» не всегда можно выразить количественно, поэтому вам понадобятся и доводы, связанные с экономией ресурсов. Например:

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

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

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

На крупных предприятиях анализом корпоративных бизнес-процессов, оценкой связанных с ними рисков и проблемами внутреннего контроля может заниматься специализированное подразделение. Обычно конфликты полномочий (SoD-конфликты) представляют в виде гигантских матриц, проверять которые вручную при каждом согласовании заявки на доступ невозможно. Однако данную задачу прекрасно автоматизирует IDM, что, безусловно, заинтересует подразделение внутреннего контроля.

Разделяй и властвуй

Залог успеха проекта – четкое понимание его границ и постоянный контроль над их неизменностью. При определении функциональных границ не следует включать в них «впрок» все потенциально полезные свойства. Эти затраты сложно обосновать: они необходимы сейчас, а востребованность «запасных» функций в будущем туманна. К тому же расширение границ проекта отнимает ресурсы, которые можно направить на реализацию 20% функционала, дающих, по закону Парето, 80% эффекта внедрения. При «адаптации» функциональных требований в ходе проекта для обеспечения их постоянной адекватности, скорее всего, вы этот проект вообще не реализуете. Функционал должен «закрывать» только актуальные задачи, а временные рамки проекта – составлять не больше года!

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

Например, весь функционал IDM поделен на первостепенный, второстепенный и остальной, а структурные подразделения – на Центр, ключевые и остальные. На I этапе первостепенный функционал разрабатывается и внедряется в Центре. На II этапе он тиражируется в ключевых подразделениях. На III этапе второстепенный функционал разрабатывается и внедряется там, где уже действует первостепенный; одновременно первостепенный функционал тиражируется в остальных подразделениях. На IV этапе второстепенный функционал тиражируется в остальных подразделениях, а остальной функционал разрабатывается и внедряется в Центре. На V этапе остальной функционал тиражируется в тех подразделениях, в которых завершилось внедрение второстепенного.

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

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

Полезно вспомнить, как вы обосновывали внедрение IDM. Нужно снизить стоимость процессов контроля доступа и сократить время простоя пользователей в ожидании доступа? Значит, первыми ИР в последовательности функциональной реализации должны стать те, по которым больше всего заявок и/или которые характеризуются наибольшей трудоемкостью их обработки. Хотите устранить денежные потери из-за простоя новых сотрудников и ожидания изменения доступа уже работающих? Тогда первыми реализуйте бизнес-процессы «прием на работу» (передача данных о работнике из кадровой службы в наиболее востребованные корпоративные ИС) и «назначение роли пользователю» (обеспечение маршрутизации заявки между согласующими и ее исполнения).

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

Аналогичный подход применим и к географии: определим структурные подразделения, внедрение в которых IDM даст наиболее заметный эффект. Например, это подразделения с наиболее дорогими трудовыми ресурсами или те, чья специфика работы обусловливает максимально большое количество заявок на изменение прав доступа.

Команда экспертов

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

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

Выбор критериев оценки

К набору критериев оценки IDM предъявляются следующие требования:

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

Рассмотрим этапы формирования списка критериев.

1. Каждый эксперт формирует свой перечень критериев оценки. Перечни могут не соответствовать требованиям к критериям, но должны покрывать все требования к системе.
2. Перечни критериев сводятся в единый список. Он может не удовлетворять требованию неизбыточности.
3. Экспертная группа проводит процедуру «отсеивания» требований. При обсуждении автор требования должен доказать остальным экспертам его важность. В случае несогласованности позиций решение принимается путем голосования. Результирующий список должен соответствовать всем требованиям к критериям оценки системы.

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

Стратегии выбора и порядок оценки решений

Возможны следующие стратегии выбора нужных решений.

• «все сами». Вы ставите задачу собственным программистам, и они пишут ровно то, что вам нужно, а затем выполняют весь комплекс работ по развитию продукта;
• «покупаем индивидуализированную коробку». Разработчик на основе ваших требований создает кастомизированную ветку своего продукта. Этот вариант представляется проигрышным: вы получаете по нерыночной цене эксклюзивный продукт, стоимость дальнейших поддержки и развития которого будет неадекватной;
•  «покупаем готовую коробку», которая максимально покрывает наши потребности, и проводим с разработчиком переговоры о стратегическом партнерстве. Данный вариант – наилучший с точки зрения адекватности цены сопровождения и развития. При его выборе оцените «срочность» решения (насколько долго заказчики готовы ждать какой-либо функционал) и сравните ее с «дорожной картой» появления нового функционала у разработчика, оцените потенциал разработчика (квалификация сотрудников, особенности процесса разработки и т.д.) и архитектуру продукта с точки зрения расширения (подход к модульности, наличие API для разработки дополнений и пр.).

Возможны, например, такие этапы оценки предлагаемых на рынке решений.

1. Для ознакомления с потенциально подходящими решениями (их техническими возможностями, сильными и слабыми сторонами) организуются рабочие встречи ваших специалистов с представителями производителей. После рабочей встречи производитель отправляет в компанию заполненный список требований к его решению. Список передается каждому эксперту, который дает по нему свои варианты оценки ( ). Затем эксперты вычисляют совокупные оценки решений (S), на основе которых выбираются три лидирующих продукта.
2. Проводятся референс-визиты к прежним заказчикам выбранных решений. Каждый из продуктов нужно увидеть внедренным с функционалом, не меньшим, чем обещанный производителями (либо определяется функционал самого успешного внедрения). Необходимо узнать, каков реальный опыт работы с этими продуктами. Затем эксперты обсуждают и, возможно, корректируют результирующие оценки.
3. Результирующие оценки выносятся на бизнес-уровень, обсуждаются с заказчиками, потом выбор экспертов утверждается всеми заинтересованными лицами.

Вычисление экспертной оценки

Экспертная оценка i-го требования j-ым экспертом ( ) представляет собой целое число от 0 до 100 (0 – полное неисполнение требования, 100 – полное соответствие ему). Рекомендуется задать критерии выбора экспертных оценок, что позволит защититься от субъективизма:

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

Результирующую оценку (S) можно представить как