Усиление безопасности: 2FA, защита от SSRF, блокировка nodes, отключение Public API

Тот, кто эксплуатирует самостоятельно размещённый инстанс n8n, полностью несёт ответственность за его защиту сам, поскольку n8n Cloud автоматически берёт на себя часть этих защитных мер, а собственный сервер сам по себе этого не делает. Только в разделе конфигурации безопасности официальной документации n8n насчитывается более десятка отдельных глав, от двухфакторной аутентификации через защиту от SSRF до Public API, которые до сих пор нигде не были собраны вместе на немецком языке в такой форме. Четыре важнейших рычага для текущей эксплуатации: сделать 2FA доступной и требовать её, включить защиту от SSRF, заблокировать рискованные nodes через NODES_EXCLUDE и отключить Public API, если она никому не нужна. По состоянию на июль 2026 года.

Включение двухфакторной аутентификации

n8n включает функцию 2FA на уровне всего инстанса через переменную окружения N8N_MFA_ENABLED, которая по умолчанию имеет значение true. Благодаря этому отдельные пользователи могут сами настроить двухфакторную аутентификацию в своих персональных настройках аккаунта, а центральный переключатель, обязывающий все аккаунты одновременно, в основной документации не описан. Важно на практике: если пользователь однажды включил 2FA, n8n, согласно документации, игнорирует последующее отключение через переменную окружения, поэтому защиту нельзя случайно отменить изменением конфигурации.

• N8N_MFA_ENABLED: булево значение, значение по умолчанию true, определяет, доступна ли 2FA в аккаунте пользователя вообще.
• Без пути назад: однажды включённая пользователем 2FA сохраняется, даже если переменная окружения позже установлена в false.
• Организационная обязанность: поскольку n8n не обеспечивает централизованное принуждение к активации, вы должны внутри организации обязать команду действительно настроить 2FA.

Защита от SSRF от доступа к внутренним системам

Server-Side Request Forgery означает, что node workflow, например node HTTP Request, используется не по назначению для отправки запросов к внутренним сетевым ресурсам, endpoint'ам метаданных облака или сервисам localhost, которые в принципе не должны быть доступны извне. Для этого n8n с версии 2.12.0 предлагает собственный механизм защиты, который включается через N8N_SSRF_PROTECTION_ENABLED=true. При активной защите n8n проверяет исходящие HTTP-запросы из nodes, управляемых пользователем, по настроенным спискам разрешений и блокировок, включая цели перенаправления и разрешение DNS, чтобы предотвратить типичные приёмы обхода.

• Блокируется по умолчанию: частные сети, такие как 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16, адреса loopback, такие как 127.0.0.0/8, диапазоны link-local, а также различные зарезервированные адресные пространства.
• Расширение списка блокировки: через N8N_SSRF_BLOCKED_IP_RANGES можно добавить дополнительные диапазоны, например N8N_SSRF_BLOCKED_IP_RANGES=default,100.0.0.0/8.
• Определение исключений: N8N_SSRF_ALLOWED_HOSTNAMES разрешает имена хостов, включая wildcards, N8N_SSRF_ALLOWED_IP_RANGES разрешает определённые диапазоны IP, при этом порядок такой: список разрешённых имён хостов перед списком разрешённых IP перед списком блокировки IP.
• Не заменяет сетевую безопасность: защита действует на уровне приложения и дополняет firewalls и security groups, но, согласно документации, не заменяет их.

Блокировка рискованных nodes через NODES_EXCLUDE

Не каждый node подходит для каждой группы пользователей. Переменная окружения NODES_EXCLUDE позволяет определить список типов nodes, которые не могут быть найдены и использованы ни одним пользователем инстанса. Значение передаётся как JSON-массив идентификаторов nodes, например NODES_EXCLUDE с содержимым ["n8n-nodes-base.executeCommand", "n8n-nodes-base.readWriteFile"]. Документация особо называет node Execute Command и node Read/Write Files from Disk типичными кандидатами для сред, где не все пользователи полностью заслуживают доверия, поскольку оба обеспечивают прямой доступ к хост-системе.

