コード署名のベストプラクティスは何ですか?
コード署名は、ソフトウェア開発者または発行者の本人性を検証し、コードが署名されてからダウンロードされる時点までにコードの完全性が損なわれていないことを確認します。これにより、コードが信頼できるものであることが証明されます。残念なことに、コード署名の手法を突破して「信頼できるコード」の中にマルウェアを埋め込もうとする悪意の攻撃者が後を絶ちません。
ここでは、攻撃が成功してしまった場合のリスクを軽減させるためのベストプラクティスをいくつか紹介します。
- 鍵を安全に保管する: もし署名用の秘密鍵が危殆化したり、組織から盗まれたりした場合、マルウェアを埋め込んだソフトウェアに署名するために使用される可能性があります。こうして、リリースしたソフトウェアをその組織が発行した正規のソフトウェアに見せかけるのです。秘密鍵は、HSM（ハードウェアセキュリティモジュール）など安全な場所に保管する必要があります。CA/ブラウザ（CA/B）フォーラムの要件によれば、パブリックトラスト用途の鍵は HSM に保管しなければなりません。
- 鍵と署名のアクセス制御を徹底する: ポリシーを策定して鍵のアクセス制御を実施し、承認された開発者とユーザーのみが、必要なときに、特定の鍵で署名できるようにします。鍵が共有、紛失、盗難されないよう、鍵はクラウド上で生成します。職務分離を実施します。つまり、鍵を生成する人と署名する人の職務を分離します。多要素認証（MFA）を導入し、署名にアクセスしようとしている人が本人であることを確認します。退職した人、署名や鍵生成へのアクセスが必要なくなった人のアクセス権を取り消します。
- 鍵の署名ワークフローを監視/監査する: 誰がいつ何に署名したかを追跡します。そうすることで、不正な署名に素早く対応し、適切な是正措置を講じることができます。鍵ペアにまつわるすべてのアクティビティ（生成、証明書の運用、鍵および署名のアクセス権の割り当てなど）を定期的に監査します。
- 暗号化基準について最新情報を入手し全社的なポリシーを実施する: 組織がサイバー脅威に前もって対処できるよう、業界要件が変更になることがあります。新しい CA/ブラウザフォーラム要件では、2021 年 6 月 1 日から、パブリックに信頼されるコードサイニング証明書およびタイムスタンプ証明書の鍵の最低要件として 3072 ビット RSA と定めています。組織内の開発者やユーザーは、鍵を生成したりコードに署名をしたりする際、その変更に気付くこともあれば気付かないこともあります。ユーザーが脆弱な、あるいはコンプライアンスに違反するアルゴリズム、鍵サイズ、暗号強度を用いて鍵を生成したり証明書を申請したりしないよう、組織が業界要件をきちんと守らせる必要があります。
- SDLC プロセスで自動コード署名を有効にする: コード署名を CI/CD パイプラインなどの SDLC （ソフトウェア開発ライフサイクル）プロセスに統合して自動化することで、署名されていないコードや、コンプライアンスに違反する署名のリスクを軽減できます。自動化と合わせてセキュリティ制御を設定することで、継続的かつスピーディーなソフトウェア開発のペースはそのままに、安全かつコンプライアンスに準拠したソフトウェアをビルドできます。
- 異なるビルドサーバーの署名を比較する: 最近のソフトウェアサプライチェーン攻撃は、世界中の影響力の大きい組織に業務的にも経済的にも多大な混乱を引き起こしています。悪意のある攻撃者がターゲット組織の開発業務に侵入し、SDLC 中にコードにマルウェアを埋め込みます。この改ざんされたコードが後に公開され、顧客システムに展開されたケースもありました。リリース前に署名を行い、異なるビルドサーバーのソフトウェアのハッシュ値を比較し、サーバービルド間に不一致がないかを確認します。一定の複数の数のビルドが同一であることを確認することで、ビルドが安全であり、未知のコードがビルドに含まれていないことを証明できます。
- 危殆化された証明書を失効させる: 危殆化された鍵や署名されたマルウェアを発見した場合、認証局（CA）に報告してください。コードサイニング証明書を失効させることによって、ソフトウェアを無効化し、マルウェアのさらなる拡散を阻止する必要があります。
- 署名済みコードにタイムスタンプを付与する: コードサイニング証明書の有効期限切れにより、ソフトウェアが予期せずに失効するリスクを回避します。コードサイニング証明書の有効期間は 1 ～ 3 年です。コードサイニング証明書の期限が切れると、署名時にタイムスタンプが押されていない限り、署名されたソフトウェアの有効性も失われます。タイムスタンプはシステムに記録され、ソフトウェアの生産が続けられている限り有効性が保たれます。コードにタイムスタンプを付与するもう 1 つの理由は、証明書が失効した場合の影響を最小限に抑えるためです。マルウェアが発見され、関連する証明書を失効させなければならなくなった場合でも、タイムスタンプが付与されていれば、失効は侵害日以後にリリースされたソフトウェアのみに適用されるため、その影響を最小限に抑えることができます。
