Секреты в n8n: как выдать доступ подрядчику и затем безопасно его отозвать

Подрядчик открыл ваш n8n и видит сценарий: вебхук, пара HTTP-узлов, запись в CRM, уведомление в мессенджер. Это ещё не повод отдавать ему серверный терминал. Между «видит и правит workflow» и «может читать всё, что лежит на машине» проходит граница, и в n8n она проходит не там, где её обычно ожидают. Дальше разберём, как дать ровно столько, сколько нужно для одной задачи, и как потом закрыть всё так, чтобы после ухода исполнителя сценарий продолжал работать без его личных ключей.

Разбор ведём на условном примере: фрилансер Игорь дорабатывает один сценарий, который принимает заявки с сайта, обогащает их данными из внешнего сервиса и создаёт сделки в CRM. Он должен поправить маппинг полей, добавить обработку ошибок и проверить работу на тестовых данных. Всё остальное в вашей установке к его задаче не относится.

Что Игорь на самом деле будет делать

Первый шаг — не открывать настройки, а выписать действия. Размытая формулировка «нужен доступ к n8n» почти всегда превращается в доступ ко всему. Конкретный список выглядит иначе:

• открывать и редактировать один workflow;
• запускать его вручную на тестовых данных и смотреть результаты выполнения;
• использовать подключение к CRM, чтобы узел мог создавать сделки, но не обязательно видеть сам токен;
• обращаться к сервису обогащения данных, для которого нужен API-ключ;
• при необходимости добавить новый узел с уведомлением в мессенджер.

Обратите внимание, чего в списке нет: перезапуска сервиса, обновления n8n, чтения переменных окружения, работы с другими сценариями, доступа к базе. Каждый пункт, которого нет в списке, — это то, что подрядчику выдавать не нужно. Если в процессе выяснится, что что-то понадобилось, выдать это можно отдельным решением, а не заранее «на всякий случай».

Второй шаг — для каждого действия определить, какая внешняя система за ним стоит. Правка маппинга затрагивает только сам n8n. А вот тестовый запуск с настоящим подключением к CRM уже способен создать реальные сделки у реальных клиентов. Это важное различие: права в n8n и права во внешних системах — разные вещи, и опасность часто сидит именно во втором слое.

Какие возможности даёт ваша редакция

Дальше нужно сопоставить желаемую картину с тем, что умеет выбранная редакция. По сравнению редакций n8n, в Community нет проектов, совместного использования credentials и external secrets, как нет и внешнего бинарного хранилища. Для нашей задачи это значит вполне конкретные вещи. Если у вас Community, вы не можете аккуратно положить в отдельный проект один сценарий вместе с одним подключением и пригласить туда Игоря. И не можете подключить внешнее хранилище секретов, из которого узлы берут значения, а подрядчик их не видит.

Это не обвинение продукта, а повод трезво выбрать схему. Если вам нужна изоляция по проектам и работа с external secrets, нужно смотреть на редакцию, где эти функции заявлены, и сверять условия на странице сравнения. Если же вы остаётесь на Community, ограничения придётся компенсировать организационно: отдельная установка для подрядчика, отдельные учётные данные во внешних сервисах, жёсткие границы по времени. Обратите внимание: сравнение говорит только о перечисленных возможностях. Вопросы, которых оно не касается, — например, детали ролей пользователей в вашей конкретной версии — стоит проверять в интерфейсе и документации своей версии, а не додумывать.

Там же сказано, что queue mode и multi-main имеют разные условия доступности. Для нашего разговора это важно косвенно: если установка у вас масштабная, с отдельными воркерами, то секреты и ключи живут не в одном месте, и список того, что придётся менять при отзыве, длиннее.

Три слоя, которые легко принять за один

Теперь главное разграничение. Когда говорят «доступ к n8n», подразумевают минимум три разных слоя.

Интерфейс n8n

Это учётная запись в веб-интерфейсе. Подрядчик логинится, видит то, что позволяют его права, правит сценарии, запускает их. Здесь границы определяются возможностями вашей редакции и версии. Отзыв в этом слое самый простой: отключить или удалить пользователя. Но простота обманчива, потому что всё, что человек успел увидеть и скопировать, остаётся у него.

Серверный CLI

Это командная строка, которая работает на самой машине установки. В документации по Server CLI указано, что она выполняется на машине с n8n и имеет прямой доступ к базе, а её модель доступа отличается от удалённого API с пользовательскими правами. Простыми словами: у пользователя интерфейса есть роль, которая что-то разрешает и что-то запрещает, а у человека с командной строкой на сервере такой роли нет — он работает рядом с самими данными.

