2

私のビジネスにはJNLPアプリケーションを使用しています。実際の使用には、リリースごとに手動の署名jarが必要です。これは確かに異なる証明書、期限切れの証明書などを持つことにつながります。

MavenをPOCして、MavenJarsignerプラグインを使用してアプリケーションに自動的に署名しました。

さて、そのようなプロセスを工業化するための最良のアプローチは何ですか？毎回再作成するのではなく、すべてのアプリケーションで証明書を共有したいのですが。

特に：

  • 多数の企業アプリケーションの証明書を持っているのは正しいですか、それともアプリケーションごとに1つ持っていることを検討しますか？

  • 証明書を依存関係として（ビジネスリポジトリの下に）保存し、開発証明書とリリース証明書の両方をビルドで取得することを想像できますか？ローカルビルドの開発証明書とリリースのリリース証明書を言います。

  • そのような使用の欠陥は何ですか？

  • 他の/より良い解決策はありますか？

回答ありがとうございます。

4

1 に答える 1

0

問題を解決する方法はたくさんあるので、私はその問題についての私の考えを共有することしかできません。

a）異なるリリースは異なるブランチにあると思いますので、本質的には一度に1つのリリースバージョンのみを扱います。

b）次に、バージョンごとに、環境ごとに異なる証明書があると想定します。環境ごとの部分は、Mavenプロファイル（http://maven.apache.org/guides/introduction/introduction-to-profiles.html）を使用して処理できるため、...

複数の証明書を持っているか単一の証明書を持っているかは好みの問題です。特定のユーザーと特定のアプリの間の信頼レベルを提供するため、本質的にはリスクと保守性の判断になります。リスクは、同じ証明書を持つ複数のアプリがより高い露出をもたらし、悪意のある露出にもなり、1つの違反はすべての違反です。したがって、証明書が何を保護するかが重要になる場合があります。すべてのアプリが同じ更新サイクルに従うという保守性と、1つに変更することはすべてに変更することを意味します。

したがって、結合は少し高く、リスクはより難しく、メンテナンスはより簡単です。グローバル企業の場合、Acme Incのリスクは、ローカル企業のIcme Inc.の場合よりもおそらく高く、他の人々のデータまたはお金である可能性があります。利用可能な最も安全なオプションを招待します。

証明書を保存できない理由はわかりません。リポジトリまたは他の安全なリポジトリにあるか、単に横になっています。さらに興味深いのは秘密鍵です。これはプロパティとして指定し、開発者のプロファイルにバインドし、開発者のプロファイルとリリースのキーを省略できるため、コマンドラインで指定する必要があります。

maven jarsignerプラグインを使用すると仮定すると、${my.keypass}と${my.keystore}を使用してから、両方のプロパティが設定されたdevプロファイルと、キーストアのみが設定されたリリースプロファイルを使用できます。

前回、私が持っていたのと同様の方法で証明書を使用しました。-個々のコンポーネントのセット-単一のリポジトリ内-単一の完全なエンティティとして構築できます。

したがって、証明書の共有は簡単な持ち帰りでした。最終製品を除くすべての証明書はソースコードリポジトリにありました。リリースの証明書は安全なサーバー上にあり、バッチプロセスがあり、アクセスできるのはごくわずかでした。

セキュリティの侵害については..これまでに遭遇したことはないと思いますが、準備はできていました:)

于 2013-05-14T07:06:31.357 に答える