適切なコード署名環境ガイドラインとは何ですか？
このシナリオを例にとります。組織には、リポジトリからソースを定期的にチェックアウトしてすべてをビルドするいくつかのビルドサーバーがあります。ビルドが完了すると、バイナリはコード署名およびアーカイブされ、署名と公開証明書とともに公開されることもあります。
仮定して：
- プライベートEV証明書は、おそらく物理的に安全な環境（コード署名環境）の署名サーバーに接続されたハードウェアトークンに保存されます。
- サーバーはおそらくLinuxベースです。
そのような署名サーバー、HSMなどに適切な予防策は何ですか。
- 署名環境は、IDバッジでのみアクセスできるロックされたドアの後ろに配置する必要があります。
- 単純な物理的なアクセスを拒否するだけで十分でしょうか（署名された環境を、換気された物理的に安全なボックスに入れますか？
- 環境を物理的に安全に保つための考慮事項は何ですか？
- ロックされたサーバールームは十分に安全ですか？
- 会社のネットワークにコード署名サーバーを接続するのはいつ問題がありますか？ （構築サーバーへのアクセスを提供するため）
- キーベースのSSHセッションは、会社のネットワークを介したビルドサーバーと署名サーバー間の通信をセキュリティで保護するのに十分ですか？
ありがとう！
考慮すべき主要な原則はこれです：秘密鍵は決して移動してはなりません。
コード署名環境にビルド/テスト環境からアクセスできないようにする必要があります。ビルド環境がコード署名リクエストを直接満たすことができる場合、ビルド/テスト環境（巨大な攻撃面のあるスペース）が危険にさらされ、コード署名が侵害されることを意味します。
署名するコードは署名環境に再配置する必要があります。キーをビルド環境に移動することはできません。
このために考えられる1つの解決策は、ビルドシステムが適格なビルドアーティファクトを公開し、キーカストディアン（実際の人）がそれらのビルドアーティファクトを取得して署名環境で署名し、署名されたアーティファクトをアーティファクトに公開することです。リポジトリ。
署名環境は物理的に分離されていることが望ましいですが、ビジネス上の理由から、署名環境は、キーの公開のリスクにキーの公開のコストを掛けたリスクを超えないようにする必要があります。非常にリスクの低いシナリオでの署名環境（展開の便宜のためにコード署名のみを行い、悪意を持って使用された場合、評判の損害と法的責任のリスクを受け入れる）は、十分に安全であれば、カストディアン自身のワークステーションになる可能性があります。