Чеклист безпеки n8n для спільного self-hosted інстансу
Чеклист безпеки n8n для інженерних менеджерів: базові налаштування, ключ шифрування, вебхуки, доступи й ролі (rbac) та обмеження функцій.
Перевірено за документацією n8n .
Що охоплює цей чеклист безпеки n8n
Цей чеклист безпеки n8n написаний для моменту, коли self-hosted інстанс перестає бути пісочницею однієї людини й стає спільною інфраструктурою. Він охоплює п'ять напрямів: базові налаштування інстансу, облікові дані та ключ шифрування, відкритість вебхуків, доступ користувачів і ролі, а також обмеження функцій, які лімітують те, що може прочитати воркфлоу.
Усі фактичні дані тут походять із власної продуктової документації n8n. Жодних бенчмарків, опитувань чи даних про інциденти не надано, тож сприймайте перевірки як задокументовані контролі, а не як виміряний захист, і підтвердьте доступність у вашому плані та значення за замовчуванням на власній версії, перш ніж планувати впровадження.
«Виконано» для кожного розділу означає одне й те саме: призначений власник перевірив налаштування на живому інстансі, записав очікуване значення там, де команда його знайде, і призначив дату наступної перевірки. n8n документує огляд безпеки self-hosting, який охоплює запуск аудиту безпеки, налаштування SSL і SSO, обмеження нод і публічного API та редагування даних виконань, а також двофакторну автентифікацію для користувачів.
Сам аудит можна запустити трьома способами: через командний рядок, через публічний API з автентифікацією як власник інстансу, або через ноду n8n. Його звіт Instance позначає незахищені вебхуки, відсутні налаштування безпеки та застарілий інстанс.
Sources: Security | Deploy | n8n Docs, Run security audits | Deploy | n8n Docs
Базові налаштування інстансу та гігієна ключа шифрування
Почніть із транспорту. Для TLS n8n рекомендує термінувати з'єднання перед інстансом за допомогою реверс-проксі, як-от Traefik, або мережевого балансувальника, а не виставляти n8n назовні напряму.
Далі — ключ шифрування. n8n шифрує облікові дані ключем, який автоматично генерується в домашній директорії .n8n під час першого запуску, і його можна перевизначити змінною середовища N8N_ENCRYPTION_KEY. Пропонований командний стандарт: задавати його явно і зберігати у вашому менеджері секретів, щоб ключ не існував лише на одному диску. Якщо ви працюєте в queue mode, документація прямо вказує, що змінну середовища з ключем шифрування треба задати для кожного воркера.
Двофакторну автентифікацію можна зробити обов'язковою для всіх користувачів через N8N_MFA_ENFORCED_ENABLED, значення за замовчуванням — false. Зверніть увагу: коли ця політика керується змінними середовища, відповідні елементи керування в інтерфейсі заблоковані.
Єдиний вхід через SAML або OIDC — платна функція: Cloud Enterprise, а на self-hosted — Business або Enterprise. Налаштування SSO змінними середовища доступне з n8n 2.18.0; старіші інстанси налаштовують його в інтерфейсі.
Sources: Security | Deploy | n8n Docs, Set up SSL | Deploy | n8n Docs, Set a custom encryption key | Deploy | n8n Docs, Security | Deploy | n8n Docs, Configure SSO | Deploy | n8n Docs
Перевірки відкритості вебхуків
Вебхуки — це те місце, де спільний інстанс протікає першим, бо продакшн-URL доступний будь-кому, хто про нього дізнається. Нода Webhook підтримує Basic auth, Header auth або JWT auth, а також None, що залишає URL відкритим. Якщо поле списку дозволених IP залишити порожнім, продакшн-URL вебхука зможе викликати будь-яка адреса.
| Опція | Що перевіряє | Залишає відкритим |
|---|---|---|
| Basic auth | Ім'я користувача й пароль у запиті | Нічого додатково не задокументовано |
| Header auth | Значення іменованого заголовка | Нічого додатково не задокументовано |
| JWT auth | Підписаний токен у запиті | Нічого додатково не задокументовано |
| None | Жодної перевірки викликача | Будь-кого, хто має URL |
| Порожній список дозволених IP | Жодного обмеження джерела | Усі IP-адреси |
Розумний командний стандарт, запропонований як рекомендація, а не задокументована вимога: кожен продакшн-вебхук отримує метод автентифікації та список дозволених IP, і обидва перевіряються під час рев'ю воркфлоу разом із іменуванням та обробкою помилок. Саме ця частина безпеки n8n найчастіше випадає, коли воркфлоу публікують кілька людей.
Одна поведінка, залежна від версії, варта уваги перед оновленням. З n8n 1.103.0 HTML-відповіді вебхуків автоматично загортаються в sandboxed iframe як механізм захисту, що може зламати воркфлоу, які покладалися на попередню поведінку.
Sources: Webhook | Nodes | n8n Docs
Доступ користувачів, ролі та приклади rbac
Контроль доступу в n8n діє на рівні інстансу з вбудованими ролями Owner, Admin і Member, і ви також можете створювати кастомні ролі інстансу. Сенс кастомних ролей, згідно з документацією, у тому, що користувач отримує лише потрібні йому можливості замість повного доступу Admin. Кастомні ролі — і інстансу, і проєкту — потребують Enterprise як на Cloud, так і на self-hosted, тож перевірте тариф, перш ніж будувати на них дизайн.
Проєкти групують воркфлоу й облікові дані разом, а адміністратори проєкту додають і видаляють користувачів у межах свого проєкту. Практичні приклади rbac для спільного інстансу: нові учасники за замовчуванням отримують Member; невелика поіменна група тримає Admin; кожен відділ отримує свій проєкт, щоб його облікові дані не були видимі всім; а адміністратор проєкту відповідає за зміни при приході й виході людей у цьому проєкті.
Одна операційна пастка має бути у вашому процесі змін. Переміщення воркфлоу чи облікових даних між проєктами або користувачами знімає всі наявні шеринги й може вплинути на інші воркфлоу, тож оголошуйте переміщення заздалегідь, а не робіть їх тихо в п'ятницю.
Якщо ваша команда зберігає воркфлоу n8n у GitHub-репозиторії, ось пропонований додаток до цього рев'ю: вирішіть, хто має доступ до цього репозиторію, одночасно з переглядом ролей інстансу. Надана документація n8n не охоплює контроль версій, тож встановіть цей стандарт самостійно.
Sources: Set permissions and roles (RBAC) | Administer | n8n Docs, Organize work in projects | Administer | n8n Docs, Custom roles | Administer | n8n Docs
Обмеження функцій і ритм перегляду
Останній шар обмежує те, до чого воркфлоу може дотягнутися, навіть коли він виконується успішно. N8N_BLOCK_ENV_ACCESS_IN_NODE керує тим, чи можуть користувачі читати змінні середовища з виразів і ноди Code, а значення за замовчуванням можуть відрізнятися залежно від версії, тож зчитайте значення на своєму інстансі, а не припускайте. Той самий огляд вказує на обмеження нод і публічного API та редагування даних виконань, що найважливіше тоді, коли багато людей можуть відкрити чужу історію виконань.
Чесно окресліть межі свого перегляду. Жодне з наданих джерел не розкриває детально резервні копії, мережеву ізоляцію, зовнішні менеджери секретів чи моніторинг логів, тож це потребує окремої роботи поза цим списком.
Робочий ритм, радше запропонований, ніж приписаний: запускати аудит щомісяця, переглядати ролі та склад проєктів, коли хтось приходить або йде, і перечитувати налаштування автентифікації вебхуків щоразу, коли воркфлоу переходить у продакшн. Завершення — це не разова зелена галочка; це короткий повторюваний прохід, за який хтось відповідає.
Повторюваний прохід перегляду безпеки n8n
- Аудит: Запустіть аудит безпеки і прочитайте звіт Instance.
- Тріаж: Вважайте незахищені вебхуки та застарілий інстанс блокувальними.
- Доступи: Перегляньте Owner, Admin і склад проєктів відповідно до поточної команди.
- Вебхуки: Підтвердьте автентифікацію та списки дозволених IP на продакшн-вебхуках.
- Запис: Запишіть очікувані значення й призначте дату наступного перегляду.
Саме цей повторюваний прохід робить безпеку n8n на спільному інстансі реальною, а не декларативною.
Sources: Security | Deploy | n8n Docs, Security | Deploy | n8n Docs
