Учётные данные и секреты

API-ключи, токены, пароли к базам, OAuth-секреты — всё это секреты. Если они попадут в чужие руки, последствия могут быть от «придёт счёт за чужие запросы» до «удалили данные клиента». Поэтому к ним надо относиться отдельно от обычных настроек сценария.

Никогда не вписывайте секреты в выражения и тела запросов

Самая частая ошибка — вставить API-ключ прямо в тело HTTP-запроса или в строку URL. Так делать нельзя:

  • секрет окажется в экспортированном JSON сценария, и его легко случайно показать или закоммитить;
  • его увидят все, кто имеет доступ к редактированию сценария;
  • если вы решите выложить шаблон сценария — секрет уйдёт «в публику».

Правильно: создаёте в n8n запись Credentials, выбираете её в поле Authentication узла. Сам ключ при этом хранится в зашифрованном хранилище n8n и в открытом виде в сценарий не попадает.

Один Credential — много сценариев

Один и тот же набор учётных данных можно использовать сразу в нескольких сценариях. Например, OAuth-токен для Google Sheets вы один раз авторизуете, а дальше десять разных сценариев пользуются одной и той же записью.

Плюс: ротация ключа — это правка в одном месте.

Минус: если один сценарий «утечёт» (вы его экспортировали для тестирования и забыли удалить), у злоумышленника всё равно будет только ссылка на credential, а не сам ключ.

Что делать, если ключ всё-таки утёк

  1. Немедленно отзовите ключ в кабинете соответствующего сервиса (OpenAI, Google, Stripe, что угодно).
  2. Создайте новый ключ.
  3. В n8n обновите запись Credentials — без удаления и пересоздания сценариев.
  4. Просмотрите логи сервиса: были ли в последние часы запросы, которых вы не делали.
  5. Если был — оцените масштаб ущерба и реагируйте по обстоятельствам.

Чем быстрее вы сделаете шаг 1, тем меньше успеют натворить с вашим ключом. На большинство платных API за час «свободного использования» можно получить очень крупный счёт.

OAuth и refresh-токены

Многие интеграции (Google, Microsoft, Notion, Slack и др.) используют OAuth. Принцип простой: вы один раз авторизуетесь через интерфейс n8n — он получает access-токен (короткоживущий) и refresh-токен (для обновления). Дальше n8n обновляет токены сам.

Что важно:

  • OAuth-credentials привязаны к конкретному пользователю/аккаунту. Если человек, который проходил OAuth, потерял доступ к сервису — credential перестанет работать. Лучше использовать технический аккаунт, не привязанный к конкретному сотруднику.
  • Если refresh-токен «протух» (пользователь отозвал доступ, сменил пароль и т.п.), нужно повторно пройти OAuth.

Бэкап секретов

Учётные данные хранятся в базе n8n. Если вы потеряете базу (упал сервер, удалился volume), вы потеряете все credentials — и придётся пересоздавать.

Что с этим делать:

  • Регулярные бэкапы базы n8n — отдельная инженерная практика, должна быть включена обязательно.
  • Резервная копия списка credentials — где-нибудь снаружи (например, в менеджере паролей) храните пометку: «n8n использует такие-то ключи от такого-то сервиса». Не сами ключи, а информация о том, какие ключи где живут — чтобы при восстановлении знать, что нужно перевыпускать.

Принцип минимальных прав

API-ключ должен иметь минимально необходимые права. Если сценарий только читает Google Sheets — не давайте ключу права на удаление. Если ключ нужен только для одного бакета в S3 — не давайте доступ ко всем.

Когда сценарий будет атакован или у него обнаружится баг (баги случаются всегда), ущерб ограничится тем, что разрешено ключу.

Сводка

  • Секреты хранятся только в Credentials, не в выражениях.
  • Один и тот же Credential можно переиспользовать.
  • При утечке — отзывайте, не «меняйте пароль через неделю».
  • Делайте бэкапы базы n8n.
  • Ключам — минимум прав.