Кратък отговор
Не можете.
Ако паролата се съхранява в артефакта, който се изпраща до крайния потребител, трябва смятай го за компрометиран! Дори артефактът да е компилиран двоичен файл, винаги има (повече или по-малко сложни) начини да стигнете до паролата.
Единственият начин да защитите ресурсите си е като изложите на крайния потребител само ограничен API. Или създайте програмен API (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) или изложете само определени функционалности във вашата DB чрез SPROC (вижте по-долу).
Първо някои неща...
Въпросът тук не трябва да бъде как да се скрие паролата, а как да се защити базата данни. Не забравяйте, че само паролите често са много слаба защита и не трябва да се считат за единствен механизъм за защита на DB. Използвате ли SSL? Не? Е, тогава дори ако успявате да скриете паролата в кода на приложението, все още е лесно да я подушите в мрежата!
Имате множество опции. Всички с различна степен на сигурност:
„Роля на приложението“
Създайте един потребител на база данни за приложението. Приложете разрешение за тази роля. Много често срещана настройка е разрешаването само на CRUD операции.
Плюсове
- много лесен за настройка
- Предотвратява
DROPзаявки (напр. в SQL инжекции?)
Против
- Всеки, който вижда паролата, има достъп до всички данни в базата данни. Дори ако тези данни обикновено са скрити в приложението.
- Ако паролата е компрометирана, потребителят може да изпълни
UPDATEиDELETEзаявки без критерии (т.е.:изтриване/актуализиране на цяла таблица наведнъж).
Атомно удостоверяване и удостоверяване
Създайте един потребител на база данни за приложение/краен потребител. Това ви позволява да дефинирате атомарни права за достъп дори на база на колона. Например:Потребителят X може да избира само колони далеч и база от таблица foo. И нищо друго. Но потребителят Y може да SELECT всичко, но без актуализации, докато потребителят Z има пълен CRUD (избиране, вмъкване, актуализиране, изтриване) достъп.
Някои бази данни ви позволяват да използвате повторно идентификационните данни на ниво ОС. Това прави удостоверяването на потребителя прозрачно (трябва само да влезете в работната станция, след което тази самоличност се препраща към БД). Това работи най-лесно в пълен MS-стек (OS=Windows, Auth=ActiveDirectory, DB=MSSQL), но - доколкото ми е известно - е възможно да се постигне и в други DBs.
Плюсове
- Доста лесно се настройва.
- Много атомна упълномощаваща схема
Против
- Може да е досадно да настроите всички права за достъп в DB.
- Потребители с
UPDATEиDELETEправата все още могат случайно (или умишлено?) да изтрият/актуализират без критерии. Рискувате да загубите всички данни в таблица.
Съхранени процедури с атомно удостоверяване и удостоверяване
Напишете не SQL заявки във вашето приложение. Стартирайте всичко чрез SPROC. След това създайте db-акаунти за всеки потребител и задайте привилегии на SPROC само .
Плюсове
- Най-ефективният защитен механизъм.
- SPROC могат да принудят потребителите да предават критерии към всяка заявка (включително
DELETEиUPDATE)
Против
- не съм сигурен дали това работи с MySQL (знанията ми в тази област са нестабилни).
- сложен цикъл на разработка:Всичко, което искате да направите, трябва първо да бъде дефинирано в SPROC.
Последни мисли
Никога не трябва да разрешавате административни задачи на базата данни на приложението. През повечето време единствените операции, от които се нуждае приложението, са SELECT , INSERT , DELETE и UPDATE . Ако следвате тази насока, едва ли има риск потребителите да открият паролата. С изключение на точките, споменати по-горе.
Във всеки случай, пазете резервни копия. Предполагам, че искате да проектирате базата си данни срещу случайни изтривания или актуализации. Но инциденти се случват... имайте това предвид;)
