Всеслав Соленик: С внедрением IDM новый сотрудник начинает работать уже через полчаса после подписания документов

Всеслав Соленик, руководитель отдела информационной безопасности банка «ДельтаКредит», подробно рассказал о процессе выбора IDM-системы и тонкостях ее внедрения, а также поделился рекомендациями для тех, кто собирается внедрять подобную систему.

Проект банка «ДельтаКредит» по внедрению системы управления учетными записями и правами доступа — IDM занял в этом году второе место в премии «Цифровая пирамида» в номинации «Digital-трансформация года». Хотелось бы узнать, почему этот проект получил такое признание?

В. С.: В банке «ДельтаКредит» есть трехлетняя стратегия развития информационной безопасности с 2016-2018 гг. Идея этой стратегии — перевести все банки группы Societe Generale, в которую входит банк «ДельтаКредит», в 70 странах мира к единому уровню зрелости в отношении информационной безопасности. Для нас это возможность взять лучшие мировые практики и грамотно выстроить процессы информационной безопасности в отдельно взятом банке.

На мой взгляд, в информационной безопасности есть три краеугольных камня: первый — управление рисками, второй — управление учетными записями и привилегиями, третий — это выявление атак и реагирование.  Где-то между ними — целый ряд технических процессов, которые обеспечивают общий уровень защиты. Но именно эти три направления сильно зависят от процесса, а не только от технических решений. Если мы говорим про защиту почты, там все понятно: есть известные эшелоны защиты, которые надо правильно установить, настроить — и это работает. Риски, доступы и реагирование требуют большой процессной части с вовлечением многих подразделений, выстраивания рабочих процессов, с получением конкретных компетенций. И если говорить об управлении доступами — это один из трех больших проектов, который затронул весь банк и все его процессы.

Изначально у нас был запрос от бизнеса: существует некий набор прав доступа, который нужен новому сотруднику, чтобы начать работать — и его сложно и долго получить. Например, руководитель регионального филиала говорит, что ему требуется два часа, чтобы завести все заявки, которые нужны для выполнения должностных обязанностей его новым подчиненным. Не всегда он это делает, как должен, за 3 дня до выхода работника — тогда последний выходит и еще какое-то время простаивает, дожидаясь выполнения заявок от ИТ. И представьте нагрузку руководителя: если у него вышло пять сотрудников, то ему нужно потратить 10 часов, чтобы  заполнить все заявки, а затем еще «стимулировать» несколько дней согласующих и исполнителей. Это огромная дополнительная нагрузка на человека, который должен заниматься другими вещами.

Второй момент — время выполнения заявок со стороны ИТ. По нашему предыдущему внутреннему SLA заявки на доступ выполнялись за 3 рабочих дня, причем нередко с учетом высокой занятости согласующих или IT Service Desk даже в этот срок не получалось уложиться. Это обычная ситуация для многих компаний. Естественно, инициатор заявки начинает оказывать давление на первую линию ИТ-поддержки, те тоже перегружены и недовольны. Плюс в какой-то момент бизнес начинает говорить, что 3 дня — это слишком долго для современных динамичных agile-процессов.

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

То есть все совпало, что с одной стороны была потребность на местах оптимизировать процессы выдачи и управления правами, с другой — это удачно легло на стратегию группы Societe Generale?

В. С.: Для того чтобы что-то делать, нужно две вещи — бизнес-необходимость и финансирование. Бывает, что-то сделать нужно, но денег нет — значит, пока потерпим. Или наоборот: есть финансирование, но решаются другие задачи, поскольку в этом процессе всё всех устраивает. Здесь все сложилось, потому что в головном офисе была выработана стратегия, и на нее было выделено финансирование.

Сколько систем вы пилотировали на этапе выбора?

В. С.: Пилотировали четыре решения — два отечественных и два зарубежных, о них я скажу позже — и проанализировали ряд других. Например, один из лидеров рынка и Gartner — решение SailPoint, но у них не было представительства в России и экспертов, которые качественно проводили бы пресейл, внедрение и поддержку. Даже если бы данное решение было эффективным и идеально решало наши задачи за приемлемую стоимость, мы понимали, что в России у них нет компетенций. А они нужны, потому что IDM — это не коробочный продукт.

На пилоте у нас были One Identity, Oracle Identity Manager, Avanpost IDM и Solar inRights. Тут важно понимать, что итоги любого пилотирования зависят от целей, масштабов и специфики организации. Например, у нас были пилоты по другим проектам, когда мы отказывались от хорошего решения, потому что оно оказалось слишком громоздким — надо иметь в штате двух или трех инженеров, чтобы только его поддерживать. Если у компании 15000 сотрудников, то, наверное, им это решение подойдет, но это не наш случай.

