Учётные данные в Staqflow: шифрование, изоляция и аудит

Автоматизация обмена заказами между 1С и CRM требует доступа к обеим системам. Важно понимать, где сохраняются ключи API, кто может прочитать токены и какие данные остаются после запуска workflow. В публикации от 30 октября 2026 года Staqflow описывает защиту учётных данных на нескольких уровнях: шифрование, изоляцию пространств, ограничения интерфейса и API, очистку логов и аудит. Ниже — разбор этих механизмов и границ их применения по описанию поставщика.

Что относится к учётным данным

Учётные данные — это ключи API, токены OAuth, логины и пароли для подключения к внешним сервисам. Они принадлежат пространству и используются его процессами. Сохранённый секрет не возвращается через интерфейс, API или MCP, в том числе администратору пространства. При замене нужно ввести новый ключ: посмотреть прежнее значение таким способом нельзя.

Это ограничение относится к чтению через пользовательские интерфейсы и API. Оно не означает, что инфраструктура платформы не использует секрет при выполнении запроса: для подключения к внешнему сервису работающей системе нужен доступ к учётным данным. Компаниям, которым нельзя доверять ключи инфраструктуре поставщика, предназначена установка в собственном контуре.

Как работает шифрование AES-256-GCM

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

Ключ шифрования хранится отдельно от базы и не выводится из других секретов платформы. В облаке используется хранилище секретов кластера. Дамп, резервная копия базы или чтение таблиц сами по себе дают шифротекст; для расшифровки дополнительно нужен ключ из другого хранилища. Если ключ шифрования не задан, сервис не запускается и сообщает об ошибке в логах, чтобы не сохранять секреты открытым текстом.

Что показывают интерфейс, API и MCP

В списке учётных данных видны название, тип и даты. Поле с секретами вообще не включается в выборку. Карточка показывает структуру полей, но секретные значения замаскированы. Для OAuth отображается состояние «подключено», без самого токена.

ИИ-клиент через MCP может увидеть названия и типы учётных данных пространства, создать новые и связать их с узлом. Прочитать ранее сохранённые секреты он не может. Это важно отличать от создания учётных данных, при котором пользователь сам передаёт новое значение выбранным способом. При подключении Claude, Cursor или другого клиента следует выдавать права под конкретную задачу; OAuth-доступ только на чтение не разрешает запись даже по запросу клиента.

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

Логи и история запусков: что очищается и где есть ограничение

Перед записью запросов в логи и трейс запуска Staqflow очищает заголовки авторизации, поля с паролями, токенами и ключами API, а также ключи в адресах запросов. В истории сохраняется путь данных через узел; вместо распознанного секретного значения показывается пометка.

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

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

Пространства разделяют доступ, папки упорядочивают процессы

Процесс использует учётные данные только своего пространства. Запрос к учётным данным другого пространства возвращает «не найдено», а не «доступ запрещён»: ответ не подтверждает само существование чужой записи.

Для разных клиентов, подрядчиков или отделов с разными требованиями к доступу подходят отдельные пространства. Папки workflow помогают навести порядок внутри пространства, но не заменяют разделение доступа.

Какие события попадают в журнал аудита

Журнал фиксирует создание, изменение и удаление учётных данных, входы, смену ролей, действия администраторов и выдачу OAuth-доступа. Вместе с событием сохраняются адрес и клиент, откуда поступил запрос.

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

Защита работающей системы

Шифрование в базе дополняется ограничениями при выполнении процессов.

Выражения и сетевые запросы

Выражения вида {{ $json.поле }} исполняются в отдельной изолированной среде V8 без доступа к окружению сервера. Узлам запрещены обращения к внутренним адресам инфраструктуры платформы. Проверка встроена в разрешение имён, чтобы исключить обход подменой DNS между проверкой адреса и подключением.

Вход, сессии и транспорт

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

Соединения используют TLS 1.3. Для старых клиентов допускается TLS 1.2 с современными шифрами. Браузеру предписано использовать HTTPS; страницы платформы защищены от встраивания в чужой сайт, изменяющие запросы с чужих источников отклоняются.

Облачное размещение и собственный контур

В исходной статье указано размещение облака в России, заявлено соответствие 152-ФЗ и включение Staqflow в Единый реестр российского ПО, запись № 18374. Эти сведения приведены как заявления поставщика на дату публикации.

Если ключи и данные должны оставаться внутри инфраструктуры компании, предусмотрена установка Staqflow на своих серверах с Docker Compose или k3s. Механизмы защиты сохраняются. При установке в Kubernetes ключ шифрования можно вести во внешнем хранилище секретов, например Vault, отдельно от кластера. В этом варианте компания контролирует и базу, и хранилище ключа.

Что проверить при подключении и замене ключей

1. Создать отдельного пользователя интеграции в 1С, CRM или базе данных. Личный аккаунт сотрудника для этого не использовать.
2. Выдать минимальные права. Процессу чтения заказов не нужны права удаления клиентов.
3. Разделить по пространствам системы и процессы, доступ к которым должен быть у разных людей. Отдельно настроить и при необходимости отозвать доступ ИИ-клиента.
4. После сохранения убедиться, что поля замаскированы, а в списке и через MCP доступны только разрешённые сведения. Для проверки использовать тестовые данные, не выводя рабочий секрет в результат узла.
5. Проверить выходы узлов и историю запусков: рабочие ключи не должны намеренно передаваться в обычных полях данных.
6. Менять ключи по графику и при изменении состава сотрудников с доступом. При компрометации сначала отозвать старый ключ на стороне сервиса, создать новый и сохранить его в тех же учётных данных Staqflow.

Процессы, использующие эту запись учётных данных, подхватывают новый ключ без редактирования самих workflow. Замена отражается в аудите. Так проверка охватывает не только хранение, но и права, исполнение и следы работы интеграции. Общая информация о системе — на странице платформы STAQ.

Подробнее о возможностях автоматизации — на сайте Staqflow.