Отсюда практический вывод для Игоря. Если ему выдан SSH-доступ к VPS «чтобы удобнее было отлаживать», вы фактически вывели его из мира пользовательских прав. Ограничения интерфейса перестают что-либо значить. Для правки маппинга терминал не нужен. Если подрядчик просит его, стоит спросить, какое конкретное действие он собирается выполнять, и чаще всего окажется, что задача решается через интерфейс или через экспорт и импорт workflow.

База данных и файлы окружения

Третий слой — сама база, в которой n8n хранит сценарии, историю выполнений и credentials, и файлы запуска с переменными окружения. Прямой доступ к базе вообще не опирается на логику n8n. А в переменных окружения лежит то, что нужно для работы всей установки, включая ключ шифрования. Доступ к этому слою — это уже административный доступ ко всему, а не «доступ подрядчика к сценарию».

Резюме по слоям удобно держать как лестницу: интерфейс — ограничено правами, CLI — на уровне установки, база и окружение — на уровне всего содержимого. Каждая ступень выше требует отдельного обоснования.

Почему шифрование credentials не спасает от администратора

Частое успокоение звучит так: «Credentials в n8n зашифрованы, значит, даже если человек доберётся до базы, ничего не прочтёт». Это верно лишь отчасти. Как указано в описании ключа шифрования, ключ шифрует credentials перед сохранением в базе. То есть шифруются данные в базе — например, чтобы дамп или чужая копия таблицы не раскрывали токены в открытом виде.

Но сама установка должна уметь расшифровывать их, иначе узлы не смогут авторизоваться во внешних сервисах. Значит, ключ доступен работающему приложению. Тот, кто контролирует сервер и окружение, видит и ключ, и данные. Для доверенного администратора шифрование — не преграда, а лишь слой защиты от других угроз: утечки резервной копии, случайного показа таблицы, чужого дампа.

Есть ещё один нюанс. В queue mode этот ключ нужен всем workers: в документации прямо сказано, что он требуется каждому из них. Значит, копия ключа живёт не на одной машине, а на нескольких, и каждая такая копия — ещё одно место, где его может увидеть человек с доступом к инфраструктуре.

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

Карта доступов для одного подрядчика

Теперь соберём всё в одну таблицу, привязанную именно к Игорю и его задаче. Она нужна не как формальность, а как рабочий документ: по нему вы выдаёте доступ и по нему же закрываете.

Строка про SSH стоит последней и в скобках не случайно: её лучше не заполнять вообще. Но если вы всё же решили выдать терминал, то и строка про завершение оказывается самой тяжёлой — она тянет за собой смену ключа шифрования, перевыпуск credentials и пересмотр содержимого окружения.

Два способа выдать доступ и цена каждого

На практике есть два рабочих подхода, и выбирать между ними стоит по тому, что допускает ваша редакция и насколько вам важна чистота отзыва.

Отдельная песочница вместо вашей боевой установки

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

Цена такого подхода — время на подготовку и необходимость держать тестовые аккаунты в CRM и других сервисах. Выигрыш — резкое сужение того, что можно потерять: при отзыве достаточно удалить песочницу и тестовые ключи, а боевые секреты вообще не покидали вашу зону. Для небольшой задачи отдельный VPS под песочницу — естественное решение: машина изолирована от основной установки и её можно удалить целиком, когда работа закончена. У MAATRIX в публичном предложении указаны NVMe, AMD EPYC и root-доступ, а в каталоге заявлены n8n и Nextcloud с установкой; наличие образа и операционной системы нужно уточнять в форме заказа. Для одного сценария с лёгкой нагрузкой хватит и самого скромного тарифа Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe), хотя ёмкость под вашу реальную нагрузку стоит проверять отдельным замером, а не по цифрам в списке.

Работа в основной установке с ограниченным интерфейсом

Второй путь — оставить Игоря в вашей боевой установке, выдать учётную запись и использовать существующие подключения. Это быстрее, но с ограничениями. Если у вас Community, проектов и совместного использования credentials нет, то ограничить его одним сценарием средствами продукта вы не сможете; нужно заранее понимать, что права определяются тем, что есть в вашей версии, и сверять их в интерфейсе. Чаще всего придётся компенсировать это договорённостями и отдельными внешними ключами.

Главное правило этого пути: не отдавать подрядчику ваши общие токены. Для него заводятся отдельные ключи в CRM и сервисе обогащения с минимально необходимыми правами. Тогда отзыв сводится к удалению этих ключей, а не к смене того, чем пользуется вся компания.

Если нужен более общий разговор о том, как строить автоматизации в n8n на собственном сервере и какие ресурсы им нужны, он есть в материале про ИИ-автоматизации в n8n на VPS.

Отдельные ключи вместо общих: как это выглядит на практике

Принцип «один подрядчик — один набор внешних ключей» кажется бюрократией, пока не наступает время отзыва. Представим два варианта.

