Как правильно построить процесс внедрения IdM-системы, кто и за чей счёт должен разрабатывать ролевую модель, можно ли использовать для обработки запросов, связанных с назначением прав и ролей, уже имеющуюся службу пользовательских обращений? Эти и другие вопросы обсудили практикующие специалисты, эксперты и представители заказчика на «Баттле IdM-интеграторов», организованном компанией One Identity.
- Введение
- Как формировать содержание и концепцию проекта
- Какие подходы к внедрению наиболее перспективны для IdM
- Можно ли внедрять IdM-систему без готовой ролевой модели
- Как строить ролевую модель
- Правильная клиентская часть IdM
- Коннекторы, интеграция, данные
- Выводы
Введение
В январе 2021 года компания One Identity Russia собрала в одной студии четырёх интеграторов, специализирующихся на внедрении IdM-решения Identity Manager, представителя заказчика и трёх экспертов от вендора, чтобы обсудить практику реализации проектов в области управления правами и доступом. Дискуссия, получившая название «IAM Talking: Баттл IdM-интеграторов», заняла почти три часа и затронула главные аспекты внедрения систем этого класса.
В дебатах приняли участие:
- Андрей Каганский, руководитель группы внедрения IdM компании УЦСБ.
- Анастасия Мирошкина, аналитик IdM-проектов компании «Инфосекьюрити» (группа компаний SoftLine).
- Александр Едриванов, технический эксперт и тренер «One Identity Россия».
- Кирилл Карташев, руководитель технического отдела «One Identity Россия».
- Алексей Колпаков, представитель управления информационной безопасности АО «ОТП Банк».
- Роман Ястребов, системный архитектор IdM компании Softailor, ГК «Открытые технологии».
- Юрий Касулин, руководитель и эксперт по IdM компании GreenLight Technologies.
Модерировал дискуссию Яков Фишелев, руководитель представительства One Identity в России и СНГ.
Предлагаем вам краткий обзор ключевых идей, высказанных экспертами в студии. Полную запись дискуссии можно найти на YouTube-канале One Identity Russia.
Как формировать содержание и концепцию проекта
Дискуссия стартовала с базовых вопросов, возникающих на начальных этапах сотрудничества интегратора и заказчика. Что собой представляет «скоуп» (охват) проекта внедрения IdM-системы? Должен ли он быть максимально обширным, нести больше ценности, но предполагать длительные сроки реализации, или же необходимо сконцентрироваться на наиболее важных задачах, предполагающих быстрое внедрение?
Как отметили собравшиеся в студии эксперты, задача «скоупа» — продемонстрировать заказчику будущие результаты внедрения IdM-системы. При этом речь идёт не только о руководстве компании и сотрудниках подразделения, являющегося прямым получателем конечного решения, но и о смежных департаментах. Как отметил Юрий Касулин, затраты на внедрение несёт вся компания, поэтому эффект должен быть отчётливо виден всем заинтересованным лицам. Анастасия Мирошкина посоветовала обязательно включить в «скоуп» автоматизацию рутинных операций, которые в данный момент выполняются в ручном режиме — так эффект от внедрения IdM будет более заметным.
Роман Ястребов назвал три «группы влияния», которые должны увидеть эффект от внедрения системы: бизнес, информационная безопасность и ИТ. «Скоуп» должен решать проблемы каждой из них, иначе полной вовлечённости достичь не удастся. «Заказчик любит глазами» — с таким неожиданным тезисом выступил Андрей Каганский. Эксперт напомнил: нельзя забывать, что красивый портал, возможность построения отчётов и другие аспекты визуализации являются важной частью внедрения. Нельзя уводить разработку «скоупа» только в «техническую» часть.
Итог обсуждению подвёл Александр Едриванов: первый этап внедрения должен включать небольшое количество систем, обеспечивающих максимальный эффект для заказчика. Небольшой охват с ключевыми системами несёт больше выгод для бизнеса, для пользователей и для администраторов. Кирилл Карташев добавил также, что приступая к внедрению можно начать параллельное движение — одновременно подключать типовые, инфраструктурные элементы и работать над подготовкой к интеграции специфичной (и важной для конкретного бизнеса) системы.
Какие подходы к внедрению наиболее перспективны для IdM
Следующей темой для обсуждения стали методы ведения проекта. Насколько жёстко заказчик и интегратор должны формализовать параметры внедрения? Необходимо точное техническое задание или допустим гибкий подход? Как совместить необходимость изменений, открывшуюся в процессе реализации проекта, с изначально определёнными финансовыми параметрами?
Как отметили эксперты в студии, для гибкого подхода при внедрении требуется высокий уровень доверия между интегратором и заказчиком. При этом, чтобы не терять гибкости, необходимо каждый раз искать «золотую середину» — например, зафиксировать конечную цель (для заказчика) и трудозатраты (для исполнителя). Ещё один вариант — провести agile-сессию перед заключением договора, чтобы точнее определить параметры ТЗ. Безусловно, важно чётко обозначить границы проекта, чтобы он не превратился в неуправляемое бесконечное действие.
По мнению спикеров, при работе по ТЗ интегратору необходимо оставаться в диалоге с заказчиком и быть готовым к изменениям. Один из вариантов, предложенных экспертами, — писать техническое задание по этапам, чтобы обеспечивать проекту должную гибкость, не теряя из виду конечной цели. Собравшиеся в студии отметили, что процесс внедрения не должен быть для заказчика «чёрным ящиком» — необходимы регулярные встречи, на которых стороны могли бы обсуждать состояние проекта. Такая вовлечённость заказчика даст ему возможность влиять на ход работ и позволит интегратору в определённой степени корректировать ожидания другой стороны.
Чёткое ТЗ нужно на первом этапе — оно необходимо для участия в конкурсе, для выбора системы и формирования первоначального «скоупа», который покажет заказчику ключевые выгоды от внедрения. В дальнейшем, по мере увеличения доверия к интегратору и росту вовлечённости заказчика, можно пробовать более свободные формы сотрудничества. При подведении итогов дискуссии прозвучала мысль, что методику работы (ТЗ или «agile») можно также определить при помощи пилотного проекта, в ходе которого заказчик и исполнитель смогут лучше узнать друг друга.
Уровень вовлечённости заказчика — это ещё один важный вопрос, который обсудили эксперты. Команда клиента не должна оставаться сторонним наблюдателем процесса внедрения, поскольку именно ей в большинстве случаев приходится осуществлять дальнейшее сопровождение системы. Как точно отметил Роман Ястребов, интегратор — это третья линия поддержки, разбирающая наиболее сложные вопросы.
При этом участие заказчика не должно ограничиваться только этапом ввода IdM-системы в эксплуатацию. Андрей Каганский и Анастасия Мирошникова подчеркнули, что команда клиента должна быть вовлечена в проект и во время подготовки ТЗ, и в ходе его реализации. На вопрос Алексея Колпакова о том, как заставить сотрудников подразделений заказчика, не относящихся к ИТ и ИБ, участвовать во внедрении, Юрий Касулин ответил, что в первую очередь людей надо заинтересовать, показав преимущества, которые они получат после реализации проекта.
Можно ли внедрять IdM-систему без готовой ролевой модели
Продолжая разговор о практике внедрения IdM-систем, эксперты в студии One Identity затронули важный вопрос о необходимости консалтинга на предварительном этапе проекта. Действительно, возможно ли «автоматизировать хаос»? Есть ли шансы на удачное внедрение IdM в случае отсутствия у заказчика разработанной ролевой модели? Можно ли «разгребать процессы» по ходу внедрения?
Анастасия Мирошникова посоветовала начать с описания основных кадровых функций — приёма, увольнения, перемещения. Это обеспечит хороший старт внедрения IdM и быстрое получение первого результата. Разработку ролевой модели и описание остальных бизнес-процессов можно выполнять по мере реализации проекта. Сначала — «база», потом — всё остальное.
Юрий Касулин отметил, что ролевая модель устаревает на следующий день после того, как её согласовали. В том, чтобы фиксировать её в начале внедрения, нет особого смысла. Гораздо лучше уложить ролевую модель на готовый IdM-инструментарий, что позволит поддерживать её в актуальном состоянии.
Роман Ястребов напомнил, что согласование полной ролевой модели потребует множества ресурсов и может серьёзно увеличить сроки и затраты проекта. Эксперт посоветовал придерживаться двух постулатов — «дорогу осилит идущий» и «слона надо есть по кусочкам», то есть формировать ролевую модель по ходу внедрения IdM-системы.
Андрей Каганский, согласившись с коллегами по поводу неразумности разработки ролевой модели до внедрения IdM, высказался о практике создания отдельных ролей для каждой заявки на доступ. По мнению представителя компании УЦСБ, оправданность такого подхода необходимо оценивать на основе статистики — ведь не факт, что созданная таким образом роль будет назначена более чем одному сотруднику.
Как строить ролевую модель
Продолжая тему консалтинга, модератор дискуссии затронул вопрос о методах построения ролевой модели. Как должен быть построен процесс определения ролей? Что должно лежать в основе этого процесса — исторические данные и анализ (Role Mining) или же мнение бизнеса, полученное через опросы руководителей, изучение должностных инструкций и другие инструменты?
По мнению собравшихся экспертов, наилучшие результаты даёт симбиоз этих методов. Исторические данные дают понимание текущей матрицы доступа, а опросы руководителей — информацию о том, насколько она соответствует целям и задачам компании в сфере управления правами. Действующие доступы в разрезе подразделений и отдельных сотрудников необходимо обсудить с владельцами бизнес-процессов, чтобы отсечь лишние права и, возможно, добавить новые роли.
Для того чтобы между интегратором и заказчиком не возникло недопонимания, спикеры в студии порекомендовали заранее оговаривать, на каком этапе, кем и за чей счёт будет создаваться ролевая модель. Role Mining — это не волшебная кнопка, которая избавит от всех проблем, а лишь отправная точка для построения ролевой модели. Важно понимать также, насколько глубоко интегратор готов погружаться в управление ролями и где проходят границы проекта. Например, должны ли его рамки включать настройку ролей в SAP или иной системе, используемой заказчиком?
Эксперты заметили, что успеху проекта поможет обучение сотрудников заказчика инструментам составления ролевой модели и подключение их к этой работе ещё на этапе внедрения. Другая важная мысль, высказанная гостями студии, — не существует универсального метода построения ролевой модели. То, что подходит для банка, не подойдёт для производственной компании. Немаловажную роль играет также размер организации — чем меньше заказчик, тем проще построить ролевую модель.
Правильная клиентская часть IdM
Яков Фишелев попросил представителей интеграторов поделиться опытом организации порталов для обработки заявок. Какой инструментарий лучше для этого использовать — встроенные средства IdM-системы (в Identity Manager это — модуль IT Shop) или же ITSM-портал, который уже внедрён у заказчика для приёма других запросов пользователей?
Роман Ястребов:
— К этому вопросу можно подходить с точки зрения удобства пользователя. Если в компании есть развитый «service desk» (инструментарий работы с пользовательскими заявками. — Прим. ред.), на который «завязаны» и заявки получаемые из других систем, то, возможно, лучше интегрировать туда функции IdM-портала. Когда такого инструмента нет, логичнее использовать отдельный веб-интерфейс IdM.
Процесс согласования доступа в Identity Manager может проходить двумя путями: встроенные алгоритмы IdM-системы; встроенные алгоритмы внешней системы (не обязательно уровня «service desk») с передачей результата согласования в IdM.
Андрей Каганский:
— Мне как интегратору удобнее использовать IT Shop, входящий в состав Identity Manager, поскольку я самостоятельно разрабатываю этот портал и могу быть уверен в его функциях. С другой стороны, если заказчик уже построил экосистему своих бизнес-процессов вокруг своего «service desk», то вряд ли возможно его перевести на портал IdM-системы.
Юрий Касулин:
— Процесс согласования в IdM-системе выполнять проще: там есть необходимый набор функциональных возможностей, чтобы выстроить алгоритмы с точки зрения владельцев ролей, согласующих, руководителей. При этом на ITSM-портале можно оставить ссылку на соответствующую заявку в IdM, а также создать единое облако тегов для обеих систем, чтобы облегчить поиск.
Анастасия Мирошникова:
— Пользователям удобнее иметь единый сервис для обработки заявок, поэтому, реализуя его через IdM, возможно, придётся дублировать часть функций ITSM. Реализация портала обработки заявок при помощи IdM-системы позволяет привязать процессы, связанные с доступом, к событиям кадровой системы — например, переназначению ответственного в случае увольнения.
Что же касается возможности публикации IT Shop в интернете, то наши эксперты высказали мнение, что это имеет смысл только для быстрого доступа руководителей к инструментам согласования. Рядовым пользователям такая возможность не нужна. Единственная вещь, которая может потребоваться сотруднику извне, — это сброс пароля, остальные вопросы доступа к ресурсам при удалённой работе решаются при помощи VPN. Другой аспект этой проблемы — портал саморегистрации внешних пользователей. Его имеет смысл сделать в качестве отдельной, защищённой реплики общего интерфейса с ограниченными функциями.
Коннекторы, интеграция, данные
Заключительная часть беседы была посвящена вопросам связи IdM-систем с другими решениями, которые использует заказчик. Эта часть внедрения традиционно вызывает множество вопросов. Например, должна ли синхронизация с кадровыми системами быть событийной или же выполняться регулярно?
Как пояснили спикеры, зачастую регулярная синхронизация мало чем отличается от событийной, поскольку события также накапливаются в стек, который обрабатывается с заданной периодичностью. Технически возможно реализовать и событийную синхронизацию в режиме реального времени, однако использование очереди даёт возможность обрабатывать отмены или изменения кадровых событий, которые нередко случаются в больших организациях. Чем реже обрабатываются кадровые события, тем меньше риск передать в IdM-систему незавершённую операцию, которая в итоге приведёт к ошибке.
Безусловно, существуют экстренные события (например, незапланированное увольнение сотрудника), которые необходимо передать в IdM оперативно; для этих целей существует интерфейс блокировки пользователя. Поэтому при внедрении системы управления доступом необходимо найти «золотую середину» в вопросах частоты синхронизации. Как точно подметил Юрий Касулин, все клиенты хотят обмен в режиме реального времени, важно объяснить, что им он не нужен.
Периодичность опроса кадровой системы должна подбираться под конкретного заказчика. Одним из факторов выбора времени обновления информации является нагрузка на кадровую систему, создаваемая запросами. В практике экспертов, собравшихся в студии, были примеры использования промежуточной базы данных, в которую собирается информация из нескольких систем, для выгрузки в IdM.
Продолжая разговор о связи с другими системами, гости студии коснулись вопроса о реализации функций управления рисками и соответствием требованиям в SAP средствами IdM-системы. Спикеры отметили, что подобные проекты встречаются крайне редко: в случае если у заказчика уже внедрена SAP GRC, он, скорее всего, откажется от передачи её функций в IdM. Что же касается интеграции с другими решениями, например SSO- или PAM-системами, то, по мнению собравшихся в студии экспертов, правильно спроектированный IdM способен облегчить внедрение таких решений. Спикеры подчеркнули, что если заказчик ещё не внедрил SSO или PAM, то разумно построить архитектуру на два решения в совокупности, а внедрять их — поочерёдно.
Выводы
В качестве итога дискуссии приведём сформулированные участниками дебатов три главных преимущества внедрения IdM-системы. Их можно использовать как обоснование необходимости подобного решения для заказчика.
- Снижение затрат на администрирование прав доступа за счёт автоматизации рутинных операций.
- Быстрый выход человека на работу, сокращение простоев, связанных с оформлением и «вводом в строй» нового сотрудника.
- Повышение безопасности за счёт сокращения рисков (излишние права, оставшийся после увольнения доступ и т. д.).
