Владислав Алмазов: При внедрении IdM важно создать в компании компетенции бизнес-анализа

Владислав Алмазов, руководитель отдела сопровождения информационных технологий компании Lamoda Group, рассказал Anti-Malware.ru об опыте выбора и внедрения IdM-системы в быстрорастущем ритейлере, а также разъяснил, как при этом удалось повысить эффективность работы ИТ-департамента, сохранить гибкость в настройке прав доступа и возможности самостоятельной и быстрой доработки системы в условиях постоянно меняющейся среды.

С 2014 года вы начали внедрение IdM-системы. Почему возникла такая необходимость?

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

Начались обследования: что у нас есть. На тот момент компании было 3 года, и она уже имела огромное количество систем, потому что быстро развивалась: бизнес рос вдвое каждый год. Соответственно, как внутренние разработки, так и внешние системы требовали управления, в том числе - именно пользователями, поскольку количество сотрудников в компании тоже росло. Классические решения вроде службы технической поддержки, писем, заявок, ссылок не всегда справлялись, потому что есть человеческий фактор, и мы всегда считали, что человек – это слабое звено. Иначе говоря, все рутинные задачи должны быть автоматизированы, потому что человек ошибается, а если человек ошибся – это риск не пройти аудит, риск не соответствовать требованиям. Даже одна ошибка в критичной системе может привести к минусу в аудите с соответствующими последствиями. Поэтому изначально была проведена инвентаризация, мы выделили информационные системы, сделали для них карточки, где определили бизнес-владельцев, технических владельцев, многие другие атрибуты, а также разработали процедуру согласования. Классическая процедура согласования для всей Lamoda стандартна: мы определили, что по умолчанию для всех систем в ней участвуют линейный руководитель и бизнес-владелец. Для некоторых систем это привело к развитию данного подхода: мы назначали делегатов по определенным процессам, т.е. бизнес-владелец мог делегировать какую-то роль другому человеку по разным причинам. Инвентаризация служила инструментом для технической поддержки, которая при приеме заявок определяла, к какой системе и команде они относятся. Использовалась она и для разработки ITIL-модели. Таким образом, это помогло всей компании.

Сколько времени потребовалось на первичный аудит, построение ролевой модели, внедрение?

В.А. Это - непрерывный процесс, он до сих пор идет, но первый большой прыжок – полтора года. Дальше уже было развитие, то есть подключение и обработка новых систем, разработка ролевой модели, которую мы интегрировали c Active Directory (у нас она обеспечивает аутентификацию во всех системах). Я читал интервью с представителем «Ренессанс Кредита» о том, как они у себя «боролись» с Axapta и в итоге сделали в IdM коннектор; мы пошли другим путем, у нас вся ролевая модель в Axapta была интегрирована с AD. Иначе говоря, когда мы добавляем пользователя в AD, он сразу получает необходимую роль и привилегии в Axapta.

Вы изначально все делали сами, или у вас были выделены специалисты, которые занимались проектом?

В.А. Изначально, когда мы составили ролевую модель, она развивалась, но на тот момент была не такой зрелой, как сейчас, и тогда мы пришли к решению внедрять систему управления. Кроме того, у нас есть 1С, и в нее поступает вся актуальная информация о сотрудниках: когда они работают, когда они уволены. (Кстати, благодаря этому доверенному источнику кадровой информации в нашей компании не бывает такого, что сотрудник уволен, но до сих пор работает и до сих пор получает зарплату.) Кадровых систем у нас четыре, так как мы работаем с четырьмя странами: Россия, Украина, Беларусь, Казахстан. Все эти подструктуры соединены с 1С, и она берет оттуда информацию. Соответственно, было принято решение внедрять систему IdM; на тот момент мы остановились на российском решении Avanpost. Это была разработка под нас, мы использовали стороннюю компанию, которая внедряла решение и «допиливала» для нас.

То есть к вам с этой системой пришел какой-то интегратор?

