欧州の「EUサイバーレジリエンス法（EU Cyber Resilience Act：CRA）」では、域内でデジタル製品を販売する製造業等に対し、セキュリティ確保の観点から「ソフトウェアの完全性」を維持する責任を求めている。しかし段階的に義務的な効力が適用されていく現状において、製造業の現場では法的要件を把握してもまだ最終的に準拠すべき明確な基準が発表されていないため、実際にどう守るのか、どこまで対策すべきか測りかねる状況が続いている。
ZDNET Japanでは2025年12月17日、製造業を対象としたオンラインセミナー「ZDNET Japan Security Seminar――CRA対応の核心：ソフトウェアの改ざん防止と秘密鍵保護、製造業の現場で何ができるのか」を開催。法制度の読み解きに加えて、今から取り組むべき「改ざん防止」「署名管理」「秘密鍵保護」といった実装面での最適解を提示し、法対応を形式ではなく実効性へとつなげるための視点を紹介した。
CRA発効に伴い製造業が直面する新たな責任とは
基調講演に、サイバーセキュリティ法務を主業とする、アレシア国際法律事務所 代表弁護士 有本真由氏が登場。「EUサイバーレジリエンス法に伴い製造業が直面する新たな責任」と題して、CRAの全体像と製造業が今後直面する実務的なインパクトについて解説した。
冒頭で有本氏は、EUサイバーレジリエンス法の概要を説明。同法は頭文字を取って「CRA」と略されるが、正式名称を日本語に訳すと「デジタル要素を備えた製品に対する水平的サイバーセキュリティ要件に関する規則」となる。「水平的」とは「一律に何らかの要件を適用する」ことを意味するもので、それまでデジタル製品のセキュリティに関する一律の規律がなかったため、デジタル要素を備えた製品（以下、デジタル製品）のサイバーセキュリティを確保するための水平的な規律としてCRAが導入された形となっている。
CRAは2024年12月10日から効力が発生しているが、その下で課せられる義務については、2026年9月11日から「インシデント通知と脆弱性の報告」について適用が開始され、2027年12月11日から「それ以外の義務」が課される。従って全面適用は2027年12月11日以降に上市された対象製品となるが、その際の注意点として有本氏は、「『上市』とは、商業活動の一環として有償・無償を問わず、EU市場での頒布または使用のためにEU市場で『初めて』供給すること。リリースが2027年12月前であっても個々の製品がEU市場に乗るのがそれ以降の場合は義務を守らなければならない」ことを挙げた。
CRAの適用範囲と対象となる製品と製造業の義務
CRAが適用範囲とする製品は、「（1）市場で提供される（2）デジタル製品であって、（3）その本来の用途または合理的に予測可能な使用に、デバイスまたはネットワークへの直接・間接なデータ接続が含まれるもの」となる。デジタル製品とは、「ソフトウェアまたはハードウェア製品およびそのリモートデータ処理ソリューション（クラウドソリューション）」で、その際にソフトウェアとハードウェアのコンポーネントも含まれる。例としては、PCやスマートフォン、スマートホーム製品、モバイルアプリなどで、接続が想定されないスタンドアロン製品は対象とならない。医療機器や自動車製品、航空機機器なども対象外だが、それらはすでに規律があるので適用除外という形になる。
対象デジタル製品は、「一般的なデジタル製品」「重要デジタル製品 クラスⅠ」「同クラスⅡ」「重大デジタル製品」に分けられ、「必須とされるサイバーセキュリティ要件は同じだが、カテゴリー別に順守する際に使う統一標準（規格）が異なる。適合性評価の手続きも、一般的なデジタル製品は自己評価だが、それ以外は第三者が介在する」（有本氏）という。
一般的なデジタル製造業者に課される義務としては、中核となるのが「必須サイバーセキュリティ要件の順守」だという。順守にあたっては、自社製品のサイバーリスク評価を実施する必要があり、第三者から部品等を調達する場合、そこにも注意義務を負う。その上でそれらを具備していることを示す「技術文書」を作成して、適合性評価を実施し、「EU適合宣言」を作成して製品に「CEマーク」を付ける。そのほかに、脆弱性対応ポリシーを作成しサポート期間を決める。ここまでは上市前の義務で、上市後には各種文書の保管、継続的なセキュリティアップデート提供などに加え、インシデント・脆弱性の通知・報告があるとしている。
製造業者に課される義務
必須セキュリティ要件をどう守り実装するか
必須サイバーセキュリティ要件は、「製品の特性」と「脆弱性」に関するものがあり、それらはCRA付属書Ⅰに記されている。その中で、製品の特性に関する必須サイバーセキュリティ要件としては、（1）「デジタル製品は、“リスクベースで”適切なレベルのサイバーセキュリティを確保するように設計、開発、製造されなければならない」、（2）「サイバーセキュリティリスク評価に基づき、該当する場合は、(a)既知の悪用可能な脆弱性がない状態で市場に提供する、(b)別段の合意がない限りデフォルトでセキュアなコンフィギュレーションで市場に提供する―など、aからmまでの13項目の条件を満たさなければならない」と規定され、該当する場合それらをどのように実装したかを技術文書に含めて文書化することが求められている。
技術文書は上市前に作成し、上市後もサポート期間中は継続的にアップデートする必要がある。必要的記載事項は付属書Ⅶに記載されているが、その中から有本氏は項目５の「事業者において適用した統一標準、共通仕様、欧州サイバーセキュリティ認証制度のリスト。それらを適用していない場合は、必須サイバーセキュリティ要件を満たすために採用されたソリューションの説明」に注目。「事業者としては、製品を統一標準に沿って必須サイバーセキュリティ要件に準拠させるのが最も効率・効果的で、仮に何かあった場合当局に説明しやすい」と説明する。
しかし、肝心な統一標準はまだ存在せず、前述した製品の必須サイバーセキュリティ要件（1）に対する統一標準は2026年8月30日まで、（2）の要件に対する統一標準は2027年10月30日までに作成される予定である。すると発表を待っていては間に合わないため、有本氏は「事業者としてはこれまでの技術的知見に則って、だいたいこうなるだろうと想定しながら動かなければならない」と指摘する。
その際に参考になる資料として有本氏は、EUサイバーセキュリティ機関の欧州ネットワーク・情報セキュリティ機関（ENISA）から出ている報告書を紹介。そこでは、EUが策定した共通サイバーセキュリティ認証制度である「EUCC（European Union Cybersecurity Certification）」で利用されている保護プロファイルを利用してCRAを実装していくことが提案されている。保護プロファイルとは、製品をカテゴリー分けし、それぞれがどのようなセキュリティ要件を備えればよいかまとめたもので、現在EUで有効とされる保護プロファイルは約300種類存在している。
「報告書内にCRAの必須要件とEUCCで使われているコモンクライテリアの規格をマッピングした表もあるので、参照してほしい。ただEUCCとCRAでは差分があり、それらに対しては別の物差しを使って必須要件を順守していく必要が出てくるので、技術者の知見を総合的に活用して対応していく必要がある」と有本氏は推奨手順を示す。
違反した場合は25億円の制裁金
それらの必須要件に準拠できていない場合、製品の是正、回収、リコールが命令され、応じない場合は制裁が加えられる。「必須サイバーセキュリティ要件に順守していない場合、その他の義務に違反している場合は、1500万ユーロ（約25億円）か直前の会計年度売上総額の2.5％のいずれか高い方を上限とする制裁金が課される。制裁の程度はGDPRに匹敵するレベルなので、順守にあたっては十分に注意を払う必要がある」（有本氏）
それらを受けて有本氏は、事業者がCRAに順守するために実施しておくべきことの対応フローの例を以下の図にまとめた。その際には、第三者から製品を調達する際のサプライチェーンリスクマネジメントとして、調達先に契約書や誓約書で必要条件の順守を文書によって確認することも推奨している。
CRA対応で実施すべき事項とフロー
最後に有本氏はそのほかのリスクとして、2026年12月までに製造物責任（PL）指令が国内法化されて適用されることに言及。「CRAのサイバーセキュリティ要件にかかわる義務が適用される2027年にはPL指令が適用されている。事業者が必須サイバーセキュリティ要件に準拠していない場合、CRAに基づいて巨額な制裁金が課される可能性に加え、PL指令に基づき消費者側から訴えられるリスクも負う可能性があるので気を付けて欲しい」と注意を促した。
製造業が取るべき対応のベストプラクティス
次にマクニカ 営業統括部 セキュリティコンサルティング部 部長 飯田洋平氏が登場し、自らの業務経験も踏まえつつ、これから製造業が参照可能なベストプラクティスを解説した。同氏は製造業におけるCRA対応ステップを、「要件の理解」「社内体制の整備」「プロセスの整備」の３つに分けた上で、社内体制の整備を中心に説明を行った。
まず飯田氏はCRAが製造業者に直接影響を及ぼすポイントとして、第13条「デジタル製品の設計、開発、製造、販売、サービス運用後の各段階でサイバーセキュリティ必須要件を順守する義務」と、第14条「デジタル製品に係る報告対象の脆弱性・インシデント認識時に24時間以内にCSIRT・ENISAに対して報告する義務」を紹介。そこで求められる要件を製造業の開発プロセスに当てはめて、「製品設計・開発時では、技術・プロセス要件を充足さるため、『セキュアな開発プロセスの実施』『セキュリティ仕様および機能の実装』『調達部品のCRA対応状況の確認』が必要となる。上市時は、サイバーセキュリティ対応のエビデンス作成、CE認証取得の必要があるため、『CE認証取得に必要な技術文書の交換および提出』『ユーザー情報の開示』が求められる。上市後は、『重大なインシデントや脆弱性の悪用が確認された際のENISAへの報告』が求められる」と説明した。
製品開発時や上市時に必要な技術要件はCRA付属書Ⅰ-1に記されており、それらは（1）「脆弱性を最小化した構成」、（2）「データのセキュアな管理」、（3）「インシデント発生時の対策・影響軽減」に分類されるという。それぞれ代表的なものは、（1）では「悪用可能な既知の脆弱性の排除」「安全なデフォルト設定」、（2）では「保存・通信データの暗号化」「改ざん防止とプログラム・データの破損通知機能」「処理データの最小化」「内部保管されているデータやプログラム設定の永久削除機能」、（3）では「アクセスログ・変更ログの記録・監視」などとなっている。
第14条が規定する上市後の対応については、報告対象は「製品のセキュリティに重大な影響を与えるインシデント」と「積極的に悪用された脆弱性」になるという。まだその定義は確定していない状況だが、飯田氏は「前者に関しては、製品の気密性や完全性に影響を与えるもの。設計情報の流出も重大なインシデントとして考えられる。後者は、脆弱性が見つかっただけでなく、悪用の事実が確認された時点から報告が必要になってくる」と解説した。
製品セキュリティ実装体制構築の要件と実例
続いて飯田氏は、CRA準拠に向けた社内体制を構築する際のベストプラクティスを紹介。まずプロセスには、（1）「欧州展開製品の棚卸」、（2）「製品ごとにCRA製品クラスを精査」、（3）「製造業者の義務順守に向けた準備」、（4）「製品クラスに応じた適合性評価」の4ステップがあるという。その中で同氏は、「製品セキュリティやCRA対応を実施するためには、設計・開発・品質を保持できる組織体制や人材の『People』、実行する際のルールやガイドラインを整備する『Process』、プロセスや対策を実施する際の技術である『System』の3要素を考える必要がある」と強調し、それぞれを解説した。
CRA準拠に向けた活動の全体像
製品セキュリティのCRA対応に必要となる3つの観点
Peopleを各層に分けて考えると、経営層では品質の担当役員が製品セキュリティ領域を担う事が多いという。管理層では、製品開発におけるセキュリティ担保のルールやガイドラインを定め、それを品質管理担当役員の下に設置された品質管理部門の責任者が管理する形となる。その中で、製品セキュリティの方向性や状況の確認、外部動向等を話し合う「製品セキュリティ委員会」と、脆弱性の管理と対処をしていく「PSIRT」を運営し、その２つに各事業部・開発部の実務層が参加する形になるという。
Process面では、既存のQMS文書と整合性を図りつつ文書類を設計していく。文書体形としては、上から「基本方針」「基準」「手順」「ひな形」という構造となる。「全社の製品セキュリティ基本方針」から始まり、実務基準としての「製品セキュリティ管理基準」、脆弱性対処を全社で実施する際の「脆弱性管理基準」、外部から調達した製品等を管理する「サプライチェーンリスク管理基準」、実務レベルで実施していくための「脆弱性管理手順」、セキュア開発プロセスにおけるリスクアセスメントの「脅威分析実施手順」「セキュリティ検証手順」「インシデント対応手順」、さらに「実施手順において必要なひな形」までつながっていく。
Systemでは、製品単位でセキュア開発プロセスの実行が求められる。まず「企画・設計・開発」フェーズで、企画、要件定義、システム設計、ハード/ソフトの詳細設計・実装があり、そこからそれまでの工程を遡る形でテストを実施した後に「製造」のプロセスに移行し、その後「保守・運用」フェーズへと進んでいく。セキュア開発を実践するにあたっては、「設計までの領域はまだ人手で実施する形が現実的だが、セキュリティテストや脆弱性診断、SBOMの作成、脆弱性の管理についてはツールを活用することが有効」と飯田氏は説明する。
セキュア開発プロセスの流れ
脅威分析やリスクアセスメント対応の仕方については、（1）「ユースケース分析やデータフロー分析」、（2）「保護資産や重要なものの存在を洗い出す」、（3）「保護資産に対してどのインターフェースや攻撃接点からアクセスできるかを分析」、（4）「具体的に起きうる脅威シナリオと被害の分析」、（5）「被害影響度と発生可能性、リスクレベル算出」、（6）「対応方針や対応しない場合の理由の明確化」を検討していく。そこから次のステップとして、「対策案や対策の具体的な内容を考えていく」形となる。
最後に飯田氏は、CRAにおける「完全性保護」に言及。付属書では、「Ⅰ-1(c)、セキュリティアップデートによる脆弱性への対応」「Ⅰ-1 (d)、適切な制御メカニズムによる不正アクセスからの保護」「Ⅰ-1(e)、強力な暗号化技術などによるデータの保護」「Ⅰ-1(f)不正な操作・変更からの、データ・プログラムなどの完全性の保護」に要件が記されているが、「それらで書かれている真正性を確保するためのデジタル署名や暗号化、認証などを行う際には鍵管理が必要になってくる」と説明し、次のセッションにバトンを渡した。
CRA対応の鍵管理を効率的に実現するHSMとは
続いて、マクニカ セキュリティソリューション営業統括部 今西弘昴氏が登場し、製造業の設計・開発担当者に対し、HSM（ハードウェアセキュリティモジュール）による秘密鍵の安全な保護と署名プロセスの強化を中心に、CRA対応を効率的に実現するための実践的アプローチを解説した。
冒頭で今西氏は、CRA第13条の項目８と９内に記された、ソフトウェアのサポート期間の脆弱性対処義務と販売後にセキュリティアップデートを利用可能にするという項目を指摘。「今までのように売ってサポートをして終わりではなく、ソフトウェアアップデートなどのセキュリティ面を意識しなければならなくなっている」と注意を促した。
また、セキュリティ特性要件という付属書の中から、項目(c)の「セキュリティアップデートにより脆弱性に対処できること」と、(f)の「データやプログラムなどの完全性を許可されていない操作から保護」という文言に注目し、「OTA（Over The Air）によるアップデートの必要性と、Root of Trustの考え方でソフトウェア署名用の秘密鍵を管理する必要性が生ずる」と説明。「CRAで詳しい情報は出てきていないので、実際に他のレギュレーションも引用しながら必要な項目になり得る部分をお伝えしたい」と述べた。
今西氏はその際に参考になるサイバーセキュリティの国際規格として、産業用オートメーションおよび制御システムの「IEC62443-4-2」と、EUでの自動車向けの「UN-R155」を提示。「IEC62443-4-2への準拠は、CRA適応の裏付けになりやすいと言われている。その中で秘密鍵の管理に言及していることから、CRAでも同様なことが求められてくるだろう。UN-R155では、コードサイニング（コード署名）＋αで秘密鍵の管理が行われている」と説明した。
CRAで厳格な秘密鍵の管理が求められるなか、鍵管理の際には認証済み暗号モジュールの使用で高いセキュリティ基準を確保し、鍵の生成には認証された暗号モジュールを利用する必要性が生ずる。加えて改ざん耐性のある保管、秘密鍵のライフサイクル管理とアクセス制御が求められる。
その中で使われるのが、暗号の仕組みを使って行われるコードサイニング技術だ。まず専用アプリケーションなどで「公開鍵」と「秘密鍵」というキーのペアを生成。秘密鍵のデータを使って署名値を生成して、それを製品製造時にCPUやチップに書き込まれた公開鍵の情報と照合し、その鍵のペアは正しいものか製品の中で検証が行われる。署名の検証を行って正しければソフトウェアの起動を行い、正しくなければ起動しないという動きになる。
「秘密鍵が漏えいすると署名値を抽出できてしまい、コードサイニングを行っていても悪意のある第三者が署名をし、偽のソフトウェアがアップデートされることが危惧される。そのため秘密鍵はしっかり管理する必要があると、IEC62443-4-2やUN-R155でも言及されている」（今西氏）
ソフトウェアの完全性を担保するコードサイニングの仕組み
暗号鍵管理で意識するポイントとそれを実現するソリューション
今西氏は、ソフトウェア完全性を担保するにあたっての暗号鍵管理において意識すべきポイントとして、３つの要件を挙げる。
１つめは、「暗号鍵のライフサイクル管理」。暗号鍵の運用時には、認証された仕組みを使った安全な「生成」、耐改ざん性のある「保管」、アクセス制御などを通じた「使用」、セキュリティ維持のための「ローテーション」、完全消去をする「廃棄」という一連のライフサイクルを意識した鍵管理が重要になる。
２つめは、「HSMでの安全な暗号鍵保管」。HSMは、暗号処理をハードウェア上で実行する専用装置で、暗号鍵を安全に生成・保管できる暗号鍵の金庫のようなもの。サーバーやPC、ソフトウェアで鍵を管理する場合に比べ、機密情報の漏えいや秘密鍵の漏えい・改ざんリスクを大幅に低減できる。「高い耐タンパ性を備え、高速な暗号処理を提供し、金融や政府、製造業など厳格なセキュリティが求められる環境で利用されている」（今西氏）という。
３つめは、「適切なアクセス制御、アクセスログの管理」。「CRAでは製品のセキュリティ確保のために暗号鍵の安全な管理と適切なアクセス制御が求められる。適切なアクセス制御のためには、秘密鍵へのアクセスは最小限の権限を付与することと、アクセス履歴・操作ログの取得と監査、不要になった鍵や権限の迅速な無効化が求められる」（今西氏）
それらを実現するため、マクニカは製造業向けに、Thales社のHSM製品と、現場におけるHSMの利用を簡素化するソリューション「IDEA鍵管理システム」を組み合わせて提供している。双方を利用することで、HSMを使用する鍵や署名値を生成する際に、扱いやすい画面を通じて操作することが可能となる。
Thalesでは、ネットワーク型でリソース共有型の「Luna Network HSM」、サーバー組み込み型の「Luna PCIe HSM」、USB接続型の「Luna USB HSM」の３ラインアップを用意。またIDEA鍵管理システムには、鍵生成や暗号鍵の登録、鍵の参照、署名生成などの業務機能と、ID・パスワードを使ったログイン認証およびユーザー管理機能、ログ出力機能が備わっている。
マクニカが展開するHSMソリューションの構成図
「HSMと鍵管理システムを使用することで、製造現場に負荷をかけずにソフトウェア署名用の秘密鍵管理が実現できる。CRAで求められるソフトウェアの完全性の保護と担保を実現しようとする際には、まず我々が提供するソリューションを思い出して欲しい」（今西氏）
WACOCA: People, Life, Style.