簡単な答え
できません。
パスワードがエンドユーザーに出荷されるアーティファクトに保存されている場合は、必須 妥協したと考えてください！アーティファクトがコンパイルされたバイナリであっても、パスワードを取得する方法は常に（多かれ少なかれ複雑です）あります。
リソースを保護する唯一の方法は、限られたAPIのみをエンドユーザーに公開することです。プログラムAPI（REST、WS + SOAP、RMI、JavaEE +サーブレットなど）を構築するか、SPROCを介してDB内の特定の機能のみを公開します（以下を参照）。
最初にいくつかのこと...
ここでの問題は、パスワードを非表示にする方法ではなく、データベースを保護する方法です。多くの場合、パスワードは非常に弱い保護であり、DBを保護する唯一のメカニズムと見なすべきではないことに注意してください。 SSLを使用していますか？いいえ？ええと、 if アプリケーションコードでパスワードを隠すことができたとしても、ネットワーク上でパスワードを盗聴するのは簡単です！
複数のオプションがあります。すべてセキュリティの程度はさまざまです：
「アプリケーションの役割」
アプリケーション用に1つのデータベースユーザーを作成します。この役割に承認を適用します。非常に一般的な設定は、CRUD操作のみを許可することです。
長所
- 非常に セットアップが簡単
-
DROPを防止します クエリ（SQLインジェクションなど）
短所
- パスワードを見た人は誰でも、データベース内のすべてのデータにアクセスできます。そのデータが通常アプリケーションに隠されている場合でも。
- パスワードが侵害された場合、ユーザーは
UPDATEを実行できます およびDELETE基準のないクエリ（つまり、テーブル全体を一度に削除/更新します）。
Atomic auth＆auth
アプリケーション/エンドユーザーごとに1つのデータベースユーザーを作成します。これにより、列ごとでもアトミックアクセス権を定義できます。例：ユーザーXは、テーブルfooからfarおよびbazの列のみを選択できます。何もありません。ただし、ユーザーYはSELECTできます ユーザーZが完全なCRUD（選択、挿入、更新、削除）アクセス権を持っている間は、すべてが更新されません。
一部のデータベースでは、OSレベルの資格情報を再利用できます。これにより、ユーザーへの認証が透過的になります（ワークステーションにログインするだけで、そのIDがDBに転送されます）。これは、完全なMSスタック（OS =Windows、Auth =ActiveDirectory、DB =MSSQL）で最も簡単に機能しますが、私が知る限り、他のDBでも実現できます。
長所
- セットアップはかなり簡単です。
- 非常にアトミックな承認スキーム
短所
- DBにすべてのアクセス権を設定するのは面倒な場合があります。
-
UPDATEを使用するユーザー およびDELETE権利は、誤って（または意図的に？）削除/更新する可能性があります 基準。テーブル内のすべてのデータを失うリスクがあります。
アトミック認証と認証を使用したストアドプロシージャ
noと書く アプリケーションでのSQLクエリ。 すべてを実行します SPROCを介して。次に、ユーザーごとにデータベースアカウントを作成し、SPROCにのみ特権を割り当てます。 。
長所
- 最も効果的な保護メカニズム。
- SPROCは、ユーザーにすべてのクエリ（
DELETEを含む）に条件を渡すように強制できます。 およびUPDATE）
短所
- これがMySQLで機能するかどうかわからない（その分野での私の知識は不安定です）。
- 複雑な開発サイクル：実行したいことはすべて、最初にSPROCで定義する必要があります。
最終的な考え
アプリケーションにデータベース管理タスクを許可しないでください。ほとんどの場合、アプリケーションに必要な操作はSELECTだけです。 、INSERT 、DELETE およびUPDATE 。このガイドラインに従えば、ユーザーがパスワードを発見するリスクはほとんどありません。上記の点を除いて。
いずれにせよ、バックアップを保管してください。偶発的な削除や更新に対してデータベースを投影したいと思います。しかし、事故は起こります...それを覚えておいてください;）