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

Введение

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

Первое и самое очевидное решение — это автоматизация процессов управления учетными записями и правами доступа. Для этого существует отдельный класс решений — IDM- /IGA-системы. При интеграции IDM-системы в инфраструктуру заказчика автоматизация процесса выдачи полномочий является одним из важных этапов.

В статье мы рассмотрим, как с помощью системы управления учетными записями и правами доступа Avanpost IDM 6.0, разработанной российской компанией «Аванпост», можно настроить процесс согласования доступа по типовым требованиям заказчика. Не так давно мы уже делали обзор новой версии Avanpost IDM 6.0. В этом же материале рассмотрим типовой бизнес-процесс, который наиболее часто встречается в компаниях, — согласование доступа пользователя к информационной системе, и покажем, как его реализовать в Avanpost IDM.

Описание типового бизнес-процесса согласования доступа к информационной системе

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

В качестве примера разберем распространенную ситуацию — процесс предоставления доступа, при котором пользователю (например, операционисту) для выполнения бизнес-задач нужны новые права к корпоративному порталу:

• Доступ к корпоративному порталу «Администратор портала»;
• Доступ к корпоративному порталу «Котировки»;
• Доступ к корпоративному порталу «Отчетность».

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

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

После руководителя заявка должна быть согласована владельцами ресурсов: начальник департамента ИТ согласует доступ к корпоративному порталу (администратор портала), а начальник операционного департамента согласует остальные две роли. Если хотя бы один владелец не согласовывает доступ к ресурсу, то заявка отклоняется. В случае отклонения заявки процесс должен завершаться. Участники бизнес-процесса оповещаются об отклонении.

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

Настройка процессов согласования доступа в Avanpost IDM

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

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

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

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

Для создания процесса согласования по заданным выше условиям на схему добавим «Стартовый блок», блоки «Завершение БП» и «Параллельное принятие решения».
Блок «Параллельное принятие решения» переименовываем в «Согласование руководителем» и осуществляем настройку его параметров. Данный блок будет описывать процедуру согласования доступа на уровне руководителя сотрудника. Отметим, что гибкая настройка в Avanpost IDM позволяет осуществлять как последовательные, так и параллельные согласования, с возможностью тайминга, эскалации, замещения или делегирования.

Как требовалось в условии задачи, укажем ограничение длительности этапа — 240 часов, по истечении которого процесс принятия решения по заявке переходит обработку просрочки этапа. В рамках данного блока происходит обработка документа (Функция вычисления объектов обработки). В параметре «Функция вычисления ответственных» укажем роль «Ответственные руководители». Далее укажем интервал отправки повторного уведомления — 24 часа, возможные действия — руководитель имеет возможность: отклонить, одобрить, отправить на дополнительное согласование (выбрать сотрудника из списка и получить его комментарий, после получения комментария заявка вернется к руководителю), согласовать и ограничить срок (доступ будет предоставлен до указанной даты).

Добавим блоки «Обработка просрочки этапа» и завершающие. Блоки «Согласование руководителем» и «Обработка просрочки этапа» соединим через событие timeout. Это необходимо для эскалации принятия решения по заявке.

В случае если руководитель не согласует запрос на доступ в течение 240 часов, заявка автоматически будет отклонена.

Блок «Отклонена?» для реализации логики должен иметь переходы: стрелку false устанавливаем на завершающий блок «Заявка отклонена», а стрелку true возвращаем в «Согласование руководителем».

Руководитель для принятия решения о предоставлении доступа может выбрать сотрудника из списка и получить его комментарий о необходимости предоставления прав (дополнительное согласование). Для этого добавим блок «Дополнительное согласование» и соединим его с блоком «Согласование руководителем». В данном случае мы видим на схеме «петлю». Она необходима для того, чтобы после получения комментария от дополнительных согласующих заявка вернулась к руководителю для принятия окончательного решения.

После руководителя заявка должна быть согласована владельцами ресурсов: начальник департамента ИТ согласует доступ к корпоративному порталу (администратор портала), а начальник операционного департамента согласует остальные две роли (котировки и отчетность).

В рамках данного блока происходит обработка ролей (Функция вычисления объектов обработки). В параметре «Функция вычисления ответственных» укажем роль «Владельцы ролей». Далее укажем интервал отправки повторного уведомления — 24 часа, возможные действия — руководитель имеет возможность: отклонить, одобрить. При этом если хотя бы один владелец не согласовывает доступ к ресурсу, то заявка отклоняется. Частичное согласование не допускается. В случае отклонения заявки процесс должен завершаться, а участники процесса оповещаются об отклонении.

После согласования владельцами ресурсов процесс переходит администратору информационной безопасности. Для этого добавим блок «Согласование администратором ИБ». Между блоками «Согласование владельцами системы» и «Согласование администратором ИБ» добавим блок «Согласована?». Для реализации логики блок «Согласована?» должен иметь переходы: стрелку false устанавливаем на завершающий блок «Заявка отклонена», а стрелку true отправляем в «Согласование администратором ИБ».

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

Все этапы отклонения доступа, за исключением процессов согласования руководителя, завершаются уведомлением автора.

После в системе происходят различные операции, например:

• определение даты начала доступа (используется блок «Ожидание»),
• определение ресурса с ручным исполнением и оправка поручения в HelpDesk (необходимо, когда в целевой системе нет коннектора у IDM),
• определение SOD-конфликтов (несовместимых ролей).

Последним этапом является определение даты окончания доступа (блок «Ожидание»). После него система отзывает запрашиваемый доступ к системе.

На этом этапе схема бизнес-процесс согласования доступа готова, ее необходимо сохранить.

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

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

Руководитель в случае своего отсутствия (отпуск, больничный) в Avanpost IDM может назначить заместителей для согласование доступа.

Выводы

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

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

Процедуры управления учетными записями и полномочиями изменяются кардинальным образом. Кроме того, автоматическое исполнение спасает от ошибок, связанных с человеческим фактором. Без внедрения такого центрального узла контроля полномочий почти невозможно добиться гарантии соответствия процедур управления доступом необходимым требованиям регуляторов — стандарта СТО БР ИББС, PCI DSS и ISO 27 001, а также повысить прозрачность процессов управления доступом.