13.09.2021Процесс интеграции любого решения сферы информационной безопасности в существующую ИТ-среду компании имеет свою специфику и сопутствующие проблемы. Внедрение же IdM/IGA-систем зачастую приобретает форму наиболее сложных проектов.
Как сделать процесс внедрения более эффективным? Что поможет техническим специалистам и команде лучше понять желания и потребности заказчика и быстрее реализовать необходимый функционал?
Рассказывает заместитель директора департамента по производству Solar inRights Виктор Еремин.
Имеет ли процесс внедрения решений IdM специфические особенности по сравнению с другими продуктами?
Своя специфика есть во всех продуктах безопасности, где-то внедрение сложнее, где-то проще.
С этой точки зрения IdM/IGA – это сложная система. На первый взгляд кажется, что пул задач не такой большой и существенный, однако сложность реализации оказывается достаточно высокой. Это связано с тем, что в процессе внедрения возникает очень много интеграционных решений, а сами бизнес-процессы, которые нужно автоматизировать, – тоже достаточно сложны.
Ни одна система безопасности не обладает таким же широким охватом различных процессов компании. Изменения затрагивают практически все направления бизнеса и работы компании, и возникает много заинтересованных сторон. Для внедрения IdM-системы наведение порядка в процессах является одним из ключевых аспектов эффективности/успешности.
Обычно, пока инцидент не произошел, никто не думает о плохих последствиях.
Часто бывает так, что компания сначала несет серьезные убытки от возникшего инцидента ИБ, связанного с правами доступа, и только потом начинает задумываться о том, что нужно предпринимать соответствующие меры, чтобы в будущем такого не происходило. В любой компании есть отступления от правил, и внедрение IdM-систем как раз решает такие проблемы, вносит технологичность и согласованность в предоставление доступа и в целом – в бизнес компании.
Правда ли, что инженер внедрения должен быть мастером на все руки?
Да, именно так – он должен быть мастером на все руки. Это объясняется тем, что охват технологий, связанных с внедрением IdM, очень большой, по причине того, что это интеграционный проект, который обеспечивает взаимодействие со многими информационными системами.
Инженер внедрения IdM должен знать:
- структуру баз данных;
- различные операционные системы;
- инфраструктурные сервисы;
- серверы веб-приложений;
- IdM-решение;
- возможности интеграции и др.
Поэтому инженер – это действительно мастер на все руки, который с каждым очередным проектом приобретает все новые и новые знания. Здесь важны и навыки получения самих этих знаний, и опыт их эффективного применения на новых проектах.
Применяются ли какие-то специальные методики/практики, чтобы процесс внедрения сделать более эффективным?
Для того чтобы предлагать нашим клиентам технологичность, надо самим быть технологичной командой, не бояться использовать различные приемы и практики.
Понимая всю сложность внедрения решения IdM, мы стараемся свести ее к минимуму. И добиваемся ее снижения, например, за счет типизации процессов.
Для инженеров мы разработали ряд технологических карт, которые позволяют специалисту выполнять определенные действия в зависимости от решаемой задачи и от входных условий, понимать, какое действие в какой ситуации будет наиболее правильным.
Технологические карты позволяют:
- выделить типовые операции;
- описать шаги выполнения;
- понизить порог вхождения для новых специалистов.
Эти карты носят скорее рекомендательный характер, так как кастомизация системы может быть на разном уровне, – но в целом основные типовые элементы настройки и типовые процессы ими покрываются. За счет описания технологии с помощью карт-шагов, дающих исчерпывающие ответы по необходимости и цели каждого действия, мы понизили порог сложности решаемых задач для инженеров внедрения: продвинутые инженеры используют их как чек-листы, а начинающие – как подробную инструкцию, сокращающую время на онбординг (знакомства с технологией внедрения) и повышающую скорость и качество работы.
Удалось ли вам, используя эти методики, достичь желаемых результатов?
Мы начали все задачи выполнять быстрее. Если раньше требовалось от трех до шести месяцев, для того чтобы научить человека внедрять систему IdM, то сейчас, за счет документации, нового подхода к проектированию и технологических карт, требуется полтора месяца. Это значительное сокращение времени погружения для нового специалиста, которое позволяет команде расти и расширяться в ответ на требования бизнеса.
Аналогично и для реализации проектов. Технологические карты позволяют даже опытным инженерам перепроверить себя и при помощи чек-листа к технологической карте убедиться, что никаких ошибок не сделано. А если какие-то неточности были допущены, то в дальнейшем на сервисе карта позволяет быстро диагностировать ошибку и ее исправить.
Используете ли вы в работе известные популярные методологии: в проектировании, в разработке, в инженерных работах?
В проектировании мы применяем системный подход. Внедрение IdM – это достаточно сложный и долгий процесс, и в случае неудачи у нас нет возможности перевнедрить систему повторно. Поэтому уже до начала внедрения мы прорабатываем очень детально техническое решение, применяя методику системного подхода.
За рубежом ее называют технологией OMG-essence. Эта модель позволяет архитекторам увидеть жизненный цикл создаваемой конструкции IdM во всем комплексе и определить перечень необходимых работ и компонентов будущей системы таким образом, чтобы она удовлетворяла потребностям клиента.
Мы используем некоторые элементы из Agile-философии и, в частности, методологию Scrum. Наша команда работает короткими циклами, следующими один за другим так называемыми спринтами, в результате каждого из которых создается какая-то ценность для наших клиентов.
А инженеры используют элементы метода Kanban – то есть не в чистом виде, а в гибридном. Например, kanban-доски для отслеживания движения задач и backlog-журнал с перечнем рабочих задач с указанием их приоритетности, а так же применяем спринты и еженедельное планирование для координации работ.
Насколько важно, чтобы инженер – технический специалист мог разговаривать с заказчиком на языке бизнеса?
Скорее важно уметь говорить с заказчиком на одном языке, на разных уровнях и в разных контекстах. Самому инженеру не очень нужно и важно разговаривать именно с бизнесом на языке бизнеса - для этого есть другие участники команды. Но с администраторами систем на стороне заказчика, с ИТ специалистами, со специалистами служб информационной безопасности инженер должен общаться на одном языке, понимая предметную область, понимая терминологию – что бы быстро договариваться о необходимых шагах.
Архитекторы, в отличие от инженеров, выходят на коммуникации на уровень бизнеса, потому что это необходимо для защиты решения. Важно понимать все особенности и системы IdM, особенности решаемых бизнес-задач и постараться всё донести доступно (без специфической терминологии), чтобы было понятно бизнес-аудитории.
В некоторых случаях присутствие на встречах бизнес-аналитика помогает решить задачи корректной коммуникации и получить от встречи максимум пользы и эффективности. Например, у нас в команде, в зависимости от разных проектов, есть сложившиеся пары архитектор-аналитик, которые взаимно дополняют друг друга.
Каковы ваши ближайшие планы по развитию?
Если говорить про развитие команды внедрения, то мы будем продолжать курс на снижение сложности внедрения. Развивать универсальность наработок, чтобы можно было использовать их от проекта к проекту. Типизация создаёт прозрачность внедрения и это очень важно для наших заказчиков и партнёров.
Если говорить про развитие, с точки зрения нашего позиционирования, то здесь у нас тоже большие планы. В прошлом году мы сертифицировали коннектор к системе 1С, в будущем году мы планируем получить сертификат совместимости с решением SAP. Это достаточно амбициозная для нас задача.
Если говорить про развитие продукта, то мы очень внимательно смотрим на потребности заказчиков и планируем развитие функционала согласно потребностям, которые возникают на проектах. А также разрабатываем функционал, который приближает наше решение к тому, чтобы заказчики могли самостоятельно настраивать, обслуживать и поддерживать систему. Чтобы настройка системы была достаточно простой и технологичной.
Если же говорить про развитие технологии, то мы строим планы по обновлению технологического стека нашей платформы и уже даже сделали первые шаги в этом направлении.
Расскажите об интересном и позитивном проекте/опыте, который вам особенно запомнился?
Каждый проект внедрения IdM обязательно начинается с обследования. Часто случается так, что заказчик не всегда осознаёт масштаб изменений, которые принесёт проект и новые задачи, которые перед ним возникнут. И к команде, которая пришла внедрять ему систему, поначалу относится с недоверием.
Наши специалисты в процессе обследования всё подробно проговаривают, делятся своей экспертизой, опытом внедрения. Фактически раскрывают все проблемы, связанные с внедрением, предлагают грамотные решения по возникающим задачам. Т.е. в этот период мы заручаемся поддержкой заказчика и его доверием.
Это приносит свои плоды: у нас есть ряд позитивных проектов, где заказчик прислушивается к нам, как к экспертам, и в результате проект идёт более гладко для всех сторон, и на выходе мы получаем хороший результат и положительную обратную связь.
Слышать друг друга и уметь вовремя донести информацию, предварительно её проработать – это очень важно при внедрении сложных систем. И мы стараемся это совершенствовать.
О чем, что мы сегодня не обсудили, вам бы хотелось еще рассказать?
Мне хочется пожелать заказчикам, нашим партнерам, техническим специалистам не бояться участвовать в проектах внедрения IdM-системы. Потому что существуют значительные риски, связанные с избыточным доступом, которые зачастую сразу не видны, и они несопоставимы с той сложностью, которая возникает в процессе внедрения.
Лучше работать на опережение.
Да и сами процессы нужно приводить в порядок, чтобы было все прозрачно и подконтрольно. Лучшие мировые практики говорят о том, что нужно стремиться создавать прозрачную среду работы сервисов.
IdM – этот как раз такая история.