В.А. Да, мы воспользовались услугами интегратора. Они оценили то, что у нас уже есть, какую детализацию мы уже провели, и внедрили это решение в объеме управления должностными доступами. Мы всегда стремились к тому, чтобы писать ролевую модель компании, чтобы свести к минимуму количество индивидуальных запросов. Раньше мы использовали следующий принцип: есть IdM-система и есть атомарный доступ, роль в системе. Бизнес-процесс, бизнес-роль пользователя мы тогда не описывали. Соответственно, получалось, что имеется должность работника в 1С и существует набор ролей в разных системах, которые нужно назначить для этого сотрудника. Но в перспективе мы поняли, что это большая боль, потому как компания растет: если сравнить штатную структуру сейчас и год назад, то это уже просто будут две разные организации. Lamoda постоянно меняется, появляются новые компетенции, новые департаменты, новые блоки. Процесс построен так, что HR без согласования с нами ничего не меняет в 1С, потому что это нарушит работу системы IdM; соответственно, только с нашего согласия, когда мы готовы к переводу какого-то блока, может произойти реорганизация, разделение, соединение, даже просто переименование, и уровень доступа при этом остается таким же. Для IdM это важно, потому что в системе может возникнуть, например, другой идентификатор.

Сколько на первичном этапе было подключено систем для управления доступом?

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

И все остальные права - через AD?

В.А. Да. Наш первый приоритет, первичная задача – это финансово критичные системы, потом - бизнес-критичные системы, и при разработке ролевой модели некоторые из них имели локальную авторизацию и даже локальную аутентификацию. Мы приводили их в соответствие; на тот момент мы использовали AD-аутентификацию, а сейчас мы переходим к SSO и авторизации по группам AD (т.е. все роли 1-в-1 соответствовали этим группам). На сегодняшний день все системы синхронизированы с AD. Какие-то смотрят в режиме реального времени, какие-то - выгружают по cron раз в час.

Какая-то разработка понадобилась?

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

Получается, что у вас просто не было большого количества Linux-систем, отдельно стоящих систем, которые с AD не контактируют?

В.А. Мы используем ключи, там другая система, которая тоже «смотрит» на AD для управления ими. У нас 90% систем разработаны и функционируют на Linux. Все достаточно технологично, современно. Большинство приложений «крутится» в Docker и Kubernetes.

В какой момент пришло осознание того, что старой IdM-системы, с которой вы начинали, недостаточно? Что сподвигло на поиск нового, более зрелого решения?

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

То есть вы хотели больше гибкости для собственной разработки и конфигурирования внутри системы?

В.А. Да. Мы хотели перейти к ролевой модели, иметь гибкость в работе с интерфейсом, workflow, хотели все реализовывать быстро и уметь это делать самостоятельно. У нас все системы разработаны самостоятельно, мы заказываем такую систему, которую, кроме нас, никто не использует. Поэтому нужен был фреймворк, где имелись бы возможности для работы программиста. Мы посмотрели на рынок, изучили несколько решений и остановились на One Identity Manager. На тот момент я практически ничего о нем не слышал, потому что тогда оно еще не присутствовало на российском рынке и только старалось на него выйти. Нам действительно понравилось то, что это - workflow, большой конструктор, бесконечный лес функционала, который  можно было «допиливать», а то, что не поддавалось доработке, - допрограммировать и сделать отдельным модулем. Конечно, это был вызов, нужно было разбираться с большой системой, но мы выбрали это решение, потому что оно полностью удовлетворяло все наши желания и потребности.

Вас не останавливало то, что это было для вас новым проектом, что все пришлось бы делать заново? Ролевая модель, конечно, остается, но надо ее переносить на другую платформу...

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

Итак, в конце 2017 года вы купили One Identity Manager...

В.А. Да. Этап до запуска у нас составил один год. В 2019 году, во втором квартале, мы полностью выключили старую систему. При этом было несколько этапов запуска. В первую очередь мы делали функционал, равный тому, что имелся в старой системе: полностью переносили ролевую модель, переезжали по блокам, постепенно отключая один за одним. Потом был «день Х»: мы сравняли старую ролевую модель с новой и полностью переключились.

Конечных пользователей как-то затронул этот переход?

