Доступ поддержки вендора

Актуально для: SimpleTwo 0.9.x, координатор с ADR-0052, агент 0.5.118 · Проверено: 07.10.2026

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

он только читает API консоли и ничего не меняет;
он не видит секретов — экраны, где лежат ключи, пароли, токены и расшифрованные данные, для него закрыты;
он заканчивается сам: срок — от одного до трёх лет;
его выдаёт и отзывает только владелец, и каждая выдача, отзыв и использование видны в журнале аудита.

Первый потребитель — продукт SimpleOne VCSM; поле «Вендор» по умолчанию заполнено им.

Выдать токен

Выдаёт только пользователь с ролью owner, вошедший полностью — паролем и кодом второго фактора (или через SSO / identity). Аварийная учётная запись (break-glass) токенов не выдаёт.

Консоль → Settings → карточка «Vendor support access» / «Доступ поддержки вендора». Карточку видят только владельцы.
Issue a token / Выдать токен: имя (например, «поддержка VCSM, обращение 4711»), вендор, цель — обязательна, она попадёт в аудит, — и срок: 1, 2 или 3 года.
Токен вида st_vst_<id>_<секрет> показывается один раз. Скопируйте его кнопкой Copy и передайте вендору по доверенному каналу. Повторно его не показать: потерянный токен отзывают и выдают новый. Хранится только его хеш.

Продлить токен нельзя — по окончании срока выдайте новый.

Через API то же самое (сессия владельца):

curl -fsS -X POST "$S2/admin/api/vendor-tokens" -H "X-Admin-Token: $OWNER_SESSION" \
  -H 'Content-Type: application/json' \
  -d '{"name":"VCSM support","vendor":"SimpleOne VCSM","purpose":"обращение 4711","term_days":365}'

term_days — от 365 до 1095. Список — GET /admin/api/vendor-tokens (без секретов), отзыв — POST /admin/api/vendor-tokens/{id}/revoke.

Как вендор им пользуется

