Статья: все, что вы хотели спросить про IDM

Short intro: here you can find "All you wanted to ask about IDM" article, initially these questions were distributed before AM Live event...

Перед трансляцией AM Live на сайте anti-malware были опубликованы вопросы к обсуждению, но не все удалось обсудить в рамках трансляции. Мне показалось интересным ответить письменно в рамках статьи (и заодно обновить раздел Статьи), которую и публикую здесь. Статья, которую я назвал "Все, что вы хотели спросить про IDM" - под катом.

1. Состояние рынка IdM 

a. Кто является внутренними заказчиками IdM/IGA 

Может быть ИТ, может быть ИБ. В моем опыте это 70 / 30 в пользу ИТ. Решение Oracle на российском рынке уже 13 лет, изначально был интерес со стороны автоматизации ИТ, позже стал виден интерес со стороны безопасников.

b. Как рассчитать экономический эффект от внедрения

Исторически внедрения в России IDM развивались со стороны ИТ и большинство экономического эффекта рассчитывалось как сокращение стоимости ручного труда администраторов, переориентация труда администраторов на поддержку других бизнес-задач (и, как следствие, более быстрый time-to-market для каких-то выводимых на рынок продуктов), ну и сокращение простоя сотрудников из-за несвоевременного предоставления доступа (при приеме на работу, при смене должностных обязанностей и/или подразделения). 

Составляющую ИБ, связанную со снижением рисков в денежном выражении в связи с реализацией, например, принципа наименьших полномочий, принципа разделения полномочий (SOD), контроля привязки учетных записей в целевых системах к реальному сотруднику (отсутствие сиротских учетных записей) и прочее, на моей памяти не считалось, ну или почти не считалось (или я при этом не присутствовал). В теории можно, конечно, опираться на данные каких-либо институтов типа Ponemon, которые помогают оценить риски утечки данных в численном выражении, но я пока с таким не сталкивался. Составляющую ИБ если и учитывают, то качественно.

c. Какие отрасли являются передовыми по внедрению IdM/IGA 

Отрасли, в которых изначально стремились к систематизации управления правами доступа, где уже имела место формализация процессов, связанных с управлением доступа, с управлением ролями. Это телекомы, финансовый сектор, нефтегазовый, это в первую очередь. Интересуются IDM’ом многие, но для того, чтобы почувствовать эффект от IDM, компания должна обладать определенным размером, мало кто задумывается об IDM, если в компании 50 сотрудников и все друг друга знают. 

d. Как переход на удаленку повлиял на рынок 

При удаленной работе дополнительный вес получает составляющая ИБ, в частности, принцип наименьших полномочий, чтобы сотрудник имел доступ только к тем данным, которые положены ему по должностным обязанностям. Если раньше процессы сертификации доступа (как проверка неизбыточности полномочий на периодической основе) и контроля разделения полномочий были почти у всех на заднем плане, сейчас заказчики начинают этим интересоваться. 

Но ажиотажного спроса, который накрыл некоторые другие рынки (например, устройств аутентификации), при переходе на удаленку не случилось.

2. Технические особенности различных IdM/IGA 

e. Какой должна быть современная архитектура IGA-система 

Когда мы говорим об архитектуре современной информационной системы (и IDM/IGA как частный случай), мы говорим про микросервисы, контейнеризацию, кластера Kubernetes, API-first (сначала API, затем оркестровка и интерфейс конечного пользователя), самооптимизирующиеся автономные базы данных, Terraform и Ansible как средства быстрого разворачивания конфигураций, публичное или частное облако, наконец. 

Мне попадалась аналогия Pet versus Cattle (домашний питомец и домашняя скотина). Если раньше каждый сервер (IDM/IGA в том числе) имел имя, если он ломался, его чинили, лечили, сервер был домашним питомцем. Сейчас на первое место вышла взаимозаменяемость и сервера стали, по аналогии, «домашней скотиной». Вышел из строя узел кластера? Не вопрос, заменим другим точно таким же, автоматизированно скачаем докер-контейнер из реестра и при необходимости автоматизированно подправим конфигурацию. 

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

При этом обязательна поддержка общепринятых стандартов в частности SCIM (System for Cross-Domain Identity Management), представляющий универсальный REST-API для работы с системой. 

Это с архитектурной точки зрения.

