Как надежно идентифицировать базу-инициатора при соединении с HTTP-сервисом 1С?

В современной практике интеграции систем часто возникает сложная архитектурная задача: необходимо обеспечить обмен данными между двумя базами 1С (назовем их БД1 — приемник и БД2 — отправитель) таким образом, чтобы принимающая сторона могла гарантированно подтвердить личность отправителя. Ситуация осложняется тем, что в БД2 разработчики имеют полный доступ к конфигуратору, а значит, любые статические пароли, заголовки или простые алгоритмы шифрования, написанные на языке 1С, могут быть подсмотрены и скомпрометированы. Рассмотрим способы решения этой проблемы, переходя от простых организационных мер к сложным криптографическим методам.

Ограничение на уровне сетевого экрана и веб-сервера

Проанализируем самый очевидный и в то же время эффективный способ — фильтрацию входящего трафика. Если БД1 и БД2 являются корпоративными системами, логично предположить, что они имеют фиксированные IP-адреса. Вместо того чтобы пытаться реализовать проверку внутри кода 1С, мы можем перенести эту задачу на уровень инфраструктуры.

Рассмотрим порядок действий при использовании веб-сервера (например, Apache или IIS):

1. Настроим веб-сервер, на котором опубликована БД1, таким образом, чтобы он принимал входящие запросы к публикации HTTP-сервиса только с IP-адреса сервера, на котором развернут кластер БД2.
2. Дополнительно можно использовать WAF (Web Application Firewall) для более глубокого анализа пакетов.

Преимущество: Разработчик БД2, даже имея доступ к конфигуратору, не сможет отправить запрос со своего рабочего ПК, так как сервер БД1 просто отклонит соединение по IP. Однако этот метод не защищает, если злоумышленник напишет обработку прямо в БД2 для несанкционированной выгрузки данных.

Использование двустороннего TLS (mTLS) и сертификатов

Выясним, как использовать механизмы операционной системы для защиты соединения. Вместо обычной авторизации по логину и паролю, мы можем использовать сертификаты. В 1С объект HTTPСоединение позволяет указывать сертификат клиента.

Разберем алгоритм настройки:

1. Для БД2 выпускается уникальный клиентский сертификат.
2. Секретный ключ этого сертификата устанавливается на сервере 1С (где работает БД2) в хранилище сертификатов Windows/Linux под учетной записью, от которой запущен rphost. Важно: при установке в Windows необходимо снять флаг "Разрешить экспорт закрытого ключа".
3. В коде 1С при создании соединения мы обращаемся к этому сертификату.

Посмотрим на пример инициализации такого соединения:

Сертификат = Новый СертификатКриптографии(ОтпечатокСертификата);
ЗащищенноеСоединение = Новый ЗащищенноеСоединениеOpenSSL(Сертификат);
Соединение = Новый HTTPСоединение("server1c.db1.com", , "user", "pass", , , ЗащищенноеСоединение);

В этой схеме, даже если программист БД2 увидит код, он не сможет скопировать закрытый ключ сертификата на другое устройство, так как ОС запрещает его экспорт. Проверка на стороне БД1 (веб-сервера) будет гарантировать, что запрос пришел именно от владельца закрытого ключа.

Вынос логики авторизации во внешнюю компоненту (DLL)

Проанализируем ситуацию, когда нам нужно скрыть сам алгоритм формирования подписи запроса. Поскольку встроенный язык 1С открыт для чтения в конфигураторе, мы можем реализовать критически важный функционал на языке C++ или C# и подключить его как внешнюю компоненту Native API.

Рассмотрим, что именно стоит вынести в компоненту:

• Генерация динамического хэша на основе текущего времени, параметров запроса и "соли".
• Обращение к защищенным хранилищам данных, недоступным из обычного кода 1С.
• Алгоритмы асимметричного шифрования (например, формирование цифровой подписи запроса по стандарту RS256).

В коде 1С это будет выглядеть как вызов одной функции:

ПодключитьВнешнююКомпоненту("ОбщийМакет.КомпонентаЗащиты", "SecurityLib");
Компонента = Новый ("AddIn.SecurityLib.Validator");
ТокенЗащиты = Компонента.СформироватьПодписьЗапроса(ДанныеЗапроса);
// Далее ТокенЗащиты добавляется в заголовок HTTP-запроса

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

Реализация асинхронного подтверждения (Callback)

Рассмотрим хитрый способ, упомянутый в обсуждении, который позволяет избежать передачи паролей в открытом виде. Суть метода заключается в том, что БД1 сама проверяет подлинность намерения БД2.

1. БД2 отправляет в БД1 короткий запрос-уведомление: "Я хочу получить данные, вот мой временный ID сессии".
2. БД1 не отдает данные сразу. Вместо этого она сама инициирует обратный HTTP-запрос к БД2 по заранее жестко прописанному адресу (который знает только администратор БД1).
3. БД1 спрашивает у БД2: "Это ты сейчас запрашивал данные с ID таким-то?".
4. Если БД2 подтверждает запрос в своем внутреннем контексте, БД1 завершает первый запрос и отдает данные.

Этот метод исключает возможность подделки запроса сторонней программой, так как сторонняя программа не сможет принять входящий подтверждающий вызов от БД1 на порту сервера БД2.

Передача данных между сеансами без записи в БД

Одной из проблем при реализации сложных схем проверки является передача информации между сеансом HTTP-сервиса и основным сеансом пользователя (или фоновым заданием). Как было отмечено, запись в справочники или регистры нежелательна из соображений безопасности.

Для решения этой задачи мы можем использовать Внешнюю компоненту с синглтоном. Поскольку внешняя компонента, загруженная в рамках процесса rphost, может хранить статические переменные в оперативной памяти сервера, она становится идеальным "буфером":

1. Сеанс HTTP-сервиса принимает данные и передает их в метод компоненты ЗаписатьВПамять(Ключ, Значение).
2. Другой сеанс (например, фоновое задание, ожидающее результат) вызывает метод ПрочитатьИзПамяти(Ключ).
3. Данные не касаются диска и исчезают при перезагрузке рабочего процесса или удалении компоненты.

Резюме

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