Credential audit n8n: ревизия доступов и секретов ¶

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

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

Credential audit в n8n нужен, чтобы понять, какие API keys, OAuth tokens, database passwords и service accounts реально используются workflow, кому они принадлежат и какие права имеют. Хороший аудит не сводится к «поменять все пароли»: сначала строят инвентарь, находят личные аккаунты сотрудников, лишние scopes, неиспользуемые credentials и критичные write-доступы, затем планируют ротацию без остановки production.

Почему credentials становятся риском ¶

n8n часто подключает CRM, платежи, почту, таблицы, AI-провайдеров, базы данных и внутренние API. Один workflow может иметь больше прав, чем отдельный сотрудник: читать клиентов, менять сделки, отправлять письма, создавать платежи или выгружать персональные данные. Если credential создан на личный аккаунт сотрудника или имеет лишние scopes, автоматизация становится слабым местом.

Аудит особенно нужен после:

• ухода сотрудника;
• перехода workflow в production;
• подключения платежей или CRM;
• добавления AI-сервисов;
• миграции на self-hosted;
• инцидента с 401/403 или подозрением на утечку;
• массового копирования workflow между окружениями.

1. Инвентарь credentials ¶

Начните не с ротации, а с таблицы. Нужно понять, что вообще существует.

Не называйте credential Google или CRM. Лучше: prod-bitrix24-leads-write-service, staging-google-sheets-readonly, prod-openai-support-drafts. По имени должно быть понятно окружение, сервис, действие и владелец.

2. Найти личные аккаунты ¶

Самая частая проблема — production workflow работает через аккаунт конкретного сотрудника: его Google, CRM, Telegram bot, email или OAuth app. Когда человек увольняется, меняет пароль или теряет права, workflow ломается.

Проверьте:

• чей email указан в OAuth consent или connected account;
• кто владелец API key в CRM;
• есть ли сервисный аккаунт или shared mailbox;
• что произойдёт при удалении пользователя;
• кто может сделать reauth, если token истёк;
• есть ли второй администратор приложения.

Для production лучше использовать сервисные аккаунты, app owner или team-owned credentials, а не личные токены.

3. Scopes и принцип минимальных прав ¶

Credential должен иметь ровно те права, которые нужны workflow. Если workflow только читает строки из Google Sheets, ему не нужен доступ ко всей почте. Если workflow создаёт лиды, ему не обязательно удалять сделки.

Если сервис не поддерживает тонкие scopes, компенсируйте ограничениями на уровне workflow: allowlist действий, IF-фильтры, отдельная staging/prod credential, журнал write-операций.

4. Проверка секретов в workflow ¶

Даже если n8n credentials настроены правильно, секреты могут оказаться в других местах: Code node, Set node, prompt для AI, примеры payload, документация, HTML-страницы, exports, screenshots.

Ищите:

• строки вида sk-, token, secret, apikey, password;
• Authorization headers в HTTP Request node;
• Basic Auth, сохранённый как текст;
• приватные URL с embedded token;
• webhook secret в открытом примере;
• ключи в AI prompt или system message;
• payload-файлы в репозитории.

Хорошая практика: секреты живут в credentials или secret manager, а workflow содержит только ссылки на них и безопасные placeholder-значения.

5. План ротации без простоя ¶

Не меняйте все credentials одновременно. Ротация должна быть похожа на deploy: подготовка, тест, переключение, rollback.

Порядок:

1. Выбрать один credential и список зависимых workflows.
2. Создать новый ключ или OAuth app рядом со старым.
3. Проверить новый credential на staging или read-only операции.
4. Переключить один workflow с низким риском.
5. Выполнить smoke test.
6. Переключить остальные workflow.
7. Отозвать старый ключ.
8. Записать дату, owner и результат.

Для OAuth учитывайте reauth: иногда нельзя просто заменить secret, нужно заново пройти авторизацию. Для внешних API проверьте, можно ли временно держать два активных ключа.

6. Что делать при подозрении на утечку ¶

Если есть шанс, что ключ попал наружу, не ждите полного расследования.

Если credential имел доступ к персональным данным или деньгам, подключайте юридическую/безопасностную процедуру компании, а не только n8n-команду.

7. Особенности AI credentials ¶

AI-ключи часто недооценивают: «это же просто генерация текста». На практике они могут привести к большим расходам, утечке контента или отправке чувствительных данных внешней модели.

Проверьте:

• лимиты бюджета и rate limit;
• кто может использовать ключ;
• какие workflow отправляют персональные данные;
• есть ли redaction до AI node;
• логируется ли prompt целиком;
• есть ли отдельные ключи для dev/staging/prod;
• как быстро ключ можно отозвать.

Метрики аудита ¶

После первого аудита полезно вести простые показатели:

• доля credentials с назначенным owner;
• доля личных аккаунтов в production;
• количество credentials без даты проверки;
• количество write credentials без smoke test;
• количество секретов, найденных вне credentials;
• средний возраст ключа;
• количество workflow с admin-level scopes.

Контрольный чеклист ¶

• У каждого credential есть владелец и окружение.
• Личные аккаунты в production заменены или имеют план замены.
• Scopes соответствуют реальным действиям workflow.
• Секреты убраны из Code, Set, prompt и экспортов.
• Для критичных credentials есть дата ротации.
• Ротация проверена smoke test, а не только сохранением формы.
• Старые ключи отозваны после переключения.
• При утечке есть короткий runbook.

FAQ ¶

Как часто проводить credential audit?
Для production-инстанса — минимум ежеквартально и после кадровых изменений, инцидентов, новых платежных/CRM-интеграций или миграций.

Можно ли просто пересоздать все credentials за один день?
Можно, но рискованно. Лучше идти по критичности и зависимости workflow, иначе легко получить массовый простой.

Что хуже: старый ключ или лишние scopes?
Оба риска важны. Старый ключ повышает вероятность компрометации, а лишние scopes увеличивают ущерб, если компрометация произойдёт.

Нужно ли хранить owner внутри имени credential?
Можно частично: окружение и назначение — да. Имя человека лучше хранить в реестре, чтобы не переименовывать credential при смене ответственного.

Как проверять credentials, которые пишут данные?
Через staging, read-only endpoint, тестовый объект или безопасный dry-run. Не делайте smoke test записью в реальную CRM без уникальной тестовой метки.

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