С каждым годом парк информационных систем компаний все больше разрастается, вместе с ним пропорционально усложняются задачи управления, контроля и разграничения прав доступа сотрудников к информационным ресурсам. Наличие на рынке решений, частично перекрывающих функционал друг друга, дает плодотворную почву для новых и новых дебатов. Как должна быть реализована система управления доступом – через интеграцию с ITSM или внедрение отдельного IGA-решения?
Есть несколько причин для споров. Во-первых, традиционно в компаниях доступом к корпоративным системам заведует ИТ, однако с ростом численности персонала и ИБ-зрелости перед компанией открываются новые риски. Среди них и предоставление избыточных прав доступа, и стоимость прерывания бизнес-процессов, вызванного несвоевременным предоставлением доступа. Как итог, не всегда очевидно, кто должен решать эти задачи: ИТ или ИБ?
Во-вторых, если даже в компании нет разделения на службы ИТ и ИБ, часто просто непонятно, какое решение способно закрыть нужную компании функциональность, какое будет более удобным для администраторов и рядовых сотрудников.
Итак, существует два подхода к решению задачи:
Не существует однозначного ответа на вопрос, что лучше. При принятии решения стоит понимать, что типовые IGA/IdM специализируются на автоматизации доступа к ключевым информационным ресурсам компании и выполняют ряд смежных функций. И наоборот, инструментарий ITSM выполняет широкий спектр запросов на ручное обслуживание пользователей систем, но не имеет возможности выполнять функции IGA. Мы расскажем о преимуществах и подводных камнях каждого из вариантов и попробуем помочь сориентироваться, что подойдет именно вашей компании.
Интеграционный подход
При разговоре об интеграционном подходе следует сразу пояснить, что вообще существуют две схемы интеграции IGA и ITSM:
Система ITSM как frontend
Бизнес-задача: единая точка входа для любых запросов пользователей к IT.
Реализуется за счет встраивания формы формирования заявок на доступ в систему ITSM.
Требуется доработка системы ITSM (разработка формы) и наличие API (SOAP web-сервис или REST) у системы IGA.
Возможные варианты реализации:
Система IGA как frontend
Бизнес-задачи:
Реализация
Заявки формируются и согласуются в системе IGA, после чего сформированные запросы на изменения полномочий доступа экспортируются в систему ITSM. Они могут группироваться в один тикет, содержащий несколько запросов.
Запросы, которые могут быть выполнены коннектором, выполняются, после чего тикеты в ITSM закрываются.
Запросы, которые не могут быть выполнены коннектором (или коннектора нет), ожидают исполнения администраторами в ITSM. При изменении статуса тикета в ITSM запрос автоматически закрывается в IGA. Администратор может вводить важную информацию в полях тикета при его закрытии, что означает необходимость обратной синхронизации в IGA.
При всем этом развитие функциональности будет требовать изменений в двух системах.
Кроме того, у систем класса ITSM есть некоторые принципиальные ограничения:
Нужно понимать, что в случае реализации интеграционного решения его будет гораздо сложнее поддерживать или изменять, т.к. возникнет необходимость задействовать две команды разработки, а значит согласовывать два ТЗ, синхронизировать их работу, бюджетировать работы в обеих командах. При принятии решения эту сторону вопроса нельзя упускать из вида.
На другой чаше весов лежит проблема для пользователя: при выборе соответствующего варианта интеграции ему теперь нужно заходить, как минимум, в 2 системы и более (как правило, у компании есть еще и корпоративный СЭД). Для руководителей компаний это становится достаточно большой головной болью. Пользователи и IT-сотрудники постоянно спрашивают: «Зачем это нужно? Давайте весь новый функционал сделаем в ITSM!» При этом во многих компаниях заявки принимаются по почте/через call-центр, и достаточно низкий процент пользователей работает с ITSM непосредственно через интерфейс.
В нашей практике встречались компании, где не существует собственного интерфейса IGA, есть функционал как движок, и он действительно завязан на заявочные системы. Однако возможности по изменению БП (например, вычислению согласующих неочевидными алгоритмами) в ITSM весьма ограничены.
IGA как единое решение
Очевидным преимуществом использования только IGA для построения системы управления правами пользователей является то, что это автоматически избавляет нас от всех сложностей, неизбежно возникающих при интеграции с внешней системой.
Наличие встроенного workflow в существенной степени облегчает аудит и позволяет в едином окне видеть основания выдачи тех или иных прав. Это позволяет снизить издержки при поиске и подготовке информации для аудиторских проверок и внутренних расследований инцидентов информационной безопасности, обеспечивая целостную картину прав в едином интерфейсе.
Если классический функционал IdM может успешно реализовываться в связке с ITSM, то интеграция с IGA (в частности, реализация функциональности для изменения процессов управления ресурсами и организационными структурами) потребует настолько больших трудозатрат, что фактически находится на грани экономической целесообразности.
На самом деле, при внедрении IGA в компании возникает целый ряд новых процессов. При использовании системы должны быть доступны не просто возможности запроса полномочий, но и предоставлены разнообразные дополнительные сервисы, такие как:
С одной стороны, все эти интерфейсы не очень сложны. С другой стороны, в классическом ITSM можно реализовать достаточно простые операции, но уже склеивание или разбиение заявок в ITSM реализовать достаточно сложно. Какие здесь есть варианты?
При этом все чаще встречаются бизнес-пользователи, которые, хотя и далеки от мира IT, с интересом пользуются возможностями IGA, выстраивают динамику и применяют аналитические инструменты. Это означает, что рано или поздно людей придётся пустить в другой интерфейс.
Итак, можно ли создавать заявки в ITSM? Да, можно, и это достаточно просто. Но любой расширенный функционал, включая согласования заявок, лучше реализовывать в системе IGA, предназначенной для решения этих задач.
Попробую провести параллели с нашей реальной жизнью: представьте, что вы студент, учитесь и работаете. Чтобы везде успевать, вы ездите по городу на собственном мотоцикле. Это и правда здорово, вас полностью устраивает такой вид транспорта – быстро, легко и экономично. Проходит время, и вот уже вчерашний студент подрос и женился, появляется ребенок, и возникает вопрос: как передвигаться новым составом? Конечно, можно приобрести мотоциклетную коляску и закрыть требование по перевозке ребенка, но согласитесь, такое решение вряд ли можно назвать оптимальным. А значит, требуется приобретать автомобиль соответствующего класса.
Взгляд со стороны ИБ
Также стоит отразить взгляд на дилемму с точки зрения сотрудников ИБ:
Итак, небольшой чеклист вместо заключения:
Есть несколько причин для споров. Во-первых, традиционно в компаниях доступом к корпоративным системам заведует ИТ, однако с ростом численности персонала и ИБ-зрелости перед компанией открываются новые риски. Среди них и предоставление избыточных прав доступа, и стоимость прерывания бизнес-процессов, вызванного несвоевременным предоставлением доступа. Как итог, не всегда очевидно, кто должен решать эти задачи: ИТ или ИБ?
Во-вторых, если даже в компании нет разделения на службы ИТ и ИБ, часто просто непонятно, какое решение способно закрыть нужную компании функциональность, какое будет более удобным для администраторов и рядовых сотрудников.
Итак, существует два подхода к решению задачи:
- расширить инструментарий ITSM и использовать его заявочную систему в связке с IGA;
- использовать IGA как единое решение и портал самообслуживания сотрудников.
Не существует однозначного ответа на вопрос, что лучше. При принятии решения стоит понимать, что типовые IGA/IdM специализируются на автоматизации доступа к ключевым информационным ресурсам компании и выполняют ряд смежных функций. И наоборот, инструментарий ITSM выполняет широкий спектр запросов на ручное обслуживание пользователей систем, но не имеет возможности выполнять функции IGA. Мы расскажем о преимуществах и подводных камнях каждого из вариантов и попробуем помочь сориентироваться, что подойдет именно вашей компании.
Интеграционный подход
При разговоре об интеграционном подходе следует сразу пояснить, что вообще существуют две схемы интеграции IGA и ITSM:
- Система ITSM как frontend.
- Система IGA как frontend.
Система ITSM как frontend
Бизнес-задача: единая точка входа для любых запросов пользователей к IT.
Реализуется за счет встраивания формы формирования заявок на доступ в систему ITSM.
Требуется доработка системы ITSM (разработка формы) и наличие API (SOAP web-сервис или REST) у системы IGA.
Возможные варианты реализации:
- Форма ввода с произвольным текстом с уточнением заявки администратором непосредственно в системе IGA. Не требует серьезной доработки, но крайне неудобна в использовании.
- Формирование полноценной заявки в ITSM с последующим согласованием в IGA.
Плюсы – автоматизация формирования заявки в IGA.
Минусы – требуется полноценная интеграция с подкачкой справочников и получения статуса заявки из IGA для отображения в ITSM. Согласование производится в IGA, и поэтому ITSM не является единой точкой входа для согласующих. Им приходится использовать frontend IdM для согласования. - Формирование и согласование заявки в ITSM с последующим исполнением в IGA.
Плюсы – простота реализации, единая точка входа для всех пользователей (в т.ч. и согласующих).
Минусы – трудности в реализации согласования, завязанного на контент заявки. Нужно строить маршрут, исходя из информации в ITSM, которой там может и не быть. - В ITSM реализуется формирование заявки, после чего заявка импортируется в IGA, и там формируется маршрут согласования. В ITSM заводятся задачи на согласование и операции согласования/отклонения/делегирования инициируются в интерфейсе ITSM, но реально выполняются в IGA посредством API. Самый сложный для интеграции, но самый удобный для пользователей вариант.
Система IGA как frontend
Бизнес-задачи:
- В некоторых организациях по внутреннему регламенту все изменения в IT-инфраструктуре должны отражаться как задачи в ITSM-системе.
- Использовать ITSM для реализации дополнительных этапов выполнения заявок (например, подготовка рабочего места) и для управления доступом к системам, для которых не планируется разработка коннектора – на данном этапе или вообще (вследствие малого количества пользователей, отсутствия целесообразности и т.д.).
- IGA становится единой точкой входа для любых заявок на управление доступом.
- Обеспечивается постепенное наращивание количества подключенных к IGA систем, при том что заявочная система вводится сразу для всех.
- В IGA хранится информация о доступе пользователя во всех системах компании, даже для тех, подключение которых на данном этапе не производится или не планируется вообще.
- Обеспечивается своевременное прекращение доступов пользователей в неуправляемых системах при увольнении пользователя или уходе его в отпуск.
Реализация
Заявки формируются и согласуются в системе IGA, после чего сформированные запросы на изменения полномочий доступа экспортируются в систему ITSM. Они могут группироваться в один тикет, содержащий несколько запросов.
Запросы, которые могут быть выполнены коннектором, выполняются, после чего тикеты в ITSM закрываются.
Запросы, которые не могут быть выполнены коннектором (или коннектора нет), ожидают исполнения администраторами в ITSM. При изменении статуса тикета в ITSM запрос автоматически закрывается в IGA. Администратор может вводить важную информацию в полях тикета при его закрытии, что означает необходимость обратной синхронизации в IGA.
При всем этом развитие функциональности будет требовать изменений в двух системах.
Кроме того, у систем класса ITSM есть некоторые принципиальные ограничения:
- Отсутствие возможности видеть весь бизнес-процесс целиком, включая события HR (важно при проведении аудита и расследовании инцидентов ИБ).
- Сложность определения реального времени выполнения бизнес-процесса предоставления доступа.
- Ограниченная возможность определения основания выдачи тех или иных прав сотрудникам компании.
- Отсутствие возможности аудита.
Нужно понимать, что в случае реализации интеграционного решения его будет гораздо сложнее поддерживать или изменять, т.к. возникнет необходимость задействовать две команды разработки, а значит согласовывать два ТЗ, синхронизировать их работу, бюджетировать работы в обеих командах. При принятии решения эту сторону вопроса нельзя упускать из вида.
На другой чаше весов лежит проблема для пользователя: при выборе соответствующего варианта интеграции ему теперь нужно заходить, как минимум, в 2 системы и более (как правило, у компании есть еще и корпоративный СЭД). Для руководителей компаний это становится достаточно большой головной болью. Пользователи и IT-сотрудники постоянно спрашивают: «Зачем это нужно? Давайте весь новый функционал сделаем в ITSM!» При этом во многих компаниях заявки принимаются по почте/через call-центр, и достаточно низкий процент пользователей работает с ITSM непосредственно через интерфейс.
В нашей практике встречались компании, где не существует собственного интерфейса IGA, есть функционал как движок, и он действительно завязан на заявочные системы. Однако возможности по изменению БП (например, вычислению согласующих неочевидными алгоритмами) в ITSM весьма ограничены.
IGA как единое решение
Очевидным преимуществом использования только IGA для построения системы управления правами пользователей является то, что это автоматически избавляет нас от всех сложностей, неизбежно возникающих при интеграции с внешней системой.
Наличие встроенного workflow в существенной степени облегчает аудит и позволяет в едином окне видеть основания выдачи тех или иных прав. Это позволяет снизить издержки при поиске и подготовке информации для аудиторских проверок и внутренних расследований инцидентов информационной безопасности, обеспечивая целостную картину прав в едином интерфейсе.
Если классический функционал IdM может успешно реализовываться в связке с ITSM, то интеграция с IGA (в частности, реализация функциональности для изменения процессов управления ресурсами и организационными структурами) потребует настолько больших трудозатрат, что фактически находится на грани экономической целесообразности.
На самом деле, при внедрении IGA в компании возникает целый ряд новых процессов. При использовании системы должны быть доступны не просто возможности запроса полномочий, но и предоставлены разнообразные дополнительные сервисы, такие как:
| Роль |
Сервисы |
| Сотрудник |
|
| Согласующий |
|
| Сотрудник ИБ |
|
С одной стороны, все эти интерфейсы не очень сложны. С другой стороны, в классическом ITSM можно реализовать достаточно простые операции, но уже склеивание или разбиение заявок в ITSM реализовать достаточно сложно. Какие здесь есть варианты?
- Мы занимаемся подменой понятий и, говоря про интеграцию, просто пробрасываем интерфейсы примерно в ту же консоль ITSM. Но такой подход сложно назвать полноценной интеграцией.
- Если же мы начинаем полноценную интеграцию, то сталкиваемся с целым рядом таких сложных задач, как расширение БД в самом ITSM, кастомизация процессов и т.п. На выходе получаем интеграцию с IGA на уровне исполнения и ожидания ответов, т.к. сами механизмы остаются в IGA. К тому же эти работы придётся проводить в двух информационных системах.
При этом все чаще встречаются бизнес-пользователи, которые, хотя и далеки от мира IT, с интересом пользуются возможностями IGA, выстраивают динамику и применяют аналитические инструменты. Это означает, что рано или поздно людей придётся пустить в другой интерфейс.
Итак, можно ли создавать заявки в ITSM? Да, можно, и это достаточно просто. Но любой расширенный функционал, включая согласования заявок, лучше реализовывать в системе IGA, предназначенной для решения этих задач.
Попробую провести параллели с нашей реальной жизнью: представьте, что вы студент, учитесь и работаете. Чтобы везде успевать, вы ездите по городу на собственном мотоцикле. Это и правда здорово, вас полностью устраивает такой вид транспорта – быстро, легко и экономично. Проходит время, и вот уже вчерашний студент подрос и женился, появляется ребенок, и возникает вопрос: как передвигаться новым составом? Конечно, можно приобрести мотоциклетную коляску и закрыть требование по перевозке ребенка, но согласитесь, такое решение вряд ли можно назвать оптимальным. А значит, требуется приобретать автомобиль соответствующего класса.
Взгляд со стороны ИБ
Также стоит отразить взгляд на дилемму с точки зрения сотрудников ИБ:
- Любая IGA-система позволяет сравнивать согласованные и реально имеющиеся у сотрудника права доступа. Перенести эту функциональность в ITSM крайне сложно. Как это в итоге будет выглядеть для безопасника? В одной системе ему придется смотреть, куда сотрудник имеет доступ, а в другой – кто, когда и на каком основании выдал этот доступ.
- Использование дополнительной интеграционной корпоративной системы может быть связано с рисками подмены/искажения данных, несанкционированного доступа.
- IGA – сама по себе закрытая программа, к которой можно предъявлять определенные требования по целостности, ограниченному доступу к БД, шифрованию и т.п. Эти требования могут оказаться крайне сложными и неприменимыми для ITSM.
Итак, небольшой чеклист вместо заключения:
| Интеграционный подход |
Централизованная система IGA |
| ? Статическая, устоявшаяся организационная структура компании. |
? Динамичная компания, меняющаяся ОШС (необходима возможность безболезненно отразить или изменить любые схемы согласования заявок). |