Утечка секрета в n8n: runbook для revoke и rotate ¶

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

Intent: runbook secret leak: найденный токен/API key/OAuth secret, containment, revoke, rotate, audit, replay и профилактика утечек
H1: Утечка секрета в n8n: как быстро отозвать ключ, заменить credential и проверить последствия
Schema: TechArticle, HowTo, FAQPage, BreadcrumbList
Old word count: 664
New word count: 901

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

Если в n8n утёк API key, OAuth secret, webhook token или пароль, первым делом остановите affected workflow и отзовите секрет у провайдера. Не ограничивайтесь заменой значения в n8n: старый ключ должен стать недействительным во внешнем сервисе, иначе злоумышленник сможет использовать его вне вашей инфраструктуры. После revoke создайте новый credential, проверьте executions за период утечки, зафиксируйте affected systems и уберите причину: логирование payload, тестовый репозиторий, скриншот, общий чат или export workflow.

Когда применять этот runbook ¶

Используйте этот runbook, если секрет попал туда, где его не должно быть: в Git, лог, execution data, Slack/Telegram, email, скриншот, публичный issue, документацию, экспорт workflow, CSV, backup без защиты или prompt для AI-модели. Для n8n это особенно важно, потому что workflow часто соединяет CRM, платежи, таблицы, Telegram, email, LLM API и внутренние HTTP endpoint-ы.

Типичные сигналы:

• в логе виден Authorization: Bearer ...;
• workflow отправил credential в Telegram/Slack;
• разработчик вставил token прямо в HTTP Request node;
• export workflow попал в общий репозиторий;
• AI node получил секрет в prompt/context;
• API provider прислал alert о подозрительном использовании;
• после теста в execution data остался полный request body.

Цель runbook — не просто “заменить пароль”, а доказать, что старый секрет больше не работает, понять период риска и убрать путь повторной утечки.

1. Остановить распространение ¶

Первые 10 минут важнее идеального расследования. Сначала ограничьте дальнейшее использование секрета.

Не пытайтесь “просто удалить строку из чата” как единственную меру. Если секрет был виден людям, ботам, индексаторам или внешним системам, он уже считается раскрытым.

2. Отозвать старый секрет у провайдера ¶

Порядок безопасной ротации:

1. Найти provider и credential owner.
2. Создать incident ticket с временем обнаружения.
3. Остановить workflow, которые используют секрет.
4. Отозвать старый token/key/password у provider.
5. Создать новый секрет с минимальными правами.
6. Обновить credential в n8n.
7. Запустить smoke test.
8. Вернуть workflow в работу.
9. Проверить usage/audit log у provider.

Важно: если секрет используется в нескольких workflow, не меняйте его “на лету” без списка зависимостей. Иначе часть workflow продолжит падать, а команда может начать создавать обходные ключи.

3. Найти affected workflows и executions ¶

Соберите карту использования секрета:

• имя credential в n8n;
• workflow, где credential подключён;
• node, где есть inline token или header;
• executions за период риска;
• внешние объекты, которые могли измениться;
• пользователи, у которых был доступ к workflow/export/log;
• места, куда workflow отправлял payload.

Если утечка произошла через execution data, проверьте не только failed executions. Успешный workflow тоже мог сохранить request, response, headers или body с секретом.

4. Проверить последствия ¶

Для разных секретов последствия разные:

Если provider поддерживает audit log, выгрузите события за период: от последнего известного безопасного времени до момента revoke. Если audit log недоступен, используйте косвенные признаки: created/updated records, API usage, billing, IP, timestamps.

5. Убрать источник утечки ¶

Ротация секрета бесполезна, если новый ключ снова попадёт в тот же канал.

Проверьте:

• нет ли token в Set node, Code node, HTTP headers как plain text;
• не пишется ли полный request/response в журнал;
• не отправляется ли payload целиком в чат;
• не попадает ли credential в prompt AI-модели;
• не экспортируются ли workflow с реальными значениями;
• есть ли masking для чувствительных полей;
• кто может открывать executions;
• включён ли внешний secrets vault, если он доступен в вашей редакции/инфраструктуре.

Хорошее правило: секрет должен жить в credential/secrets layer, а workflow должен получать только результат авторизованного действия.

6. Вернуть процесс в production ¶

Перед включением workflow:

• smoke test проходит с новым credential;
• старый секрет не работает;
• affected executions помечены;
• replay не создаёт дубли;
• владелец процесса уведомлён;
• incident ticket содержит root cause;
• добавлена профилактика: masking, checklist, code review или запрет inline-secret.

Если были платежи, CRM или персональные данные, replay делайте только после сверки внешнего состояния. Не повторяйте side-effect, пока не понятно, была ли операция выполнена старым секретом.

FAQ ¶

Можно ли просто удалить execution с секретом?
Нет. Удаление истории не отзывает token. Сначала revoke/rotate у provider, затем уже чистка следов и ограничение доступа.

Что считать утечкой: token был виден только внутри команды?
Если секрет оказался вне intended storage, лучше считать его раскрытым. Особенно если это общий чат, экспорт, скриншот или лог.

Нужно ли менять все credentials в n8n?
Нет. Меняйте affected secrets и связанные credentials. Но если утёк master-доступ, backup, database password или admin account, scope расследования расширяется.

Как предотвратить повторение?
Запретить inline keys, маскировать payload, ограничить доступ к executions, проверять exports, добавить credential review и использовать secrets manager там, где это возможно.

{
  "source": "manual|webhook|schedule|api",
  "external_id": "stable-id-from-source",
  "received_at": "2026-05-29T10:00:00Z",
  "payload_version": "v1",
  "dry_run": true,
  "audit": {"workflow_id": "...", "execution_id": "..."}
}