С точки зрения функциональной архитектуры возможны разные подходы, каждый продукт реализует ее по-своему, функциональная архитектура не столь быстро устаревает и привязана к самой решаемой задаче, а задачи в области IDM/IGA меняются не столь быстро. 

f. В какой ИТ-среде должна работать IGA-система 

Ну мы это уже обсудили. Микросервисы, контейнеры, кластера Kubernetes, умные базы данных.

g. Коннекторы: предустановленные, заказные и самописные 

Безусловно, должен быть некоторый набор коннекторов из коробки, как правило к самым распространенным системам и инструментарий, позволяющий создавать эти коннекторы самостоятельно, скажем на Java, .NET, Groovy, да на чем угодно. Но тут интересно не это. По моему опыту индивидуальные коннекторы работают, когда у компании ограниченное количество подключенных к IDM информационных систем (точнее, типов информационных систем) – 3, 5, 10, в конце концов. 

Но если количество типов информационных систем исчисляется несколькими десятками и (одно часто дополняет другое) системы собственной разработки или заказной разработки, то в удачных проектах всегда разрабатывали некоторый промежуточный интерфейс, например, таблицы в СУБД, шина и т.д., а разрабатываемым системам ставили условие их принятия, если они будут поддерживать соответствующий интерфейс и задача создания и, самое главное, поддержки интеграции с IDM ложилась на плечи разработчиков. Исторически для этой цели существовал стандарт SPML на основе XML (Service Provisioning Markup Language), но работать с ним было сложно и он мало использовался. Сейчас есть стандарт SCIM (System for Cross-Domain Identity Management) на базе REST API, который существенно проще в использовании. 

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

Также есть смысл упомянуть о рынке SCIM-шлюзов (SCIM Gateway’и), когда коммерческие компании сами пишут и поддерживают SCIM-интерфейсы к различным целевым системам (фактически коннекторы), в Штатах сейчас этот рынок на подъеме.

h. Зачем нужна сертификация и аттестации доступа 

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

Если нет реализации идеальной ролевой модели, когда все выдается только через роли и только автоматизировано (например, путем оценки атрибута), чего почти не случается, а, скажем, через процессы запроса доступа и согласование, может происходить накапливание полномочий, так как пользователи редко запрашивают себе отзыв полномочий. Это несет в себе риски и противоречит принципу наименьших полномочий и именно с этим борются процессы сертификации доступа.

i. Как работает предотвращение конфликтных полномочий (SOD - Segregation of Duties) 

Понятно, что не все полномочия могут быть назначены одновременно, даже если пользователь может обладать ими по должностным обязанностям (например, разместить заказ и отгрузить заказ), одновременное назначение таких полномочий ведет к возможности мошенничества. Исторически SOD делался внутри бизнес-системы, например, Oracle E-Business Suite, такой SOD обладал рядом преимуществ, он глубоко работал с информационной системой и позволял выявить SOD-конфликты на низком уровне. 

Но зачастую такой подход не позволял реализовать кросс-системный SOD, когда конфликтуют полномочий в разных системах, и соответствующие механизмы использовались в различных системах, что приводит к дублированию функционала. Системы IDM/IGA зачастую предоставляют возможности упрощенного кросс-системного SOD, причем как превентивно (когда несовместимые полномочия не назначаются), так и детективно (когда они назначены, но нужно выявить конфликт).

Еще один момент. То, что полномочия несовместимы еще не означает, что они не могут быть одновременно назначены по бизнес причинам. Но важно потом не забыть и отобрать их, тут на помощь приходит детективный SOD и связь с процессами сертификации доступа (есть конфликт, высокий риск, пользователь заметен в сертификационном отчете).

j. Зачем нужен киоск самообслуживания и как научить сотрудников с ним работать 

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

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

k. Как правильно интегрировать IGA с системами аутентификации и SSO 

Смотря в каком контексте имеется в виду интеграция. Да, часто подключают IDM к корпоративной SSO системе (у нас в Oracle так сделано). Если говорить про то, что IDM должен управлять учетными записями и правами доступ в целевой системе, которая входит в контур SSO, то это обычный провижионинг.

l. Есть ли место машинному обучению и ИИ в IGA? 

Конечно. Например, в процессах Role Mining’а или в процессах формирования риска, ассоциированного с пользователем. За этим будущее и у нашего продукта на эту тему достаточно агрессивная дорожная карта развития.

3. Особенности внедрения IdM 

