Перейти к содержимому

JWT для машинных интеграций

Рекомендация

#аутентификация #безопасность #http

Рекомендация

Для машинных интеграций «от лица пользователя» через HTTP/Web-сервисы вместо хранения логина/пароля использовать JWT (поддержка с 8.3.21). Ключи асимметричные, приватный ключ не хранится в исходниках/конфигурации, ротация по регламенту с перекрытием периодов действия.

Асимметричная подпись (проверка по публичному ключу на стороне 1С).
Приватные ключи — в защищённом хранилище секретов, не в текстовых файлах конфигурации и не в git.
Ротация ключей по регламенту, со стадией двойного перекрытия (старый + новый валидны), чтобы не ронять интеграции в момент смены.

Зачем

JWT применим в HTTP-сервисах, Web-сервисах и при подключении к ИБ через интернет тонким/веб-клиентом — заменяет логин/пароль подписанным токеном и снимает с интеграции необходимость хранить пароль учётки. Пароль учётки — долгоживущий секрет, который надо где-то хранить и ротировать вручную; JWT короткоживущий и отзывается сменой ключа.

// Логин/пароль учётки зашиты в код вызывающей системы:
// утечка = полный доступ, ротация = правка кода у всех потребителей.
Соединение = Новый HTTPСоединение("erp.example.ru", 443,
    "ИнтеграцияРобот", "P@ssw0rd");

// Вызывающая система подписывает короткоживущий JWT приватным ключом
// (ключ — в хранилище секретов); 1С проверяет подпись по публичному ключу.
Запрос = Новый HTTPЗапрос("/hs/api/v1/orders");
Запрос.Заголовки.Вставить("Authorization", "Bearer " + ПодписанныйJWT);

На стороне 1С у технического пользователя включается признак «Аутентификация токеном доступа» (это один из auth-флагов пользователя ИБ), роль — минимальная под задачу (см. техпользователь).

Гигиена токена

Короткий срок жизни. exp — минуты, не часы: токен перевыпускается на каждый сеанс работы, утёкший токен быстро протухает.
Payload — не хранилище секретов. Содержимое JWT только закодировано base64, но не зашифровано: ПДн, пароли, внутренние идентификаторы в клеймы не кладутся.
kid в заголовке. Идентификатор ключа позволяет ротацию с перекрытием: принимающая сторона держит старый и новый публичные ключи одновременно и выбирает по kid.

Регламент ротации фиксируется, а не «когда вспомним»:

Параметр	Что фиксируем
Период ротации ключей	например, раз в N месяцев + внеплановая при подозрении на утечку
Окно перекрытия	сколько времени валидны оба ключа (старый + новый)
Владелец	кто выпускает ключи и уведомляет потребителей
Проверка после смены	какие интеграции прогнать после ротации

Когда не применять

JWT не решает интерактивный вход в конфигуратор на RDS (там — аутентификация ОС; автономный сервер конфигуратор не поддерживает). Это про каналы HTTP/web/тонкий веб, а не про толстый клиент и конфигуратор.

См. также