- PVSM.RU - https://www.pvsm.ru -
С каждым годом парк информационных систем компаний все больше разрастается, вместе с ним пропорционально усложняются задачи управления, контроля и разграничения прав доступа сотрудников к информационным ресурсам. Наличие на рынке решений, частично перекрывающих функционал друг друга, дает плодотворную почву для новых и новых дебатов. Как должна быть реализована система управления доступом – через интеграцию с 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 для построения системы управления правами пользователей является то, что это автоматически избавляет нас от всех сложностей, неизбежно возникающих при интеграции с внешней системой.
Наличие встроенного workflow в существенной степени облегчает аудит и позволяет в едином окне видеть основания выдачи тех или иных прав. Это позволяет снизить издержки при поиске и подготовке информации для аудиторских проверок и внутренних расследований инцидентов информационной безопасности, обеспечивая целостную картину прав в едином интерфейсе.
Если классический функционал IdM может успешно реализовываться в связке с ITSM, то интеграция с IGA (в частности, реализация функциональности для изменения процессов управления ресурсами и организационными структурами) потребует настолько больших трудозатрат, что фактически находится на грани экономической целесообразности.
На самом деле, при внедрении IGA в компании возникает целый ряд новых процессов. При использовании системы должны быть доступны не просто возможности запроса полномочий, но и предоставлены разнообразные дополнительные сервисы, такие как:
Роль |
Сервисы |
Сотрудник
|
|
Согласующий
|
|
Сотрудник ИБ
|
|
С одной стороны, все эти интерфейсы не очень сложны. С другой стороны, в классическом ITSM можно реализовать достаточно простые операции, но уже склеивание или разбиение заявок в ITSM реализовать достаточно сложно. Какие здесь есть варианты?
При этом все чаще встречаются бизнес-пользователи, которые, хотя и далеки от мира IT, с интересом пользуются возможностями IGA, выстраивают динамику и применяют аналитические инструменты. Это означает, что рано или поздно людей придётся пустить в другой интерфейс.
Итак, можно ли создавать заявки в ITSM? Да, можно, и это достаточно просто. Но любой расширенный функционал, включая согласования заявок, лучше реализовывать в системе IGA, предназначенной для решения этих задач.
Попробую провести параллели с нашей реальной жизнью: представьте, что вы студент, учитесь и работаете. Чтобы везде успевать, вы ездите по городу на собственном мотоцикле. Это и правда здорово, вас полностью устраивает такой вид транспорта – быстро, легко и экономично. Проходит время, и вот уже вчерашний студент подрос и женился, появляется ребенок, и возникает вопрос: как передвигаться новым составом? Конечно, можно приобрести мотоциклетную коляску и закрыть требование по перевозке ребенка, но согласитесь, такое решение вряд ли можно назвать оптимальным. А значит, требуется приобретать автомобиль соответствующего класса.
Также стоит отразить взгляд на дилемму с точки зрения сотрудников ИБ:
Итак, небольшой чеклист вместо заключения:
Интеграционный подход |
Централизованная система IGA |
✓ Статическая, устоявшаяся организационная структура компании. ✓ Уже внедрено классическое IdM-решение. ✓ В наличии ресурсы для реализации и поддержки интеграционного решения. ✓ Регламенты компании требуют отображения всех изменений в IT-инфраструктуре как задач в ITSM-системе. ✓ Необходима единая точка входа для любых запросов пользователей к IT.
|
✓ Динамичная компания, меняющаяся ОШС (необходима возможность безболезненно отразить или изменить любые схемы согласования заявок). ✓ Необходима функциональность, характерная для систем класса IGA (процессы управления ресурсами и ОШС, SoD). ✓ Важно наличие удобных аналитических инструментов. ✓ Частые аудиторские проверки. ✓ Есть требования к целостности системы. ✓ В компании существует контроль сроков исполнения заявок.
|
Автор: SolarSecurity
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/264657
Ссылки в тексте:
[1] Источник: https://habrahabr.ru/post/338990/
Нажмите здесь для печати.