В.А. Никто не заметил. Были нюансы, но в целом мы достаточно плавно это сделали. Опять же, мы запускались в четыре этапа, начиная с сентября 2018 года.

Можете ли Вы отметить какой-то набор функций, который стал для вас ценен уже после переезда?

В.А. Сначала мы действительно смотрели на полное совпадение функционала, 1-в-1. Раньше у нас был подход «система-роль». От этого мы перешли к подходу «система-привилегия-роль»: начали описывать сотрудника не по должности, присваивать ему вместо этого бизнес-роль, т.е. совокупность системных ролей, которую может описать аналитик, руководитель. Теперь в организационной структуре есть человек, который описывает бизнес-роли. Мы решили, что нам это удобнее. Бизнес-роли мы разработали в момент, когда переключали российское подразделение.

Получается, что системная роль – это атрибут для бизнес-роли?

В.А. Да. Низший уровень – это привилегия; из привилегий состоит системная роль. Сотрудник пользуется несколькими системами, и мы все это описали. Например, есть бизнес-роль «оператор call-центра»; у такого оператора имеется набор из 37 системных ролей. Для IdM это множество полномочий выглядит как одна целая бизнес-роль, которую мы прикрепляем к штатной структуре.

Бизнес-роли составляли руководители отдельных подразделений?

В.А. У нас есть отдельное подразделение бизнес-анализа, которое этим занимается. Это - группа из двух человек, которые хорошо осведомлены обо всех нюансах. Мы, скажем так, познали большинство бизнес-процессов, а там, где не знаем, – просто спрашиваем. Общаемся в чате, в почте.

Как вы все это делали, в большой таблице Exсel?

В.А. В Confluence. Впрочем, таблицы Exсel, документы Google и другие подобные инструменты тоже используются для некоторых процедур. Все описание ролевой модели сводилось в Confluence, где содержится инвентаризация всех информационных систем. В каждой карточке системы есть раздел, который называется LAM (Logic Access Management); там описана должностная ролевая модель и прочие атрибуты.

Помимо добавления бизнес-ролей, что еще было важно и что приятно удивило после переезда на новую систему?

В.А. Не сказал бы, что нас что-то удивило. Мы получили именно то, что мы ждали. Это оказалось удобно, и мы начали развивать систему. Сейчас наша цель - полностью перейти на бизнес-роли, описать все бизнес-роли в компании, распределить на каждого человека не более трех бизнес-ролей, чтобы кадровые процессы не слишком отвлекали соответствующие подразделения. Так мы автоматически управляем всеми ролями. Добились того, что, когда мы говорим о бизнес-ролях, сотрудники понимают, о чем идет речь. При этом бизнес-роль не обязательно строго соответствует штатной должности: у нас есть, например, менеджер проектов, который выступает еще и как разработчик.

Как на данный момент устроен процесс запросов дополнительных привилегий через киоск самообслуживания?

В.А. Это было одной из причин перехода. Возможность встроить киоск была и в предыдущей системе, но нам не очень нравились возможности настройки и интерфейс. Поэтому одним из пунктов в тендере, когда мы закупали новое решение, как раз был киоск. Реализация IT-shop, «магазина доступов», была вторым шагом его внедрения, и у нас уже есть положительная обратная связь: пользователям очень нравится исполнение в формате магазина. На тот момент у нас 95% доступов управлялось через должностные шаблоны, ролевую модель, бизнес-роли и т.д., а 5% запрашивалось вручную, в виде заявки в хелпдеск, где сотрудник поддержки искал роли, направлял на согласование, работнику выдавалась группа в AD и т.д. Мы хотели и хотим сейчас этот этап полностью автоматизировать, чтобы человек не принимал в нем участия. 95% - это 300-900 операций IdM-системы в день, и, соответственно, еще где-то 10-60 заявок касаются индивидуального доступа. Они бывают типичными и поэтому со временем тоже описываются как бизнес-роли, причем руководители подразделений иногда сами приходят с такими пожеланиями.

К бизнес-ролям привязана выдача компьютера, телефона?

