Как организовать изолированную среду выполнения собранного dotnet приложения?
Наша команда разработчиков пишет продукт для клиента на .NET, в результате после сборки конечных артефактов возникает большое количество .dll файлов, которые по хорошему должны запускаться на инфраструктуре клиента.
Мы заботимся о сохранении кода и защиты его от утечек. Dll файлы же никак не защищены. Подскажите пожалуйста, я уверен такая утилита есть, как организовать защищённый контейнер (на подобие докеров) только без возможности обратного инжиниринга.
Фактически при запуске этого контейнера, dotnet подтягивался бы в этой изолированной среде, а пробрасывались только порты, необходимые для взаимодействия через REST например. При этом нельзя было бы получить доступ к виртуальной файловой системе контейнера и как либо профилировать оперативную память.
Пожалуйста, не предлагайте обусцификаторы :)
Код скрываем мы по той причине, что приложение и его функционал очень актуальны в нашей занятой нише.
Обфускатор явно лучше, чем его отсутствие. Вы всерьёз верите, что кто-то станет тратить время, чтобы разобраться в иероглифах? Иногда в готовом проекте сложно разобраться, я бы не полез в обфусцированный код. Быстрее с нуля написать, думаю. Я не отговариваю вас от поиска решения, которое вы ищете в вопросе. Так, просто решил написать своё мнение по поводу обфускаторов, которые ещё умеют вставлять в код множество go to, в этом адище вообще потом не разобраться будет.
Борис Животное,
Это очень актуальный вопрос, и это важная причина, по которой ИТ-компании во всем мире переносит все на технологию, основанную на контейнерах. Мы производим очень сложную и чрезвычайно чувствительную с финансовой точки зрения торговую платформу. Должен быть нулевой риск того, что любой заказчик сделает что-то, чего он не должен делать с продуктом, который он покупает. Неважно, сколько каждый клиент платит за услугу. Они просто платят за отдельные лицензионные копии. Все внутри контейнера, который они получают, должно быть безопасным. Всё должно запускаться в изолированной среде выполнения, без возможности профилирования оперативной памяти, доступа к "внутренней кухне контейнера" и его файловой системы.
Кажется, что прощё сделать софт как SaaS, а хостинг на серверах заказчика сделать только для тех ситуаций, когда это заказчику действительно необходимо и за индивидуальный прайс.
Даже в случае утечки будет сразу ясно, кто это сделал и набутылить.
А полностью защищённый контейнер - это физический сервер, к содержимому файловой системы которого человек со стороны не будет иметь доступ совсем.
Никакие софтовые решения (обфускация, контейнеры, шифрованные виртуалки, передача критичного исполняемого кода по сети) не спасут от тех людей, которые хотят с вами конкурировать или осознанно хотят нарушить соглашения.
Это очень актуальный вопрос, и это важная причина, по которой ИТ-компании во всем мире переносит все на технологию, основанную на контейнерах. Мы производим очень сложную и чрезвычайно чувствительную с финансовой точки зрения торговую платформу. Должен быть нулевой риск того, что любой заказчик сделает что-то, чего он не должен делать с продуктом, который он покупает. Неважно, сколько каждый клиент платит за услугу. Они просто платят за отдельные лицензионные копии. Все внутри контейнера, который они получают, должно быть безопасным. Всё должно запускаться в изолированной среде выполнения, без возможности профилирования оперативной памяти, доступа к "внутренней кухне контейнера" и его файловой системы.
ИТ-компании во всем мире переносит все на технологию, основанную на контейнерах.
Переход на контейнеры идёт не за тем, чтобы как-то оградить потребителя от исполняемого кода, а чтобы упростить и унифицировать развёртывание.
Должен быть нулевой риск того, что любой заказчик сделает что-то, чего он не должен делать с продуктом, который он покупает
Поставляйте готовый железный сервер-чёрный ящик у которого будет только ethernet для подключения к сети и разъёмы для питания.
Так много кто в финансовом/банковском секторе делает.
Всё должно запускаться в изолированной среде выполнения, без возможности профилирования оперативной памяти, доступа к "внутренней кухне контейнера" и его файловой системы.
ИМХО вариант только хостить у себя.
Всякая виртуалка в шифрованном томе не выход, т.к. чтобы оно запустилось, у клиента так или иначе должен быть ключ.
Код скрываем мы по той причине, что приложение и его функционал очень актуальны в нашей занятой нише
В таком случае вы очень неудачно выбрали язык. NET прекрасно декомпиллируется практически до идеинтичных исходников бесплатными утилитами. Поэтому единственный выход = хостить у себя.
Простой
Сложный
Сложный
Простой
