Как обеспечить безопасность в связке «64-битная программа + 32-битный COM-прокси»?
Есть 64-битная программа, связывающаяся с 32-битной бухгалтерской системой по COM. Чтобы это как-то работало, мы сделали «прокси» — 32-битную программу, которая через обычную консоль в формате XML передаёт данные 64-битной «мамаше». Бухгалтерская система проверяет, с какой программой связывается, но, разумеется, видит при этом прокси, а не мамашу.
Теоретически возможна такая утечка данных: зловред запускает прокси и тянет данные, сколько душе угодно. Какие сисадминские и программистские меры лучше принять против такого дела?
Пока единственная защита от этого — «неуловимый Джо». Перейти на 64-битный COM невозможно — разработчики бухгалтерской системы просто не предоставили COM-сервера.
Теоретически возможна такая утечка данных: зловред запускает прокси и тянет данные, сколько душе угодно. Какие сисадминские и программистские меры лучше принять против такого дела?
Теоретически утечка данных возможна всегда.
Никому не известно насколько для вас это критично и нужно ли вообще предпринимать меры, и какие именно меры вам нужно предпринимать.
Повторяю. Вижу дыру в безопасности. Ею никто не пользуется, потому что прога редкая, а в сочетании с бухгалтерской системой — совсем редкая.
Как сделать, чтобы только основная программа могла пользоваться COM-прокси?
Прокси будет 32-х битный сервер (в него добавить имеющийся COM-сервер), ваша программа - 64-х битным клиентом.
На github есть готовые обертки клиента и сервера, позволяющие обмениваться готовыми DTO-объектами. Их лучше вынести в 3-ю библиотеку, чтобы сериализации совпадали.
Так и отлаживать, запускать сервер, затем запускать клиент в Debug.
Из сервера можно сделать Windows-сервис потом, когда отладите.
Собственно, когда платформы разные, то для межплатформенного взаимодействия используют (без промежуточного стороннего ПО, такого как серверы приложений, брокеры очереди и т.д.):
- файлы (что успешно вами сделано),
- SharedMemory (когда применимо),
- TCP/IP в чистом виде или на прикладном уровне,
- Pipe.
Всё имеет право на жизнь, но имеет разный уровень масштабируемости.
Если в рамках одной машины и с наименьшим оверхедом, то именованные каналы, так можно сгладить различия битности и платформ разработки.
В частности, так хорошо работает связка WindowsOnly -> DotNetCore (или NetStandard). Это может пригодиться, в том числе, при портировании клиента на другие платформы.
я не понимаю, консоль со строкой подключения к БД? вы же хотели от этого уйти? что через Pipe?
чем короче ответы, тем меньше шансов получить адекватный ответ.
NewDevLab, Основная программа и COM-прокси общаются просто через консоль. Прокси сейчас — консольная программа. Отлаживается легко, но и с безопасностью нехорошо.
NewDevLab, Я погуглил про ACL, и там вижу, что нужна ссылка на пользователя. Откуда и какого пользователя брать, чтобы программа могла говорить от имени этого пользователя, а зловред — нет?
NewDevLab, И ещё одна причина, почему не хочу делать службу. Память не хочу загаживать 90 процентам пользователей, которые с этой бухгалтерской системой вообще не работают.
Простой
