Как разграничить роли и доступы в n8n

Доступ к автоматизации лучше распределять не по должностям, а по рабочим действиям. Сначала определите, кто должен видеть проект, менять workflow, проверять сохранённую версию, запускать её вручную, публиковать и управлять участниками. Затем сопоставьте эту модель с возможностями вашей редакции n8n и проверьте каждое разрешение и каждый запрет на отдельном процессе.

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

Начните с рабочих действий, а не с названий ролей

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

Это заготовка, а не готовая настройка n8n. Замените строки участниками своей компании и добавьте проекты, выполнения, credentials, настройки и зависимые ресурсы. Не переносите технические права автоматически из названия должности: руководителю может быть нужен только просмотр, а подрядчику — изменение одного рабочего контура без управления командой.

Разведите роли экземпляра, проекта и отдельного workflow

В n8n есть роли экземпляра и роли проекта. Первые определяют полномочия во всей установке, вторые — внутри конкретного проекта. Один пользователь может иметь разные роли в разных проектах. При проверке нужно учитывать оба уровня: ограниченная проектная роль не исправит лишние полномочия, полученные на уровне экземпляра.

Внутри проекта документация n8n описывает роли Admin, Editor и Viewer:

Не превращайте эти роли в универсальные должности компании. Например, организационная роль «проверяющий» не обязана совпадать с Project Viewer.

Доступность ролей также различается. По документации, Project Editor доступен в n8n Cloud Pro и self-hosted Enterprise, а Project Viewer — в Cloud Enterprise и self-hosted Enterprise. Перед проектированием схемы сверьте актуальные возможности своей подписки и размещения.

Отдельный уровень возникает при совместном доступе к workflow в Personal workspace. В проекте доступ к workflow определяется членством пользователя в проекте: добавить человека только к одному workflow проекта через обычный механизм совместного доступа нельзя.

Сопоставьте участников с минимально необходимыми полномочиями

Разделите организационные обязанности и технические роли. Удобно начать с шести рабочих категорий:

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

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

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

Учтите, как совместный доступ меняет полномочия редактора

Workflow в Personal workspace можно предоставить другому пользователю через совместный доступ. Для workflow внутри проекта действует другое правило: его видят участники соответствующего проекта, а права зависят от их проектных ролей.

Редактор совместно используемого workflow может просматривать выполнения, изменять workflow и запускать его. Однако он не может редактировать узлы, в которых используются credentials, не предоставленные ему отдельно; остальные узлы остаются доступны для редактирования. Есть и менее очевидное последствие: редактор может использовать credentials, уже задействованные в workflow, даже если ему не предоставили эти credentials отдельно через механизм credential sharing.

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

Поэтому проверяйте не только список выданных credentials. Запустите на отдельном проверочном процессе разрешённые и запрещённые действия от имени редактора и зафиксируйте, какие операции реально доступны через уже настроенные узлы.

Разделите изменение, проверку и право публикации

Желаемый маршрут можно описать так:

1. Разработчик сохраняет изменение.
2. Проверяющий оценивает конкретную сохранённую версию.
3. Уполномоченный участник принимает решение о выпуске.
4. Команда отдельно сверяет ресурсы, которые не входят в проверку версии.
5. После публикации ответственный контролирует ожидаемый результат.

В n8n Enterprise для этого предусмотрен Workflow Reviews. Согласно документации, функция доступна в n8n Cloud Enterprise и self-hosted Enterprise начиная с версии 2.37.0. Её включает администратор экземпляра. На момент проверки документация помечает Workflow Reviews как Preview и рекомендует не полагаться на эту функцию в производственных workflow до её общего выпуска.

Для назначения проверяющим достаточно права workflow:read на соответствующий workflow. Право workflow:publish ему не требуется. При этом отправить workflow на review или обновить открытую проверку более новой версией может пользователь с workflow:publish.

Workflow Reviews не создаёт безусловный запрет прямой публикации. После включения функции review остаётся необязательным, пока для workflow нет открытой проверки. Настройка Review required хранится в браузере конкретного пользователя и не действует для остальных. Только открытый review блокирует публикацию этого workflow до закрытия проверки — из редактора, публичного API и n8n MCP server.

Проверьте границы встроенного review

Review привязан к одной сохранённой версии одного workflow. Проверяющий может сравнить её с опубликованной версией, обсудить изменения, одобрить их или запросить доработку. Разработчик при этом может продолжать работу, но новые сохранения не меняют проверяемую версию, пока их отдельно не отправят в открытый review.

Встроенная проверка охватывает узлы и связи сохранённой версии. Она не включает:

• настройки workflow, например часовой пояс и error workflow;
• credentials;
• variables;
• data tables;
• вызываемые sub-workflows.

Изменения этих ресурсов не входят в visual diff и не блокируются одобрением review. Более того, они могут повлиять на опубликованный workflow во время открытой проверки. Поэтому добавьте зависимости в отдельный контрольный список. Для вызываемого sub-workflow при необходимости нужен собственный review.

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

Разберите условный маршрут изменения

Ниже — синтетический учебный пример. Это не клиентский кейс Switch On AI и не отчёт о выполненном тесте.

Условная компания передаёт обращения с сайта в CRM через n8n. Владелец процесса описывает ожидаемый результат и принимает изменение. Ответственный за n8n управляет проектом и участниками. Подрядчик меняет workflow. Сотрудник отдела продаж проверяет логику на согласованных данных. Руководитель просматривает workflow и выполнения, но не должен запускать его вручную.

Перед подключением команды ответственный сопоставляет модель с ролями, доступными на текущем тарифе. Если Workflow Reviews доступен и включён, маршрут выглядит так:

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

Даже при успешном одобрении команда отдельно сверяет зависимости. Review не охватывает настройки workflow, credentials, variables, data tables и вызываемые sub-workflows.

Проведите приёмку и назначьте обслуживание доступов

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

Для каждого участника проверьте:

1. Видит ли он только нужные проекты и workflow.
2. Может ли просматривать выполнения.
3. Может ли изменять узлы и настройки.
4. Доступен ли ему ручной запуск.
5. Может ли он публиковать workflow.
6. Может ли управлять участниками и проектом.
7. Какие операции доступны через credentials в совместно используемом workflow.
8. Не получает ли он дополнительные права через роль экземпляра или другой проект.

Если Workflow Reviews доступен и включён, отдельно пройдите обычное изменение, отправку на review, запрос доработки и одобрение. Затем проверьте ресурсы вне review.

Результат удобно фиксировать в такой матрице:

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

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

Подготовьте данные для обсуждения внедрения

Перед обсуждением решения соберите:

• список участников и их рабочие задачи;
• перечень проектов и workflow;
• разрешённые и запрещённые действия;
• зависимые системы и используемые credentials;
• настройки, variables, data tables и sub-workflows, требующие отдельной проверки;
• текущий вариант размещения, тариф и версию n8n;
• ответственных за выдачу, изменение и отзыв доступа.

Switch On AI занимается разработкой и внедрением автоматизации. В рамках услуги внедрения можно спроектировать матрицу полномочий, сопоставить её с возможностями вашей редакции n8n и подготовить проверочный маршрут. Если штатные роли не выражают нужное разделение, это выявляют до подключения рабочего процесса и отдельно согласуют подходящий контур совместной работы.

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