ソフトウェアの信頼性確保のためのコードサイニング証明書の新基準
DigiCert（デジサート）は、信頼される認証局事業者を目指すTLS（SSL）/PKI ベンダーのリーダーで、日本ではデジサートジャパン合同会社の名で活動している。シニアセールスエンジニアの中村圭祐氏は証明書の役割と、コード署名用証明書（コードサイニング証明書）の重要性について語った。
暗号化（情報漏えい防止）、署名（改ざん防止）、認証（なりすまし防止）の3つの機能を有している。サーバー証明書はサービスの信頼性を確認するために用いられる一方で、コードサイニング証明書は、ユーザーにそのアプリケーションが信頼性のあるものであることを示すために用いられる。ソフトウェアの配布がデジタル化された現代において、この証明書はコードの真正性を示す重要なメカニズムとなっている。
中村氏は、さまざまなソフトウェア署名セキュリティインシデントの事例を紹介した。PCメーカーASUSのBIOS改ざん検知機能のマルウェア被害や、それによる海運企業での大規模な再インストール被害、ソーラーウインズ社のサプライチェーン攻撃などが挙げられた。特にソーラーウインズ社の攻撃後に米国政府は、「国家のサイバーセキュリティ強化について」という大統領令を発布し、ソフトウェアのコンポーネント情報（SBOM）の提出が求められるようになった。また、コロニアルパイプラインへのランサムウェア攻撃など、社会全体に影響を与える事件が増えており、それに伴い対策としてのポリシーやフレームワーク策定の必要性が高まっている。
中村氏は、多くのインシデントで証明書の秘密キーが安全でない場所に保存されていたと説明。この課題を解決するために認証局ブラウザフォーラム（CA/ブラウザフォーラム）がコードサイニング証明書の基準を改定。新基準では、秘密キーは認定ハードウェアに保存することが求められ、2023年6月1日から適用された。CA/ブラウザフォーラムは、デジサートをはじめとする認証局、インターネットブラウザ、安全な電子メールソフトウェア、オペレーティングシステム、その他のPKI対応アプリケーションのベンダーが集まって、業界ガイドラインを公布する自発的なコンソーシアムだ。
コードサイニング証明書の新基準により、ファイル形式での証明書のやり取りや従来のコード署名プロセスの使用が禁止され、ソフトウェア開発チームへ大きな影響が出ている。特に、自動化技法CI/CDを行う開発チームにとって大きな問題となっていると指摘した。
証明書新基準は、開発現場においてさまざまな影響を与えている
続いて中村氏は、そのコードサイニング証明書をローカルの環境、あるいはリモートのビルドアンドデプロイ環境に直接配置し、従来型のコード署名を行う方法が、ソフトウェアベンダーにとってリスクを引き起こす理由について説明した。コードに署名する理由は3つ。1つはマルウェアの拡散を防ぐため。2つ目は、ソフトウェアが会社を代表するものとして、その身元を確認し、コンプライアンスを維持するためだ。そして3つ目はセキュリティ警告を回避するためだ。しかしながら、コード署名の管理は難しく、これが脆弱性を生み、サイバー犯罪者がこれを突く方法を探し始めていると言われている。
署名キーは盗難に対して脆弱だ。ユーザー間で共有されていたり、あるいは安全でないストレージに保管されていたりすると、盗まれやすくなる。すべてのアプリケーションを同じキーで署名する運用をしている組織もあり、盗難にあってしまうと改修の影響が大きい。署名に対する説明責任や権限管理もなく、割り当てられた担当者が署名をしていて、監査証跡もない状況だという。
署名キーが盗難にあった場合、なりすましによる署名やマルウェアの混入に使われてしまうリスクが大きい。正しい証明書として配布、インストールされるのでユーザーは気づかない。そのような被害を出してしまったソフトウェアベンダーは、修復コストもかかるし、ブランドへも悪影響を及ぼしてしまう。
中村氏は、コードサイニング証明書の基準の変更によって影響を受けた以下3つの事例を紹介した。
- 1つ目は分散開発環境での物理的なハードウェアトークンの必要性による問題。特に、全員がビルド担当や開発メンバーが社外の人の場合、ハードウェアトークンの管理が難しくなる。
- 2つ目はCI/CDの自動化問題。ハードウェアトークン導入により、署名の段階で人手が必要となり自動化が妨げられる。
- 3つ目は内製コード署名システムの強化問題。ハードウェアトークンでは解決しきれず、HSMの導入が必要だが、専門的な知識と維持費用が必要となり、負担が増える。
コード署名を盛り込んだCI/CDパイプラインを再構築しコストを削減した事例
中村氏は、このような課題解消のためには署名管理ツールが有効であるとし、デジサートのソリューションを説明した。署名管理ツールでは、開発者チームは既存のビルドプロセスを変えずに、安全かつ高速なリモートのコード署名をビルドプロセスに組み込める。誰がいつどのモジュールに署名したかを追跡可能となるため、従来の課題を解決できる。
「DigiCert ONE」は、コード署名の「Software Trust Manager」ほか複数の管理アプリケーションを配置し、シングルサインオン環境で管理アプリケーションを自由に行き来しセキュリティを実現するプラットフォーム。コンテナベースで常に新しい機能を提供し、またクラウド／オンプレミスどちらにも展開可能となっている。アプリケーション開発者は必要に応じたセキュリティ機能を随時適用できるメリットがある。
Software Trust Managerでは、一般的な開発からデリバリーまでのプロセスの環境に影響を与えず、デジサートのコード署名サービス基盤と連携する。ハードウェアトークンなどの要件はこのサービス基盤が満たすため、ユーザーは秘密キーの管理を意識することなく開発に集中できる。インターネットに接続できる環境は必要であるものの、現在の開発環境では問題がないだろう。
中村氏は、このソリューションを活用してCI/CDパイプラインを見直し開発の効率化を果たしている会社事例を紹介した。最初の段階では、MicrosoftのSigntoolを使用し、GitHub社が提供するElectronというビルドツールを活用し、USBトークンレスコードサイニングを実現した。次の段階では、GitHub ActionsというクラウドCI/CDサービスとデジサートのコード署名サービス基盤を接続してビルドパイプラインを新しくした。GitHub Actionsではビルドにかかる時間に対して課金されるため、時間のかかる処理を外部に出すことで、コスト削減も実現した。
このようなクラウドCI/CDツールとの統合によるビルドでは、サーバレスビルド環境を利用することでビルドサーバーの維持費などのコスト削減にもつながるという。同社のサービスに対する顧客の声について中村氏は「今までできなかった自動化ができたので、人件費の削減などビルド運用の効率化に評価をいただいております」と述べた。
Software Trust Managerは、有名なCI/CDプラットフォームなどさまざまなエンタープライズシステムと統合可能だ。中村氏は、そのなかでもReversingLabs社のシステム「Threat Detection」を使ったアプリケーションの脆弱性テストの提供について説明した。これはソフトウェアのバイナリをスキャンして、その結果としてSBOMとリスク分析レポートを出力する。リスクがなければ、先に説明した大統領令の規制要件に対応できる。
ビルドやテストを行っているチームは、動作テストには注意を払うが、マルウェアに関するテストを行っていない場合も多い。デジサートでは、コードが書き換えられたかをチェックする機能「Reproducible Builds（再現可能なビルド）」や期待するリリース成果物との不一致をキャプチャすることで、マルウェア混入のリスクを低減する機能「Deterministic Compilation（決定論的コンパイル）」なども提供している。
攻撃対象となっているのはなりすましのみではないため、署名キーの保護だけでは不十分で、ソフトウェア開発工程内にも対策が必要である。それに対しての厳格なキー管理では不十分で、コードスキャンも必要である。CI/CD環境など、人間の手を介さない自動化された開発環境が進んでいる今、その環境が壊れてしまうという問題は喫緊の課題となる。中村氏は最後に「デジサートならこれらの課題全て解決できます。ぜひご相談ください」と呼びかけた。
詳細および問い合わせはこちらよりご確認ください。
