Криптирана база данни - мотики за настъпване?

Смятам да си поиграя малко с SQLeet - свободна, криптирана версия на SQLite. Става въпрос за AsmBB.

Не съм правил досега уеб приложение с криптирана база данни. Идеята е, даже при хакване на сървъра (или недобросъвестни хостер провайдери) да не може да се получи достъп до данните в базата данни. Или поне при изтичане на въпросната база данни като файл.

Та въпросът е – на какви мотики да не настъпя поне на първо време. И въобще, реално ли е да се достигне такава сигурност, или на чужд хардуер няма въобще никакво спасение?

Според мен би имало смисъл само ако паролата се въвежда "на място" от усера.
В противен случай паролата се пази някъде, демек при хакване пак ще се види.

Мен ако питаш, няма особен смисъл.

Това мнение е било редактирано от dvader на 18-09-2019, 14:53

Да, безспорно. Но тъй като приложението е постоянно работещо, то това може да се организира даже през уеб интерфейса.

Неудобството ще бъде, че при рестарт на сървърите, администраторът ще трябва първо да въвежда парола в специална уеб страница, иначе нищо няма да работи. Но това се случва реално рядко. Примерно веднъж в месеца.

Така че, паролата е сравнително лесно да се съхранява само в RAM паметта. И това би трябвало да е памет, която не се суапва никога. Но това зависи от SQLeet-а, а как е написано там, това не го знам.

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

Но на мене не ми е ясно например дали това може да се направи откъм физическите сървъри или непременно трябва да е отвътре на виртуалната машина?

Има нещо или всичко сбъркано ми се струва. Трябват асиметрични ключове които работят САМО на този сървър. Някой ако ги гепи може да си ги завре където иска или може.

А малко по-подробно? Какво значи "асиметрични ключове" в контекста на криптирана база данни SQLite???

sqleet е за ембедед системи.

Ми не.

Не е реално постижимо. Стъкснет червея от 2010 прониква във физически защитени машини. Ако някой е мотивиран, то ще намери начин.

Идеята ти за искане на парола при старт е добра. Дори и паролата да се слага в разменяемата памет на харда, пак ще е малко по-трудно от липсата на каквито и да е прегради. Това е добре начало.

Това мнение е било редактирано от SuN на 18-09-2019, 18:42

Задачката е почти безсмислена. Криптирането на самия сторидж (базата данни) има ефект в някои доста ограничени ситуации. А шанса за изтичане на ключа там е доста голям.

От друга страна - пробойните по sql сървърите се състоят основно в sql инжекции. Което значи, че ако те пробият така базата данни ще изтече, независимо дали си криптирал целия файл/сторидж. Тук влиза и директен достъп до вече отключена база данни (било локално или отдалечено).

Решението на тоя проблем е криптиране на самите данни. Недостатък е загубата на възможност за индексиране/търсене. Затова трябва да намериш баланс между това кои данни да криптираш, кои да хешираш и кои да оставиш в чист текст.

Та ако ще тръгваш по тоя път, първо трябва да се погрижиш за криптиране на данните и чак след това да мислиш за криптиране на носителя и разбирасе на връзката между базата данни, драйвера и приложението.

Това мнение е било редактирано от thrawn на 18-09-2019, 19:10

Е, в моя случай SQL инжектиране е невъзможно въобще. Така че, откъм мрежата базата данни е в безопасност. Идеята е и от към сървъра да е в безопасност.

Но май това е въобще невъзможно... Доколкото разбирам, RAM паметта винаги е достъпна от към сървъра, така че (поне теоретично) ключът може да се намери в нея. Друг е въпросът колко лесно е това... Май ще трябва да гледам сорсовете ...