Безопасность деплоя n8n: HTTPS, секреты и доступы ¶

Обновлено: 2026-05-29

Короткий ответ ¶

Безопасность self-hosted n8n начинается до подключения первых credentials. Минимальный набор: HTTPS через домен, закрытый порт 5678, непубличные PostgreSQL и Redis, постоянный N8N_ENCRYPTION_KEY, отдельные токены для n8n, backup перед обновлениями и контроль того, какие данные сохраняются в executions. Главная ошибка — считать n8n “внутренней админкой”, хотя он часто имеет доступ к CRM, почте, платежам, таблицам и AI API.

Почему n8n нужно защищать отдельно ¶

n8n — не просто редактор автоматизаций. В production он становится узлом, через который проходят заявки, персональные данные, платежные события, документы, токены, API-ключи и OAuth-доступы. Один workflow может читать CRM, писать в Google Sheets, отправлять Telegram-сообщения, вызывать AI API и менять статусы заказов. Поэтому взлом n8n часто означает не только доступ к интерфейсу, но и доступ к связанным сервисам.

Для self-hosted установки опасны четыре класса проблем:

открытый наружу редактор или порт контейнера;
утечка .env, токенов и credentials;
слишком широкие права у внешних API-ключей;
сохранение лишних персональных данных в executions, логах и backup.

Безопасная схема не обязана быть сложной. Но она должна быть спроектирована до того, как в n8n появятся реальные токены.

Базовая модель доступа ¶

У self-hosted n8n должно быть три уровня доступа.

Публичный уровень: только HTTPS-домен, на который приходят webhooks и через который открывается редактор. Обычно это https://n8n.example.ru.

Внутренний уровень Docker network: PostgreSQL, Redis и сам порт контейнера n8n. Эти сервисы не должны быть доступны из интернета напрямую.

Административный уровень: SSH, backup, обновления, доступ к .env и compose-файлам. Его нужно ограничивать сильнее всего, потому что через сервер можно получить все секреты.

Простой тест: если с внешней машины открывается http://server-ip:5678, схема ещё не готова к production.

Firewall для VPS ¶

Для типовой VPS-инсталляции достаточно открыть минимум портов:

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose

Порт 80 нужен reverse proxy для выпуска или обновления сертификата. Порт 443 нужен для HTTPS. Порт 5678 наружу не открывается: reverse proxy обращается к n8n внутри сервера или Docker network.

PostgreSQL и Redis тоже не публикуются наружу. Если в docker-compose.yml у них есть ports:, проверьте, действительно ли это нужно. В большинстве production-сценариев достаточно expose или вообще внутреннего доступа по имени сервиса.

Секреты и credentials ¶

В n8n есть несколько мест, где можно случайно оставить секреты. Самые частые: .env, Code node, HTTP Request body, Set node, execution data, логи контейнера и экспорт workflow.

Правило простое: токены должны жить в credentials или секретах окружения, а не в обычных полях workflow. Если интеграция поддерживает отдельные роли, создавайте отдельный токен именно для n8n. Например, для CRM не используйте личный админский ключ владельца, если можно выпустить сервисный webhook token с ограниченными правами.

N8N_ENCRYPTION_KEY задавайте до создания первых credentials. Храните его отдельно от публичного репозитория и не меняйте без backup. В queue mode один и тот же ключ нужен всем инстансам, которые работают с зашифрованными credentials.

Что стоит сделать с секретами:

хранить .env вне web-root;
ограничить права на файл: chmod 600 .env;
не отправлять .env в поддержку или подрядчикам целиком;
не вставлять API-ключи в Code node;
не сохранять токены в тестовых payload;
регулярно отзывать ключи, которые больше не используются.

Защита редактора ¶

Редактор n8n должен открываться только по HTTPS. Для командной работы включите двухфакторную аутентификацию там, где она доступна, и не создавайте один общий аккаунт “admin для всех”. Если работает несколько человек, каждый должен иметь отдельный доступ: так проще понять, кто изменил workflow или credential.

