Дмитрий Стуров: Назначить права доступа несложно. Сложно назначить правильные права

Исполнительный директор, начальник управления информационной безопасности банка «Ренессанс Кредит» Дмитрий Стуров, рассказал читателям Anti-Malware.ru о том, какие плоды принесло внедрение ролевой модели доступа и как в процессе внедрения развивались отношения бизнес-подразделений со службой информационной безопасности. 

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

Д. С.: Наиболее значимый проект, который у нас идет последние 5 лет, — это создание ролевой модели доступа. Когда мы только запускали этот проект, было много разных активностей, потом их количество естественным образом стало уменьшаться, потому что то, что было реализовано, уходило в автоматизацию, и наши силы уже не требовались. Например, то, что связано с различными аудитами, которые мы проходили по требованию руководства и внешних партнеров. 

Ролевая модель была связана с внедрением каких-то средств защиты?

Д. С.: Исторически ролевая модель у нас возникла не на пустом месте. В конце 2000-х годов мы озаботились тем, что все доступы у нас управляются вручную, и никакой автоматизации нет. Это вызывало множество рисков, связанных с неправильно выданным, не вовремя отключенным или неправильно сконфигурированным доступом. Тогда мы разработали концепцию ролевой модели, которая предполагала уход от заявочной системы и составление особых шаблонов, чтобы человек не запрашивал себе доступ «как у коллеги», а просто начинал работу, и голова у него была свободна от того, какие доступы ему нужно запросить. На первом этапе мы попробовали составлять ролевые модели в таблице Excel или на бумаге. Но эффекта это не принесло, потому что на бумаге ты составил одно, а на деле выходит совсем по-другому, и без технических средств невозможно было двигаться дальше.

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

Д. С.: В то время у нас использовался широкий пул продуктов Microsoft, и первым естественным желанием было посмотреть продукт этой компании, который тогда назывался Forefront Identity Manager (FIM). Он позволял обеспечить автоматизацию на уровне OU в Active Directory. Но ролевой модели там не было, она была в стороннем продукте, который назывался BHOLD. Мы использовали его.

Затем  начали обсуждать, как проводить процесс внедрения ролевой модели. Было два варианта – «сверху» и «снизу», и, кроме того, был выбор относительно того, «идти» ли по системам или по подразделениям.

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

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

Далее мы все доступы в одной системе «загнали» в Microsoft FIM, и все это выстроили. Одну систему он кое-как «прожевал» — эффект был. Но когда мы подошли ко второй системе — она была гораздо больше, чем CRM, затрагивала порядка 8-10 тысяч пользователей (а в CRM — примерно 2-3 тысячи), с этой системой Microsoft уже не справился — ушел в бесконечный цикл пересчета. Мы запросили поддержку и помощь у интегратора, но оказалось, что не все так просто: этим продуктом мало кто пользуется, и сам Microsoft готов выделять только ограниченное количество специалистов, правда, даже эти специалисты ничего не смогли сделать.

Мы начали смотреть на аналоги. Фактически критерий успешности пилота сводился к тому, чтобы соединить все, что у нас есть, и чтобы это работало – красиво, быстро, понятно, надежно. Одним из таких продуктов на тот момент был One Identity; его внедрял департамент IT, я позже подключился к проекту именно по технической части. В IT развернули его быстро, чуть ли не за одну ночь — и все заработало.

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

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

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

Ну и, конечно, мы как безопасность видели в этом проекте в первую очередь возможность снизить риски: в рамках любого аудита мы видим, что огромное количество уволенных сотрудников остается в системах, у многих людей неверный доступ и т. п. В одном отделе мы сравнили трех человек, они обладали абсолютно разными доступами, пересекались в лучшем случае на 20%. Начали выяснять — оказалось, что, условно говоря, когда-то человек запросил права, чтобы посмотреть данные, потом перешел в другое подразделение, а все доступы у него остались.

Возвращаясь к техническим средствам: почему вы стали смотреть именно в сторону One Identity? Рассматривались ли какие-то другие варианты?

Д. С.: Мы смотрели на стендах SailPoint, Avanpost на презентациях и опять же на стендах, и, в общем-то, все. Нас подкупило то, что пилот был очень репрезентативный: фактически мы попали сразу в яблочко. У нас есть система, мы ее за день запустили и увидели, что все работает.

Несколько лет назад — это ведь было после событий вокруг Крыма? У вас не было опасений насчет того, что это международный вендор, санкции, могут все отключить?

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

В общем, получилось удачно, что поставили One Identity, и он сразу положительно себя показал на интеграции с этими двумя целевыми системами. А какие этапы, шаги по развитию этого проекта были у вас дальше?

