Есть БД1, у нее, допустим, есть http-сервис. Есть БД2, из нее посылается запрос по этому сервису. БД1 принимает запрос, и требуется видеть, что запрос послан именно из БД2, а не сторонней программой, системой.
ВАЖНО, данные отправителя нужно чтобы нельзя было подделать. Т.е. добавить заголовки вроде "источник"-"БД2" и отправить запрос откуда угодно - не подойдет.
Скорее всего, средствами 1С сделать такое возможности нет. Но может есть какой хитрый способ, вроде COM-соединения, ODATA или еще как.
Главная цель - создать закрытое соединение между базами, чтобы в базу с данными нельзя было подсоединиться из других баз программисту.
БД1 - закрыта для широкого круга разработчиков, БД2 - доступна для широкого круга.
---
Придумал вот что, прошу развить:
Т.к. БД1 закрыта для всех, то она будет отправлять данные по определенному адресу в БД2. БД2 перед этим отправляет команду на это действие:
1. БД2 отправляет запрос в БД1
2. БД1 отправляет запрос ТОЛЬКО в БД2
3. БД2 принимает данные с нужной информацией из БД1
4. Полученную информацию в сеансе HTTP сервиса нужно передать внутри БД2 в сеанс, откуда все началось.

Вот четвертый пункт интересный, я пока не знаю как передавать данные между сеансами, не сохраняя их в файлы и БД
---
Создать еще одну БД3 1С, в ней периодически генерить и хранить текущий пароль определенного пользователя к БД1.
Из БД2 запрашивать пароль у БД3 для доступ к БД1.
Доступ к БД3 не давать никому.
---
Так а что мешает, при наличии полного доступа к БД2, подсмотреть параметры обращения к БД3 и подделать их?
---
как минимум - сменяемый пароль в виде хэша
а так да, против лома сложно найти прием.
---
Поставить на http-сервис логин/пароль и никому его не давать, кроме как БД2?

Или предполагается, что в БД2 есть доступ в конфигуратор и его подсмотреть могут?
---
Да, проблема в том, что есть доступ в конфигуратор БД2.
---
варианты:
1. забрать доступ бд2.
2. сделать запароленный модуль в котором проверяется пароль.
---
Может это поможет: https://its.1c.ru/db/v8std/content/740/hdoc
---
Вероятно что-то типа такого, через сертификаты.
https://infostart.ru/1c/articles/1564337/

Для БД2 поднять отдельную службу сервера, с отдельным пользователем, ему поставить сертификат. Обращаться к сервису только из серверного контекста.

Соответственно, не работает, если будут права создать новую базу на этом же сервере 1С.

UPD: сертификат программно тоже можно получить при наличии полных прав, так что, вероятно, и это не подойдет.
---
Можно еще на уровне вебсервера указать только один IP-адрес(адрес сервера 1С БД2), с которого может быть подключение к БД1.
---
Придумал вот что, прошу развить:
Т.к. БД1 закрыта для всех, то она будет отправлять данные по определенному адресу в БД2. БД2 перед этим отправляет команду на это действие:
1. БД2 отправляет запрос в БД1
2. БД1 отправляет запрос ТОЛЬКО в БД2
3. БД2 принимает данные с нужной информацией из БД1
4. Полученную информацию в сеансе HTTP сервиса нужно передать внутри БД2 в сеанс, откуда все началось.

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

1. Сделали вызов из БД2 в БД1, в ответ получились некий ID, завершили соединение.
2. БД1 подготовила данные, передала их в БД2, в БД2 в некий регистр сложили данные с этим же ID.
3. БД2 периодически проверяет наличие записи в регистре с нужным ID, при появлении идет дальше по алгоритму.
---
Только вот запись в некое хранилище нельзя делать. Цель - держать конфиденциальную информацию только в переменных на время выполнения. Запись информации куда-либо недопустима.
Вот курю бамбук...
---
если совсем серьезно подходить...
то далее упретесь в теорию чисел и методы высшей математики.
там идея что есть два простых! числа (знаков ~250) A и Б и их произведение. данное произведение однозначно раскладывается на А и Б. в общем небольшое отклонение на Q от произведения.
приводит к тому что найти обратное решение - задача решаема, но время трудозатрат более 100 лет.

т.е. есть А*Б + Q = С - посылаем С. надо найти А Б. - Q ключ который позволяет быстро найти их - он зашифрован и никуда не передается.
---
По моему данная коллизия не решаема т.к. априори подразумевается не надёжность источника данных.
Мне видится решение - В первую очередь необходимо уверенность в безопасности источника, если мы уверены что безопасность не поколебима, то делаем DLL в нее зашиваем алгоритм генерации Хэш суммы на основании например имени базы данных, даты пакета, номера пакета.
Далее в приемники аналогичная DLL генерирует хэш суммы на основании принятого пакета и сверяет ее.
---
Хорошая идея, спасибо. Придется студию ставить...