LINUX.ORG.RU

Защита веб-приложения на debian от взлома.

 , , ,


0

2

Всем доброго!
Имеется веб-приложение у которого есть фронтенд и бэкэнд. Фронт и бэк, написаны на некомпилируемых языках js и ts. В качестве браузера используется electron. В качестве ос debian 11. Все это на железном компьютере, к которому имеется доступ пользователя приложением.

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

Рассматривал шифрование, но если делать шифрование по паролю, то придется давать этот пароль пользователю и это бесполезно в этом случае, также бесполезно если будет ключ, его тоже можно будет прочитать, тк, ему все равно для работы нужны 400 права. Пока получается некий сумбур из смеси LUKS и selinux. Хочу узнать, вдруг уже есть некое решение, а я его просто не знаю и не видел.
Для избежания холивара: ЯП не изменить, ос не изменить, пользователю нужен физический доступ к машине обязательно.

Я хз. Скорее всего щас бред напишу) Но что если back запускать под одним юзером, а потом разлогиниваться и логиниться под другим юзером в котором открывать только фронт?

romanlinux ★★★
()
Ответ на: комментарий от Original_1

Это никак не защищает код от прочтения, также не защищает диск от подключения как съемный к другому устройству.
Мы добавим API и токены, но это не решает проблем физического доступа.

Vlan-48
() автор топика

Перенести бэк на удалённый хост, физически недоступный пользователю (как и предполагается в клиент-серверной архитектуре). Ну или всякие непотребства с TPM и тому подобным, не знаю насколько оно вообще работоспособно в линуксе

MrClon ★★★★★
()

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

Vlan-48
() автор топика

Защита веб-приложения на debian от взлома.

обфусцируем, шифруем, привязываем к железке выкладываем на гитхаб, но на#уй никому не нужно

kindof
()

Опять задача XY?

Я так понял, проблема в том, что жалко, если кто-то другой воспользуется интеллектуальным трудом и собственностью?

Так это решается на уровне договора Заказчик-Исполнитель и Работодатель-рабочий. Всё остальное - это костыли.

Понятно, что условия договора зачастую диктует Заказчик и не торопится прописывать свою ответственность.

Действенный метод - писать такой код, что проще его переписать, чем переиспользовать.

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 1)
Ответ на: комментарий от Original_1

Эээ… дать приложению доступ по API

FSM разрисовать вначале, или диаграмму переходов.

токены

Ну, это можно, конечно, если знать алгебру и теорию эллиптических функций.

i_am_not_ai
()
Ответ на: комментарий от Vlan-48

сняв диск

TPM

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

uwuwuu
()

Шифровать аппаратным ключом. Аппаратный ключ аппаратно опломбировать пломбой и печатью организации.

Это не защитит от вынимания ключа, но позволит вставить что-то интересное куда-то тому, кто такое допустил. Обычно этого достаточно.

Aceler ★★★★★
()