В первом Игорь использует тот же токен CRM, которым пользуются ещё три сценария и менеджеры через интеграцию. Чтобы закрыть его доступ, нужно перевыпустить токен и найти все места, где он указан. Если хоть одно пропущено, какая-то автоматизация тихо перестанет создавать сделки — и вы узнаете об этом по жалобам.

Во втором у Игоря свой токен с правом создавать сделки в одной воронке. Его отзыв ничего не ломает: боевой сценарий работает на другом ключе, который вы подставили сами после приёмки. Стоимость второго варианта — десять минут на выпуск отдельного ключа в начале. Выгода — спокойный и предсказуемый финал.

Тот же принцип относится к сервису обогащения. Если там предусмотрены отдельные ключи, заведите отдельный; если сервис выдаёт один ключ на аккаунт, оцените, готовы ли вы менять его целиком по завершении работ. Это решение лучше принять до начала, а не в день окончания договора.

Когда работа закончена: обход по списку выданного

Отзыв доступа удобно вести не по памяти, а по той самой таблице. Порядок важен: сначала вы убеждаетесь, что боевой сценарий не зависит от личных доступов Игоря, затем закрываете то, что выдавали.

1. Сверьте, на чём реально работает сценарий. Откройте workflow и проверьте каждый узел с подключением: какие credentials он использует. Если где-то остались ключи, выпущенные для Игоря, замените их на боевые ещё до отзыва.
2. Найдите всё, что Игорь добавил сам. Новые узлы с уведомлениями, дополнительные вебхуки, вспомогательные сценарии, временные расписания. Оставленная автоматизация — самый частый «забытый секрет»: она может продолжать ходить во внешние системы по расписанию и после его ухода.
3. Отзовите внешние токены. В CRM, сервисе обогащения, мессенджере — везде, где для него заводились отдельные ключи. Сначала подставьте новые в боевой сценарий, потом удаляйте старые, чтобы не получить простой.
4. Закройте интерфейс. Отключите или удалите учётную запись в n8n.
5. Закройте сервер, если он выдавался. Уберите его ключ из списка разрешённых и проверьте, нет ли других способов входа, которые вы создавали на время работ.
6. Решите, нужна ли ротация шифрования и секретов окружения. Если серверного доступа не было, чаще всего достаточно замены внешних ключей. Если был — исходите из того, что окружение ему было видно, и меняйте всё, что в нём лежало.

О ключе шифрования отдельно. Он защищает credentials в базе, и если Игорь мог его прочитать, то смена ключа — часть закрытия доступа. Но это не одна строчка в настройках: credentials, сохранённые под старым ключом, нужно переносить аккуратно, а в queue mode новое значение обязано оказаться у всех workers. Подробную процедуру смены ищите в документации своей версии и репетируйте её на копии, а не на боевой установке. Здесь важно только одно: не откладывайте это решение, когда выдаёте серверный доступ.

Что отзыв не сделает

Стоит трезво понимать пределы. Отзыв доступа не удаляет то, что человек уже увидел или скопировал. Если он видел значение секрета, то отзыв сводится к тому, чтобы это значение перестало работать, — то есть к замене на новое. Поэтому правильная формулировка задачи звучит не «закрыть Игорю доступ», а «сделать так, чтобы всё, что он мог знать, стало бесполезным».

Также отзыв не защищает от того, что сценарии, которые он написал, делают нечто неожиданное. Проверьте результат: просмотрите логику, особенно узлы с HTTP-запросами наружу и узлы выполнения кода. Нужно понимать, куда уходят данные и почему. Это не недоверие к человеку, а обычная приёмка чужой работы — как код-ревью.

И наконец, не стоит надеяться, что где-то есть режим, который сам всё ограничит. Что именно умеет ваша версия по ролям и разделению доступа, смотрите в интерфейсе и документации. Там, где защитного механизма нет, его заменяет процесс: отдельная песочница, отдельные ключи, срок действия.

Финал: сценарий, который живёт без Игоря

Проверка того, что всё сделано правильно, проста и наглядна. После отзыва запустите боевой сценарий тестовой заявкой с сайта. Она должна пройти путь целиком: вебхук принимает данные, сервис обогащения отвечает на ваш ключ, CRM создаёт сделку от вашей интеграции, уведомление приходит в ваш канал. Если на каждом шаге в журнале выполнения используются ваши подключения, а ни одной учётной записи или токена Игоря в системе больше нет, работа завершена.

Теперь представьте, что Игорь пропал, сменил почту или просто потерял ноутбук. Для сценария ничего не меняется: он не ходит по личным ключам и не завязан на чей-то терминал. Если в карте доступов напротив каждой строки стоит отметка «прекращено», а боевые подключения заменены на ваши, подрядчик остался в истории проекта как автор хорошей работы, а не как скрытая зависимость. Именно такой результат и стоит считать успешным завершением.