Что в процессе выбора было для вас было особенно важным, какие критерии при выборе были определяющими?

В. С.: Критериев много. Проще оттолкнуться от того, почему те или иные решения не подходили. Один из основных моментов — наличие адекватного и грамотного пресейла, потому что первое впечатление складывается во время показа продукта. По одному или двум решениям были проблемы с предпродажной поддержкой, причем я общался с коллегами из других компаний, и у них пилоты прошли успешнее просто потому, что у них был другой инженер. Например, у нас во время финальной демонстрации по итогам пилота одного отечественного решения выскакивали какие-то окошки с кодом, ошибки и так далее. Ты понимаешь, что если парни не смогли на пилоте настроить систему так, чтобы не выскакивали ошибки, то, наверно, в продуктиве будет еще хуже, потому что здесь у них идеальная среда. Из этого, например, был сделан вывод, что одно из российских решений сыровато. Хотя в случае с Solar inRights мне понравился их продукт с точки зрения UX и хода мысли, который там заложен. Но в 2016 году системе просто не хватало зрелости — отсюда «детские болезни», связанные с архитектурой и движком.

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

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

А у второй российской системы были похожие проблемы?

В. С.: Во-первых, у Avanpost отличается лицензионная политика, я об этом говорил выше. Во-вторых, IDM обычно требуется большая кастомизация. Если у банка  нет возможности развить внутреннюю компетенцию по решению, самостоятельно что-то дорабатывать или поправлять, то мы становимся зависимыми от вендора, скорости и стоимости его поддержки. Любую мелкую доработку приходится заказывать у них. Это тоже важный критерий. Насколько я помню, данное решение закрытое, предполагается, что его будет дорабатывать и настраивать только вендор или подрядчик. А мы по всем ключевым решениям развиваем свою компетенцию. У нас работают инженеры, которые являются экспертами не в меньшей степени, чем внедренцы из партнеров. Если завтра партнер не сможет что-то сделать, мы попробуем это сделать сами, а если нет времени и не хватает рабочих мест — мы можем обратиться к партнеру. То есть мы можем балансировать между in-house и аутсорсом, а в случае c Avanpost IDM — это полный аутсорс.

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

Что касается Oracle Identity Manager, то это очень хорошее промышленное решение, но это кейс для крупного бизнеса, как я говорил выше. Оно имеет развитый, но перегруженный интерфейс. Чтобы поддерживать эту систему, необходимо иметь в штате только на эту задачу минимум трех обученных сотрудников, сертифицированных по недешевому стеку Oracle. Для нас в этом были немногие, но критичные минусы — система дорогая и громоздкая.

Что определило ваш выбор в пользу One Identity?

В. С.: Он выглядел оптимальным решением — у него есть свои минусы и плюсы, но важно, что у него не будет «детских болезней» и багов. Если решение 10 лет работает в компании Daimler, то для меня это показатель. При этом это не такое сложное и громоздкое решение, как Oracle, —  мы понимаем, что если обучить инженеров, то его можно поддерживать и дорабатывать самостоятельно. При этом в нашем случае этим проектом занимались 1-2 человека плюс партнер, а поддержка после внедрения осуществляется 0,5 – 1 FTE (включая внешние ресурсы). К слову, на рынке есть кейс полностью самостоятельного внедрения данного продукта. Что касается цены, то они дороже, чем российские решения, но они все же в лидерах квадранта Gartner, и при наличии гибкой позиции российского представительства стоимость может быть приемлемой. Кроме того, вендору интересно развиваться в России, у них есть команда инженеров и пресейлов, которые помогают партнерам, проводятся мероприятия и обучение, формируется комьюнити.

Еще один значимый критерий выбора — количество кода. В большинстве решений приходится писать код для создания процессов и воркфлоу, в One Identity есть возможность строить процессы в GUI в виде блок-схем. Это удобно, и этого не было в других решениях на тот момент. Продукт поддерживает любые кастомные скрипты — если нужно прописать отсутствующий процесс или функциональность, можно написать скрипт на Python, и он отрабатывает. Не во всех продуктах используются те же скрипты на Python или других распространенных языках, в некоторых доступны только нативные скрипты.

Вы считали стоимость владения всеми решениями? Насколько сложно было его оценить?

В. С.: Мы, как правило, считаем стоимость владения минимум на три года. Но здесь сложно было сделать оценку. Что касается лицензий — все прозрачно, но внедрение, например, потребовало больше ресурсов, чем предполагал наш партнер. Для One Identity работа с банком «ДельтаКредит» была только седьмым внедрением в России, и проектного опыта было еще мало. Сейчас ситуация изменилась, есть более 20 проектов, компетенции у большинства крупных интеграторов. Что касается коннекторов — они бесплатные и основные работают из коробки.

