Compromised credential в n8n: runbook ротации и containment ¶

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

Intent: runbook compromised credential: утечка API key/OAuth token, containment, revoke, rotate, workflow audit, replay и postmortem для n8n
H1: Compromised credential в n8n: как отозвать ключ, найти affected workflows и восстановить доступ
Schema: TechArticle, HowTo, FAQPage, BreadcrumbList
Old word count: 654
New word count: 844

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

Если credential в n8n мог быть скомпрометирован, сначала ограничьте ущерб: отключите affected workflows, отзовите ключ или OAuth token у внешнего провайдера и проверьте, где этот credential использовался. Затем создайте новый credential с минимальными правами, протестируйте affected workflows и только после этого возвращайте production. Не ограничивайтесь сменой значения в n8n: если старый token не отозван у провайдера, он может продолжать работать вне n8n.

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

Сценарии:

• API key попал в лог, чат, issue, Git repository или скриншот;
• сотрудник с доступом к credential уходит из проекта;
• внешний provider сообщил о подозрительной активности;
• OAuth app/token использовался в незащищённом окружении;
• staging и production делят один credential;
• кто-то случайно вставил secret в Code node, HTTP header или execution data.

Цель — быстро понять affected scope и заменить credential так, чтобы не сломать критичные workflow.

1. Containment: первые минуты ¶

Действуйте в таком порядке:

1. Определить provider и тип credential: API key, OAuth token, basic auth, webhook secret, DB password.
2. Найти affected workflows.
3. Временно деактивировать workflows, которые могут делать опасные side effects.
4. Отозвать старый secret у provider.
5. Проверить audit/provider logs на подозрительные действия.
6. Создать новый secret с минимальными scopes.
7. Обновить credential в n8n.
8. Провести smoke test и вернуть workflow.

Если credential даёт доступ к платежам, CRM, email-рассылкам, базе данных или облачному storage, не ждите полного расследования перед revoke.

2. Найти affected workflows ¶

Нужно понять, где credential используется и какие действия он мог выполнять.

Проверьте:

• workflows, где выбран этот credential;
• duplicate/staging workflows;
• archived workflows, которые всё ещё active;
• HTTP Request nodes с hardcoded headers;
• Code nodes, где secret мог быть вставлен руками;
• environment variables и credential overwrites;
• внешние webhooks, где используется shared secret.

Составьте таблицу:

Для AI/LLM workflows отдельно проверьте, не уходили ли secrets в prompt, tool output или execution logs.

3. Отозвать старый credential у provider ¶

Просто заменить значение в n8n недостаточно. Старый secret должен перестать работать в системе-источнике.

Типовые действия:

• API key: revoke/delete old key, создать новый;
• OAuth: revoke token, re-auth, возможно rotate client secret;
• webhook secret: создать новый secret и обновить provider/n8n одновременно;
• DB password: сменить пароль пользователя и обновить connection string;
• service account: rotate key, удалить старый key file;
• bot token: revoke token и перевыпустить.

После revoke проверьте, что старый credential действительно не работает. Это особенно важно, если provider поддерживает несколько активных ключей.

4. Обновить n8n без потери контроля ¶

При обновлении credential:

• не расширяйте scopes “на всякий случай”;
• используйте отдельные credentials для staging и production;
• не переиспользуйте личные аккаунты, если нужен service account;
• проверьте owner и доступ команды;
• запустите безопасный test connection;
• проверяйте workflow на маленьком payload.

Если инстанс self-hosted, убедитесь, что N8N_ENCRYPTION_KEY стабилен и одинаков для main/workers. Иначе workers могут не прочитать обновлённые credentials в queue mode.

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

После ротации нужно понять, успел ли кто-то использовать старый secret.

Проверьте:

• provider audit logs;
• необычные API calls;
• созданные/изменённые объекты;
• массовые export/download;
• failed auth attempts после revoke;
• n8n executions за период риска;
• логи reverse proxy, если credential использовался в webhook.

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

6. Вернуть workflow в production ¶

Возврат делайте постепенно:

1. Smoke test на безопасном объекте.
2. Проверить одну реальную операцию.
3. Включить workflow.
4. Следить за 401/403/429/500.
5. Проверить error workflow и алерты.
6. Сделать replay событий, которые были остановлены во время containment.

Для side-effect операций replay должен использовать idempotency: lookup перед create, проверка статуса платежа, dedup по external_event_id.

7. Postmortem и профилактика ¶

В отчёте зафиксируйте:

• когда credential мог утечь;
• кто обнаружил;
• какие workflows затронуты;
• когда secret отозван;
• какие подозрительные действия найдены;
• какие события переиграны;
• что изменено, чтобы не повторилось.

Профилактика:

• минимальные scopes;
• отдельные credentials для environments;
• регулярный credential audit;
• запрет secrets в Code node и plain text notes;
• masking logs;
• external secrets store для зрелых инсталляций;
• удаление доступов ушедших сотрудников.

FAQ ¶

Достаточно ли поменять credential в n8n?
Нет. Нужно отозвать старый secret у провайдера, иначе он может продолжать работать вне n8n.

Нужно ли отключать все workflows?
Нет, отключайте affected workflows и опасные side-effect операции. Но для критичных credentials лучше временно остановить всё, что может писать данные.

Что делать с OAuth credential?
Revoke token у provider, при необходимости rotate client secret, затем выполнить re-auth в n8n и smoke test.

Можно ли оставить старый key до конца расследования?
Если есть реальный риск компрометации, сначала revoke/containment, потом расследование. Старый key в расследовании не нужен активным.

{
  "request_id": "req_demo_001",
  "prompt_version": "2026-05-29",
  "input": "краткое нормализованное сообщение пользователя",
  "allowed_actions": ["read", "draft", "classify"],
  "forbidden_actions": ["send_without_review", "change_payment"],
  "expected_output": {
    "intent": "technical|support|sales|unknown",
    "confidence": 0.0,
    "needs_human_review": true,
    "sources": []
  }
}