Один список «опасных узлов» не защищает рабочую среду. Сначала нужно выяснить, какие операции выполняют процессы, затем выбрать доступный в вашей версии n8n механизм и проверить не только новые, но и существующие workflow.
Документация n8n на дату проверки 21 октября 2026 года описывает два разных средства: node type policies для экземпляра и проектов и NODES_EXCLUDE для всего self-hosted-экземпляра. Первое средство имеет статус Preview, доступно с n8n 2.45.0 в Cloud Enterprise и self-hosted Enterprise, а документация рекомендует не полагаться на него в production как на единственный барьер. Поэтому окончательное решение зависит от версии, редакции, размещения и обязательности запрета.
Начните с необходимых операций, а не со списка опасных узлов
Для каждого рабочего workflow запишите:
- вход и ожидаемый результат;
- внешние системы и разрешённые операции в них;
- файловые операции и выполнение кода;
- ответственного за процесс;
- проект, в котором находится workflow;
- способ запуска и доставки изменений;
- вызываемые подпроцессы.
Точные имена типов берите из фактических схем. В документации n8n предложено скопировать узел с холста в текстовый редактор и прочитать поле type. Отдельно отметьте HTTP Request, Code, SSH, файловые и community nodes, а также узлы, которые ИИ-агент использует как инструменты. Правило по имени интеграционного узла распространяется и на его tool-версию: например, ограничение Gmail затрагивает Gmail Tool.
Такой разбор отделяет реальную потребность от предположения. Если процессу нужен HTTP-запрос к согласованной CRM, это ещё не означает, что ему нужен произвольный сетевой доступ. Адреса, методы, учётные данные и допустимые операции задают отдельными требованиями.
Составьте реестр узлов, пакетов и исключений
Реестр связывает техническое правило с рабочей причиной. Подойдёт такая структура:
| Поле | Что фиксировать |
|---|---|
| Тип или пакет | Точное имя типа либо пакета |
| Область | Экземпляр, проект и связанный workflow |
| Назначение | Какую рабочую операцию выполняет узел |
| Источник | Где workflow создан или как доставляется |
| Решение | Разрешить, запретить, делегировать или согласовать отдельно |
| Основание | Почему операция нужна или недопустима |
| Исключение | Владелец, область и согласующий |
| Пересмотр | Условие отзыва или повторной проверки |
| Проверка | Действие и ожидаемый результат |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
В node type policies селектор name относится к одному точному типу, а package — ко всем узлам установленного пакета. Это разные уровни решения. Проверка происхождения и содержимого community package — тоже отдельная задача: разрешение пакета не доказывает его безопасность.
Для каждого исключения укажите не только имя узла, но и разрешённую операцию, проект, владельца и способ подтвердить отзыв доступа. Формулировка «SSH разрешён технической команде» слишком широка; проверяемая запись связывает SSH с конкретным проектом, назначением и условием отключения.
Проверьте доступность механизма в вашей среде
До проектирования зафиксируйте версию, редакцию и размещение n8n, права администраторов и доступные способы управления.
Node type policies документированы для n8n 2.45.0 и новее в Cloud Enterprise и self-hosted Enterprise. Ими управляют через public API: владелец или администратор экземпляра задаёт правило экземпляра, а администратор проекта может дополнительно ограничить свой проект. Функция находится в Preview, поэтому её нельзя представлять как гарантированно стабильный единственный барьер production-среды.
NODES_EXCLUDE относится к self-hosted n8n. Переменная останавливает загрузку перечисленных типов во всём экземпляре. Она не создаёт исключений для отдельных проектов и требует проверки влияния на существующие процессы после изменения конфигурации.
Если нужного механизма нет в фактической редакции или он не обеспечивает обязательный запрет, не подменяйте ограничение регламентом. Измените архитектуру, разделите среды либо откажитесь от схемы до появления приемлемого контроля.
Выберите уровень ограничения
У механизмов разные области применения:
| Задача | Возможный механизм | Ограничение |
|---|---|---|
| Управлять типами по экземпляру или проекту | Node type policies | Preview; только документированные редакции и версии |
| Не загружать тип во всём self-hosted-экземпляре | NODES_EXCLUDE | Нет проектных исключений |
| Запретить доступ к сервису или данным | Сетевые, credential- и иные отдельные меры | Блокировка узла сама по себе этого не делает |
| Ограничить Code node | Политика узлов плюс отдельное проектирование исполнения | Не заменяет контроль сети, файлов и секретов |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Для обязательного запрета типа в self-hosted-среде можно рассматривать NODES_EXCLUDE после анализа влияния на необходимые workflow. Для Cloud и проектных исключений решение зависит от фактически доступных средств. Универсального победителя между механизмами нет.
Спроектируйте правила экземпляра и проектов
Разделите узлы на четыре группы: разрешены во всех проектах, запрещены во всём экземпляре, разрешаются только в определённой области и требуют отдельного согласования.
В node type policies правила проверяются по порядку, применяется первое совпадение, а при его отсутствии — defaultAction. Сначала n8n оценивает политику экземпляра, затем проекта:
| Решение экземпляра | Что может проект |
|---|---|
deny | Не может снова разрешить узел |
allow | Может ограничить его дополнительно |
delegate | Должен явно разрешить узел правилом allow |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
delegate принимается только политикой экземпляра. Одного defaultAction: allow в проекте недостаточно, чтобы включить делегированный тип. Если политика запрещает всё по умолчанию, нужно явно разрешить каждый необходимый тип, включая служебные узлы вроде Manual Trigger.
Назначьте владельца политики экземпляра, владельцев проектных исключений и согласующего. Для срочного исключения заранее определите срок, проверку и условие отзыва.
Управляйте политикой как контролируемым изменением
До изменения сохраните читаемое представление текущих правил и список затрагиваемых workflow. При работе через API сначала прочитайте действующую политику, измените полный набор правил и отправьте его с полученной версией. Если другой администратор уже изменил политику, API возвращает конфликт; тогда состояние нужно прочитать заново, а не перезаписывать чужое изменение.
После записи проверьте возвращённую политику и предупреждения. Владелец изменения должен уметь восстановить прежнее состояние и знать, какие процессы нужно повторно проверить.
Если команда использует source control, включите pull в программу изменения. Согласно документации, node type policies пропускают при pull workflow с заблокированным узлом и сообщают об этом в результате. После пропуска версия в Git и состояние n8n различаются, пока узел не разрешат или не удалят. Назначьте человека, который разбирает список пропусков, и не считайте pull завершённым при необъяснённом расхождении.
Проверьте существующие workflow и вложенные вызовы
Инвентаризируйте опубликованные workflow, триггерные запуски, отключённые узлы, переносы между проектами и подпроцессы. Новая node type policy не переписывает существующий workflow, но ограничивает действия с ним: опубликованный процесс остаётся опубликованным, однако выполнение с заблокированным типом завершается ошибкой. Отключённый узел тоже учитывается.
Проверки только верхнего workflow недостаточно. Документация указывает, что node type policies не проверяют узлы подпроцесса, если ссылка на него находится внутри параметров другого узла. Поэтому испытайте два маршрута:
- прямой запуск подпроцесса;
- вызов того же подпроцесса через родительский узел.
Если доступные средства не перекрывают обнаруженный маршрут, зафиксируйте ограничение как неприемлемое или измените схему до рабочего запуска.
Проверьте альтернативные пути к ресурсам и выполнение кода
Запрет специализированного интеграционного узла не закрывает сервис. Пользователь может выполнить похожую операцию через HTTP Request или Code, а в self-hosted-среде — также через SSH, файловые или community nodes, если они разрешены и имеют нужный доступ.
Для каждого закрываемого ресурса отдельно проверьте:
- доступные адреса и методы;
- учётные данные и секреты;
- файловые пути;
- возможность произвольного кода;
- универсальные и сторонние узлы.
Для JavaScript в Code node документация self-hosted n8n описывает external task runners в отдельных контейнерах. Это дополнительная мера изоляции процесса выполнения, но не ограничение доступности узлов и не доказательство полной изоляции среды. Её конфигурацию, сеть, файловую систему и доступ к секретам нужно проектировать и проверять отдельно.
Учебный пример: два проекта в одном экземпляре
Ниже синтетическая схема проектирования по документации. Это не клиентский кейс Switch On AI и не результат выполненного теста.
Условная компания готовит два проекта в одном экземпляре n8n. Проект заявок использует Webhook, проверку полей, HTTP Request к согласованной CRM и уведомление ответственному. Техническому проекту дополнительно нужен SSH для ограниченной операции.
| Тип или класс | Проект заявок | Технический проект | Проектное решение |
|---|---|---|---|
| Webhook и проверка полей | Нужны | По необходимости | Разрешить подтверждённые точные типы |
| HTTP Request | Нужен для CRM | По необходимости | Разрешить вместе с отдельными сетевыми требованиями |
| SSH | Не нужен | Требуется для одной операции | Блокировать по умолчанию, рассмотреть явное исключение |
| Execute Command | Не нужен | Не нужен | Запретить во всём экземпляре |
| Локальные файлы | Не нужны | Не нужны | Не загружать типы в self-hosted-среде после проверки влияния |
| Code | Требует отдельного решения | Требует отдельного решения | Проверить возможный обход и среду исполнения |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Команда сначала собирает точные type name, существующие и отключённые workflow, подпроцессы и сценарии из source control. Затем выбирает механизм для фактической версии и редакции. В программу приёмки включает вложенный вызов подпроцесса, pull из Git и попытку обратиться к закрываемому ресурсу через разрешённые HTTP Request или Code.
Ожидаемый результат этой учебной схемы — необходимые процессы сохраняют согласованные операции, Execute Command и локальные файловые типы недоступны выбранным способом, а SSH нельзя использовать вне одобренной области. Полученный результат можно записать только после испытания на конкретной среде.
Проведите приёмку и закрепите порядок исключений
До запуска запишите для каждой проверки входные условия и ожидаемый результат. Затем сохраните фактический результат, версию, редакцию, размещение, настройки, ограничения и способ возврата.
Минимальная программа включает:
- разрешённый узел в нужной области;
- добавление, сохранение, публикацию и запуск заблокированного типа;
- существующий и отключённый узел;
- перенос workflow между проектами;
- прямой и вложенный вызов подпроцесса;
- source control pull и перечень пропусков;
- альтернативный доступ через HTTP Request или Code;
- для
NODES_EXCLUDE— запуск self-hosted-экземпляра, недоступность типов и сохранность нужных процессов.
Для исключения зафиксируйте инициатора, основание, согласующего, область, проверку и условие отзыва. Если Cloud или используемая редакция не предоставляет подходящего механизма обязательного запрета, такую схему нельзя принимать только на основании организационной договорённости.
Switch On AI помогает обследовать зависимости workflow, спроектировать ограничения и подготовить приёмку автоматизации. На странице услуг по разработке и внедрению автоматизации можно выбрать подходящий формат обсуждения. Для первого разговора подготовьте список workflow, подпроцессов, проектов, типов узлов, внешних систем и способа доставки изменений. Состав работ, передаваемые материалы и сопровождение фиксируются в ТЗ и договоре после проверки вашей среды.
Вопросы по этой задаче
Чем node type policies отличаются от NODES_EXCLUDE?
Node type policies управляют доступностью типов на уровне экземпляра и проектов, но имеют статус Preview и доступны только в указанных документацией версиях и редакциях. NODES_EXCLUDE относится к self-hosted n8n и останавливает загрузку перечисленного типа во всём экземпляре без проектных исключений.
Можно ли разрешить узел только одному проекту n8n?
В среде с доступными node type policies политика экземпляра может назначить типу действие delegate, а политика нужного проекта — явно разрешить его правилом allow. Возможность нужно подтвердить для фактической версии и редакции; одной настройки проекта по умолчанию недостаточно.
Что произойдёт с существующим workflow после блокировки узла?
Политика не переписывает workflow. Его можно открыть и редактировать в документированных пределах, но публикация и запуск с заблокированным типом будут отклонены; запуск по триггеру или как подпроцесс завершится ошибкой. Отключённый узел также учитывается.
Почему нужно отдельно проверять подпроцессы и source control?
Node type policies не проверяют узлы подпроцесса, если ссылка на него находится в параметрах другого узла. При source control pull workflow с заблокированным узлом пропускается, из-за чего Git и n8n могут разойтись. Оба маршрута требуют отдельных проверок.
Почему блокировка интеграционного узла не закрывает доступ к сервису?
Тот же ресурс может оставаться доступным через HTTP Request, Code, SSH, файловый или community node. Сеть, методы, учётные данные, секреты, файлы и выполнение кода нужно ограничивать и проверять отдельными мерами.