Д. С.: Дальше мы начали развиваться вширь, подключать новые системы. На первом этапе мы не особо беспокоились о качестве, честно признаюсь — поначалу вообще не тратили время на второстепенные процессы, такие, как аттестация доступов или оценка рисков. Мы захватывали управление пользователями в нашем банке; для этого была построена довольно простая метрика — количество атомарных доступов, которые выдаются «руками», и количество доступов, выдаваемых IdM. Постепенно этот столбик рос от 0 до 80-85%. Были скачки: когда мы добавляли систему с большим количеством пользователей, большим количеством управления ими, эта метрика сразу ощутимо росла, и это коррелировало с тем, что люди чувствовали на себе — например, администраторы стали свободнее, их на планерке честно спрашивали: «Ощущаете эффект?», и все в один голос отвечали утвердительно.

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

Д. С.: Да. Через некоторое время был проведен внешний аудит нашей ролевой модели. Мы сами, конечно, понимали ее достоинства, но внешнее мнение всегда полезно. Его проводили силами сторонних специалистов, они оценили нашу ролевую модель и дали рекомендации. Мы немного скорректировали стратегию, но в целом было понятно, что путь, который мы выбрали, является верным и правильным.

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

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

Не было ли у некоторых бизнес-подразделений негативного отношения? Часто звучит, что, мол, ИТ или ИБ мешают бизнесу: мы работаем, а у нас отнимают права, мы не можем осуществлять свою прямую деятельность. В конце концов, людей надо переучивать работать по-новому.

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

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

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

Что происходило на дальнейших этапах подключения целевых систем? Сейчас у вас, как я понимаю, почти всё подключено к IdM.

Д. С.: Поначалу мы шли через системы, которые интегрированы с AD, потому что у One Identity Manager  есть коннектор к AD, мы его из коробки поставили и использовали, никаких нареканий к нему нет — он работает так, как должен. Это продолжалось до тех пор, пока мы не дошли до CRM-системы, которая построена на Microsoft Dynamics; там нет возможности через AD управлять пользователями. Тогда мы начали делать свой первый коннектор. Делается он на двух сторонах: на стороне системы и на стороне IdM. Мы в первый раз прошли этот путь, выбрали механизм интеграции, набили шишки и интегрировались — и новая целевая система, которая пришла на замену прежней, устаревшей, сразу заработала с ролевой моделью. Это было большим подспорьем: система, которая соответствует всем нашим принципам, вдруг стала центральной, и все ощущали преимущества проекта ролевой модели.

Приходилось ли вам самим разрабатывать коннекторы, или вы использовали в основном варианты из коробки, которые уже были в One Identity?

Д. С.: Из коробки мы использовали и используем только два коннектора — к Microsoft AD и к Microsoft Exchange, потому что они хороши и нет смысла их переписывать. По поводу других систем: в принципе, в One Identity есть набор коробочных коннекторов, но мы пошли немного другим путем. Мы использовали стандартный механизм, который в него встроен, это универсальный коннектор, который конфигурируется под каждую целевую систему.

Имеете ввиду прямой коннектор к базе?

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

Были ли какие-то технические сложности при подключении целевых систем, из-за которых, например, приходилось подключать техподдержку? Или все было гладко?

Д. С.: Для каждой системы, если она не интегрируется с AD, нужно было что-то выдумывать. У большинства систем, которые написаны какое-то количество времени назад, никакого API тоже нет. Что-то везде и всегда доделывали; но, тем не менее, интеграция работает уже более трех лет, все задачи решены, коннекторы сделаны. Если используются стандартные системы — промышленные, коробочные, то есть, как правило, способы интегрироваться. Где-то мы просим разработать коннектор — например, в процессинговую систему нельзя залезть напрямую, она защищена согласно стандартам PCI, и тогда приходилось делать API, которое мы использовали. Везде абсолютно разный подход. Но нет ни одной системы, с которой мы бы не смогли интегрироваться: везде это либо вопрос времени, либо вопрос ресурсов со стороны третьей линии поддержки.

Я правильно понимаю, что внедрение вы проводили внутренними силами, без привлечения интегратора? Если да, то почему так? Почему не решили отдавать проект на аутсорсинг, хотя бы частично?

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

Сколько сейчас всего целевых систем подключено к IdM?

Д. С.: Системы, как я уже говорил, подключены через коннекторы, и их довольно много, порядка 40. Систем, которые сделаны с кастомными коннекторами, — 15-20.

Выходит, всего около шестидесяти?

