Kort svar
Det kan du ikke.
Hvis adgangskoden er gemt i artefakten, der er sendt til slutbrugeren, skal anser det for kompromitteret! Selvom artefakten er en kompileret binær, er der altid (mere eller mindre komplicerede) måder at finde adgangskoden på.
Den eneste måde at beskytte dine ressourcer på er ved kun at udsætte en begrænset API til slutbrugeren. Byg enten en programmatisk API (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) eller eksponer kun visse funktionaliteter i din DB via SPROC'er (se nedenfor).
Nogle ting først...
Spørgsmålet her bør ikke være, hvordan man skjuler adgangskoden, men hvordan man sikrer databasen. Husk, at kun adgangskoder ofte er en meget svag beskyttelse og ikke bør betragtes som den eneste mekanisme til at beskytte DB. Bruger du SSL? Ingen? Nå, så endda hvis du formår at skjule adgangskoden i applikationskoden, er det stadig nemt at snuse til det på netværket!
Du har flere muligheder. Alle med forskellige grader af sikkerhed:
"Applikationsrolle"
Opret én databasebruger til applikationen. Ansøg autorisation til denne rolle. En meget almindelig opsætning er kun at tillade CRUD-operationer.
Fordele
- meget nem at sætte op
- Forhindrer
DROPforespørgsler (f.eks. i SQL-injektioner?)
Idele
- Alle, der ser adgangskoden, har adgang til alle data i databasen. Også selvom disse data normalt er skjult i applikationen.
- Hvis adgangskoden er kompromitteret, kan brugeren køre
UPDATEogDELETEforespørgsler uden kriterier (dvs.:slet/opdater en hel tabel på én gang).
Atomic auth&auth
Opret én databasebruger pr. applikation-/slutbruger. Dette giver dig mulighed for at definere atomare adgangsrettigheder selv på en per-kolonne basis. For eksempel:Bruger X kan kun vælge kolonner langt og baz fra table foo. Og intet andet. Men bruger Y kan SELECT alt, men ingen opdateringer, mens bruger Z har fuld CRUD-adgang (vælg, indsæt, opdater, slet).
Nogle databaser giver dig mulighed for at genbruge legitimationsoplysningerne på OS-niveau. Dette gør autentificering til brugeren gennemsigtig (behøver kun at logge ind på arbejdsstationen, denne identitet videresendes derefter til DB). Dette virker nemmest i en fuld MS-stack (OS=Windows, Auth=ActiveDirectory, DB=MSSQL), men er - så vidt jeg ved - også muligt at opnå i andre DB'er.
Fordele
- Ret nemt at konfigurere.
- Meget atomart autorisationsskema
Idele
- Kan være trættende at konfigurere alle adgangsrettigheder i DB.
- Brugere med
UPDATEogDELETErettigheder kan stadig ved et uheld (eller med vilje?) slette/opdatere uden kriterier. Du risikerer at miste alle data i en tabel.
Lagrede procedurer med atomic auth&auth
Skriv nej SQL-forespørgsler i din applikation. Kør alt gennem SPROC'er. Opret derefter db-konti for hver bruger og tildel privilegier til SPROC'erne kun .
Fordele
- Mest effektive beskyttelsesmekanisme.
- SPROC'er kan tvinge brugere til at videregive kriterier til hver forespørgsel (inklusive
DELETEogUPDATE)
Idele
- ikke sikker på, om dette virker med MySQL (min viden på det område er ustabil).
- kompleks udviklingscyklus:Alt, hvad du vil gøre, skal først defineres i en SPROC.
Sidste tanker
Du bør aldrig tillade databaseadministrative opgaver til applikationen. For det meste er de eneste handlinger, en applikation har brug for, SELECT , INSERT , DELETE og UPDATE . Hvis du følger denne retningslinje, er der næppe en risiko forbundet med, at brugere opdager adgangskoden. Bortset fra de punkter, der er nævnt ovenfor.
Under alle omstændigheder skal du beholde sikkerhedskopier. Jeg antager, at du vil projicere din database mod utilsigtede sletninger eller opdateringer. Men der sker uheld... husk det;)