--- title: "Compromised credential в n8n: ротация и containment — Nodbot" source_url: "https://nodbot.ru/playbooks/runbook-compromised-credential/" canonical_url: "https://nodbot.ru/playbooks/runbook-compromised-credential/" language: "ru" content_type: "TroubleshootingGuide" section: "playbooks" generated_at: "2026-05-30" word_count_source: 1044 --- # Compromised credential в n8n: ротация и containment containment ## AI summary Production-гайд «Compromised credential в n8n: ротация и containment»: настройка n8n, инфраструктура, мониторинг, backup, rollback и ошибки эксплуатации. ## Best used for Страница объясняет «Compromised credential в n8n: ротация и containment — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Короткий ответ - Когда применять runbook - 1. Containment: первые минуты - 2. Найти affected workflows - 3. Отозвать старый credential у provider - 4. Обновить n8n без потери контроля - 5. Проверить последствия - 6. Вернуть workflow в production ## Source outline # Compromised credential в n8n: ротация и containment 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: первые минуты Действуйте в таком порядке: - Определить provider и тип credential: API key, OAuth token, basic auth, webhook secret, DB password. - Найти affected workflows. - Временно деактивировать workflows, которые могут делать опасные side effects. - Отозвать старый secret у provider. - Проверить audit/provider logs на подозрительные действия. - Создать новый secret с минимальными scopes. - Обновить credential в n8n. - Провести 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. Составьте таблицу: - Workflow | Credential | Side effect | Risk | Action - CRM lead sync | amoCRM OAuth | create/update leads | high | disable, reauth - Payment webhook | provider secret | verify events | critical | rotate secret - Report export | Sheets OAuth | write rows | medium | reauth/test Для 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 Возврат делайте постепенно: - Smoke test на безопасном объекте. - Проверить одну реальную операцию. - Включить workflow. - Следить за 401/403/429/500. - Проверить error workflow и алерты. - Сделать 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 в расследовании не нужен активным. ## Как применять playbook в команде Playbook «Compromised credential в n8n» должен быть понятен человеку, который не писал workflow. Поэтому в нём нужны входной сигнал, частота запуска, критерий тревоги, ответственный и ожидаемое действие после срабатывания. Используйте этот материал как операционную инструкцию: что проверить, где посмотреть логи, как понять масштаб проблемы и когда эскалировать. - Слой | Что зафиксировать | Зачем - Вход | нормализованный prompt, контекст, список источников, версия промпта и ожидаемый JSON-ответ | позволяет повторить проблему без доступа к production-секретам - Контроль | validation_error_rate, token_cost, fallback_usage, human_review_rate, source_coverage | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | случайно расширить права credentials, сохранить секреты в логах или отдать действие без approval | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Compromised credential в n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "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": [] } } ``` ### Критерий готовности - есть понятный вход, выход и владелец процесса - проверены пустой input, повтор события и ошибка внешнего сервиса - результат логируется без секретов и персональных данных - страница связана с соседними рецептами, ошибками или playbook по теме ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.