БЛАЖКО С.В., аспирант кафедры информационных технологий и вычислительных систем Московского государственного технологического университета «СТАНКИН», г. Москва, blazhko@sergei.by

Рассмотрение концептуальных
особенностей решений типа IdM

В рамках производственной деятельности ИТ-персоналу предприятия приходится подчас выполнять много однотипных операций, связанных с управлением учетными записями пользователей в разных информационных системах. Для уменьшения времени, необходимого для выполнения таких операций, персонал может разрабатывать собственные программные решения, но их использование, как правило, ограничено конкретными системами, которые не связаны между собой. На крупных предприятиях для управления жизненным циклом учетных записей одних и тех же пользователей в различных системах внедряют системы делегированного администрирования, или IdM (англ. Identity Management). В данной статье будут рассмотрены особенности функционирования, внедрения и проектирования IdM-систем

Введение

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

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

Однако указанная ситуация с каждым годом встречается все реже. Разработчики enterprise-решений изначально закладывают определенные программные возможности для организации того или иного взаимодействия с имеющимися целевыми системами предприятия. Также стоит отметить положительное влияние фирм-интеграторов, которые в данном случае являются, с одной стороны, посредником между разработчиком продукта и заказчиком, с другой стороны, осуществляют доработку/донастройку системы для конкретного заказчика. В ряде случаев именно фирмы-интеграторы реализуют механизмы для взаимодействия между гетерогенными системами. Но далеко не все проблемы можно решить лишь путем интеграции систем. Например, типовым бизнес-процессом предприятия является введение нового сотрудника. Представим возможные этапы данного процесса в рамках некоторого абстрактного предприятия.

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

Время создания учетных записей в конкретных системах может различаться в зависимости от различных факторов: уровня доступа в рамках одной системы, количества исполняющих узлов, зависимости учетных записей одной системы от записей других систем, внутренних таймингов конкретной системы и т.п. В идеальной ситуации все необходимые ресурсы будут предоставлены новому сотруднику за время между подписью документов о приеме на работу и окончанием прочтения распорядительной документации предприятия. В реальности возникает большое число факторов, которые так или иначе влияют на скорость ввода сотрудника в информационное пространство: занятость сотрудников, ошибки в программном обеспечении, недоступность аппаратных средств, невнимательность и т.д. В случае предоставления всех необходимых ресурсов в ходе работы сотрудник может столкнуться с необходимостью личного обращения к персоналу, обслуживающему конкретную систему, с целью предоставления дополнительных полномочий либо попросту сброса пароля [8], [3].

Ситуация может усугубляться в случае, если действительно все операции в конкретных системах производятся вручную, а также в компании отсутствуют системы вида IT Service Management.

Проведем примерный расчет среднего времени заведения учетных записей в служебных системах.

• Количество сотрудников – 6000.
• Количество ресурсов – 28.
• Количество принятых и уволенных сотрудников в день (в среднем) – 11 чел.
• Время заведения/удаления учетной записи на первого пользователя – от 1 минуты (например, в Microsoft Active Directory) до одного часа (например, в Diasoft 5NT) или до нескольких часов (Misys Kondor Plus).

Задача: рассчитать минимальное время (T) регистрации/удаления 11 сотрудников (например, в 10 ресурсах). Примем среднее время создания/удаления сотрудника равным 10 мин:

T = 11 (чел.) * 10 (ресурсов) * 10 (мин) = 1100 мин ≈ 18 ч

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

Концепция IdM

Для решения вышеуказанной проблемы существует комплекс подходов и реализаций программных средств для централизованного управления учетными данными – делегированное администрирование (англ. Identity Management, IdM).

В общем и целом IdM как методика заключается в том, чтобы переназначить (делегировать) типовые задачи управления учетными данными с обслуживающего персонала на специализированное программное решение. Использование IdM-решений позволяет не только снизить нагрузку на персонал, но также предоставить единую точку управления учетными данными [5].

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

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

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

Ключевым определением методологии IdM принимается идентичность, цифровая личность или глобальная учетная запись (англ. Identity) – некое отображение реального организационного объекта в информационном пространстве системы. Пример отображения (см. рис. 1):

