6

Authenticode コード署名証明書をビルド サーバーに直接インストールして、実稼働署名済みビルドを作成することは許容されますか? ビルド サーバーと、ビルドを作成および展開するプロセスを保護するための適切な手順を実行した場合に、この慣行が正当であることを示唆またはサポートするネット上のリソースを探しています。

コード署名の実践に関して私が見つけることができるすべての「ベスト プラクティス」のガイダンスは、提案されたプロセスの点で非常に優れています。Microsoft のリファレンス ドキュメントには、単一のアセンブリに署名するという単純な行為のために、6 台ものサーバーが使用されています。 http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc

背景:

私の会社では、従業員と直接の顧客向けに、単純なリッチクライアント基幹業務アプリケーションを作成しています。私たちは商用ソフトウェアを作成しません。私のビルド サーバーは、会社の厳格なセキュリティ ポリシーと手順を使用して、物理的にセキュリティで保護され、ネットワークでセキュリティで保護されています。私の環境でビルドを開始することさえできるのは、組織内の非常に特定の人だけです。

現在のプロセスでは、ビルド/デプロイ プロセスを多くの段階に分割し、多くの手動プロセスを実施する必要があります。物理デバイスを使用して Authenticode 証明書を保存し、アクセスするにはユーザーが入力した PIN を必要とします。コード署名が必要なアセンブリ/マニフェストを、物理的に保護する必要がある指定されたコード署名 PC にシャッフルする必要があります。

私にとって、物理的なトークン/デバイスを渡して、これらすべての手動の​​手順をそのままにしておくのは安全ではありません. トークン/デバイスに物理的にアクセスできる人が、必要なものに署名することを妨げるものは何もありません。少なくとも、自動化され、ログに記録され、制御されたビルド サーバー環境があれば、誰が何に署名したかがわかります。

4

1 に答える 1

2

The main problem with installing a certificate on a build server and making it accessible to a build account, is that now any developer can sign any malicious piece of code by temporarily commiting it to some legitimate project, and reverting it back after the build.

No matter the actions are logged, the breach is hard to identify or prevent. Especially if development is active and several builds are done per day.

The only solution I can think of is to limit a number of people who can trigger an "RTM" build. Other build types may use a test certificate or avoid signing at all.

In fact, this is the question I bother my head too.

于 2012-10-02T22:04:40.970 に答える