Коннекторы часто могут стать проблемой, особенно в России, где популярны 1С и другие системы. У западных вендоров может не найтись готовых решений. Их надо писать с нуля или разрабатывать с привлечением вендора, как у вас с этим обстояло дело?

В. С.: Все истории были использованы. У нас был очень широкий скоуп, мы планировали насколько возможно широко использовать возможности системы с высоким уровнем автоматизации процессов. Поэтому внедрение у нас происходило в два этапа: первый начали в январе 2017 года и вывели в продакшен в июле того же года. В рамках этого этапа мы подключали AD, Exchange, Skype for Business, файловые шары, 1С. В итоге у сотрудника на момент выхода были базовые IT-системы, а бизнес-системы вынесены во второй этап. Почти все было сделано на стандартных коннекторах. Кстати, у одного из отечественных решений плюсом при анализе было наличие коннектора к 1С. Мы думали, что это плюс по сравнению с One Identity. Но когда внедряли, оказалось, что универсальный коннектор к базам данных отлично заработал для 1С, не требуя больших ресурсов на внедрение и дополнительно дав гибкость для доработки и поддержки своими силами.

Самым сложным элементом для нас стало  изменение и внедрение процессов. Это отдельная история — мы набили много шишек и значительно пересмотрели нашу изначальную картину их реализации. Адаптация процессов банка под IDM и IDM под процессы банка идет красной линией через весь проект и потом переходит и в поддержку системы.

На втором этапе мы реализовывали бизнес-системы — начали с конца года 2017 и продолжаем это делать сейчас. В скоуп проекта вошли АБС, CRM, IT Service Desk и СЭД, то есть основные системы, в которых ведется бизнес. Здесь история другая, где-то мы используем коннектор к базе данных, но делать отдельные таблицы и представления — это все равно написание коннектора. В любом случае со стороны бизнес-системы у нас есть штат разработчиков и аналитиков, которые пишут часть коннектора со стороны бизнес-системы, для того чтобы бизнес-система могла отдать нужные данные в нужном формате IDM-системе и получить от нее команды, которые она дает. C АБС мы все реализовываем с помощью универсального коннектора БД. К CRM мы зашли с другой стороны — по сути наши разработчики написали коннектор как API для IDM, и эта история достаточно длительная, это разработка, ресурсы банка и так далее. То есть мы попробовали все варианты — полный готовый коннектор, универсальный коннектор, который работает после допилов, и третий,  когда половина коннектора универсальна, остальное надо писать изнутри.

Реализовывали ли вы в рамках этого проекта контроль за действиями привилегированных пользователей, у того же One Identity есть PAM-модуль для контроля IT-персонала.

В. С.: У One Identity есть решение, но с ним у нас не получилось просто потому, что вендор был не готов. Их решение PAM представляет собой программно-аппаратный комплекс, который необходимо было привезти в Россию и сертифицировать. Соответственно, когда мы выбирали решение, возникал ряд вопросов относительно ввоза и сертификации, плюс — на тот момент у них не хватало функциональности, которую они закрыли недавно, купив Balabit, — то есть сейчас они по сути получили полноразмерное решение за счет этой покупки. Мы выбрали другое решение, хотя я вижу у них пару плюсов. Главный, на мой взгляд, — это железное защищенное исполнение, у других PAM-систем уровень физической защиты ниже, потому что они располагаются на обычных серверах. Так как Balabit они присоединили недавно, то никой выгоды в интеграции IDM с родным PAM пока нет.  

Если говорить о функциональности текущего решения — что используется и что нет? Например, большинство вендоров IDM рассказывают про портал самообслуживания, вы это используете?

В. С.: У нас — полностью полнофункциональное решение с порталом. На нем есть, например, Password Manager. Вроде бы мелочь, но он снял более 600 запросов в месяц на сервис-деск о смене пароля. У пользователя на экране ввода пароля Windows появляется кнопка Forgot Password, дальше есть возможность кастомизировать, создать несколько секретных вопросов, добавить второй и третий факторы, но самое главное — сотрудник может сменить пароль без сервис-деска.

