Безопасное управление учётными данными: шифрование, общий доступ, External Secrets

Учётные данные — это настоящее сердце любой автоматизации n8n: без API-ключа, OAuth2-токена или пароля к базе данных ни один цифровой сотрудник не сможет обращаться к внешним системам. Именно поэтому стоит внимательно разобраться, как n8n на самом деле защищает эти учётные данные, кому в команде разрешено использовать их, не видя самих значений, и как можно полностью вынести конфиденциальные данные за пределы n8n, поручив их управление внешнему хранилищу секретов. Актуально на июль 2026 года.

Эта статья чётко разделяет три уровня: модель шифрования, работающую в фоновом режиме, права на совместное использование для команд и подключение внешних хранилищ секретов для корпоративных (Enterprise) конфигураций. В конце вы будете точно знать, какой уровень подходит именно для вашей установки.

Как n8n шифрует учётные данные

n8n всегда хранит все учётные данные в базе данных в зашифрованном виде, никогда в открытом тексте. Согласно руководству по настройке собственного ключа шифрования, n8n при первом запуске автоматически создаёт случайный ключ и сохраняет его в папке `~/.n8n`. Этим ключом n8n шифрует каждую учётную запись перед записью в базу данных. Если вы хотите сами контролировать этот ключ, например, чтобы управлять им централизованно или создать резервную копию независимо от файловой системы, задайте перед запуском следующую переменную окружения:

```

export N8N_ENCRYPTION_KEY=<случайная, длинная строка>

```

Важно для командной и продуктивной эксплуатации: если n8n работает в режиме очереди (queue mode) с несколькими воркерами, все инстансы должны использовать абсолютно одинаковое значение `N8N_ENCRYPTION_KEY`. Иначе воркеры не смогут расшифровать учётные данные, зашифрованные основным процессом, и workflow'ы будут завершаться ошибкой именно там, где требуется учётная запись.

Двухуровневая модель с ротацией ключей

Для self-hosted-инстансов n8n дополнительно предлагает ротацию шифрования. Согласно документации по ротации ключей шифрования, n8n работает при этом с двумя уровнями:

• Instance Encryption Key (`N8N_ENCRYPTION_KEY`): постоянный мастер-ключ, который не меняется.
• Data Encryption Key: фактический ключ, который шифрует учётные данные и другие конфиденциальные данные и может быть заменён без изменения мастер-ключа.

Уже зашифрованные данные остаются читаемыми после ротации; при последующих операциях записи n8n автоматически перешифровывает их новым Data Encryption Key. Функция активируется через переменную окружения `N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION=true` на всех инстансах, после чего ротацию можно запустить в разделе Settings > Data Encryption Keys в интерфейсе или через API (`POST /encryption/keys`). Один момент, который стоит обязательно усвоить заранее: как только функция активна и новые данные записаны в новом формате, ротацию уже нельзя отменить, а автоматизированного инструмента для обратного преобразования данных не существует. Поэтому полная резервная копия базы данных перед активацией — это не рекомендация, а обязательное требование.

Совместное использование учётных данных в команде без их раскрытия

Как только несколько человек начинают работать над одними и теми же workflow'ами, встаёт вопрос, кому разрешено видеть и использовать те или иные учётные данные. n8n здесь сознательно разделяет использование учётной записи и доступ к просмотру её значений. Согласно документации о совместном использовании workflow действует правило: тот, кто делится workflow, автоматически предоставляет доступ и ко всем используемым в нём учётным данным, даже если они не были явно предоставлены по отдельности. Это гарантирует, что общие workflow'ы действительно остаются работоспособными для всех участников.

По ролям n8n различает два уровня:

• Creator (изначальный автор, создавший workflow): может просматривать, запускать, редактировать, экспортировать, предоставлять доступ и удалять workflow.
• Editor (пользователи с предоставленным доступом): может просматривать, запускать, редактировать и экспортировать, но не может ни предоставлять доступ, ни удалять.

Принцип минимальных привилегий действует и здесь последовательно: если используемая в workflow учётная запись не была дополнительно предоставлена отдельно, Editor может запустить workflow и редактировать другие узлы (nodes), но не может изменить именно тот узел, где используется непредоставленная учётная запись. Значения предоставленной учётной записи, то есть API-ключи или пароли, при этом принципиально остаются невидимыми для Editor'ов. Они могут использовать учётную запись, но не могут прочитать её содержимое. Важное практическое замечание: право собственности на workflow нельзя просто передать другому лицу, за исключением случая удаления учётной записи пользователя. Поэтому тем, кто с самого начала работает в команде, стоит создавать workflow'ы сразу в общем проекте, а не в личном рабочем пространстве, поскольку добавление отдельных пользователей через функцию "Add users" согласно документации работает только для workflow'ов в личном пространстве. Для workflow'ов внутри проекта права распределяются вместо этого через членство в самом проекте.