Для production-инстанса полезно разделить роли: один человек администрирует сервер и backup, другой работает с workflow, третий выдаёт API-доступы во внешних сервисах. Даже если команда маленькая, такое разделение помогает не хранить все ключи у одного пользователя в браузере.

Webhooks и внешние события ¶

Webhook — публичная дверь в workflow. Не каждый webhook опасен, но каждый нужно проектировать так, будто его URL могут увидеть.

Минимальная защита webhook-сценариев:

принимайте только нужный HTTP-метод;
проверяйте обязательные поля payload;
валидируйте подпись, secret или token, если сервис это поддерживает;
не доверяйте email, phone, amount, status без проверки источника;
добавляйте idempotency key для повторных событий;
не возвращайте в ответ внутренние ошибки, токены и stack traces.

Для Telegram, CRM и платёжных систем лучше хранить исходный request ID или event ID. Так вы сможете отличить новый заказ от повторной доставки одного и того же события.

Executions, логи и персональные данные ¶

Даже если credentials зашифрованы, executions могут содержать обычные данные: имя клиента, телефон, email, текст сообщения, стоимость заказа, ответ AI-модели, фрагмент документа. Поэтому безопасность n8n — это не только про API-ключи, но и про жизненный цикл данных.

Проверьте:

сколько executions хранится;
сохраняются ли данные успешных запусков;
попадают ли токены во входные или выходные JSON;
есть ли в workflow лишние console.log;
уходят ли персональные данные в сторонние AI API;
шифруются ли backup-архивы перед переносом в облако.

Если workflow обрабатывает чувствительные данные, добавьте отдельный шаг редактирования payload: удаляйте токены, лишние headers, внутренние комментарии и поля, которые не нужны дальше по цепочке.

Backup как часть безопасности ¶

Backup нужен не только для аварии диска. Он нужен перед обновлением n8n, заменой домена, миграцией сервера, поворотом ключей и массовым изменением credentials. Без backup любое исправление превращается в риск потерять workflows и доступы.

Минимальный backup должен включать:

dump PostgreSQL;
.env или безопасную копию его структуры;
compose-файлы;
данные .n8n, если они используются;
версию n8n и дату backup;
короткую инструкцию восстановления.

Хранить backup на том же сервере полезно только как временную копию. Настоящий backup должен уходить во внешнее хранилище и периодически проверяться восстановлением.

Чеклист перед подключением реальных токенов ¶

Перед тем как добавлять CRM, платежи, почту или AI API, пройдите список:

сайт открывается только через HTTPS-домен;
порт 5678 не доступен извне;
PostgreSQL и Redis не опубликованы наружу;
N8N_ENCRYPTION_KEY задан и сохранён;
.env не лежит в публичном репозитории;
включён firewall;
создан backup и понятна процедура restore;
у credentials минимально необходимые права;
webhook payload валидируется;
executions не хранят лишние токены и персональные данные;
есть error workflow или alert для критичных сценариев.

Если хотя бы половина пунктов не выполнена, инстанс лучше считать тестовым, а не production.

FAQ ¶

Нужно ли закрывать n8n за VPN?
Для внутренних автоматизаций это хороший вариант. Но если n8n принимает публичные webhooks, домен всё равно должен быть доступен внешним сервисам. Часто используют HTTPS-домен для webhooks и дополнительные ограничения для редактора.

Можно ли хранить API-ключи прямо в workflow?
Лучше не хранить. Используйте credentials n8n, переменные окружения или внешнее хранилище секретов. Так ключ проще заменить и сложнее случайно показать в execution.

Почему нельзя менять N8N_ENCRYPTION_KEY как обычный пароль?
Этим ключом связана расшифровка credentials. При неправильной смене старые credentials могут перестать открываться.

Достаточно ли HTTPS для безопасности?
Нет. HTTPS защищает транспорт, но не решает проблему широких API-прав, публичного порта, утечки .env, слабых webhook-проверок и лишних данных в executions.

Что делать после подозрения на утечку токена?
Сначала отзовите токен во внешнем сервисе, затем проверьте executions и логи, выпустите новый credential с минимальными правами, обновите workflow и зафиксируйте причину утечки.