• сотрудник – пользователь;
• организационная единица – организация/отделение/отдел;
• должность – роль и т.п. в зависимости от реализации.

Рисунок 1. Пример связи реальных сущностей с сущностями IdM

Общая модель идентичности может быть построена из небольшого набора аксиом, например, что все идентичности в данном пространстве имен являются уникальными или что такие идентичности имеют определенное отношение к соответствующим сущностям в реальном мире. Такая аксиоматическая модель выражает чистую идентичность в том смысле, что модель не ограничена конкретным контекстом приложения. В целом объект (реальный или виртуальный) может иметь несколько идентичностей, и каждая идентичность может включать в себя несколько атрибутов, часть которых является уникальной в данном пространстве имен.

IdM-решения

Итак, в общем случае минимальным составом компонентов системы делегированного администрирования может являться следующий:

1. Центральное хранилище учетных записей.
2. Механизмы получения данных об учетных записях.
3. Механизмы распространения данных.
4. Пользовательский UI.

В ряде решений данный список может дополняться специфическими компонентами, свойственными для конкретного решения, и являться визитной карточкой конкретного разработчика. Также решения могут различаться по способу хранения и представления данных. Выделяются online-решения – когда IdM предоставляет информацию на данный текущий момент, обращаясь непосредственно к источнику информации (к целевой системе), все действия по модификации этой информации выполняются в реальном времени и offline – в хранилище находятся условно-постоянные данные, которые периодически подгружаются из целевых систем и загружаются в них. К достоинствам online-систем можно отнести актуальность представляемой информации, к недостаткам – высокую нагрузку на канал передачи данных и целевую систему и невозможность получения информации при нарушении работы последней. Достоинства и недостатки offline-систем, соответственно, являются диаметрально противоположными online. В связи с этим большинство актуальных решений комбинируют данные подходы, например, осуществляя периодическую выгрузку для предоставления данных, а операции по модификации – в реальном времени.

Заполнение центрального хранилища системы может осуществляться двумя способами:

• ручное управление – таким образом, IdM может выступать в роли HR-системы;
• выгрузка из так называемого «источника достоверных данных», или ИДД (например, HR-системы). Данный способ называют «реконсилиацией» (англ. reconciliation). Стоит отметить, что данный вид управления подходит какдля идентичностей, так и для, собственно, учетных записей в информационных ресурсах, которые в данном случае уже не HR-системы, а конкретные целевые системы.

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

Как и любые сущности в других системах, сущности в IdM обладают набором(ами) атрибутов, каждый из которых может быть заполнен либо получен из разных источников, а также может распространяться различным получателям (ресурсам). Например:

• ФИО и должность получаются из HR-системы;
• логин и пароль формируются автоматически в самой IdM;
• должностная роль указывается вручную привилегированным пользователем IdM;
• указанные выше атрибуты передаются в ресурс типа «корпоративная электронная почта», после чего из последнего в процессе выгрузки получается атрибут «адрес электронной почты» и т.д.

Таким образом, в случае регулярной синхронизации между IdM и другими системами первая будет отражать актуальную информацию о атрибутах идентичности и всех ее ресурсов.

На данный момент существует достаточное число различных реализаций IdM, которые разнятся начиная от дизайна пользовательского интерфейса и заканчивая подходом к организации взаимодействий между другими системами. Указанные ранее компоненты описывают лишь базовые концептуальные элементы IdM, которых достаточно лишь для представления IdM как консолидированного справочника атрибутов и ресурсов с возможностью их управления и распространения. Актуальные продукты, реализующие концепцию IdM, вводят множество других элементов, которые необходимы для более приближенного к бизнесу взаимодействия [3]. В качестве наиболее часто встречающихся элементов можно выделить следующие [2]:

