Мережева безпека n8n: перевірки перед обмеженням доступу

Автор: Roman Rodomansky·Опубліковано 22 жовт. 2026 р.

Чекліст мережевої безпеки n8n: як зберегти потрібні вебхуки, виклики API, DNS і залежності режиму черги під час перевірки обмежень доступу.

• Самостійне розгортання
• Готовність до промислової експлуатації
• Мережева безпека
• Чекліст

Перевірено за наведеними джерелами 22 жовт. 2026 р..

Чекліст: визначте мережеві залежності n8n

Перш ніж змінювати правила мережевої безпеки n8n, зафіксуйте, які з’єднання потрібні вашому самостійно розгорнутому середовищу. n8n визначає інфраструктурні міжмережеві екрани, групи безпеки та мережеві політики як основний засіб мережевого захисту. На нашу думку, перевірений перелік з’єднань — краща відправна точка, ніж скопійований набір правил.

Це редакційний чекліст перевірок, а не стандарт відповідності, повний набір правил міжмережевого екрана чи посібник із розгортання. Точні порти, селектори, адреси призначення та маршрутизацію через проксі потрібно визначати за вашим розгортанням. Почніть з ізольованого навчального середовища, версії та топологія якого відповідають робочому; використовуйте наведені нижче рекомендовані перевірки, щоб визначити критерії завершення.

• Зафіксуйте встановлену версію n8n, топологію розгортання та, якщо застосовно, реліз Helm chart.
• Складіть перелік потрібних джерел вхідних запитів, адрес зовнішніх API та з’єднань із DNS, базою даних і Redis.
• Окремо перевірте виділені обробники вебхуків, task runners, додаткові сховища та з’єднання multi-main, якщо вони є.
• Для кожного запропонованого обмеження визначте відповідального, очікуваний і фактичний результати та дію для відкату.

Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/security/enable-ssrf-protection.md at main · n8n-io/n8n-docs · GitHub

Чекліст: збережіть надходження вебхуків через проксі

n8n покладає відповідальність за TLS через зворотний проксі на тих, хто самостійно розгортає платформу. У документації щодо зворотного проксі для публічної адреси вебхуків використовується N8N_WEBHOOK_URL; WEBHOOK_URL вважається застарілою починаючи з n8n 2.35.0. Перш ніж змінювати давніше розгортання, перевірте встановлену версію.

Описана в документації схема проксі передбачає N8N_PROXY_HOPS=1 і заголовки X-Forwarded-For, X-Forwarded-Host та X-Forwarded-Proto. Така кількість проміжних проксі стосується саме описаної схеми. Скористайтеся цими рекомендованими перевірками, щоб завершити перевірку вхідного трафіку.

• Перевірте обробку TLS і адресу вебхуків, оприлюднену для зовнішніх систем.
• Узгодьте налаштування кількості проміжних проксі та заголовків пересилання з розгорнутим ланцюжком проксі.
• Надішліть типовий потрібний вебхук через публічний маршрут з обмеженнями й переконайтеся, що потрібний робочий процес виконується.

Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/configure-webhook-urls-with-reverse-proxy.md at main · n8n-io/n8n-docs · GitHub, Security

Чекліст: збережіть інфраструктурні з’єднання режиму черги

В офіційній документації Helm chart n8n зазначено, що режим черги потребує зовнішніх PostgreSQL і Redis. У ній описано, що воркери забирають завдання з Redis, а не отримують вхідний HTTP-трафік робочих процесів. Наведена документація стосується релізу, який ще розвивається: main описує chart 2.0 як release candidate, тоді як chart 1.x встановлює n8n 2.x. Зіставте ці твердження зі встановленим релізом chart.

Для описаного в документації chart готовність воркерів залежить від з’єднань із базою даних і Redis та доступу, потрібного для міграцій. Невдала перевірка готовності — це сигнал для діагностики, а не доказ проблеми з міжмережевим екраном. Наведені нижче рекомендовані перевірки пов’язують доступ до залежностей із виконанням, яке можна спостерігати.

• Збережіть потрібні з’єднання з PostgreSQL і Redis для встановленої топології.
• Перевірте доступ для перевірок стану воркерів окремо від вхідного трафіку робочих процесів.
• Запустіть типове завдання, ініційоване вебхуком, і підтвердьте його виконання воркером та успішну перевірку готовності.

Sources: n8n-hosting/charts/n8n/README.md at main · n8n-io/n8n-hosting · GitHub

Чекліст: обмежте вихідний трафік і перевірте винятки SSRF

Для самостійно розгорнутого n8n захист від SSRF доступний починаючи з версії 2.12.0. У цій документованій функції списки дозволених імен хостів дають змогу обходити перевірки списку заблокованих IP-адрес. Це опис поведінки застосунку, а не інфраструктурного міжмережевого екрана.

На нашу думку, винятки для імен хостів потребують такої самої ретельної перевірки, як і нові дозволи на вихідні з’єднання. Для мережевої безпеки n8n перевіряйте фактичну конфігурацію застосунку разом з інфраструктурними обмеженнями, використовуючи ці рекомендовані перевірки.

• Підтвердьте, що розгорнута версія підтримує захист від SSRF, і перевірте, чи його ввімкнено.
• Для кожного винятку імені хоста перевірте, якій потрібній інтеграції він відповідає та хто за нього відповідає.
• Перевірте звернення до типових потрібних адрес API за запропонованих обмежень.

Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/security/enable-ssrf-protection.md at main · n8n-io/n8n-docs · GitHub

Чекліст: перевірте застосування правил Kubernetes і DNS

Kubernetes реалізує NetworkPolicy через мережевий плагін, який її підтримує. Політики, що застосовуються, об’єднують дозволи за принципом додавання, тому нова обмежувальна політика не скасовує ширших дозволів іншої політики. Заборона вихідного трафіку за замовчуванням також блокує DNS.

Для розгортань Kubernetes завершення перевірки означає підтвердження потрібних дозволів на практиці. Ці рекомендовані перевірки зосереджені на застосуванні правил і фактичному шляху перетворення імен у вашому розгортанні.

• Переконайтеся, що встановлений мережевий плагін забезпечує застосування NetworkPolicy.
• Перегляньте всі політики, що вибирають поди n8n, на наявність дозволів, які перекриваються.
• Визначте потрібні адреси DNS і перевірте перетворення імен за запропонованої політики вихідного трафіку.

Sources: Network Policies | Kubernetes

Чекліст: перевірте дозволені та заборонені з’єднання перед впровадженням

У своїй статті для спільноти за квітень 2026 року Натан Берг рекомендує спробувати виконати недозволений вихідний запит і перевірити, що його заблоковано та зафіксовано в журналі. Це рекомендація спільноти, а не обов’язковий стандарт чи свідчення виміряних результатів у сфері безпеки.

Ми вважали б фактично спостережувану поведінку критерієм завершення зміни мережевої безпеки n8n. Наведені нижче рекомендовані перевірки дають змогу ухвалити рішення про впровадження, яке можна перевірити.

• Підтвердьте успішне проходження потрібних перевірок вхідного трафіку, API та інфраструктури.
• Спробуйте звернутися до навмисно забороненої адреси та збережіть підтвердження блокування й очікуваний запис у журналі, якщо він передбачений.
• Порівняйте очікувані та фактичні результати й усуньте нез’ясовані розбіжності перед впровадженням.

Sources: n8n Egress Controls for Security Automation | Nathan Berg