Сейчас процесс выхода на работу выглядит так: человек приходит, подписывает документы в HR, в 1С на него заводят приказ, в течение 10-20 минут ему создается учетка, почта и базовый профиль доступа в те системы и группы, которые ему нужны для выполнения обязанностей, включая технические роли в зависимости от локации (например, принтеры). Сотрудник может работать уже через полчаса после того, как подписал документы. При этом никто никакой заявки не завел — все происходит автоматически, просто потому что есть приказ в HR. Как я уже упоминал, любое внедрение IDM — это большая процессная проблема, надо перестраивать HR-процессы. Сотрудники отдела кадров должны понимать, что когда они делают любые изменения в системе, это влияет на реальные доступы. Также работает самоконтроль — все понимают, что доступы должны быть, и если не появляются, то они возвращаются с обратной связью.

Для доступов, которые не входят в базовый профиль, организован портал. Мы разделили единое окно IT сервис-деска на два: одно — всё про доступы, и это IDM, второй —  про все остальные вопросы к ИТ. В перспективе мы думаем о том, чтобы усилить интеграцию между сервис-деском и IDM. Если человеку нужен, скажем, доступ с мобильного телефона к почте, он оформляет заявку на портале, после чего автоматически идет согласование. Никто не переводит статус заявки вручную — как только предыдущий согласовал, она падает на следующего. Как только согласовал последний руководитель — доступ выдан. Нигде в этом процессе не привлекаются IT-ресурcы, если все идет штатно. Сотрудник получает отбивки по каждому этапу, он видит, кто на каком этапе его заявку согласовывает. Естественно, мы требуем серьезного обоснования. Раньше нас просили: «Сделай права, как у Васи». Сейчас человек пишет обоснование под каждый конкретный доступ. Однако мы предоставляем возможность для коллег сгруппировать права доступов в «пакеты» для удобства запроса и выкладываем их на портал как роль. Есть срок, на который предоставляется доступ, а также, что удивительно, пользователи нередко размещают заявки на отзыв ненужных прав доступа — даже меня это удивляет, но есть сознательные люди.

Многие вендоры говорят об функциях IGA, в первую очередь это аудит прав доступа, модель рисков, определение конфликтов интересов. Насколько это актуально для вас?

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

По поводу рисков — эта функциональность у One Identity есть, но мы до нее еще не дошли. В системе есть возможность на все ресурсы выставить определенный вес критичности и поставить порог. Если у человека набирается высокий показатель, он сосредоточил у себя слишком много критических доступов. Дальше нужно переводить его в группу сверхкритических пользователей либо делать отсечку, что он не сможет что-то запрашивать выше определенного уровня, не отказавшись от чего-то из имеющегося у него. Второй механизм — это запрет  взаимоисключающих вещей: можно указать в системе, что доступ А и доступ Б является взаимоисключающими, и это будет отражаться при попытке запросить их и иметь одновременно.

Какие рекомендации вы дадите тем, кто находится в начале пути внедрения IDM? На что следует обратить внимание?

В. С.: Во-первых, на компетенции на рынке по проекту, потому что это область рисков. У нас было три партнера: у одного было три внедрения One Identity, у второго — два, у третьего — один. Для One Identity это было минусом, но сейчас ситуация изменилась — внедрений около трех десятков, есть даже комьюнити в России.

Обязательно нужно иметь одного, а лучше двух обученных инженеров по IDM в штате. Это окупается: если партнер будет делать что-то неправильно, ваш сотрудник увидит это и поправит. Во-вторых, вы сможете делать ряд доработок своими силами, и это ускорит внедрение. Если известно, сколько времени нужно на эту задачу, а партнер утверждает, что в три раза больше — будет возможность об этом сказать аргументированно.

Важный момент — сбор бизнес-профилей, то есть ролей. Есть опыт коллег, которые начинают внедрение IDM с того, что инициируют большой процесс по формированию ролей, чтобы затем автоматизировать их с помощью системы. Мы начали с этого процесса, но быстро захлебнулись, потому что бизнес редко понимает, для чего это нужно и что им нужно. Важно не затягивать этот процесс — если не получается, начинайте внедрение без этого и потом дособираете по ходу. Я собрал примерно 50% бизнес-ролей, потом после пятого напоминания написал оставшимся руководителям письмо, что все, кто не заполнил роли, остаются без автоматизации.

Мы начали внедрять систему и занесли в нее эти 50%, а остальным выдавались только учетка и почта при выходе нового сотрудника. Когда система заработала, стало очевидно, что один руководитель получает роли для своих сотрудников через IDM, а другой нет, и у первого все происходит быстрее и проще. Пошло сарафанное радио, и руководители отделов сами стали писать: «Можно ли мне создать бизнес-профиль для моего отдела?» Главное — показать бенефиты от реализации IDM, и бизнес сам включится и начнет участвовать с совсем другой мотивацией.

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

Большое спасибо вам за интервью, желаем интересных проектов в будущем!