証明書新基準は、開発現場においてさまざまな影響を与えている
続いて中村氏は、そのコードサイニング証明書をローカルの環境、あるいはリモートのビルドアンドデプロイ環境に直接配置し、従来型のコード署名を行う方法が、ソフトウェアベンダーにとってリスクを引き起こす理由について説明した。コードに署名する理由は3つ。1つはマルウェアの拡散を防ぐため。2つ目は、ソフトウェアが会社を代表するものとして、その身元を確認し、コンプライアンスを維持するためだ。そして3つ目はセキュリティ警告を回避するためだ。しかしながら、コード署名の管理は難しく、これが脆弱性を生み、サイバー犯罪者がこれを突く方法を探し始めていると言われている。
署名キーは盗難に対して脆弱だ。ユーザー間で共有されていたり、あるいは安全でないストレージに保管されていたりすると、盗まれやすくなる。すべてのアプリケーションを同じキーで署名する運用をしている組織もあり、盗難にあってしまうと改修の影響が大きい。署名に対する説明責任や権限管理もなく、割り当てられた担当者が署名をしていて、監査証跡もない状況だという。
署名キーが盗難にあった場合、なりすましによる署名やマルウェアの混入に使われてしまうリスクが大きい。正しい証明書として配布、インストールされるのでユーザーは気づかない。そのような被害を出してしまったソフトウェアベンダーは、修復コストもかかるし、ブランドへも悪影響を及ぼしてしまう。
中村氏は、コードサイニング証明書の基準の変更によって影響を受けた以下3つの事例を紹介した。
- 1つ目は分散開発環境での物理的なハードウェアトークンの必要性による問題。特に、全員がビルド担当や開発メンバーが社外の人の場合、ハードウェアトークンの管理が難しくなる。
- 2つ目はCI/CDの自動化問題。ハードウェアトークン導入により、署名の段階で人手が必要となり自動化が妨げられる。
- 3つ目は内製コード署名システムの強化問題。ハードウェアトークンでは解決しきれず、HSMの導入が必要だが、専門的な知識と維持費用が必要となり、負担が増える。