• Формат: JSON-массив в виде строки, каждая запись это полное внутреннее имя node.
• Эффект: заблокированные nodes нельзя ни найти в поиске nodes, ни использовать в workflow.
• Снятие блокировок по умолчанию: некоторые nodes, такие как Execute Command, уже заблокированы по умолчанию; тот, кто хочет сознательно разрешить их, явно устанавливает NODES_EXCLUDE как пустой массив.

Отключение Public API, если она никому не нужна

Public REST API n8n позволяет программно управлять практически всем, что доступно и через интерфейс, то есть создавать workflow, запускать выполнения или управлять учётными данными. Именно это делает её дополнительной поверхностью атаки, если она остаётся активной без использования. Через N8N_PUBLIC_API_DISABLED=true вы полностью отключаете Public API, документация прямо рекомендует это, если никто фактически не использует API. Тому, кому API нужна, но кто не хочет публично показывать интерактивный интерфейс документации, можно дополнительно установить N8N_PUBLIC_API_SWAGGERUI_DISABLED=true, что отключает только API-плейграунд, сама API остаётся доступной.

• N8N_PUBLIC_API_DISABLED: полностью отключает Public API.
• N8N_PUBLIC_API_SWAGGERUI_DISABLED: скрывает только интерактивный интерфейс Swagger, сама API продолжает работать.

Другие элементы документации по безопасности

Четыре названных пункта это те, что дают наибольший эффект в повседневной эксплуатации, но они не охватывают весь спектр. Документация по безопасности n8n рассматривает, среди прочего, также Single Sign-On, обязательную верификацию новых аккаунтов по электронной почте, TLS-шифрование соединения, регулярную ротацию ключей шифрования, JWE-расшифровку токенов OAuth 2.0, маскирование данных executions, защиту task runner'ов, а также отключение телеметрии. n8n дополнительно рекомендует регулярно запускать встроенный аудит безопасности, который автоматически проверяет многие из этих настроек и перечисляет открытые пункты. Тот, кто не хочет самостоятельно поддерживать эти настройки, найдёт в рамках нашей консультации по n8n поддержку по настройке и текущей эксплуатации, при этом мы честно говорим, где одной автоматизации недостаточно и остаются необходимыми организационные правила внутри команды.

Часто задаваемые вопросы об усилении безопасности n8n

Должен ли я иметь возможность принудительно включить 2FA для всех пользователей?

n8n включает функцию на уровне всего инстанса через N8N_MFA_ENABLED, но фактическая настройка происходит для каждого аккаунта пользователя в персональных настройках. Центральный переключатель, немедленно делающий 2FA обязательной для всех аккаунтов, в основной документации не описан, поэтому обязать команду в организационном порядке к активации остаётся вашей задачей.

Заменяет ли защита от SSRF firewall?

Нет. Защита от SSRF работает на уровне приложения и проверяет исходящие запросы из nodes workflow, дополняя тем самым сетевые средства контроля, такие как firewalls и security groups, но, согласно документации, прямо не заменяет их.

Какие nodes следует блокировать по умолчанию?

Документация называет node Execute Command и node Read/Write Files from Disk типичными кандидатами для NODES_EXCLUDE, поскольку оба обеспечивают прямой доступ к базовой хост-системе. Какие ещё nodes являются рискованными, зависит от вашей конкретной группы пользователей.

Действительно ли мне нужна Public API?

Только если вы управляете n8n программно, например из собственных скриптов, других систем или CI/CD-пайплайнов. Если API активно не используется, документация рекомендует полностью отключить её через N8N_PUBLIC_API_DISABLED.

Источники: Обзор безопасности n8n, Двухфакторная аутентификация, Включение защиты от SSRF, Блокировка nodes, Отключение Public API