42

多くの異なるクライアント アプリケーション (Web サービス、いくつかの Java アプリ、およびいくつかのドット ネット アプリケーション) が接続するデータベースがあります。これらのすべてが Windows で実行されているわけではありません (残念ながら、そうでなければ、データベース接続の Windows 認証を有効にするだけで簡単に答えられる質問になります)。現時点では、パスワードはシステムのさまざまな構成/プロパティ ファイルに保存されています。理想的には、ファイルが実行されているサーバーにアクセスできるのはサポート スタッフだけですが、他の誰かがサーバーの 1 つにアクセスできるようになった場合、現状のデータを公正に取得するのに十分なデータベース アクセス許可が付与されます。

私の質問は、何気ない人間の読者がパスワードを簡単に利用できるようにせずに、パスワードを設定可能にしておくための最良の方法は何ですか?

編集明確にするために、DBサーバーはMSSQL 2005を実行しているWindows Server 2003です。

PS: これと重複する質問は見当たりませんが、もしあれば、お気軽にこの質問を閉じてください。

4

11 に答える 11

17

偶然の観察者からパスワードを隠したいと思っていると思います。彼らが、接続するマシンの 1 つですべてのソース コードにアクセスできる邪悪で冷酷な観察者である場合、少しリバース エンジニアリングを行うことでパスワードを取得できます。

異なるクライアントごとに同じ保護を使用する必要はないことに注意してください。いくつかのステップ:-

  1. データベースにアクセスするシステムごとに異なるデータベース アカウントを作成する
  2. 組み込みのデータベース GRANT を使用して、データベースへのアクセスを必要なものだけに制限する
  3. データベースのパスワード マネージャー クラス内にトリプル DES (または何でも) キーを格納します。これを使用して、プロパティ ファイル内の暗号化された値を復号化します。

また、アプリケーションが起動時にパスフレーズを要求するようにすることも検討しましたが、これは面倒で、運用スタッフがパスワードを知る必要があるため、実装していません。安全性が低いのではないでしょうか。

于 2008-11-03T11:07:50.767 に答える
10

次の一般的なシナリオを想定してみましょう。

  • すべての環境で同じコード ベースを使用し、コード ベースには各環境のデータベース パスワードがあります。

  • 実稼働アプリケーション サーバーにアクセスできる担当者 (システム管理者、構成マネージャー) は、実稼働データベースのパスワードを知ることができますが、それ以外の人は知ることができません。

  • ソース コードにアクセスできる人に、運用パスワードを知られたくありません。

このようなシナリオでは、運用パスワードを暗号化して、アプリケーションのプロパティ ファイルに保存できます。アプリケーション内に、プロパティ ファイルからパスワードを読み取り、パスワードを解読してからデータベース ドライバに渡すクラスを含めることができます。ただし、パスワードの復号化に使用されるキーとアルゴリズムはソース コードの一部ではなく、実行時にシステム プロパティとしてアプリケーションに渡されます。これにより、キーの知識がアプリケーションのソース コードから分離され、アプリケーションのソース コードだけにアクセスできる人は、アプリケーションのランタイム環境 (アプリ サーバー) にアクセスできないため、パスワードを復号化できなくなります。

Java を使用している場合は、より具体的な例についてthisを参照してください。この例では、Spring と Jasypt を使用しています。このようなことは、.Net などの他の環境に当てはめることができると確信しています。

于 2009-01-07T19:18:58.290 に答える
4

私の古い職場では、すべてのパスワードが暗号化されるシステムを使用していました (トリプル DES または当時使用していたものを使用)。多くの場合、パスワードはプロパティー・ファイルに保管されていました (これは Java システムにありました)。

パスワードを変更する必要がある場合、単純に「!plaintext」を値として使用するだけで、コードでパスワードをロードして暗号化し、暗号化された値をプロパティ ファイルに保存します。

これは、元の値が何であるかを知らなくてもパスワードを変更できることを意味していました。

于 2008-11-03T10:50:13.983 に答える
3

簡単な答えはないように思えます (接続するアプリケーションの種類が異なるため)... 実際、私が目にする唯一の問題は、データベースに直接接続しているように見える Java アプリです。あれは正しいですか？

その場合、次のことができます。

1) DB に直接接続するクライアント側アプリケーションをサービスを経由するように変更します。（直接接続する必要がある場合は、少なくともサービスから「パスワードを取得」する最初のステップを提供してから、直接接続できます）。

2) パスワードを web.config ファイルに保存し (.Net Web サービスを選択した場合)、ファイルの「接続文字列」セクションを暗号化します。

于 2008-11-03T10:51:01.797 に答える
2

パスワードを使用しないでください。通常、サーバー間認証は、キー ファイルまたはクライアント証明書、またはパスワード以外の方法を使用して実行できます。

于 2008-11-03T10:42:31.050 に答える
0

NTLM 認証または LDAP ベース (Active Directory) 認証は、少し努力すれば利用できるはずです。これにより、アプリケーション全体で「Windows 認証」を使用できるようになります。

運用スタッフにとっては多少の移行を意味するかもしれませんが、一連のアプリケーションの SSO は便利です。

于 2008-11-03T12:50:17.360 に答える
0

はい、(salted) ハッシュを保存するオプションに同意する必要があります。データベースに保存されているパスワードの (salted) SHA256 ハッシュをお勧めします。また、安全なパスワード ルールを適用することも忘れないでください。

于 2009-10-18T02:46:22.367 に答える
0

Blowfish などの可逆暗号化アルゴリズムを使用して、応急処置としてパスワードを保存できます。このアクセスを必要とするすべてのプログラムにこれを組み込むために使用できる無料のライブラリがいくつかあるはずです。

Blowfishの Bruce Schneier のページ

フグに関するウィキペディアの記事

于 2008-11-03T10:48:41.723 に答える
0

Java については、アプリ サーバーを使用している場合は、データ ソースを定義できるかどうかを確認してください。アプリは JNDI を使用してデータ ソースを取得できます。このように、データソース (接続の詳細を含む) の管理はアプリ サーバーによって処理され、アプリケーション コードはデータソースを要求するだけです。

于 2008-11-03T11:16:53.400 に答える
-2

暗号化を使用することはお勧めできません。誰かがキーを侵害した場合、彼はそれを解読できます。パスワードを保存するには、salt を使用したハッシュ アルゴリズムを使用します。ハッシュアルゴリズムは一方向であるため、元に戻すことはできません。ただし、それらは辞書攻撃に対して脆弱であるため、salt を使用します (平文をハッシュ化するよりも長くて冗長なものと連結します)。また、内部攻撃からデータベースを保護します。

于 2009-06-18T20:35:55.490 に答える