В.А. Были привязаны, у нас была описана ролевая модель для оборудования, но мы сейчас отходим от нее, потому что решили стандартизировать это оборудование. Раньше у нас был набор из трех видов компьютеров PC и двух видов Maс, но людям оказалось тяжело его поддерживать, и никто из руководителей не хотел этим заниматься: для каждой должности надо было описать пять типов компьютеров, что, конечно, являлось сложной задачей. В итоге мы от этого отказались. Теперь есть два варианта - PC и Mac; если хотите индивидуальную сборку (например, более мощный компьютер), то обращайтесь в техподдержку.

При этом у нас остался функционал при выходе нового сотрудника, раннее введение учетной записи, потому что нам необходимо иметь такую информацию заранее. Там есть HR-интерфейс, HR заблаговременно заводит в систему сведения, можно сразу назначить индивидуальные доступы, и тут же создается запрос на оборудование. Обычно процесс подготовки оборудования для рабочего места занимает 3 дня, и мы стараемся сделать так, чтобы сотрудник с первого дня уже мог начинать работать. Есть еще отдельная тема с системами, которые никуда не интегрированы и работают локально, так как у нас целевая система – это не только AD. В таких случаях формируется заявка в Jira. Допустим, создается роль в системе, которой нет в AD; IdM ставит задачу, и соответствующие команды выдают нужный доступ, готовят оборудование и т.д. В итоге, когда сотрудник приходит на рабочее место, там уже лежит, например, Mac, и рекрутер приносит в конверте пароль.

Получается, что даже если коннектора к IdM нет, и все делается через Jira, то IdM все равно об этом знает, и это можно использовать, например, для compliance?

В.А. Да. И, что важно, когда сотрудник увольняется, а в какой-то системе (например, внешней) применяется локальная авторизация или аутентификация, тоже ставится задача через Jira, после чего администратор удаляет пользователя и закрывает ее.

Правильно ли я понял, что сейчас вам для работы IdM нужно всего три коннектора: для 1С, для AD и для Jira?

В.А. Jira работает через почту, но в целом да. Сейчас мы уже подключаем Google, есть план перейти на их SSO, чтобы управлять не только пользователями. Нужно работать с лицензиями, создавать учетные записи, блокировать их, управлять приложениями (почта, Google Cloud, другие сервисы). Самое важное – это работа с группами рассылок. Их - бессчетное количество, и ими нужно управлять вручную. Мы это все поместим в IT-shop. Сейчас люди не могут сами добавиться в группу (менеджер должен одобрить), а после этих изменений все будет очень просто выглядеть: есть список групп, открываешь любую и вступаешь. И еще, кстати, мы очень ждали перехода на новую версию IdM, где в коннекторе уже есть управление не только пользователями, но и их контентом. При блокировке пользователя весь его контент переносится в специальный архив.

Возвращаясь к IT-shop: расскажите подробнее о его возможностях.

В.А. В нем есть всё: и внутренние, и внешние системы, которые используются в компании. Для каждой описан бизнес-владелец, технический владелец, есть карточка LAM. Имеется подструктура для каждой страны, в AD размечено огромное количество систем и ролей для каждого города, для каждого экспресса. Если человеку нужен доступ, то он создает запрос, пишет обоснование, и дальше заявка пойдет по процедуре согласования руководителю и бизнес-владельцу соответствующей роли. У каждого запроса можно посмотреть, на каком этапе он находится, какой этап будет следующим и т.п. В общей сложности сейчас в IT-shop введено порядка 5100 системных ролей для 70 сервисов; до конца квартала мы планируем окончательно перенести в него все системы. В частности, это сильно снижает нагрузку на службу технической поддержки: если то, о чем просит пользователь, доступно через IT-shop, то поддержка просто присылает инструкцию для самостоятельных действий.

