Мы начинаем цикл статей, посвященный практическому решению для управления идентификационными данными и правами доступа пользователей, которое можно брать на вооружение. Сегодня расскажем о предпосылках и сложностях выбора варианта реализации со стороны заказчика, а также дадим краткое описание системы. Речь пойдет о нашей разработке на собственной платформе ЦРП («Цифровое Рабочее Пространство»), зарегистрированной в Едином реестре российских программ для электронных вычислительных машин и баз данных (регистрационный номер ПО: 7466). В системе используется свободное программное обеспечение, что исключает риск потери прав на его компоненты по решению зарубежных субъектов.

Схема разработанного нами решения IDM
Схема разработанного нами решения IDM

Назначение решения

Представляемое программное обеспечение относится к классу систем управления учетными или идентификационными данными IDM (Identity Management). Краткое изложение целей подобных решений мы приводим в разделе «Преимущества IDM». Что касается нашей системы, она используется в организации с несколькими сотнями тысяч пользователей, каждый из которых в среднем имеет доступ с различным сочетанием полномочий более чем к 10 информационным системам (ИС) и автоматизированным рабочим местам (АРМ) с различиями в назначении, архитектуре и  моделях управления доступом. Количество ИС и АРМ в эксплуатации превышает 2000. Таким образом, под управлением системы IDM находится несколько миллионов отдельных полномочий, срок действия которых ограничен политиками организации максимум двухлетним периодом, и которые подлежат пересмотру до окончания срока действия. В среднем в год рассматривается более 2 миллионов запросов на предоставление доступа. При этом архитектура решения обеспечивает необходимый уровень производительности и комфортную для пользователей скорость реакции. Все архитектурные узлы решения поддерживают технологии обеспечения и распределения нагрузки с помощью наращивания количества экземпляров.

История: кейс крупного игрока транспортной отрасли

Масштабное изменение структуры и сотни тысяч пользователей в управлении

Подобно многим другим системам на рынке решение приобрело форму и наполнение в ходе разработки под потребности в части управления доступом конкретного заказчика, в данном случае одного из крупнейших игроков российской транспортной области. Во второй половине 2000-х компания претерпевала кардинальные изменения в своей структуре, уходя от регионально обособленных полнофункциональных филиалов к управлению по функциональным блокам на всей территории страны. Эти процессы не обошли и службу ИТ, и в итоге под контролем объединённой ИТ-структуры оказались несколько тысяч информационных систем, АРМ и приложений, обеспечивающих работу сотен тысяч сотрудников компании. Конечно, это потребовало внедрения новых технологий и нового инструментария для управления полномочиями пользователей, чтобы соответствовать строгим требованиям информационной безопасности организации.

Сложности выбора: низкая эффективность и высокая стоимость готовых фреймворков управления доступом

На выбор пути решения этой задачи повлиял комплекс факторов. В пользу лидирующих на рынке систем говорила широта функционального охвата и глубина проработанности функций, множество готовых коннекторов для взаимодействия с управляемыми системами для решения задач предоставления, лишения и запроса актуального состояния полномочий пользователей, для обмена справочными данными и т.п. Но воспользоваться функциональной развитостью было затруднительно. Все аспекты только что объединенной организационной структуры с налаживающимися процессами, унаследованными регулирующими правилами и нормами, изменение которых не могло быть проведено одномоментно, напротив, могли сделать внедрение сложных параметризованных систем малоэффективным и рискованным. Значительное же количество готовых коннекторов было малополезным, поскольку, помимо относительно небольшого количества систем общего назначения, построенных на распространенных за рубежом платформах, находящаяся в эксплуатации основная масса решений была заказной разработки, что не позволяло надеяться на применение готовых фреймворков для управления полномочиями пользователей и сквозной аутентификацией. Всё это не сулило скорого значительного полезного эффекта. В то же время за всё функциональное богатство платить нужно было сразу. И немало, ведь ценообразование таких систем построено на лицензировании по количеству управляемых учетных записей. При этом пользователей в организации насчитывалось несколько сотен тысяч, каждый из них должен был иметь несколько учетных записей в общекорпоративных системах, а также ИС и АРМ в рамках своей специализации.

Создание и текущее состояние

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

На начальных этапах технологической основой была выбрана платформа OрenIDM, однако впоследствии в силу изменения лицензионной политики вендора и для исключения сложностей адаптации к жизненному циклу и составу прикладных функций стороннего ПО функциональное наполнение решения было реализовано уже с применением унифицированных компонентов собственной платформы ЦРП. Это облегчило решение вопросов совместимости, функционального расширения и адаптации, интеграции, переносимости и масштабирования.

Был внедрен блок автоматического или автоматизированного управления полномочиями на основе описаний бизнес-ролей как совокупности правил доступа, ролевых профилей, программных интерфейсов и коннекторов для взаимодействия с управляемыми системами.

Список бизнес-ролей в системе
Список бизнес-ролей в системе