External Secrets: управление учётными данными вне n8n

Для корпоративных (Enterprise) конфигураций n8n идёт ещё дальше и позволяет вообще не хранить конфиденциальные значения в самом n8n, а оставлять их во внешнем хранилище секретов. Согласно документации о внешних хранилищах секретов, n8n поддерживает для этого шесть провайдеров:

• 1Password (через Connect Server)
• AWS Secrets Manager
• Azure Key Vault
• GCP Secrets Manager
• HashiCorp Vault
• Infisical

Эта функция привязана к тарифам Enterprise Self-hosted и Enterprise Cloud. Хранилище (vault) настраивается в разделе Settings > External Secrets через "Add secrets vault": там вы задаёте уникальное имя для хранилища, выбираете провайдера и вводите необходимые для этого учётные данные. Внутри учётной записи вы затем обращаетесь к внешнему значению через выражение, например:

```

{{ $secrets.<vault-name>.<secret-name> }}

```

Для 1Password существует расширенный синтаксис с названием элемента и меткой поля: `{{ $secrets.<vault-name>.<item-title>.<field-label> }}`. Следует знать одно техническое ограничение: n8n поддерживает для секретов только простые текстовые значения, а не JSON-объекты, и выражения работают только внутри полей учётных данных, а не в других полях с поддержкой выражений. Зато с помощью переменной окружения `N8N_EXTERNAL_SECRETS_UPDATE_INTERVAL` можно задать, как часто n8n проверяет изменения во внешнем хранилище — по умолчанию каждые 300 секунд.

Какая модель подходит для какой конфигурации

Для небольших команд на практике часто уже достаточно правильно заданного `N8N_ENCRYPTION_KEY` в сочетании с продуманными структурами проектов и совместного доступа: то, кому разрешено видеть какой workflow, автоматически определяет и то, кто может использовать ту или иную учётную запись. Но как только нескольким средам, например staging и production, требуются одни и те же API-доступы, или требование комплаенса предписывает централизованно хранить секреты в одном хранилище и там же централизованно их ротировать, External Secrets становится разумным дополнением. Оба уровня не исключают друг друга и могут комбинироваться: шифрование базы данных защищает то, что n8n хранит сам, а External Secrets дополнительно сокращает то, что n8n вообще должен хранить постоянно.

Если вы хотите развернуть инстанс n8n для команды и с самого начала правильно спланировать шифрование, распределение прав и, при необходимости, внешние хранилища секретов, вы найдёте поддержку у автоматизаций n8n от NordFlux, чтобы конфиденциальные учётные данные с самого начала находились там, где им и место.

Часто задаваемые вопросы

Где n8n хранит автоматически сгенерированный ключ шифрования?

По умолчанию n8n сохраняет ключ, случайно сгенерированный при первом запуске, в папке `~/.n8n` и использует его для шифрования учётных данных перед сохранением в базе данных. Если вы хотите задать ключ самостоятельно, установите переменную окружения `N8N_ENCRYPTION_KEY` перед первым запуском.

Могу ли я предоставить доступ к учётной записи так, чтобы другие не видели API-ключ?

Да, это как раз стандартный случай. Если учётная запись предоставлена пользователю или через проект, этот человек может использовать её в собственных workflow'ах, но сами значения, такие как API-ключи или пароли, при этом остаются скрытыми.

Что произойдёт, если используемая в workflow учётная запись не была предоставлена отдельно?

Если workflow предоставлен в общий доступ, приглашённый пользователь всё равно может полностью его запустить, поскольку совместное использование workflow автоматически включает использование всех содержащихся в нём учётных данных. Однако редактировать соответствующий узел (node) можно только в том случае, если учётная запись была дополнительно предоставлена отдельно; все остальные узлы workflow остаются при этом незатронутыми.

Доступен ли External Secrets на любом тарифе n8n?

Нет. Согласно документации, External Secrets доступен только на тарифах Enterprise Self-hosted и Enterprise Cloud. В настоящее время поддерживаются шесть провайдеров: 1Password, AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault и Infisical.

Можно ли отменить ротацию ключа шифрования?

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