Еще в IT-shop имеется управление делегированием: например, я ухожу в отпуск на неделю, и тогда я выбираю определенного сотрудника из своих подчиненных и указываю для него те атрибуты, которые он временно получит (допустим, согласование роли бизнес-владельца такой-то системы). Могу часть атрибутов делегировать одному сотруднику, часть – другому. При этом, хотя запросы на выдачу ролей теперь будут приходить подчиненным, я тоже буду их получать, чтобы знать, что происходит. Также удобно, что если сотрудник уволился и никому не передал свою роль (и делегирование при этом не назначено), то это выводится как исключение (exception), и оно идет по отдельному пути в группу бизнес-анализа. Бизнес-анализ, соответственно, узнаёт, что была, допустим, запрошена роль, у которой нет бизнес-владельца, мы выясняем, почему это произошло и кто теперь будет курировать эту роль, а затем (когда назначен новый владелец) снимаем exception, и заявка идет дальше по согласованию. Все процессы, связанные с прохождением заявок через IT-shop, осуществляются автоматически, без участия человека: достаточно нажать кнопку.

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

Первый экономический эффект уже есть?

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

Я хотел уточнить о типичных функциях ИБ: анализ рисков, разделение обязанностей... Они уже используются, или это - следующий этап?

Это - следующий важный этап. У нас уже описаны матрицы SoD, и они внедрены напрямую «под приложение». C этим связаны ситуации, когда выдача человеку определенной роли может конфликтовать с матрицей, поэтому мы хотим полностью перевести SoD в IdM. Реализовать такую задачу легко; сейчас это – только вопрос времени. В том, что касается анализа рисков, - нужно провести инвентаризацию уровня риска для систем и бизнес-ролей, и тогда мы сможем собирать статистику. Есть такой вариант: при достижении определенного уровня риска сотруднику, например, необходимо пройти курс по борьбе с фишингом, аттестацию. Система обучения у нас уже есть, так что мы можем внести туда нужный курс и сделать так, что при запросе каких-то ролей у сотрудника будет появляться exception с информацией о необходимости его пройти.

Работа с инцидентами происходит? Вы видите, что человек запросил аномальные права, кто-то выдал не то, что должно быть?

В.А. Мы проводим ретроспективный анализ, но в дополнение к этому у нас есть классификация «чувствительных» ролей. Все такие sensitive-роли должны быть одобрены отделом информационной безопасности. Через нас проходит много заявок, половина – точно. Где-то мы просто уведомляемся, а где-то процесс действительно требует нашего участия. Например, нельзя запросить привилегии администратора в любой системе без согласования с нами. То же касается ролей, которые имеют доступ к персональным данным.

А если, допустим, человек в обход IdM получил права администратора в какой-то целевой системе?

У нас это так не реализовано, т.е. нельзя просто создать нового администратора. Для этого у нас есть процедуры пересмотра привилегированного доступа, которые выполняются раз в квартал, а также процедуры реконсиляции, которые мы проводим каждые год-два. В рамках аудита мы тоже осуществляем анализ, особенно для финансовых систем, где это – обязательное требование. Берем пользователей в системе и сверяем их с AD на предмет несовпадений.

Вы планируете какие-то нововведения для работы с привилегированными пользователями?

В.А. Да, мы планируем внедрять для этого специальный продукт, который тоже будет интегрироваться с IdM. Сейчас это сделано через инструмент собственной разработки.

У вашей компании есть несколько крупных филиалов в СНГ. Какие особенности это накладывает на использование и внедрение IdM системы? Есть ли какие-либо сложности?

В.А. Если мы говорим о персональных данных, то в России ФЗ-152обязывает нас проводить их актуализацию на территории РФ. Раньше Роскомнадзор говорил «сбор», теперь они используют слово «актуализация». Обработку мы можем делать где угодно, хранить – опять же где угодно. В странах СНГ тоже есть подобные законы, но не везде установлены жесткие требования. Бывают терминологические разночтения: например, по-разному трактуется слово «хранение» применительно к персональным данным. Клиентские базы данных к нам и к IdM отношения не имеют; если говорить о работе кадровых систем, то они действительно расположены в каждой стране, и на территории каждого из четырех государств мы имеем либо свой ЦОД, либо свою серверную, но при этом тоже нет особых требований, потому что все-таки в IdM не осуществляется сбор персональных данных. Даже предварительное введение данных сотрудника через HR-интерфейс реализовано только для России; для остальных стран все вводится через 1С локально, не нарушая местные нормативы. IdM и вся его инфраструктура находятся в ЦОДе в Москве.

