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

На примере скриншота разберем типовой маршрут: Руководитель → Владелец → Администратор ИБ. Это классический сценарий для запроса привилегированного доступа, где важна и бизнес-обоснованность, и контроль безопасности.

Гибкость определения согласующего: не только жесткие роли

Ключевая особенность системы – возможность гибко определять, кто именно должен согласовать заявку на каждом шаге. В поле «Согласующий» можно указать не только конкретного сотрудника, должность или бизнес-роль, но и выражение на языке 1С. Это открывает широкие возможности для адаптации под бизнес-логику компании.

На скриншоте мы видим примеры таких выражений:

ПолучитьРуководителя(Бенефициар) – динамически определяет руководителя сотрудника-заявителя на основе кадровых данных.

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

ПолучитьРоль("Администратор ИБ") – назначает согласующего по заранее заданной бизнес-роли.

Такой подход позволяет реализовать сложные сценарии:

• Учет иерархии. Например, если у сотрудника нет непосредственного руководителя, система может автоматически подняться на уровень выше, к руководителю подразделения.
  

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

• Каскадное согласование. Как в примере на скриншоте: если первый владелец не ответил, система может попробовать согласовать со вторым.
  

• Кроме выражений на 1С, в настройках шага можно выбрать:

Конкретного сотрудника – для уникальных, разовых случаев.

Должность – если важно согласование по штатной позиции, а не по роли.

Бизнес-роль – наиболее частый вариант для типовых процессов.

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

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

Система позволяет гибко настраивать поведение при истечении времени:

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

– Отклонение заявки. Если отсутствие ответа считается критичным, система автоматически отклоняет заявку. Это защищает от «зависших» запросов и гарантирует, что без явного одобрения доступ не будет выдан.

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

Автоматизация решений: автосогласование и автоотклонение

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

Автосогласование применяется, когда заявка соответствует заранее заданным критериям:

– запрос базовых прав для новых сотрудников по типовой роли;

– разблокировка учетной записи после кратковременной блокировки;

– доступ к общедоступным ресурсам (интранет, корпоративный чат).

Автоотклонение срабатывает при явных нарушениях или несоответствиях:

– запрос на привилегированный доступ от рядового сотрудника без обоснования;

– конфликт прав (SOD-нарушение), например, одновременный запрос на права бухгалтера и аудитора;

– заявка от уволенного или находящегося в длительном отпуске сотрудника.

Автоматизация позволяет:

– Сократить время обработки. Типовые заявки обрабатываются за секунды.

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

– Обеспечить единообразие. Правила применяются одинаково ко всем пользователям, исключая субъективность.

Разбор шагов на примере маршрута

Вернемся к примеру на скриншоте и посмотрим, как эти механизмы работают вместе:

Шаг 1: Руководитель.
 Согласующий определяется динамически через ПолучитьРуководителя(Бенефициар).
 Если руководитель не найден – заявка отклоняется.
 Если решение не принято за 120 минут – система переходит к следующему шагу.

Шаг 2: Владелец (первый).
 Согласующий – ПолучитьВладельца(Право, 1).
 Дополнительно проверяется активность согласующего (ПользовательРаботает).
 При отсутствии владельца или его неактивности заявка отклоняется.

Шаг 3: Владелец (второй).
 Аналогично предыдущему шагу, но берется второй владелец права (ПолучитьВладельца(Право, 2)).
 Это пример каскадного согласования: если первый владелец не ответил, система пробует согласовать со вторым.

Шаг 4: Администратор ИБ.
 Согласующий определяется по роли: ПолучитьРоль("Администратор ИБ").
 Это финальный контрольный этап, где решение принимает представитель службы информационной безопасности.
 При отсутствии администратора ИБ заявка отклоняется.

Практические рекомендации по настройке

При проектировании маршрутов стоит учитывать несколько моментов:

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

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

– Автоматизируйте типовые сценарии. Настройте автосогласование для базовых прав и автоотклонение для явных нарушений – это существенно снизит нагрузку на согласующих.

– Учитывайте каскадные сценарии. Если у права несколько владельцев, продумайте порядок их согласования и сценарии при отсутствии ответа.

Интеграция с внешними системами

Даже в рамках жестко заданного маршрута можно использовать внешние механизмы для расширения функциональности:

– Внешнее согласование. Если на каком-то этапе требуется сложное параллельное согласование, можно передать заявку во внешнюю СЭД, а в 1IDM вернуть только итоговый результат.

– API Self Service. Позволяет встраивать процессы согласования в корпоративные порталы, чат-боты или другие пользовательские интерфейсы, реализуя любую логику на стороне внешнего приложения.

Вывод

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

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