Значительная доля учетных записей создаётся или отключается с автоматическим или автоматизированным предоставлением/лишением полномочий при поступлении из кадровых систем сведений об изменении статуса сотрудника: принятии на работу, занятии определенной должности или увольнении. Конечно, далеко не все ИС еще охвачены автоматическими коннекторами или роботизированной автоматизацией процессов (RPA-сценариями), и часть доступов предоставляется ИТ-специалистами по задачам, автоматически поступающим в ServiceDesk из IDM и автоматически передающим обратно результат выполнения. Однако технологический скачок, открывающий новые возможности во множестве направлений, включая взаимодействие с корпоративной системой менеджмента и управления персоналом в управлении бизнес-ролями, произведён.

Пример страницы со статусом предоставления доступов сотруднику
Пример страницы со статусом предоставления доступов сотруднику

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

Пример карточки описания бизнес-роли в системе
Пример карточки описания бизнес-роли в системе

Естественным результатом также должно стать сокращение ошибок в предоставлении полномочий, лёгкость их выявления и устранения при выполнении операций аудита. Этому будет способствовать и запущенный процесс устранения конфликтов SoD. О принципах и конфликтах SoD можно прочитать в разделе «Конфликты SoD», а о реализованном в нашем решении процессе управления ими подробно расскажем в следующих статьях цикла.

Преимущества IDM

Системы IDM предназначены для управления цифровыми профилями персон, полномочиями доступа и аутентификацией пользователей в ИТ-инфраструктуре организаций. Основными их целями и преимуществами являются:

  1. Безопасность (security). Решения IDM улучшают безопасность, обеспечивая доступ к определённым ресурсам, системам и данным только авторизованным персонам. Это помогает предотвратить несанкционированный доступ, утечки информации и внутренние угрозы путем использования надёжных механизмов аутентификации, контроля доступа и процессов инициализации/деинициализации (provisioning/deprovisioning) пользователей.

  2. Соответствие (compliance). Во многих отраслях существуют требования регуляторов в области безопасности и защиты данных, которым организации должны следовать. Системы IDM помогают в достижении стандартов соответствия, предоставляя сильные механизмы контроля доступа пользователей, записи аудита и механизмы применения соответствующих политик.

  3. Упрощенная инициализация полномочий пользователей (provisioning). Решения IDM ускоряют процессы создания, изменения и лишения прав учетных записей в различных системах и приложениях. Включение в работу и исключение из процессов сотрудников, подрядчиков и партнеров становится быстрее, экономя время и уменьшая издержки на администрирование.

  4. Единый вход (SSO, Single Sign-On). Решения IDM часто предоставляют и функциональность SSO, позволяя осуществлять вход в различные системы и приложения с однократной аутентификацией при начале сеанса работы. Это упрощает жизнь пользователям, освобождая от необходимости вводить реквизиты для входа в каждую систему, снижая утомляемость от запоминания множества имен и паролей. Производительность сотрудников увеличивается за счет получения быстрого доступа к нужным ресурсам и минимизации времени на устранение ошибок аутентификации.

  5. Централизованное управление. Системы IDM предлагают единое хранилище для управления профилями пользователей, их полномочиями и прочими атрибутами. Администрирование становится проще, обеспечивается согласованность полномочий пользователей и уменьшается риск ошибок и несоответствий прав доступа в разных системах.

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

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

  8. Самообслуживание. В состав многих систем IDM включены порталы самообслуживания, где пользователи могут управлять своими правами доступа, включая запросы на их расширение, и сбрасывать пароли. Такие возможности уменьшают загрузку ИТ-персонала.

Конфликты SoD

Принцип разделения обязанностей

Принцип разделения обязанностей (SoD, Segregation of Duties) заключается в предотвращении конфликта интересов и мошеннических действий или ошибок путём распределения критических обязанностей или задач между несколькими людьми. SoD обеспечивает отсутствие ситуаций, когда один человек имеет полный контроль над каким-либо процессом от начала и до конца. Разделением ключевых функций организации создают комплекс сдержек и противовесов и обеспечивают внутренний контроль.

Конфликт ролей

Из вышеизложенного следует, что конфликт SoD — это нерешённый конфликт интересов, ситуация, когда несочетающиеся задачи или обязанности объединены в определенной роли или назначены одной персоне. Это происходит, когда у пользователя есть возможность выполнить несколько задач, которые в сочетании могу привести к нарушению внутреннего контроля и нежелательным последствиям. Конфликты SoD подрывают принцип сдержек и противовесов и увеличивают уязвимость процессов к мошенничеству, ошибкам или ненадлежащему использованию полномочий.

Примеры SoD

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

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

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

  • Управление изменениями и контроль качества (QA, Quality Assurance). Процесс управления изменениями включает непосредственное изменение ИТ-систем, QA отвечает за тестирование и валидацию изменений. Разделяя эти роли, добиваются того, что изменения не тестируют, оценивают и утверждают те же люди, кто их разрабатывал. Это помогает сохранять объективность, уменьшает риск ошибок и обеспечивает независимую проверку изменений перед их применением.

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

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

  • Утверждение и проведение платежей. В финансовых системах важно разделять обязанности между теми, кто отвечает за утверждение оплат и теми, кто их выполняет. Это снижает вероятность мошеннических действий, поскольку ни у кого не будет возможности инициировать, утвердить и провести платёж без независимой проверки.

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

Комментарии (0)