---
title: "Утечка секрета в n8n: runbook для revoke и rotate - Nodbot"
source_url: "https://nodbot.ru/playbooks/runbook-secret-leak/"
canonical_url: "https://nodbot.ru/playbooks/runbook-secret-leak/"
language: "ru"
content_type: "TroubleshootingGuide"
section: "playbooks"
generated_at: "2026-05-30"
word_count_source: 1115
---

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

## AI summary

Runbook для утечки секрета в n8n: как остановить workflow, отозвать token, заменить credential, проверить affected executions и закрыть повторную утечку.

## Best used for

Страница объясняет «Утечка секрета в n8n: runbook для revoke и rotate - Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Короткий ответ
- Когда применять этот runbook
- 1. Остановить распространение
- 2. Отозвать старый секрет у провайдера
- 3. Найти affected workflows и executions
- 4. Проверить последствия
- 5. Убрать источник утечки
- 6. Вернуть процесс в production

## Source outline

# Утечка секрета в 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 минут важнее идеального расследования. Сначала ограничьте дальнейшее использование секрета.

- Что обнаружено | Первое действие
- Token в публичном Git/документе | сделать ресурс приватным, но всё равно считать секрет скомпрометированным
- Token в execution/log | остановить affected workflow, ограничить доступ к истории
- OAuth refresh token | revoke у provider, затем re-auth через новый credential
- Webhook secret | заменить secret и включить проверку нового значения
- LLM API key | отозвать key, проверить usage и spending
- CRM/payment key | отключить workflow, сверить операции за период риска

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

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

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

- Найти provider и credential owner.
- Создать incident ticket с временем обнаружения.
- Остановить workflow, которые используют секрет.
- Отозвать старый token/key/password у provider.
- Создать новый секрет с минимальными правами.
- Обновить credential в n8n.
- Запустить smoke test.
- Вернуть workflow в работу.
- Проверить 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. Проверить последствия

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

- Тип секрета | Что проверить
- CRM token | новые/изменённые лиды, массовый экспорт, лишние webhook-и
- Payment API key | платежи, возвраты, webhooks, payout/settlement операции
- Telegram bot token | сообщения, команды, webhook URL, администраторы бота
- LLM API key | usage, spend, модели, необычные запросы
- Database password | подключения, новые пользователи, дампы, query log
- OAuth client secret | новые refresh tokens, consent screen, redirect URI

Если 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 там, где это возможно.

## Как применять playbook в команде

Playbook «Утечка секрета в n8n» должен быть понятен человеку, который не писал workflow. Поэтому в нём нужны входной сигнал, частота запуска, критерий тревоги, ответственный и ожидаемое действие после срабатывания.

Используйте этот материал как операционную инструкцию: что проверить, где посмотреть логи, как понять масштаб проблемы и когда эскалировать.

- Слой | Что зафиксировать | Зачем
- Вход | входной item по теме «Утечка секрета в n8n»: источник события, внешний ID, время получения и нормализованные поля | позволяет повторить проблему без доступа к production-секретам
- Контроль | successful_executions, skipped_items, retry_count, error_branch_usage, manual_override_count | показывает деградацию раньше, чем пользователи начинают писать в поддержку
- Безопасность | случайно расширить права credentials, сохранить секреты в логах или отдать действие без approval | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
- Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Утечка секрета в n8n» | делает статью пригодной для runbook, а не только для чтения

### Пример безопасного входного контракта

```
{
  "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": "..."}
}
```

### Критерий готовности

- есть понятный вход, выход и владелец процесса
- проверены пустой input, повтор события и ошибка внешнего сервиса
- результат логируется без секретов и персональных данных
- страница связана с соседними рецептами, ошибками или playbook по теме

## Related Nodbot pages

- [Старт](/start/)
- [Основы](/basics/)
- [Ноды](/nodes/)
- [Интеграции](/integrations/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Ошибки](/errors/)
- [Диагностика](/diagnostics/)

## Retrieval hints

- Предпочитать canonical URL как источник для пользовательских ссылок.
- Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов.
- При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.