• Движок ролевой модели – механизмы, позволяющие в автоматизированном режиме по заданным правилам производить создание/удаление/модификацию атрибутов и ресурсов идентичностей.
• Подсистема согласований – механизмы для поддержки заявок на согласование определенных действий (выдача/отзыв ресурсов, модификация несобственных атрибутов).
• Как следствие из 2 – подсистема «одного окна» – организация портала самообслуживания.
• Модуль отслеживания неизбыточности прав – механизмы для отслеживания избыточности или противоречивости прав у конкретных лиц. Пример: разрешение конфликтов вида выдачи одновременно двух ролей А и Б, роль А – выдает ресурс X, роль Б – отнимает X.
• Модуль симуляции изменений – наличие в системе временного хранилища данных, которые отражают ситуацию не в реальном времени в конкретном ресурсе, а в виде некоторой промежуточной информации в форме «как есть» – «как должно быть».
• Подсистема оповещения.
• Модуль ведения отчетности.
• Организация концепта IAM (англ. Identity and Access Management), то есть управление не только идентичностями, их атрибутами и ресурсами, но также предоставление идентификационных и аутентификационных услуг другим системам (например, работа в качестве Single Sign-On бэкенда).

Более того, разработчики систем изначально закладывают возможность определенной кастомизации продукта, предоставляя API для организации операций, необходимых конкретному заказчику. Данная ситуация логична и укладывается в концепцию IdM, как минимум потому, что для связи с другими системами при помощи так называемых коннекторов, базовых механизмов может быть недостаточно ввиду особенностей инфраструктуры конечного потребителя продукта. Таким образом, интеграторы осуществляют разработку и доработку таких элементов, как:

1. Коннекторы.
2. Обработчики событий.
3. Запланированные задачи.
4. Поведенческие механизмы.
5. Элементы интерфейса и прочие.

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

Трудности внедрения и использования IdM

Рассмотрим проблемы, которые так или иначе связаны с внедрением и использованием IdM-решений.

Первая проблема была обозначена ранее и связана в целом с отношением к решению.

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

Из дополнительных проблем стоит отметить тот факт, что ввиду автоматизации многих рутинных действий, отказ тех или иных элементов IdM приводит к тому, что ручное проведение компенсационных мероприятий (например, ручное заведение/изменение УЗ в обход IdM) может быть неполноценным или идти в разрез с сформированными правилами и потоками исполнения [7], [4].

Следующая проблема связана с тем, что IdM-системы относятся к корпоративным решениям, которые, как правило, разрабатывают крупные вендоры. На текущий момент на отечественном рынке представлены следующие функционально зрелые решения:

• Oracle (ранее Xellerate) Identity Manager
• SailPoint IdentityIQ
• IBM Security Identity Manager
• Microsoft Identity Manager
• NetIQ (ранее Novell) Identity Manager
• 1IDM
• Avanpost IdM
• RedSys RS IAM

Вендоры, в свою очередь, формируют условно закрытое комьюнити, ввиду чего без прохождения целевого обучения уровень вхождения в данную сферу бывает довольно высоким. Негативные факторы могут возникать, когда уровень кастомизации базового решения настолько высок, что непосредственный разработчик (вендор) бывает не в состоянии оказать поддержку (платную лицензированную) в определенных вопросах, а поиск решений конкретных проблем в открытых источниках не приводит к успеху. Также ситуация иногда складывается так, что явные обнаруженные программные ошибки исправляются в новой major-версии продукта, rolling update на которую без дополнительной платы непредставляется возможным. Даже в случае обновления в новых версиях продукта имеют место функциональные изменения, которые несовместимы со старыми версиями продукта. Ввиду данного факта иногда встречаются организации, которые используют IdM-решения, поддержка версий которых завершилась более десяти лет назад. Стоит отметить, что на данный момент на рынке существуют свободные IdM-решения, такие как OpenIAM, Apache Syncope и Evolveum midPoint (OpenIDM компании ForgeRock перестал быть свободным в 2017 году [1]), функционально близкие тем, которые разрабатывают крупные игроки рынка. Изучение и внедрение данных решений благоприятно сказывается на реализации конкретных проектов.

