Управление секретами в n8n: как не потерять и не раскрыть credentials ¶

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

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

Secrets management в n8n — это правила хранения, доступа, ротации и аудита credentials, API keys, OAuth tokens, webhook secrets и encryption key. Главный принцип: workflow должен иметь только те права, которые нужны для задачи, а секреты не должны попадать в payload, логи, AI prompt и execution data. Для self-hosted n8n критично сохранить N8N_ENCRYPTION_KEY: без него восстановленная база может не расшифровать credentials. Production-подход включает ownership, least privilege, rotation, external secret stores, audit и incident runbook.

Какие секреты есть в n8n ¶

В n8n секретами являются не только credentials в UI. Это OAuth refresh tokens, API keys, Basic Auth пары, webhook signing secrets, database passwords, Redis password, SMTP credentials, cloud storage keys, encryption key, service account JSON, AI provider keys, MCP credentials и временные tokens из workflow. Опасность в том, что часть секретов может случайно оказаться в Set node, execution data, error message, Telegram alert или AI prompt.

Секрет нельзя считать защищённым только потому, что он “внутри workflow”. Если node выводит credential-related ошибку в лог, а error workflow пересылает весь $json в Slack, секрет уже может утечь. Поэтому secrets management — это не одна настройка, а дисциплина проектирования workflow.

N8N_ENCRYPTION_KEY и backup ¶

Для self-hosted n8n ключ шифрования — один из самых важных элементов. n8n использует encryption key для credentials. Если база восстановлена, но правильный ключ потерян, credentials могут оказаться нечитаемыми. В queue mode все main и worker instances должны иметь совместимый key, иначе обработка credentials будет ломаться.

Правила: задайте N8N_ENCRYPTION_KEY явно через environment variable или secret manager; не храните его только внутри контейнера; включите его в disaster recovery checklist; ограничьте доступ; не печатайте его в логах; перед ротацией делайте полный backup и проверяйте процедуру. Для migration/restore отдельно документируйте: где база, где volumes, где encryption key, кто имеет доступ, как проверить credentials после восстановления.

Least privilege для credentials ¶

Каждый credential должен отвечать на вопросы: кто владелец, для каких workflow используется, какие scopes/permissions есть, когда последний раз проверялся, когда истекает, как отозвать, что сломается при ротации. Не используйте личный аккаунт сотрудника для production integration. Лучше service account или отдельный технический пользователь с минимальными правами.

Пример: workflow, который читает Google Sheets, не должен иметь права удалять файлы на Google Drive. AI Agent, который классифицирует тикеты, не должен иметь tool с правом отправить refund. Webhook, который принимает лиды, не должен использовать admin-token CRM. Чем шире scope, тем дороже инцидент.

Разделение окружений ¶

Production и staging не должны использовать одни и те же secrets. Это частая ошибка: тестовый workflow случайно создаёт настоящие сделки или отправляет реальные письма, потому что credential общий. Разделите credentials по названию и правам: crm_prod_read_write, crm_stage_sandbox, ai_openai_prod_limited, telegram_test_bot.

В workflow title и credential name должно быть видно окружение. Для dangerous tools добавьте guard: если env !== 'production', запрещать запись в production API; если workflow в production, не использовать test credential. Эта простая проверка спасает от многих аварий.

Секреты в Code node и payload ¶

Не вставляйте API keys прямо в Code node. Не прокидывайте secrets через обычный $json, если дальше данные попадут в лог, AI model или external API. Если node требует секрет, используйте credential mechanism или environment/secret store. Если нужно отправить alert, заранее сформируйте безопасный summary.

Пример masking:

function mask(value) {
  if (!value) return null;
  const s = String(value);
  if (s.length <= 8) return '***';
  return `${s.slice(0, 4)}...${s.slice(-4)}`;
}

return [{ json: {
  correlation_id: $json.correlation_id,
  credential_ref: $json.credential_name,
  token_preview: mask($json.token),
  error_code: $json.error_code
}}];

Лучше вообще не иметь $json.token, но если временный token появляется в workflow, он должен быть удалён до логирования.

Rotation policy ¶

Ротация должна быть процессом, а не героическим действием во время инцидента. Для каждого секрета задайте период: критичные API keys — 30–90 дней, service account keys — по политике компании, webhook secrets — при смене интеграции или подозрении на утечку, OAuth tokens — по необходимости и событиям безопасности. Ротация должна иметь dry-run, окно изменений, smoke test и rollback.

План ротации: создать новый credential; подключить его к staging workflow; выполнить smoke test; заменить credential в production workflow; активировать; проверить executions; отключить старый credential у провайдера; записать дату и владельца. Не удаляйте старый credential в n8n до проверки, но обязательно отзовите старый secret у провайдера, если он больше не нужен.

Incident response при утечке ¶

Если секрет утёк, первое действие — containment: отключить affected workflow, остановить dangerous triggers, отозвать секрет у провайдера, создать новый. Затем определить blast radius: какие workflow использовали credential, какие actions могли быть выполнены, какие данные могли быть прочитаны, были ли подозрительные executions, нужно ли уведомлять владельцев данных. После этого выполняется replay только для безопасных событий.

Не ограничивайтесь “поменяли пароль”. Добавьте postmortem: как секрет попал в лог или prompt, почему alert не сработал, почему scope был широким, как предотвратить повтор. Для AI workflow отдельно проверьте, не отправлялись ли secrets в модель как часть context или tool input.

Production checklist ¶

Проверьте: N8N_ENCRYPTION_KEY задан и сохранён; backup включает процедуру восстановления credentials; production/staging secrets разделены; credentials имеют владельцев; личные аккаунты заменены service accounts; scopes минимальны; secrets не попадают в execution data; alerts маскируют токены; rotation policy есть; external secret store рассмотрен; compromised credential runbook готов; доступ к n8n UI защищён MFA/SSO по возможности; список credentials ревьюится регулярно.

FAQ ¶

Что будет, если потерять N8N_ENCRYPTION_KEY? ¶

После восстановления базы credentials могут не расшифроваться. Поэтому ключ нужно хранить как часть disaster recovery, но с ограниченным доступом.

Можно ли хранить API key в Code node? ¶

Не стоит. Используйте credentials, environment variables или external secrets. Code node легко скопировать, экспортировать или залогировать.

Нужно ли отдельное credential на каждый workflow? ¶

Не всегда, но права должны соответствовать задаче. Критичные write-доступы лучше отделять от read-only.

Как понять, какие workflow используют credential? ¶

Ведите инвентаризацию: credential name, owner, workflow list, scopes, last rotation, blast radius. Проверяйте это перед ротацией.

Что делать при увольнении сотрудника? ¶

Заменить личные credentials на service accounts, отозвать tokens, проверить workflow ownership и выполнить smoke tests критичных процессов.