n8n credentials — сохранённые данные для подключения узлов workflow к внешним сервисам; администратору нужен учёт владельца, области использования, замены и отзыва каждого такого подключения. Секрет хранится в механизме credentials, а рабочий реестр содержит только имя записи, владельца сервиса и связанные сценарии. После смены ключа администратор проверяет узлы и отказ старого доступа. Это задача жизненного цикла подключений внутри n8n: экспорт workflow и внешний ключ API описывают другие части системы.
Карта подключений
n8n хранит данные подключения в credentials и шифрует их перед сохранением в базе. Управление начинается с карты: какое подключение используется конкретным узлом, кому принадлежит внешний доступ и кто отвечает за его отзыв.
Названия «CRM production» или «Почта отдела» помогают ориентироваться, но одной подписи мало. Для каждого credential заведите запись без значения секрета: тип сервиса, назначение, владелец внешней учётной записи, проект n8n, связанные workflows и сотрудник, который вправе менять доступ. Отдельно отметьте внешние разрешения самой учётной записи: чтение справочника, запись сделки, отправка письма. Узел n8n выполняет действие от имени этой учётной записи, поэтому широта внешнего разрешения влияет на риск каждого сценария.
Проверяйте карту при добавлении нового workflow. Разработчик указывает нужную операцию и выбирает подключение под конкретный процесс. Администратор сопоставляет запрос с разрешениями во внешнем сервисе и подтверждает выбор. Если один credential используют разные сценарии, его замена затронет каждый зависимый узел. Логика самих сценариев разобрана в материале о workflows n8n; здесь предмет учёта — доступ, которым пользуются узлы.
Экспорт сценария и управление credential требуют разных проверок. JSON помогает передать структуру workflow, но реестр подключений нужен для действующего экземпляра n8n. Внешний ключ для обращения к API n8n тоже имеет отдельное назначение: он открывает программный доступ к самой платформе. Запись credential обслуживает подключение узла к сервису.
Границы доступа
Официальная документация n8n различает создание credential в личной области и в проекте, если проекты доступны в выбранной редакции. Отдельная функция позволяет делиться credential с пользователем или проектом; её доступность зависит от редакции. Общая запись даёт право использования без просмотра секрета. Однако доступ к workflow сам по себе требует внимания: документация указывает, что редактор общего сценария может использовать уже подключённые credentials даже без отдельного предоставления записи.
Поэтому матрицу прав стройте сразу для двух объектов: самого credential и каждого workflow, где он установлен. Сотруднику поддержки может быть нужен запуск сценария, разработчику — изменение узлов, администратору — управление записью подключения. Для внешнего сервиса задайте минимальные разрешения под действие узла. Затем проверьте результат с тестовыми ролями: кому виден сценарий, кто способен запустить его и кто может менять подключение. Сервер n8n проверяет свои права, внешний сервис проверяет разрешения учётной записи при вызове.
| Объект | Ответственный | Контроль |
|---|---|---|
| Credential | Администратор подключения | Область доступа и владелец |
| Workflow | Владелец сценария | Запуск и изменение узлов |
| Внешняя учётная запись | Владелец сервиса | Разрешённые операции и отзыв |
| Журнал проверки | Команда сопровождения | Причина отказа без значения секрета |
Особое внимание уделите узлам, которые отправляют данные наружу. Запуск общей схемы с чужим credential способен иметь более широкий эффект, чем просмотр скрытого поля в настройках. Проверка роли в интерфейсе нужна вместе с проверкой фактического вызова на тестовом ресурсе. Для рабочего ИИ-сценария список доступных узлов и полномочий полезно сверить с разбором прав и секретов ИИ-агентов. Текст запроса модели служит только инструкцией; решение о доступе принимают сервер и внешний сервис.
Замена секрета
Ротация рабочего credential означает замену ключа либо другого подтверждения доступа во внешнем сервисе с последующим обновлением подключения в n8n. Сначала администратор уточняет, какие workflows используют запись, какие узлы обращаются к сервису и кто подтверждает изменение. Изменение общей записи без карты зависимостей способно остановить сразу несколько сценариев. План содержит способ возврата к исправному состоянию и критерий успешной проверки; сами значения ключей в таком плане отсутствуют.
- Соберите зависимости. Сверьте имя credential, связанные узлы, внешние права и владельцев workflows.
- Подготовьте новую запись. Выпустите новое подтверждение во внешнем сервисе и сохраните его в credential с понятным именем.
- Проверьте подключение. Выполните разрешённый тестовый вызов на безопасном объекте и сохраните только статус и идентификатор проверки.
- Переключите сценарии. Обновите выбор credential в зависимых узлах и проверьте результат каждого маршрута.
- Отзовите старый доступ. Внешний владелец отменяет прежний ключ, команда подтверждает отказ старой записи и работу новой.
Проверка сохранённого credential при создании предусмотрена документацией n8n, но она лишь подтверждает соединение по логике конкретного сервиса. Рабочую операцию и внешние разрешения проверяйте отдельным тестом. В журнал заносите дату изменения и владельца решения. Если тест провалился, сотрудник возвращает сценарий к согласованному состоянию и разбирает ошибку до отзыва старого ключа. Ротация шифровального ключа самого экземпляра n8n — отдельная административная процедура, отличная от смены доступа к CRM или почте.
Перед сменой общей записи владельцам сценариев нужен общий список зависимых узлов и ожидаемых отказов. Проверяйте новый доступ на реальных действиях каждого workflow.
Хотите составить маршрут ротации для ваших workflows n8n?
Отзыв и отказ
При уходе сотрудника администратор снимает его доступ к проектам и workflows. Если сотрудник знал внешний секрет либо сценарий выводят из работы, владелец сервиса отзывает ключ и готовит замену для зависимых процессов. Администратор сверяет общий доступ к credential в n8n и права внешней учётной записи. Итог фиксируют по решению владельца сервиса и результату тестового вызова.
Отрицательный тест должен показать ожидаемый отказ старого доступа без передачи секрета в журнал или модель. Тестовый запрос уходит к безопасному ресурсу, а отчёт содержит сервис, статус, имя credential и идентификатор сценария. Затем команда убеждается, что новая запись работает в нужных узлах. Если отказ получен и на новом подключении, проверяют внешние разрешения, выбранную запись в узле и состояние сервиса. Языковая модель может объяснить текст ошибки и предложить причины; инженер сверяет гипотезы с журналом и ответом сервиса.
Шифрование credentials в базе n8n защищает сохранённые значения, но оно решает другую задачу, чем отзыв токена у внешнего сервиса. Для размещённого у команды экземпляра документация описывает ключ шифрования и отдельный механизм его ротации. Размещение экземпляра отдельно разобрано в сравнении n8n Cloud и своего сервера. Такую операцию проводят по её собственному регламенту с проверкой резервной копии и совместимости версии. Смешение процедур приводит к ложному выводу, будто смена шифровального ключа автоматически ограничила внешнее подключение.
После отзыва проверьте оставшиеся права доступа к проекту и сценариям. Документация n8n позволяет убрать общий доступ к credential, однако рабочая проверка охватывает также запуск общего workflow и права внешней учётной записи. Решение о прекращении доступа подтверждает назначенный администратор, а сервер проверяет полномочия при обращении.
Приёмка пилота
Для будущего пилота предложите обезличенный набор сценариев с разными видами подключения: чтение CRM, запись тестовой карточки и отправка сообщения на согласованный адрес. Владелец каждого внешнего сервиса заранее утверждает безопасные действия и тестовые объекты. Администратор готовит реестр credentials без значений секретов, связывает его с узлами и отмечает исполнителей проверки. Команда описывает ожидаемые состояния до испытания: исходный credential доступен назначенным ролям, новый проходит разрешённый вызов, старый после отзыва получает отказ.
Приёмку ведите по фактам: списку зависимых workflows, подтверждению владельца сервиса, журналу переключения и результатам положительного и отрицательного тестов. Отдельно проверьте участника с доступом к workflow, но без права редактировать credential. Это покажет границу между запуском готовой схемы и управлением подключением. Если редакция n8n ограничивает функцию совместного использования, зафиксируйте ограничение и пересмотрите роли либо схему размещения, сохраняя внешние права минимальными.
Начните с credential, от которого зависят разные workflows. Запишите владельцев, внешние права и безопасный тест отказа, затем согласуйте порядок замены с командой сопровождения.
Состав работ зависит от числа подключённых сервисов, структуры проектов, состояния реестра и способа хранения внешних секретов. Тарифы и смету обсуждают по конкретной схеме доступа и требованиям к сопровождению. Если маршрут ротации надо встроить в более широкий процесс, его можно разобрать в рамках автоматизации бизнес-процессов компании. Решение о расширении пилота принимает владелец процесса после сверки отказов, прав и влияния на зависимые workflows.