В крупных компаниях с большой ИТ-инфраструктурой и многообразием информационных систем автоматизация управления процессами, связанными с управлением учетными записями изменениями их полномочий, становится ключевым местом. Как же выстроить и автоматизировать процесс управления доступом в компании? Как выглядит типовой бизнес-процесс согласования доступа пользователя к информационной системе и как реализовать его в Avanpost IDM.
- Введение
- Описание типового бизнес-процесса согласования доступа к информационной системе
- Настройка процессов согласования доступа в Avanpost IDM
- Выводы
Введение
В крупных компаниях управление большим количеством учетных данных пользователей и доступом к десяткам, а то и сотням информационных систем является один из самых острых вопросов. В «ручном» режиме, когда сотруднику требуются дополнительные полномочия, он создает служебную записку, которая визируется непосредственным его руководителем, проходит необходимые согласования в службе ИБ и отделе экономической безопасности, а затем поступает в ИТ-службу для исполнения. Кроме того, все служебные заявки должны храниться в компании для последующего аудита ИБ. Узким местом в таком процессе станет ИТ-служба, в условиях большого числа информационных систем пользователей процесс предоставления прав доступа затягивается, а результатом станут простои корпоративных бизнес-процессов при получении доступа к ресурсам. Кроме того, нередки случаи наделения пользователя избыточными полномочиями. Все это ведет к необходимости снижения стоимости процессов контроля доступа и сокращения времени простоя пользователей в ожидании доступа.
Первое и самое очевидное решение — это автоматизация процессов управления учетными записями и правами доступа. Для этого существует отдельный класс решений — IDM- /IGA-системы. При интеграции IDM-системы в инфраструктуру заказчика автоматизация процесса выдачи полномочий является одним из важных этапов.
В статье мы рассмотрим, как с помощью системы управления учетными записями и правами доступа Avanpost IDM 6.0, разработанной российской компанией «Аванпост», можно настроить процесс согласования доступа по типовым требованиям заказчика. Не так давно мы уже делали обзор новой версии Avanpost IDM 6.0. В этом же материале рассмотрим типовой бизнес-процесс, который наиболее часто встречается в компаниях, — согласование доступа пользователя к информационной системе, и покажем, как его реализовать в Avanpost IDM.
Описание типового бизнес-процесса согласования доступа к информационной системе
Конечно, процессы предоставления, изменения и отзыва доступа могут отличаться в зависимости от уровня организационной иерархии, времени работы в организации, географического местоположения филиала или подразделения и т. д.
В качестве примера разберем распространенную ситуацию — процесс предоставления доступа, при котором пользователю (например, операционисту) для выполнения бизнес-задач нужны новые права к корпоративному порталу:
- Доступ к корпоративному порталу «Администратор портала»;
- Доступ к корпоративному порталу «Котировки»;
- Доступ к корпоративному порталу «Отчетность».
Пользователь инициирует запрос на предоставление ему прав доступа к информационной системе. Согласование доступа должно осуществляется руководителем сотрудника. При этом в случае истечения времени согласования заявки система должна повторно оповестить руководителя о том, что необходимо согласовать доступ. Руководитель для принятия решения о предоставлении доступа может выбрать сотрудника из списка и получить его комментарий о необходимости предоставления прав (дополнительное согласование). После получения комментария заявка должна вернуться к руководителю для принятия окончательного решения. Руководитель может согласовать или отклонить доступ, а также предоставить временный доступ (доступ будет предоставлен до указанной даты). В случае отклонения заявки руководителем процесс должен завершаться с уведомлением пользователя.
После руководителя заявка должна быть согласована владельцами ресурсов: начальник департамента ИТ согласует доступ к корпоративному порталу (администратор портала), а начальник операционного департамента согласует остальные две роли. Если хотя бы один владелец не согласовывает доступ к ресурсу, то заявка отклоняется. В случае отклонения заявки процесс должен завершаться. Участники бизнес-процесса оповещаются об отклонении.
После согласования заявки владельцами ресурсов заявка должна быть согласована администратором ИБ. В случае отклонения заявки процесс должен завершаться. Участники оповещаются об отклонении.
Настройка процессов согласования доступа в Avanpost IDM
Настройка процессов согласования доступа в Avanpost IDM выполняется с помощью редактора бизнес-процессов, реализованного в виде графического конструктора. Редактор имеет дружелюбный веб-интерфейс и максимально учитывает особенности согласования доступа в различных организациях.
На схеме бизнес-процесса задается последовательность выполнения его этапов и условия переходов. Графическая модель формируется интуитивно понятным образом — посредством перетаскивания мышью блоков операций, доступных в списке блоков. Далее блоки соединяются переходами. После построения схемы определяются данные, с которыми осуществляется работа в рамках бизнес-процесса, и производится настройка операций бизнес-процесса.
В Avanpost IDM поддерживается как последовательное, так и параллельное согласование, одним или несколькими сотрудниками, с ветвлением по условиям и т. п. На каждом шаге согласования можно назначить несколько действий, которые также имеют свое графическое обозначение (согласовать, отклонить, поставить на тайм-аут, вернуть на предыдущий шаг, отправить уведомление, эскалировать на следующий уровень и др.).
Для каждого шага в цепочке согласования устанавливаются правила, по которым будет выбран согласующий для данного шага, необходимое количество согласующих на этом шаге, email-уведомления, тайм-аут в рабочих часах (через какой период времени придет повторное уведомление о необходимости принятия решения), общий срок согласования, срок согласования по каждому шагу и т. д. Также возможна настройка автоматических действий по согласованию (согласовать, отклонить, эскалировать, вернуть на предыдущий шаг, поставить на тайм-аут).
Рисунок 1. Формирование бизнес-процесса в редакторе Avanpost IDM
Для создания процесса согласования по заданным выше условиям на схему добавим «Стартовый блок», блоки «Завершение БП» и «Параллельное принятие решения».
Блок «Параллельное принятие решения» переименовываем в «Согласование руководителем» и осуществляем настройку его параметров. Данный блок будет описывать процедуру согласования доступа на уровне руководителя сотрудника. Отметим, что гибкая настройка в Avanpost IDM позволяет осуществлять как последовательные, так и параллельные согласования, с возможностью тайминга, эскалации, замещения или делегирования.
Рисунок 2. Настройка блока «Параллельное принятие решения» в редакторе Avanpost IDM
Как требовалось в условии задачи, укажем ограничение длительности этапа — 240 часов, по истечении которого процесс принятия решения по заявке переходит обработку просрочки этапа. В рамках данного блока происходит обработка документа (Функция вычисления объектов обработки). В параметре «Функция вычисления ответственных» укажем роль «Ответственные руководители». Далее укажем интервал отправки повторного уведомления — 24 часа, возможные действия — руководитель имеет возможность: отклонить, одобрить, отправить на дополнительное согласование (выбрать сотрудника из списка и получить его комментарий, после получения комментария заявка вернется к руководителю), согласовать и ограничить срок (доступ будет предоставлен до указанной даты).
Добавим блоки «Обработка просрочки этапа» и завершающие. Блоки «Согласование руководителем» и «Обработка просрочки этапа» соединим через событие timeout. Это необходимо для эскалации принятия решения по заявке.
Рисунок 3. Добавление на схему блоков «Обработка просрочки этапа» и завершающих блоков в редакторе Avanpost IDM
В случае если руководитель не согласует запрос на доступ в течение 240 часов, заявка автоматически будет отклонена.
Блок «Отклонена?» для реализации логики должен иметь переходы: стрелку false устанавливаем на завершающий блок «Заявка отклонена», а стрелку true возвращаем в «Согласование руководителем».
Рисунок 4. Добавление на схему блока «Дополнительное согласование»
Руководитель для принятия решения о предоставлении доступа может выбрать сотрудника из списка и получить его комментарий о необходимости предоставления прав (дополнительное согласование). Для этого добавим блок «Дополнительное согласование» и соединим его с блоком «Согласование руководителем». В данном случае мы видим на схеме «петлю». Она необходима для того, чтобы после получения комментария от дополнительных согласующих заявка вернулась к руководителю для принятия окончательного решения.
Рисунок 5. Добавление на схему блоков «Согласование владельцами системы» Avanpost IDM
После руководителя заявка должна быть согласована владельцами ресурсов: начальник департамента ИТ согласует доступ к корпоративному порталу (администратор портала), а начальник операционного департамента согласует остальные две роли (котировки и отчетность).
Рисунок 6. Добавление на схему блоков «Согласование владельцами системы» Avanpost IDM
В рамках данного блока происходит обработка ролей (Функция вычисления объектов обработки). В параметре «Функция вычисления ответственных» укажем роль «Владельцы ролей». Далее укажем интервал отправки повторного уведомления — 24 часа, возможные действия — руководитель имеет возможность: отклонить, одобрить. При этом если хотя бы один владелец не согласовывает доступ к ресурсу, то заявка отклоняется. Частичное согласование не допускается. В случае отклонения заявки процесс должен завершаться, а участники процесса оповещаются об отклонении.
После согласования владельцами ресурсов процесс переходит администратору информационной безопасности. Для этого добавим блок «Согласование администратором ИБ». Между блоками «Согласование владельцами системы» и «Согласование администратором ИБ» добавим блок «Согласована?». Для реализации логики блок «Согласована?» должен иметь переходы: стрелку false устанавливаем на завершающий блок «Заявка отклонена», а стрелку true отправляем в «Согласование администратором ИБ».
Рисунок 7. Добавление блоков «Согласование администратором ИБ», «Обработка ошибки вычисления согласующих» Avanpost IDM
В рамках процесса согласования администратором выполняется обработка ошибки вычисления согласующих. Для этого добавляется одноименный блок. Если владельцы систем не были назначены, процесс согласования завершается отказом в доступе, а если назначены, то администратор ИБ согласовывает доступ, заявка переходит к исполнению.
Все этапы отклонения доступа, за исключением процессов согласования руководителя, завершаются уведомлением автора.
Рисунок 8. Процессы IDM в рамках отклонения заявки на доступ
После в системе происходят различные операции, например:
- определение даты начала доступа (используется блок «Ожидание»),
- определение ресурса с ручным исполнением и оправка поручения в HelpDesk (необходимо, когда в целевой системе нет коннектора у IDM),
- определение SOD-конфликтов (несовместимых ролей).
Рисунок 9. Определение даты начала доступа Avanpost IDM
Рисунок 10. Определение ресурса с ручным исполнением и оправка поручения в HelpDesk Avanpost IDM
Рисунок 11. Определение SOD-конфликтов в Avanpost IDM
Последним этапом является определение даты окончания доступа (блок «Ожидание»). После него система отзывает запрашиваемый доступ к системе.
Рисунок 12. Определение даты окончания доступа к целевой системе в Avanpost IDM
На этом этапе схема бизнес-процесс согласования доступа готова, ее необходимо сохранить.
Рисунок 13. Сформированный бизнес-процесс согласования доступа в редакторе Avanpost IDM
Рисунок 14. Сформированный бизнес-процесс согласования доступа в редакторе Avanpost IDM (продолжение рисунка)
Схема бизнес-процесса станет для IDM активной, созданные далее заявки будут направляться по пути активного бизнес-процесса. Заявки, созданные ранее, и далее будут направляться по пути бизнес-процесса, который был активен на момент начала их обработки в IDM.
Сотрудники и их руководители могут управлять заявками из личного кабинета, используя соответствующую консоль.
Рисунок 15. Личный кабинет пользователя в Avanpost IDM
В личном кабинете предоставляется возможность создавать заявки, просматривать их текущее состояние и изменять пароли для собственных учетных записей. В свою очередь, руководители подразделений могут создавать заявки как на себя, так и в отношении подчиненных сотрудников. Отображаемые в личном кабинете заявки могут быть отфильтрованы по различным признакам (вид заявки, статус, инициатор и т. д.).
Далее приведем примеры экранных форм нашего настроенного бизнес-процесса.
Рисунок 16. Пример согласования заявки руководителем в интерфейсе Avanpost IDM
Рисунок 17. Пример согласования заявки руководителем в интерфейсе Avanpost IDM (окно утверждения)
Рисунок 18. Пример согласования заявки руководителем в интерфейсе Avanpost IDM (причина отказа)
Рисунок 19. Выбор сотрудников для дополнительного согласования в интерфейсе Avanpost IDM
Руководитель в случае своего отсутствия (отпуск, больничный) в Avanpost IDM может назначить заместителей для согласование доступа.
Рисунок 20. Добавление замещения в интерфейсе Avanpost IDM
Рисунок 21. Согласование на ограниченный срок в Avanpost IDM
Выводы
В данной статье мы рассмотрели типовой бизнес-процесс согласования доступа пользователя к информационной системе, а также показали, как реализовать его в редакторе бизнес-процессов Avanpost IDM.
Avanpost IDM позволяет настроить и реализовать самые сложные процессы управления доступом. Гибкая настройка бизнес-процессов в Avanpost IDM позволяет осуществлять как последовательные, так и параллельные согласования, с возможностью тайминга, эскалации, замещения или делегирования. Кроме того, в Avanpost IDM для удобства уже включен набор базовых схем бизнес-процессов. Таким образом, можно выбрать подходящий шаблон и внести в него необходимые уточнения.
Процедуры управления учетными записями и полномочиями изменяются кардинальным образом. Кроме того, автоматическое исполнение спасает от ошибок, связанных с человеческим фактором. Без внедрения такого центрального узла контроля полномочий почти невозможно добиться гарантии соответствия процедур управления доступом необходимым требованиям регуляторов — стандарта СТО БР ИББС, PCI DSS и ISO 27001, а также повысить прозрачность процессов управления доступом.
