Заявка на предоставление доступа: согласующий, срок действия и подтверждённый отзыв

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

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

Какую задачу решает этот процесс

ИТ-службе и владельцам бизнес-систем нужен единый способ провести запрос от заявления сотрудника до подтверждённого отзыва. Результат процесса — не просто отметка «одобрено», а связанная цепочка событий:

1. сотрудник запрашивает определённую операцию с конкретным ресурсом;
2. уполномоченный человек принимает решение;
3. администратор или интеграция изменяет право в целевой системе;
4. система проверяет фактическое разрешение;
5. по окончании срока право отзывают и повторно проверяют его отсутствие.

Такая заявка подходит для бизнес-доступов сотрудников к папкам, приложениям, группам и другим рабочим ресурсам. Она не описывает роли разработчиков в самом n8n. Общий приём внутренних обращений разобран отдельно в материале о заявках сотрудников; здесь внимание сосредоточено на жизненном цикле права.

Статусы решения и исполнения должны существовать отдельно. Значение decision_status=approved означает только согласие уполномоченного участника. Значение fulfillment_status=granted можно установить лишь после того, как целевая система подтвердила нужную роль для нужного пользователя и ресурса.

Какие данные и правила подготовить

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

Срок хранения заявки и основания её отзыва нельзя устанавливать как универсальную юридическую норму. Их задаёт и проверяет специалист заказчика с учётом внутренних, юридических, кадровых и отраслевых правил.

Короткий синтетический образец без клиентских данных:

Как описать запрашиваемое разрешение

Фраза «дать доступ ко всему» не позволяет проверить ни необходимость, ни результат. Запрос должен называть ресурс и допустимую операцию: например, «читать папку FOLDER-042 в роли viewer», а не «дать доступ к файлам».

Участники выполняют разные функции:

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

Для привилегированного права нельзя допускать самосогласование: заявитель не должен единолично одобрять собственное повышение полномочий. Если один человек совмещает несколько должностей, система всё равно должна проверить назначенное правило разделения полномочий или передать решение другому уполномоченному участнику.

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

Как выдать доступ после решения

Перед изменением права исполнитель проверяет четыре связи: личность сотрудника, ID ресурса, действующее одобрение и срок. Затем администратор или интеграция отправляет операцию в целевую систему и отдельно считывает фактическое разрешение.

Последовательность выглядит так:

1. убедиться, что user_id относится к нужному сотруднику;
2. проверить согласующего и значение decision_status;
3. убедиться, что срок ещё не истёк;
4. запросить назначение конкретной роли конкретному ресурсу;
5. повторно прочитать фактическое право;
6. только при совпадении записать fulfillment_status=granted.

Успешная отправка запроса ещё не доказывает выдачу. Целевая система может принять команду в очередь, выполнить её частично или вернуть ошибку. При ошибке API заявка остаётся в исполнении — например, со статусом in_progress или failed_retryable из согласованного словаря. Переводить её в completed нельзя.

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

Как отзывать и пересматривать разрешения

У временного права должна быть запланирована точка отзыва. Её связывают с теми же request_id, user_id и resource_id, что и выдачу. После команды удаления система повторно считывает разрешения. Только отсутствие отзываемой роли позволяет записать revocation_status=confirmed.

Помимо окончания срока, пересмотр запускают как минимум три типа событий:

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

Для каждого события журнал хранит ID заявки, пользователя и ресурса, инициатора, время, действие, технический результат и результат повторной проверки. Запись «команда отправлена» не равна подтверждённому отзыву.

Этот процесс не следует смешивать с проверкой ACL документов внутри RAG-системы. Заявка управляет правом пользователя в исходной бизнес-системе. Фильтрация документов при поиске и генерации ответа — отдельная задача: она должна учитывать уже действующие ACL, но не заменяет выдачу или отзыв исходного права.

Учебный пример: путь от входных данных до результата

Ниже — синтетический пример. Все идентификаторы, имя и даты условные; это не клиентский файл, не результат внедрения Switch On AI и не отчёт о live-тесте.

Сотрудник USR-017 запрашивает временное чтение папки FOLDER-042. Условная Марина Петрова одобряет роль viewer. Доступ должен начаться 2026-10-12T09:00:00Z и действовать семь суток.

Расчёт окончания срока:

expires_at = starts_at + 7 × 24 часа = 2026-10-19T09:00:00Z.

После одобрения промежуточное состояние такое:

• request_id=REQ-1042;
• decision_status=approved;
• fulfillment_status=in_progress;
• фактическое право ещё не подтверждено.

Первая попытка выдачи завершается ошибкой API. Поэтому задача отзыва ещё не создаётся: нельзя планировать отзыв права, которое система не подтвердила как выданное.

Заявка остаётся в исполнении. После проверки причины администратор повторяет операцию. В ожидаемом нормальном продолжении фактическая проверка обнаруживает роль viewer у USR-017 на ресурсе FOLDER-042. Тогда fulfillment_status меняется на granted, а система создаёт revoke_task_id=REV-1042 с теми же user_id и resource_id и сроком исполнения 2026-10-19T09:00:00Z.

В назначенное время исполнитель удаляет роль и снова проверяет ресурс. Ожидаемый результат — роль viewer отсутствует, после чего revocation_status получает значение confirmed. Если проверка всё ещё видит роль, задача остаётся открытой и требует вмешательства человека.

Как проверить результат перед запуском

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

Перед запуском также проверяют следующие условия:

• статусы решения и исполнения хранятся раздельно;
• ошибка API не превращается в успешное выполнение;
• привилегированное право нельзя согласовать самому себе;
• задача отзыва сохраняет исходные ID пользователя и ресурса;
• после удаления выполняется отдельная проверка отсутствия права;
• повтор события не создаёт второе несвязанное разрешение или несколько конфликтующих задач отзыва.

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

Что согласовать для внедрения

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

Часть маршрута может поддерживать готовый инструмент. Например, официальная документация Microsoft Entra ID Governance описывает entitlement management для запросов доступа, назначений, пересмотров и истечения разрешений. Это подтверждает возможности названной платформы, но не универсальную совместимость с другими системами и не наличие настроенного решения у заказчика.

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

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

Формат решения зависит от операции. Чат-бот может принять структурированную заявку и показать статус. ИИ-помощник может помочь заявителю выбрать ресурс по утверждённому каталогу, но не должен самостоятельно придумывать роль или согласующего. Обычная интеграция подходит для фиксированного маршрута между системой заявок и целевым API.

Switch On AI может разработать ИИ-помощника, бота или интеграцию для сквозной заявки на доступ с конечным сроком и подтверждённым отзывом — после проверки данных и API. Это не обещание совместимости, срока или эффекта: границы прототипа и последующей разработки определяются по одной выбранной операции.

Подходящие форматы работы описаны на странице услуг Switch On AI. Следующий шаг — обсудить задачу: разобрать одну систему и её маршрут выдачи доступа, затем согласовать прототип. Прототип проверяет согласованный фрагмент сценария и не равен полному внедрению.