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

Если каждый такой доступ проводить заявкой, прием растягивается, а после перевода старые права часто остаются «на всякий случай». Если копировать набор «как у коллеги» — копируются и его исключения за два года.

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

Разберем, откуда берётся эта модель и как 1IDM ее применяет.

Три места, где задается автоназначение

В 1IDM автоназначение — не один переключатель. Право можно привязать к людям тремя способами, с разной степенью гибкости.

1.    Из каталога прав. У элемента каталога — привилегии, право‑приложения, бизнес‑роли — можно указать, кому он назначается автоматически. Это удобно, когда норма «живет» в самом праве: вот эта бизнес‑роль или этот базовый доступ должны быть у определенной группы сотрудников, и это свойство самого элемента каталога, а не отдельная политика сбоку.

2.    Из оргштатной структуры — с наследованием по иерархии. Право привязывается к подразделению или должности ОШС. Если включено наследование, оно спускается вниз по дереву: настройка на головной организации или департаменте действует и на дочерние подразделения, пока ниже не задано иное. Не нужно повторять один и тот же пакет в каждом отделе. Появился новый подотдел в ветке — он входит в ту же норму, потому что стоит в иерархии, а не потому что кто‑то вспомнил завести еще одно правило.

3.    Отдельными правилами автоназначения. Когда ни пункта каталога, ни узла оргструктуры недостаточно, включаются отдельные правила. Здесь максимальная гибкость: можно собрать сложное условие из должности, типа сотрудника, кадрового источника, динамической выборки, дополнительных реквизитов и их сочетаний. Штатным — один пакет, внешним подрядчикам — другой, в холдинге одноименная должность в разных юридических лицах — разный контур.

На практике эти три слоя обычно соседствуют. Каталог и ОШС закрывают типовую норму. Отдельные правила разбирают случаи, которые в дерево и карточку права не укладываются.

Во всех трех случаях 1IDM смотрит только на основное назначение сотрудника. Совместительство, второе место работы, дополнительные должности в карточке на расчет не влияют: права по ним автоматически не назначаются. Если доступ нужен именно «по второй шапке», это уже ручной запрос, а не автоназначение.

Как это считается: не триггер, а регламентное задание

Автоназначение в 1IDM не срабатывает «по событию». Прием, перевод или увольнение сами по себе не запускают назначение и не снимают права. Кадры меняют картину сотрудника в оргструктуре — кто где числится, какая должность, какой статус, — а автоназначение смотрит на эту картину отдельно.

Есть регламентное задание. Оно запускается по расписанию и заново отвечает на два вопроса:

1.    кому сейчас положены права по каталогу, оргструктуре (с учетом наследования) и отдельным правилам, но этих прав еще нет: назначить;

2.    у кого права уже есть как результат автоназначения, но человек больше не попадает под условие: отозвать.

Не «сработало кадровое событие — назначили пакет», а «на этом прогоне задание сверило модель и факт». Поэтому контур не зависит от того, «доехал ли конкретный обработчик события до нужной реакции». Задание каждый раз исходит из актуального состояния: кто сейчас в каком подразделении, какие настройки действуют, какие права уже есть.

Отзыв здесь - такая же штатная часть автоназначения, как и само назначение. Одно задание двигает доступ в обе стороны. Иначе после переводов права только наслаивались бы.

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

Заявка (Ручной запрос прав). Сотрудник или руководитель просит право, которого нет в типовом пакете. Дальше — маршрут согласования. Тем же путём запрашивают доступ по совместительству или под разовую задачу.

Автоназначение. Сотрудник ничего не просит. Система по каталогу, ОШС и правилам определяет, что положено, и на прогоне задания назначает или забирает это сама.

Пересмотр (аттестация). Проверка не всего контура сотрудника, а только того, что выдано отдельно от автоназначения: заявки, точечные исключения, ручная выдача. Норму роли система и так пересчитывает сама — аттестовывать её незачем. Пересмотр смотрит на то, чего в этой норме нет и что само не отзовётся.

Если заявка отвечает на вопрос «можно ли этому человеку еще одно право?», а автоназначение — «какой доступ должен быть у роли по умолчанию?», то аттестация отвечает на вопрос «это отдельно выданное право еще нужно?».

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