Токен принимается только API консоли — путями /admin/api/*, в заголовке Authorization: Bearer … или X-Admin-Token: …:

curl -fsS "$S2/admin/api/me"       -H "Authorization: Bearer $VENDOR_TOKEN"   # кто я и что могу
curl -fsS "$S2/admin/api/overview" -H "Authorization: Bearer $VENDOR_TOKEN"

Клиентский API (/v1), двери узлов, вход break-glass и API других служб (identity, messaging, почта, файлы) его не принимают.

Что видно и что нет

Токен действует от встроенной роли vendor_support: все права на чтение из каталога (gateways:read, routing:read, users:read, settings:read, audit:read) и ни одного права на запись. Кроме того, любой запрос, кроме GET, отклоняется до обработчика — с единственным исключением: запрос журнала узла (см. «Журналы узлов»).

Закрыты, хотя это чтение, — ответ 403 с кодом vendor_token_forbidden:

Что	Почему
аварийная учётная запись, второй фактор, сами токены вендора	это управление доступом
шифрование: состояние ключа, покрытие, лист восстановления, экспорт сообщений	ключи и данные в открытом виде
коды восстановления гостей (`/admin/api/recovery`)	живые коды
раздача клиентов (`/admin/api/clients`)	токен публикации
карточка развёртывания (`/admin/api/deployments/{id}`) и отрисованные конфиги	строка подключения к базе с паролем, конфиги хостов
автоматизации и их запуски	секреты вебхуков и текст сообщений
прокси к консоли identity (`/admin/api/identity/control/…`)	персональные данные и управление identity
DNS почты (`/admin/api/mail/dns`)	чтение может создать ключ DKIM

Экраны, где секрет только отмечен («задан / не задан»), открыты: SSO, вход, APNs, FCM, ключи ИИ, SimpleOne и HRMS, LDAP, внешние хранилища, TLS. Журнал координатора, аудит и телеметрия клиентов открыты — ради них поддержка и приходит, — но в обезличенном виде (см. «Журналы узлов»).

Журналы узлов

Журналы хостов, отчёты, аудит и телеметрия вендору доступны, но только обезличенные: хосты присылают координатору журналы как есть, администраторы в консоли видят их как есть, а координатор обезличивает всё, что отдаёт токену вендора, — сырой строки вендор не получает.

Обезличиваются для токена вендора: фрагмент журнала узла и строки ошибок в здоровье узла (/admin/api/nodes/{id}/logs, …/health), отчёты хоста (/admin/api/gateways/{id}/reports), журнал координатора (/admin/api/logs), журналы аудита (/audit, /calendar/audit, /agents/audit), телеметрия клиентов (/telemetry, /client-sessions), карантин почты и отказы групп (/mail/quarantine, /mail/group-bounces), живые звонки MCU (/mcu/live), предупреждения (/alerts), строки журнала и ошибки развёртываний в /overview и /servers.

Что заменяется:

Что	Чем
закрытые ключи (PEM), заголовки `Authorization`, `Bearer`/`Basic`, cookie, логин и пароль в URL и строках подключения, токены SimpleTwo (`st_vst_…`, `bot_…`, сессионные токены и JWT), ключи AWS и известных API, значения полей `password=`, `secret=`, `token=`, `api_key=`, `dsn=` и подобных, длинные случайные строки	`[REDACTED:…]`
тема и текст писем и сообщений (`subject=`, `body=`, `text=`, `preview=`…, `Subject:` в журнале почты)	`[REDACTED:text]`
пользователи в полях `user=`, `username=`, `login=`, `account=`, `actor=`, `sub=`, `sender=`, `rcpt=`, `sasl_username=`, `display_name=`…, в `from=`/`to=` с адресом, в строках sshd, postgres, pam и coturn	псевдоним `u-xxxxxxxx`
адреса почты	`u-xxxxxxxx@домен` — домен остаётся; служебные адреса (postmaster, MAILER-DAEMON, abuse, noreply) не трогаются
телефоны (`+…`, российские `8 (9xx) …`, `+7 …`), номер в `sip:`/`tel:`	псевдоним `tel-xxxxxxxx`
IP-адреса	усечение: IPv4 до /24 (`203.0.113.x`), IPv6 до /48 (`2001:db8:1::x`); `127.0.0.1`, `0.0.0.0`, `::1` остаются

Псевдонимы. Псевдоним — первые 8 символов HMAC-SHA256 от значения на ключе установки. Ключ координатор создаёт при первом чтении вендором и хранит у себя как собственный секрет: при включённом шифровании хранения он запечатан мастер-ключом, как ключ учётной записи ACME. Ни один путь API его не отдаёт. Поэтому один и тот же человек во всех журналах установки и в любой день получает один и тот же псевдоним (видно, что в двух ошибках — один пользователь), а вернуть по псевдониму имя без ключа нельзя. Пока шифрование хранения заблокировано (мастер-ключ не загружен), координатор обезличивает временным ключом: псевдонимы меняются после перезапуска, сырым ничего не отдаётся.

Консоль показывает журналы как есть — обезличенный вид существует только в ответах токену вендора.

Что может токен вендора:

запросить журнал юнита — POST /admin/api/nodes/{id}/logs с {"unit":"…","lines":N} — это единственный POST, который пропускает токен вендора; не чаще 4 раз в минуту на токен, каждый запрос — в аудите (node.logs, от имени vendor:<id>, с узлом, юнитом и числом строк). От версии агента на хосте это не зависит;
прочитать ответ — GET /admin/api/nodes/{id}/logs — и здоровье узла в обезличенном виде.

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

Ограничения. Обезличивание — эвристика. Имена в свободном тексте («Иван Петров вошёл»), в именах файлов и в полях, которых нет в списке, не распознаются; имена хостов и пути файлов остаются как есть. Списки пользователей, групп и сессий (/users, /sessions и т. п.) вендор видит как зритель консоли — это не журналы. Поэтому чтение вендором видно в аудите, а токен можно отозвать в любой момент.

Отозвать

В карточке — Revoke / Отозвать в строке токена, затем подтверждение прямо в строке. Доступ пропадает сразу; строка остаётся с отметкой, кто и когда отозвал.

Ответы токену:

Состояние	Ответ
отозван	`401`, `vendor_token_revoked`
срок истёк	`401`, `vendor_token_expired`
неверный или неизвестный	`401`, `vendor_token_invalid`
закрытый путь или не `GET`	`403`, `vendor_token_forbidden`
больше 4 запросов журнала в минуту	`429`

Аудит

Консоль → Logs → журнал аудита:

vendor_token.issued, vendor_token.revoked — всегда, от имени владельца;
vendor_token.used — не чаще раза в час на токен, от имени vendor:<id>, с путём и адресом;
vendor_token.refused — каждая отклонённая попытка: истёкший или отозванный токен, закрытый путь;
node.logs — каждый запрос журнала узла, с узлом, юнитом и числом строк.

В карточке у каждого токена видно время и адрес последнего использования.

Переход на identity

Токены поддержки вендора — собственные учётные данные координатора, а не сессии. Поэтому оба переключателя из перехода на identity — вход (sign_in_mode) и платформенный токен (platform_token) — на них не влияют: выданные токены продолжают работать. После перехода выдавать их по-прежнему может только владелец — он входит через страницу identity, а роль owner координатор берёт из своей проекции identity (роли учётной записи и её групп). Консоль и API самой identity токены вендора не открывают.

Второй фактор в консоли

Двухфакторная аутентификация в консоли обязательна, и с этого выпуска её проверяет сервер, а не только страница. Вход паролем учётной записью без второго фактора (и первый вход после установки) открывает только настройку второго фактора: любой другой запрос к /admin/api получает 403 two_factor_enrollment_required. После подтверждения кода консоль получает полную сессию и открывается. Вход через SSO и через identity эта проверка не затрагивает — второй фактор там у поставщика входа; аварийная учётная запись всегда входит паролем и кодом.

Скрипты, которые входили в консоль одним паролем, теперь должны передавать код (scripts/fetch-geoip-ru.sh — в переменной ADMIN_CODE), а для чтения по расписанию лучше подходит токен поддержки вендора.

Выдать токен​

Как вендор им пользуется​

Что видно и что нет​

Журналы узлов​

Отозвать​

Аудит​

Переход на identity​

Второй фактор в консоли​