データベースにアクセスするカスタム サーバー アプリケーションを開発しています。そのサーバーの資格情報をどこに保存するか (およびアドレス指定するか) を決定する必要があります。
一般的な解決策は、資格情報を構成ファイルに入れることです。ただし、侵害されたサーバーが、ハッカーが DB (別のサーバーでホストされている) にアクセスできることを意味したくありません。
資格情報を環境に保存することはできますが、それはあいまいさによるセキュリティに過ぎません。Mr. Evil は環境を調べて見つけることができます。
誰かが暗号化を提案しました。ただし、キーを実行可能ファイルに保存すると、すばやく逆コンパイルされ (Java を使用しています)、まだ運命にあります。
また、サーバーを起動するたびに言い換えを入力する必要は避けたいと考えています。
助言がありますか？シンプルなものが欠けているような気がします。
ありがとう
シンプルなものが欠けているとは思いません。問題のサーバーは、ユーザーの助けなしにデータベースに接続できます。その場合、資格情報が必要です。または、それらを提供しないと接続できません。リストしたようなさまざまな手順を実行して、侵害されたサーバーが資格情報をデータベースに公開するのを難しくすることができますが、結局のところ、それらの資格情報を取得して DB サーバーに提供する必要がある場合接続するには、それらをどこかに保存する必要があります—または少なくとも、それらを取得する何らかの手段が必要であり、その意味でハッキング可能になります.
最善の策は、侵入 (侵害されたサーバー) をできるだけ早く発見することに集中すること、最悪の場合に備えて適切なオフサイトのオフライン バックアップを維持すること、そもそも侵入に対する多くの障壁を設けることなどです。
私はこれを解決した方法を共有しています。
しかし、正直なところ、これが行った唯一のことは、単純なことを複雑にしすぎたことでした。その後、さまざまな権限を持つ複数のユーザーをデータベースに作成しました。
好き
guestすることができますSELECTmod、、、CREATE_ INSERT_ UPDATE_DELETEなど、認証されたユーザーが表示されるたびにユーザーを切り替えました。
ユーザーとセッションの組み合わせにより、これまでのところ脅威から逃れることができました。しかしもちろん、コードの脆弱性は徹底的にテストする必要があります。
それをロックします。イーブル氏が根を下ろすのを防いでください。わかります、簡単ですよね？
安全なアプリケーションを作成し、アプリケーションサーバーをロックダウンしたままにします。そこでのベストプラクティスに従ってください。それがほとんどの作業です。
安全な環境でデータベースをセットアップしたとき、データベースサーバーと同じ物理ネットワーク上にあったサーバーはアプリケーションサーバーだけでした。データベースサーバーにアクセスするには、次の2つの方法があります。
したがって、データベースサーバーを危険にさらすには、アプリケーションサーバーを危険にさらす必要があります。
したがって、アプリケーションサーバーをロックダウンします。もちろん、危うくされることよりも悪いことは、危うくされてそれについて知らないことだけです。侵害を発見した場合は、脆弱性があれば修正する必要があります。ここではフォレンジックが重要です（ログを有効にして監視します）。また、復旧計画を立てる必要があります。
予防、検出、修正、および回復が最も重要です。