Д. С.: Именно. Впрочем, сложно разграничить, где кончается одна система и начинается другая. Фактически это все системы, которые есть в банке, кроме каких-то абсолютно legacy-систем и экзотики. Есть системы, у которых нет никакого управления пользователями, она просто работает, и все. Человек ее запустил, она у него в виде окошка появилась — даже никакого логина не нужно. Тогда, естественно, она сюда не попадет.

Если взглянуть назад и проанализировать этот опыт внедрения, какие могут быть подводные камни, что можно порекомендовать, например, другим компаниям, которые сейчас смотрят в сторону внедрения IdM/IGA-систем? Что можно было бы сделать по-другому?

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

Кстати, а сколько сотрудников у вас было выделено на этот проект?

Д. С.: Два-три человека.

Которые постоянно этим занимались?

Д. С.: Нет, постоянно никто не занимался, эти люди работали над проектом в равных долях с другими задачами.

Итак, на первых этапах все это было внедрено и автоматизировано. А что касается более сложных функций, присущих IGA-системам, например, SoD или анализа рисков? В каком виде это уже используется сейчас?

Д. С.: Да, это и сейчас используется, и мы будем расширять область использования. Мы широко применяем процессы аттестации доступов — бизнес-роли и доступы к объектам пересматриваются, в эту сторону тоже будем смотреть. Интеграция с самими системами — это жесткая вещь, плюс примерно с середины прошлого года мы немного поменяли акценты и начали при помощи IGA-системы автоматизировать заявочную модель. Она умеет раздавать на уровне бизнес-ролей — почему бы не раздавать и на уровне заявок, операция одна и та же.

Это киоск самообслуживания?

Д. С.: Да. Система позволяет сделать этот киоск на основе своего интерфейса, но тогда бы мы столкнулись с проблемой двух окон service desk, что для нас было неприемлемо. И мы делали интеграцию с системой HPE Service Manager — была создана специальная группа, которая фактически являлась IGA-системой, она забирала заявки, исполняла их и выкладывала результаты. Пользователь даже не догадывался, кто и как сделал доступ — админ вручную или система автоматически. При помощи этой автоматизации мы тоже достигли больших успехов. Теперь создаем пользователей, агентов, предоставляем какие-то атомарные доступы, которые невозможно вставить в ролевую модель, делаем сервисы по сбросу пароля в различных системах. Раньше пароли сбрасывала вторая линия поддержки — опять получалось, что квалифицированные люди занимались простым делом, а так как пользователи забывают пароли достаточно часто, на это тратилось много времени. Таким образом, при управлении ролевая модель и заявочная модель сходятся в одном месте, и там все заявки исполняются.

С вашей точки зрения как заказчика такой системы, чего в ней не хватает? Какая функциональность была бы востребована?

Д. С.: Мне сложно сказать, потому что я смотрю на нее с точки зрения фреймворка, как я уже говорил, и всю функциональность, которая там отсутствует, мы можем воспроизвести — в виде отчетов, процедур, внешних систем интеграции.

Помимо ролевой модели использовались ли дополнительные атрибуты управления доступом?

Д. С.: Сейчас, согласно исследованиям того же Gartner, ролевая модель уже «закончилась», и все фокусируются на атрибутной модели, когда доступ предоставляется на основе правил, а в правилах фигурируют те или иные атрибуты. Бизнес-роль становится не единственным фактором принятия решений о том, дать доступ или нет, а является лишь одним атрибутом. Мы используем помимо бизнес-ролей и другие вещи — скажем, количество измерений, чтобы дать тот или иной доступ. Нам нужно отличать менеджера в одном отделении от менеджера в другом, чтобы предоставить им разные доступы к разным объектам внутри системы. Мы используем географическое разделение на уровне офисов, которых у нас чуть больше 130. Вся эта география построена на иерархическом принципе: офисы, объединенные в одном регионе, мы можем обслуживать через этот регион — например, дать доступ по всему региону. Помимо геолокации, «геороли», как мы это у себя называем, у нас есть проектная роль, когда люди из разных подразделений работают над одним проектом. Еще мы можем решать при помощи атрибутов точечные задачи — например, контроль срока действия доверенности, по истечении которого доступ автоматически отзывается.

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

Д. С.: Да. Любое бизнес-событие может быть транслировано в системное. Мы можем влиять на бизнес-процессы, влиять гарантированно и точно.

Как это можно настроить?

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

Ну да, часто оставляют полный доступ, и человек годами сидит и все читает.

