Чтобы процесс сам выгружал заказы из 1С в Битрикс24, платформе нужны ключи от обеих систем. Это первый вопрос, который задаёт любой, кто отвечает за безопасность в компании: где эти ключи лежат, кто может их прочитать и что будет, если утечёт база.
Разберём по слоям, как это устроено в Staqflow. Без маркетинга, на уровне, который можно проверить, но без деталей, которые помогли бы атакующему.
Как Staqflow хранит учётные данные: коротко
Учётные данные в Staqflow - это ключи API, токены OAuth, логины и пароли, через которые процессы подключаются к внешним системам. Они шифруются алгоритмом AES-256-GCM при каждом сохранении, ключ шифрования хранится отдельно от базы данных, а наружу секреты не отдаются никогда: ни в интерфейсе, ни через API, ни ИИ-клиенту по MCP. Учётные данные принадлежат пространству и невидимы из других пространств, а каждое их создание, изменение и удаление пишется в журнал аудита, который нельзя исправить задним числом.
Шифрование в базе
Каждое значение шифруется отдельно, своим случайным вектором инициализации. Даже два одинаковых пароля в базе выглядят по-разному, и по шифротексту нельзя понять, что у двух пространств один и тот же ключ.
Режим GCM добавляет к шифротексту тег целостности. Если кто-то подменит или испортит зашифрованное значение прямо в базе, расшифровка не выдаст мусор, а откажет: подделка обнаруживается.
Ключ шифрования не хранится в базе и не выводится из других секретов платформы. В облаке он лежит в хранилище секретов кластера, отдельно от данных. Отсюда главное следствие: дамп базы данных, резервная копия или доступ на чтение к таблицам дают только шифротекст. Чтобы получить ключи ваших систем, нужно одновременно заполучить и базу, и ключ из другого хранилища.
Если ключ не задан, сервис просто не запускается. Это сознательное решение: лучше упасть при старте и показать ошибку в логах, чем однажды тихо записать секрет открытым текстом.
Что видно в интерфейсе и через API
Самое частое место утечек - не база, а то, что система показывает людям. Поэтому правило простое: секрет, сохранённый однажды, обратно не выдаётся никому.
| Где | Что видно |
|---|---|
| Список учётных данных | Только название, тип и даты. Поле с секретами в выборку не попадает вообще |
| Карточка учётных данных | Структура полей, секретные значения замаскированы |
| Токены OAuth | Только признак «подключено», сам токен не показывается |
| ИИ-клиент через MCP | Может создать учётные данные и привязать их к узлу, но не прочитать |
| Выгрузка процесса в файл | Ссылка на учётные данные и их название, без секретов |
| Журнал и трейсы запусков | Заголовки авторизации, токены и ключи в адресах запросов вычищаются |
Это касается всех, включая администратора пространства. Если ключ нужно поменять, его вводят заново, а не «смотрят старый».
Отдельно о выгрузке процессов в файл: в файл попадает только ссылка на учётные данные и их имя. Файл можно спокойно отправить коллеге или положить в репозиторий. При импорте в другое пространство ссылка оживает, только если там есть учётные данные с таким идентификатором; иначе она снимается с узла, и учётные данные выбирают заново.
Логи и история запусков
Секреты чаще всего утекают через логи: упал запрос, его тело записалось в журнал ошибок вместе с расшифрованным ключом, а журнал уехал в сборщик логов, к которому доступ шире, чем к базе.
В Staqflow перед записью в логи и в трейс запуска из запросов вычищаются заголовки авторизации, поля с паролями, токенами и ключами API, а также ключи, которые некоторые сервисы передают прямо в адресе запроса. Трейс, который вы видите в истории запусков, показывает полный путь данных через узел, но на месте ключа стоит пометка, а не значение.
Правила вычистки поддерживаются по каждой интеграции. У разных сервисов секрет называется по-разному и лежит в разных местах: где-то это заголовок, где-то параметр адреса, где-то поле в ответе на вход. Интеграции из каталога регулярно прогоняются автоматическими проверками, и найденные места, где токен мог попасть в трейс, закрываются как ошибки.
Изоляция пространств
Учётные данные принадлежат пространству. Процесс может использовать только учётные данные своего пространства, а запрос к учётным данным чужого пространства получает ответ «не найдено». Не «доступ запрещён», а именно «не найдено»: по ответу нельзя даже узнать, что такие учётные данные существуют.
Поэтому разным клиентам, подрядчикам или отделам с разными требованиями к доступу лучше заводить отдельные пространства, а не раскладывать всё по папкам одного. Папка упорядочивает, пространство разделяет.
Журнал аудита
Создание, изменение и удаление учётных данных, входы в систему, смена ролей, действия администраторов и выдача доступа по OAuth записываются в журнал аудита вместе с адресом и клиентом, откуда пришёл запрос.
Журнал устроен только на добавление: изменить или удалить строку запрещено на уровне самой базы данных, а не только кодом приложения. Если когда-нибудь понадобится разобраться, кто и когда поменял ключ от 1С, ответ будет в журнале, и задним числом его не поправить.
Периметр вокруг ключей
Шифрование защищает ключи в покое. Но их можно попытаться вытащить и через работающую систему: подсунуть процессу внутренний адрес, выполнить чужой код в узле, перебрать пароли. Здесь работают несколько слоёв.
- Выражения в изолированной песочнице. Выражения вида
{{ $json.поле }}выполняются в отдельной изолированной среде V8 без доступа к окружению сервера. - Защита от запросов во внутреннюю сеть. Узлы не могут обратиться к внутренним адресам инфраструктуры платформы. Проверка встроена прямо в разрешение имён, поэтому её не обойти подменой DNS между проверкой и подключением.
- Ограничение частоты запросов на входе: перебор паролей и попытки завалить сервис отсекаются раньше, чем дойдут до приложения.
- Сессии отзываются при выходе. После выхода токен доступа отзывается на сервере, а не продолжает работать до истечения срока.
- OAuth-доступ ИИ-клиентов честно ограничен. Клиент, которому выдан доступ только на чтение, не получит права на запись, даже если попросит.
- Транспорт. Соединения шифруются по TLS 1.3, для старых клиентов допускается TLS 1.2 с современными шифрами. Браузеру предписано ходить только по HTTPS, страницы платформы нельзя встроить в чужой сайт, а изменяющие запросы с чужих источников отклоняются.
Если облако не подходит
Для компаний, которым ключи нельзя выносить за свой контур, Staqflow ставится на свои серверы на Docker Compose или k3s. Механизмы те же, а ключ шифрования при установке в Kubernetes можно вести во внешнем хранилище секретов, например Vault, а не в самом кластере. Тогда у ваших служб безопасности под контролем и данные, и ключи к ним.
Что можете сделать вы
Платформа отвечает за то, как хранятся ключи. Какие ключи ей доверить, решаете вы, и несколько привычек заметно снижают риск.
- Выдавайте ключи с минимальными правами. Если процесс только читает заказы, ему не нужен ключ с правом удалять клиентов. Большинство сервисов позволяют создать ключ с ограниченными правами.
- Заведите отдельного пользователя для интеграции в 1С, CRM или базе данных, а не подключайте личный аккаунт сотрудника.
- Отдельный доступ для ИИ-клиента. Подключая Claude или Cursor по MCP, выдавайте доступ под задачу и отзывайте, когда он больше не нужен.
- Меняйте ключи по расписанию и сразу, если человек с доступом ушёл из компании. В Staqflow для этого достаточно ввести новый ключ в тех же учётных данных: процессы подхватят его без правок.
- Разносите по пространствам то, что не должны видеть одни и те же люди.
Частые вопросы
Может ли сотрудник Staqflow посмотреть мой ключ
Через интерфейс и API нет: секреты не отдаются наружу никому, включая администраторов. В базе ключ хранится в зашифрованном виде, а ключ шифрования лежит отдельно от неё, так что одного доступа к базе для этого мало. Если ваши требования запрещают доверять ключи даже инфраструктуре поставщика, для этого и существует установка на своих серверах: тогда и база, и ключ шифрования находятся только у вас.
Что будет, если утечёт резервная копия базы
В копии окажется только шифротекст. Без ключа шифрования, который в резервные копии базы не входит, расшифровать его нельзя.
Видит ли ИИ-клиент мои ключи, когда собирает процесс по MCP
Нет. Клиент видит список учётных данных пространства с названиями и типами, может привязать нужные к узлу и создать новые, но прочитать сохранённые секреты не может.
Попадают ли ключи в историю запусков
Заголовки авторизации, токены и ключи API вычищаются из трейса и логов. Учтите, что данные, которые ваш процесс сам кладёт в выход узла, сохраняются как есть: если процесс намеренно передаёт ключ дальше по цепочке, он будет в истории. Хорошая практика - не выводить секреты в данные процесса.
Где физически хранятся данные
Облачная версия размещена в России, заявлено соответствие 152-ФЗ, Staqflow включён в Единый реестр российского ПО (запись № 18374). Для полностью закрытого контура есть установка на своих серверах.
Как поменять ключ, если он скомпрометирован
Отзовите старый ключ на стороне сервиса, создайте новый и введите его в тех же учётных данных Staqflow. Все процессы, которые их используют, начнут работать с новым ключом сразу, без правок в самих процессах. Замена попадёт в журнал аудита.
Попробуйте
- Создайте пространство и подключите первый сервис: поля секретов после сохранения покажутся замаскированными.
- Подключите MCP-сервер к ИИ-клиенту и попросите его показать ваши учётные данные: он увидит названия, но не сами ключи.
- Если нужен закрытый контур, посмотрите установку на свои серверы или напишите нам про требования вашей службы безопасности.