6

SSL で保護された接続を介して他のアプリケーションやサービスに接続する Java アプリケーションが多数あります。開発中に、JVM args を使用して、使用するキーストア/トラストストアとパスワードを指定できます。

-Djavax.net.ssl.trustStore=certificate.jks 
-Djavax.net.ssl.trustStorePassword=mypassword 
-Djavax.net.ssl.keyStore=certificate.jks 
-Djavax.net.ssl.keyStorePassword=mypassword 
-Djavax.net.ssl.keyStoreType=jks

これは完全に機能します。ただし、本番環境ではパスワードを非表示にする必要があります。JVM args を使用すると、プロセス リストを見た人は誰でもパスワードを平文で見ることができるようになります。

これを回避する簡単な方法はありますか？証明書を JRE の lib/security/cacerts ファイルにインポートすることを検討しましたが、それでもパスワードが必要になると理解しています。1 つのオプションは、パスワードを暗号化してファイルに保存し、その場でアプリケーションを読み取って復号化することですが、これにはすべてのアプリケーションを変更して再リリースする必要があります (かなりの数のアプリケーションがあります)。可能であれば、むしろこれを避けたいと思います。javax.net.ssl ライブラリには、暗号化されたパスワードに対するネイティブの組み込みサポートがありますか (それが base64 エンコーディングのような単純なものであっても、パスワードを非クリアテキストにするものであっても)?

どんな提案でも大歓迎です。

4

1 に答える 1

12

まず、他のユーザーから ps 出力を非表示にすることを検討できます。次の質問を参照してください。

第 2 に、証明書を (秘密鍵を使用すると仮定して) にインポートしてlib/security/cacertsも意味がありません。これはデフォルトのトラストストアですが、デフォルトのキーストア (デフォルト値がない) ではありません。

第 3 に、アプリケーションで (非対話モードで) 使用されるパスワードを実際に「暗号化」することはできません。使用する必要があるため、暗号化されている場合は、暗号化キーをある時点で平文で使用できるようにする必要があります。したがって、それは少し無意味です。

あなたが示唆するように、Base 64エンコーディングは単なるエンコーディングです。繰り返しますが、誰でもデコードできるため、まったく無意味です (例: based64 -d)。Jetty などの一部のツールは、難読化されたモードでパスワードを保存できますが、base 64 エンコーディングほど耐性はありません。誰かがあなたの肩越しに見ている場合に便利ですが、それだけです。

ファイルからパスワードを読み取るようにアプリケーションを適合させることができます (プレーン テキストまたは難読化)。権限のない第三者がこのファイルを読み取れないようにする必要があります。

本当に重要なことは、キーストア ファイル自体が、それを読み取ることを意図していないユーザーから保護されていることを確認することです。そのパスワードは、他の人が読み取れる場合や、対話モードでのアクセスを保護したい場合に、コンテナーを保護することを目的としています。無人モードのマシンではパスワードを平文で使用することを避けることはできないため、難しいパスワードを使用する意味はほとんどなく、むしろファイル自体を保護することがより重要です。(アプリケーションがインタラクティブかどうかは明確ではありませんが、インタラクティブに入力することを期待するユーザーはほとんどいないと思います-Djavax.net.ssl....=...。)

コードをファイルから読み取るように変更できない場合は、キーストアとキーのパスワードを「ABCD」のように開示しても構わないパスワードに変更し、このキーストア ファイルからの読み取りアクセスを確実に保護してください。これが本当に重要なことです。最終的には。セカンダリ ファイルからパスワード自体を読み取ることは、問題を 1 ステップ延期するだけです。これは、パスワード ファイルとキーストア ファイルが隣り合って保存される可能性が高いためです (権限のない第三者によって一緒にコピーされる可能性があります)。

于 2013-07-23T18:56:15.817 に答える