Получается, что все запросы из филиалов идут через Москву?

В.А. В 1С заносится все локально, AD распределен, в каждой стране у нас свой контроллер, но управление осуществляется из ЦОДа в Москве. Построена отказоустойчивая инфраструктура: например, колл-центр подключен по четырем каналам. Везде есть как минимум два канала, даже в маленьких пунктах самовывоза в далеких городах. Повсюду - полная связанность.

Бизнес развивается, вы расширяете каталог, опции доставки, открываете новые пункты вывоза заказов. IdM помогает вести эти процессы быстрее?

В.А. Да. Сотрудники заводятся в кадровую систему в определенном городе, им выдается определенный набор привилегий. Они работают в нескольких системах и при выходе на работу уже имеют все необходимые полномочия: например, торговый представитель может залогиниться на своем планшете и видеть заказы своего города, своей точки.

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

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

Как вы планируете развивать IdM в этом году?

В.А. В том, что касается IT-shop: мы хотим настроить такую функцию, которая позволит сотрудникам согласовывать доступ где угодно. Для этого мы собираемся внедрить мобильное приложение, благодаря которому сотрудник сможет, не заходя с компьютера, увидеть запрос и сразу отклонить его, подтвердить или отправить на доработку, причем не обязательно из корпоративной сети, но с безопасным подключением. Удобно, когда эти возможности реализованы с помощью push-уведомлений. Будем также работать над интерфейсом киоска, тем более что там все можно настроить и изменить с помощью конструктора.

Что Вы посоветуете тем, кто только присматривается к такого рода системе, в том числе компаниям из области ритейла? На что нужно обратить внимание, какие подводные камни стоит учесть?

В.А. При выборе системы нужно исходить из потребностей. Если компания растет, и требуется постоянно менять системы, то тогда нужен фреймворк. Я бы, конечно, посоветовал развивать компетенции внутри команды. Есть разные подходы, можно и отдать на аутсорсинг, если изменения невелики; но когда есть внутренняя компетенция, все процессы идут значительно быстрее, чем в ситуации, когда всё приходит извне. Многое зависит от ресурсов и от объемов. Фреймворк действительно удобен для тех, кому нужна гибкость. Мы считаем, что система IdM не должна ломаться, сразу содержать большое количество багов или работать нестабильно. Я думаю, что стоит выбрать надежное, устойчивое решение, которое позволит бизнесу не только успешно работать, но и адаптироваться.

Как сделать так, чтобы бизнес-подразделения скорее приветствовали внедрение IdM-системы, а не препятствовали этому процессу?

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

Исходя из Вашего опыта, укажите на основные ошибки. Чего не следует делать при внедрении IdM-системы?

В.А. В какой-то момент не очень удобно описывать системные роли, привязываясь к функционалу сотрудника. Лучше описать функционал системы. Например, вместо ролей «менеджер» и «кассир» стоит сделать роль «работа с кассовым модулем». Пусть в IdM будет описание бизнес-роли, а в системе – описание системной роли. Это будет наглядно, и при аудите не возникнет вопросов. Если вы управляете системными ролями напрямую, то можно бизнес-роли оставить в системе и описать их вместе с привилегиями внутри нее. Мы у себя старались выделить уровни привилегий, уровни системных ролей - так удобнее проходить аудит и настраивать бизнес-роли. Не нужно для каждой системы придумывать что-то индивидуальное.

Можете ли Вы представить себе работу компании без IdM?

В.А. Да, представить можно. Назначить 8 человек, которые будут работать над тривиальными задачами. Будет допущена куча ошибок, появится множество случаев мошенничества. Но кто сейчас так сделает? Можно вместо экскаватора нанять 10 рабочих, которые будут копать лопатами. Это долго, это неправильно, это неудобно. Когда есть возможность автоматизировать – нужно это делать. Поэтому мы вкладываемся в профессионалов по автоматизации.

Большое спасибо за интервью!