m. Сколько времени занимает внедрение и чего нужно начинать 

Зависит от многих факторов… IDM занимает промежуточное место между технологическим решением и бизнес-приложением. Развернуть IDM можно за один день, еще за два дня настроить стандартные коннекторы к AD и Exchange, к таблице СУБД, например, где хранятся сотрудники и которая может быть доверенной. Реконсилируете пользователей из HR, настраиваете правила заведения в AD / Exchange и уже простая автоматизация готова. Добавьте к этому использование стандартных процессов согласования доступа (например, менеджером сотрудника, для которого запрашивают право доступа) и система готова к использованию. Эти процессы, кстати, описаны в материалах OIM12cPS4 Workshop. Остальные системы можно вписать в общий контур согласования как «отсоединенные ресурсы», а затем постепенно подключать их по мере разработки коннекторов. Имхо, минимально неделя.

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

n. Как убедить бизнес-подразделения в необходимости внедрения новой «неудобной» системы 

Сделать ее удобной, показать, в чем удобство и в чем ее выгода. IDM должен быть помощником, а не неудобным противником.

o. Кто и когда должен разработать модель доступа 

Разрабатывается и модель доступа, и процессы для ее доработки в процессе функционирования. Статическая модель доступа устаревает, как только ее сделали, модель доступа чаще динамическая и необходимо создавать процессы управления ролями. Роль рождается, живет и умирает.

Лучше, конечно, когда у заказчика уже имеется какая-то базовая ролевая модель, но возможно ее сформировать и в процессе внедрения. Даже иногда само внедрение IDM может ставить себе целью формирование ролевой модели (например, тем же инструментарием Role Mining’а).

p. Как снизить нагрузку на специалистов заказчика во время внедрения 

Нагрузка? Обучение, вовлечение, IDM в итоге должен быть принят заказчиком. Это редко бывает сторонней услугой, которую оказали и забыли. Часто возникает вопрос, сколько сотрудников заказчика должно сопровождать систему. Тут у меня есть хороший пример, на одной из конференций в Штатах выступал представитель крупной ритэйловой компании в должности «директора департамента управления учетными записями». Другой крайний пример – российская компания (уже не существующая), где поддержкой системы занимался один студент.

Конечно, для разных компаний IDM играет разную роль, где-то это критичная система, где-то не столь.

q. На какую поддержку в процессе эксплуатации от вендора можно рассчитывать 

Стандартная, расширенная, а также бесплатная со стороны пресэйл консультантов, workshop’ы, блоги (easyoraidm.com), коммьюнити, встречи и прочее. Заказчик не должен оставаться один на один с системой.

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

4. Прогноз развития рынка систем IDM 

r. Что ожидает рынок в перспективе 2-3 года 

Коммодизация автоматизации предоставления доступа, упор в часть IGA, интеграции IDM в корпоративные бизнес-процессы безопасности компании. Вендоры, включая Oracle, активно продвигают облачный IDM, который сочетает в себе функциональность Identity Management и Access Management. В США уже существенная доля приходится на реализацию именно облачного IDM, тогда как в России облака идут с трудом. 

За последние годы архитектура информационных систем сильно ушла вперед, и вендорам IDM придется ее догонять. Переписывать приложения под новую архитектуру трудоемко, поэтому важную роль будут играть микросервисы, которые позволят постепенно изменять приложение, существенно ускоряя сроки реализации нового функционала. 

Oracle сейчас проводит реархиктуру IDM, чтобы приложение соответствовало современным стандартам. Старые монолитные приложения это как динозавры в эпоху, когда уже появились первые млекопитающие. Те, кто это вовремя поймут и перестроятся под новую архитектуру, те и останутся на рынке, остальные вымрут как динозавры.

s. Будет ли IGA внедряться по модели SaaS 

Возможно. Сама по себе multitenancy достаточно сложна для большинства IDM систем. Скорее сам продукт как набор микросервисов может быть развернут как SaaS по щелчку мыши заказчика в частном или публичном облаке. 

t. Как облака и мобильность повлияют на рынок IGA

Они уже влияют. SCIM , SCIM Gateway – новый рынок, компании разрабатывают SCIM-шлюзы позволяющие. Консолидация услуг разработки и поддержки коннекторов.

u. Какие отрасли дозреют до внедрения IdM

Те, которые сейчас не дозрели =)