Д. С.: Либо же человек может оставить свой пароль коллеге — на случай, если что-то произойдет, чтобы он мог зайти, — а он один раз зашел, второй, ему понравилось, и это вошло в привычку в бизнес-процессе его подразделения, и потом это «выжигать» очень тяжело.

А используется ли в правилах автоматизации скоринговая модель для оценки рисков — допустим, для автоматического отзыва каких-то прав, принудительного отправления на аттестацию?

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

Нужно ли отслеживать явные аномалии в выдаче прав? Например, для нового сотрудника вдруг появляется очень большое количество привилегий, или у человека, не работающего с АБС, вдруг появляются права на доступ к ней. Эти вещи как-то отрабатываются?

Д. С.: Сперва эти вещи нужно придумать и формализовать. Потом их можно безо всякого труда реализовать в виде правил в системе IGA, которые будут пересчитываться почти в режиме реального времени. Например, если человек подпадет под какое-то правило, то об этом сразу будет сообщено офицеру безопасности, либо же может быть выполнено какое-то автоматическое действие — он просто будет заблокирован до разбирательств.

У вас работает процесс реконсиляции, когда при предоставлении прав доступа в какой-то целевой системе IdM/IGA это видит и запускает процесс подтверждения, либо просто сразу отбирается доступ?

Д. С.: Да, процесс реконсиляции — один из основных процессов, которые мы делаем при подключении системы. Если это штатный коннектор, такой как AD, то реконсиляция проходит просто как один из процессов, и единственное, что нам нужно, — указать период. При реконсиляции с внешними системами нужно ее сразу предусматривать в коннекторе. Реконсиляция сводится к тому, что мы смотрим, что есть в IdM в сравнении с конечной системой, и принимаем решение по каким-то конфликтам в ту или иную сторону – каждый определяет для себя, как он будет разрешать этот конфликтный результат. Мы таким образом имеем информацию о любом пользователе, который получил права — например, позвонил своему знакомому админу в IT, и тот ему по доброте душевной накинул какие-то права, чтобы «не сильно заморачиваться». Мы об этом узнаем при первой же реконсилиации, он попадет в отчет, прилетит «отбивка» (мы каждое утро смотрим эти «отбивки», потому что сейчас у нас такие доступы являются большой редкостью) и 99% подобных доступов будет отозвано автоматически, за исключением 1-2 систем, где время от времени админы дают людям права для исполнения каких-то нетривиальных задач.

У вас заводится инцидент, анализируются данные относительно того, кто и зачем дал права?

Д. С.: В целом это зависит от политики управления инцидентами: какое событие считается инцидентом, какое не дотягивает до этого порога. Если мы что-то видим, то просматриваем такие события и заводим инцидент. Можно привести пример, что недавно системный администратор дал довольно жесткие права в одной из систем, завели инцидент, разбирались, человек давал объяснения, на основании чего он решил так сделать. Конечно, все свелось к тому, что он действовал из лучших побуждений, чтобы упростить и ускорить.

Сколько времени раньше уходило на предоставление доступа и сколько времени это занимает сейчас?

Д. С.: Назначить права было несложно. Назначить правильные права — это было долго. Чаще всего негатив подразделений как раз связывался с тем, что дали что-то не то. Вот человек сидит, делает квартальный отчет, а у него доступа к отчету нет. Он узнает это только тогда, когда начинает этот отчет делать. Тогда уже что-то пересматривать, решать времени нет. Здесь у нас этот показатель сводится к 15-20 минутам — и мы его можем еще сократить, просто в этом нет смысла.

Практически в каждом банке сейчас есть своя разработка; у вас наверняка тоже. Помогает ли каким-то образом внедрение IGM-системы в безопасной разработке?

Д. С.: Да. Сейчас все концепции, методологии ИТ больше «заточены» на ускорение, увеличение, или, наоборот, уменьшение Time-to-Market и Agile. Мы можем предложить быстрое и точное управление доступами — при том, что айтишник зачастую может работать только в режиме permit any/any, когда у него все разрешено. Как только мы начинаем что-то ограничивать, сразу идет негатив, что вы нам замедляете процесс разработки, это отрицательно может сказаться на бизнесе. При помощи автоматизации, в том числе через IGA-систему, мы решаем два этих вопроса: админы получают нужные доступы быстро, а мы при этом не получаем каких-то проблем с безопасностью. Например, появляется новый объект в ИТ-инфраструктуре, и мы сразу же по какому-то сигналу на него можем назначить те или иные права. Это, допустим, заказ виртуальных машин, то есть частное облако. Потом опять же проектные роли.

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

Спасибо за беседу. Желаем успехов!