パスワードを簡単に利用できるようにすることなく、パスワードを構成可能な状態に保つ最良の方法は何ですか？
多くの異なるクライアントアプリケーション（Webサービスの一部、一部のJavaアプリといくつかのドットネットアプリケーション）が接続するデータベースがあります。これらのすべてがWindowsで実行されているわけではありません（悲しいことに、データベース接続のWindows認証を有効にするだけで、これは簡単な答えの質問になります）現時点では、パスワードはシステムの周囲にあるさまざまな構成/プロパティファイルに保存されています。ファイルは実行されていますが、他の誰かがサーバーの1つにアクセスした場合、現在の状態で公正なデータを取得するのに十分なデータベース権限があります。
それから私の質問、パスワードを構成可能な状態に保つための最良の方法は何ですか？
編集明確にするために、DBサーバーはMSSQL 2005を実行するWindows Server 2003です。
PS：これと重複する質問はありませんが、もしあれば、この質問を閉じてください。
私はあなたが普段の観察者からパスワードを隠したいと思っていると思います。悪意があり、接続しているマシンの1つにあるすべてのソースコードにアクセスできる鋼のような目をした観察者であれば、少しのリバースエンジニアリングでパスワードを取得できます。
異なるクライアントごとに同じ保護を使用する必要はないことに注意してください。いくつかの手順：-
- データベースにアクセスするシステムごとに異なるデータベースアカウントを作成する
- データベースへのアクセスを、組み込みのデータベースGRANTを使用して必要なものだけに制限します
- トリプルDES（または何でも））キーをデータベースのパスワードマネージャークラス内に格納します。これを使用して、プロパティファイルの暗号化された値を解読します。
また、起動時にパスフレーズを要求するアプリケーションを用意することも検討しましたが、これは実装がまだ困難であり、運用スタッフがパスワードを知る必要があるためです。おそらく安全性は低いでしょう。
次の一般的なシナリオを想定してみましょう。
すべての環境に同じコードベースを使用し、コードベースには各環境のデータベースパスワードがあります。
本番アプリケーションサーバーにアクセスできる担当者（sysadmin、構成マネージャー）は、本番データベースのパスワードを知ることができますが、他の人は誰も知ることができません。
ソースコードにアクセスできる人に、本番パスワードが何であるかを知られたくはありません。
このようなシナリオでは、運用パスワードを暗号化して、アプリケーションのプロパティファイルに保存できます。アプリケーション内に、プロパティファイルからパスワードを読み取り、データベースドライバーに渡す前にパスワードを解読するクラスを含めることができます。ただし、パスワードの解読に使用されるキーとアルゴリズムはソースコードの一部ではなく、実行時にシステムプロパティとしてアプリケーションに渡されます。これにより、キーの知識がアプリケーションのソースコードから分離され、アプリケーションのランタイム環境（アプリサーバー）にアクセスできないため、アプリケーションのソースコードのみにアクセスできるユーザーはパスワードを解読できなくなります。
Javaを使用している場合、より具体的な例については this を参照してください。この例ではSpringとJasyptを使用しています。このようなものは外挿できると確信しています。 .Netのような他の環境へ
私の昔の職場では、すべてのパスワードが暗号化されたシステムを使用していました（トリプルDESまたは当時使用していたものを使用）。パスワードはしばしばプロパティファイルに保存されていました（ Java system）。
パスワードを変更する必要がある場合、値として「！plaintext」を使用するだけで、コードはそれをロードして暗号化し、暗号化された値をプロパティファイルに保存します。
これは、元の値が何であるかを知らずにパスワードを変更することが可能であったことを意味します-それがあなたが求めていたものかどうかはわかりません！
簡単な答えはないようです（接続するアプリケーションの種類が異なるため）...実際、唯一の問題はJavaデータベースに直接接続しているように見えるアプリです。 あれは正しいですか？
もしそうなら、あなたができることはここにあります：
1）DBに直接接続するクライアント側アプリケーションを変更して、サービスを経由します。 （直接接続するためにhaveを使用する場合、少なくともサービスから「パスワードを取得する」ための最初のステップを与えると、直接接続できます）。
2）web.configファイルにパスワードを保存し（.Net Webサービスを実行することを選択した場合）、ファイルの「接続文字列」セクションを暗号化します。
パスワードを使用しないでください。通常、サーバー間認証はキーファイルまたはクライアント証明書、またはパスワード以外の方法を使用して実行できます。
Javaの場合、アプリサーバーを使用している場合は、データソースを定義できるかどうかを確認し、JNDIを使用してアプリがデータソースにアクセスできるようにします。接続の詳細など）はアプリサーバーによって処理され、アプリケーションコードはデータソースを要求するだけです。
NTLM認証またはLDAPベースの（Active Directory）認証は、少し手間をかけて利用できるはずです。これにより、アプリケーション間で「Windows認証」を使用できるようになります。
運用スタッフにとっては多少の移行を意味するかもしれませんが、アプリケーションセットのSSOは素晴らしいです。
はい、（塩漬け）ハッシュを保存するオプションに同意する必要があります。データベースに保存されているパスワードの（塩漬け）SHA256ハッシュをお勧めします。また、安全なパスワードルールを実施することを忘れないでください。