JAR ファイルに署名する必要があるのはなぜですか?
クライアント側の JAR ファイル (アプレットを含む) に署名する必要があることはわかっています。これにより、ファイル システムへのアクセスなどの特別な操作を実行できるようになり、ウィンドウの下部にある煩わしいビットが表示されなくなります。また、サーブレットなどを含むサーバー側の JAR ファイルに署名する必要がありますか?
JAR に署名するときとしないときの基本的なルールを教えていただければ幸いです - ありがとうございます!
JAR ファイルに署名する必要があるのはなぜですか?
クライアント側の JAR ファイル (アプレットを含む) に署名する必要があることはわかっています。これにより、ファイル システムへのアクセスなどの特別な操作を実行できるようになり、ウィンドウの下部にある煩わしいビットが表示されなくなります。また、サーブレットなどを含むサーバー側の JAR ファイルに署名する必要がありますか?
JAR に署名するときとしないときの基本的なルールを教えていただければ幸いです - ありがとうございます!
簡単に言えば、会社のポリシーで強制されない限り、しないでください。
長い答え
jar に署名することは、効果的に顧客に「私はこれを作成しました。システムを台無しにしないことを保証します。もしそうなら、報復のために私に来てください」と伝えています。これが、リモート サーバー (アプレット/Webstart) から展開されたクライアント側ソリューションの署名付き jar が、署名されていないソリューションよりも高い特権を享受する理由です。
JVM セキュリティの要求をなだめる必要がないサーバー側のソリューションでは、この保証は顧客の安心のためだけのものです。
署名された jar の悪い点は、署名されていない jar よりも読み込みが遅いことです。どのくらい遅くなりますか?これは CPU バウンドですが、ロード時間が 100% 以上増加していることに気付きました。また、パッチは難しく (jar に再署名する必要があります)、クラスパッチは不可能です (単一パッケージ内のすべてのクラスは同じ署名ソースを持つ必要があります)、jar を分割するのは雑用になります。ビルド プロセスが長くなることは言うまでもありません。また、適切な証明書を作成するには費用がかかります (自己署名はほとんど役に立ちません)。
そのため、会社のポリシーで強制されない限り、サーバー側で jar に署名せず、共通の jar を署名付きバージョンと署名なしバージョンで保持します (署名付きはクライアント側の展開に移動し、署名なしはサーバー側のコードベースに移動します)。 )。
正当な理由は、コードによって呼び出されるように変更されたクラスに誰かが忍び込むことができるようにしたくない場合です。
残念ながら、それはあなた自身を含みます:-Dしたがって、これは本当に必要な場合にのみ実行されます。「密封された瓶」の概念を確認してください。
アプレットに関して: 6u10 から、Sun JRE は、警告バナーを目立たない (6u12、IIRC から) 警告三角形に置き換えます (整形された透明なウィンドウをサポートするために必要です)。6u10 では、JNLP サービス API を介してファイル アクセスを制御することもできます。
最小権限の原則では、jar ファイルのクラスに署名してはいけません。セキュリティは必ずしも容易ではありません。
単に証明書のダイアログ ボックスを表示するだけでは、Web ページのコンテンツ全体が信頼できると解釈されるべきではありません。
jar ファイルへの署名は、他のコンテキストで証明書を使用する場合と同様に、それを使用する人々がそれがどこから来たのかを知るために行われます。人々は、Chris Carruthers が悪意のあるコードを書くつもりはないと信じているので、あなたのアプレットが自分のファイル システムにアクセスすることを喜んで許可します。署名は、瓶が本当にあなたによって作成されたものであり、なりすましや信頼できない誰かによって作成されたものではないという保証を彼らに与えます。
サーバー側またはライブラリ jar の場合、通常、そのような保証を誰にも提供する必要はありません。それが自分のサーバーであれば、使用している jar とそれらがどこから来たのかを知っているので、おそらく自分のコードが悪意を持っていないことを信頼しているでしょう。