Следующим моментом является необходимость в высокой квалификации сотрудников фирмы-интегратора. Исходя из гетерогенной специфики методологии сотрудникам, занимающимся внедрением и доработкой решений, необходимо обладать обширными знаниями в сфере решений масштаба предприятия. Таким образом, интеграторы являются в своем роде «универсальными солдатами» в сфере ИТ, которые должны иметь навыки в администрировании ОС, прикладных систем, программировании на языках и фреймворках целевых систем, администрировании персонала, аналитики и т.д. Низкая квалификация будет иметь последствия в виде очевидных проблем при организации взаимодействия, а также потенциальных уязвимостей в коде, используя которые можно нарушить работу не только IdM, но и конкретных ресурсов предприятия. Последний фактор находит отражение со стороны администрирующего персонала конкретных систем, которые опасаются за целостность решения и сохранность данных по причине того, что коннекторы к системам для проведения операций (создание/удаление/модификация учетных записей) должны работать от имени привилегированного субъекта.

Выводы

Резюмируя все вышесказанное: IdM как методология показала свою практическую полезность при использовании в виде соответствующих решений на предприятиях. Каждая крупная компания на данный момент в том или ином виде имеет внедренное решение для делегированного администрирования, при помощи которого производится управление пользовательскими ресурсами. Как и с любым другим решением, использование IdM сопряжено с рядом трудностей, которые можно свести к минимуму в случае грамотного подхода к проектированию внедрения и доброжелательного отношения со стороны персонала предприятия. С точки зрения автора, положительным моментом на текущий момент развития данной области является появление и бурное развитие свободных IdM-решений, которые разрабатываются и поддерживаются сообществом, состоящим из бывших разработчиков и интеграторов существующих крупных решений.

1. Березкин Д. OpenIDM и другие продукты ForgeRock перестали быть бесплатными // SecurityLab.ru by Positive Technologies. 2017. URL: https://www.securitylab.ru/blog/personal/securny/341701.php.
2. Бондарь Д. Сравнение IdM-систем // JETINFO. ИТ-ПОРТАЛ КОМПАНИИ «ИНФОСИСТЕМЫ ДЖЕТ». 2014. URL: http://www.jetinfo.ru/stati/populyarnye-idm-resheniya-chto-i-kak.
3. Лаврухин А.Ю. Подходы к практическому внедрению Identity Management-решений. // «Безопасность информационных технологий», № 17/1, 2010.
4. Принципы успешного внедрения IDM. Бизнес-кейсы [Электронный ресурс] // Хабрахабр: [сайт]. [2014]. URL: https://habr.com/ru/post/217667/.
5. Самков Д.Б., Гаврикова Ю.В. Автоматизация процесса управления идентификационными данными пользователей промышленного предприятия // Информационные технологии. Проблемы и решения: материалы всероссийской научно-практической конференции, 2016. – С. 129-132.
6. Система управления доступом (IDM): как выбрать, внедрить и не разочароваться [Электронный ресурс] // TAdviser. Государство. Бизнес. ИТ: [сайт]. [2017]. URL: http://www.tadviser.ru/index.php/Статья:Система_управления_доступом_(IDM):_как_выбрать,_внедрить_и_не_разочароваться._TADетали.
7. Титов В.А., Замараева О.А., Кузин Д.О. Приеимущества (sic!) и недостатки внедрения iDm-систем в организации. // «Международный журнал прикладных и фундаментальных исследований», № 12/1, 2014 г. – С. 138.
8. Юданов Ф.Н., Федотов А.М., Сейтасым Р.С. Технологии единой авторизации и организации единой точки доступа к информационным ресурсам сети // Вестник Новосибирского государственного университета. Серия: Информационные технологии, 2012. – С. 117-126.

Ключевые слова: idm, iam, identity manager, identity management, identity and access management, делегированное администрирование, управление учетными записями.

Conceptual features of IdM-type solutions

Blazhko S.V., Postgraduate, Department of Information Technologies and Computing Systems, Moscow State Technological University "STANKIN", Moscow, blazhko@sergei.by

Abstract: As part of the production activities, the enterprise IT staff of has to perform many similar operations related to the management of user accounts in information systems. To reduce the time required to perform such operations, staff can develop limited software solutions only to specific systems but not compatible to other systems. Large companies, to manage the life cycle of same-user accounts in various systems, often use identity management or IdM systems. This article considers the features of the functioning, implementation and design of IdM-systems.

Keywords: idm, iam, identity manager, identity management, identity and access management, user account management.

Комментарии могут оставлять только зарегистрированные пользователи