Krátká odpověď
Nemůžete.
Pokud je heslo uloženo v artefaktu, který je dodán koncovému uživateli, musíte považujte to za kompromitované! I když je artefakt zkompilovaný binární soubor, vždy existují (více či méně komplikované) způsoby, jak se k heslu dostat.
Jediný způsob, jak chránit své zdroje, je zpřístupnit koncovému uživateli pouze omezené rozhraní API. Buď vytvořte programové API (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) nebo zpřístupněte pouze určité funkce ve vaší databázi prostřednictvím SPROC (viz níže).
Něco nejdříve...
Otázka by zde neměla znít, jak skrýt heslo, ale jak zabezpečit databázi. Pamatujte, že pouze hesla jsou často velmi slabou ochranou a neměla by být považována za jediný mechanismus ochrany DB. Používáte SSL? Ne? Tedy i kdyby podaří se vám skrýt heslo v kódu aplikace, stále je snadné jej vyčmuchat v síti!
Máte více možností. Vše s různým stupněm zabezpečení:
"Role aplikace"
Vytvořte jednoho uživatele databáze pro aplikaci. Použít autorizaci pro tuto roli. Velmi běžné nastavení je povolit pouze operace CRUD.
Výhody
- velmi snadné nastavení
- Zabraňuje
DROPdotazy (např. v SQL injections?)
Nevýhody
- Každý, kdo vidí heslo, má přístup ke všem datům v databázi. I když jsou tato data běžně v aplikaci skryta.
- Pokud je heslo prozrazeno, může uživatel spustit
UPDATEaDELETEdotazy bez kritérií (tj.:odstranit/aktualizovat celou tabulku najednou).
Atomové auth&auth
Vytvořte jednoho uživatele databáze na aplikaci/koncového uživatele. To vám umožňuje definovat atomická přístupová práva i na základě jednotlivých sloupců. Například:Uživatel X může vybrat pouze sloupce daleko a baz z tabulky foo. A nic jiného. Ale uživatel Y může SELECT vše, ale žádné aktualizace, zatímco uživatel Z má plný přístup CRUD (výběr, vložení, aktualizace, smazání).
Některé databáze umožňují opětovné použití přihlašovacích údajů na úrovni operačního systému. Tím je autentizace pro uživatele transparentní (stačí se přihlásit k pracovní stanici, tato identita je pak předána do DB). Toto funguje nejsnáze v plném MS-stacku (OS=Windows, Auth=ActiveDirectory, DB=MSSQL), ale je - pokud vím - také možné dosáhnout v jiných DB.
Výhody
- Poměrně snadné nastavení.
- Velmi atomické schéma autorizace
Nevýhody
- Nastavování všech přístupových práv v DB může být únavné.
- Uživatelé s
UPDATEaDELETEpráva mohou stále náhodně (nebo úmyslně?) smazat/aktualizovat bez kritéria. Riskujete ztrátu všech dat v tabulce.
Uložené procedury s atomickým auth&auth
Napište ne SQL dotazy ve vaší aplikaci. Spusťte vše prostřednictvím SPROC. Poté vytvořte účty db pro každého uživatele a přidělte oprávnění pouze SPROC .
Výhody
- Nejúčinnější ochranný mechanismus.
- SPROC mohou donutit uživatele, aby předali kritéria každému dotazu (včetně
DELETEaUPDATE)
Nevýhody
- nejsem si jistý, jestli to funguje s MySQL (moje znalosti v této oblasti jsou slabé).
- složitý vývojový cyklus:Vše, co chcete dělat, musí být nejprve definováno v SPROC.
Poslední myšlenky
Nikdy byste aplikaci neměli povolit úkoly správy databáze. Většinou jsou jediné operace, které aplikace potřebuje, SELECT , INSERT , DELETE a UPDATE . Pokud se budete řídit tímto pokynem, existuje jen stěží riziko, že by uživatelé objevili heslo. Kromě výše uvedených bodů.
V každém případě mějte zálohy. Předpokládám, že chcete promítnout svou databázi proti náhodným smazáním nebo aktualizacím. Ale nehody se stávají... mějte to na paměti;)