巨額の罰金だけでなく…まもなく本格適用「EUサイバーレジリエンス法」企業の対策は？

ありがとうございます！
いいね！した記事一覧をみる

会員（無料）になると、いいね！でマイページに保存できます。

EUで新たに導入されるサイバーセキュリティ規制「サイバーレジリエンス法（CRA）」への対応が、日本の製造業にとって喫緊の課題となっている。この法律は、EU市場で製品を販売する企業に対し、製品ライフサイクル全体にわたる厳格なセキュリティ対策を義務付けるものだ。対応が遅れれば、巨額の罰金や市場からの締め出しといった厳しいペナルティーが科される可能性がある。多くの企業が情報収集を進める一方、具体的に何から手をつけるべきか、その全体像をつかみきれていないのが現状ではないだろうか。

残された時間は決して長くない…

（Photo/Shutterstock.com）

迫りくるタイムリミット、製造業が直面する「3つの壁」

　2022年9月に草案が発表され、急速に法制化が進むEUサイバーレジリエンス法（以下、CRA）。この法律は、IoT機器をはじめとする「デジタル要素を持つ製品」に広範なサイバーセキュリティ要件を課すもので、違反した企業には最大で全世界年間売上高の2.5％または1,500万ユーロのいずれか高い額の制裁金が科される可能性がある。

　特に注目すべきは、脆弱性に関する報告義務だ。製品に起因するインシデントや、悪用された脆弱性を認識した場合、24時間以内に欧州ネットワーク・情報セキュリティ庁（ENISA）への報告が義務付けられる。この報告義務は2026年9月から施行される予定であり、残された時間は決して長くない。

　多くの製造業が、この新たな規制への対応に苦慮している。ある専門家は「多くの企業が、まず要件を理解する段階でつまずいている」と指摘する。CRAが要求するのは、単一の技術的な対策ではない。製品の企画・設計から開発、運用、廃棄に至るまでのライフサイクル全体を見据えた、包括的なセキュリティ体制の構築が求められているからだ。具体的には、以下の3つのステップで対応を進める必要がある。

1. 要件の理解：
まず、自社製品がCRAの対象となるか、どの分類に該当するのかを正確に把握
2. 体制の整備：
次に、セキュリティを担保するための組織体制や開発プロセスを構築・見直す
3. 実践活動：
最後に、整備した体制とプロセスを実際の製品開発や運用に適用し、継続的に改善

　現在、多くの企業が「体制の整備」の段階で課題に直面している。従来の開発プロセスにセキュリティをどう組み込むか、専門知識を持つ人材をどう確保・育成するか、そして、それらを支える技術やツールをどう選定するか。こうした課題を乗り越えなければ、CRAの要求を満たすことはできない。では、どうすればこの複雑な課題を克服し、効果的な製品セキュリティ体制を構築できるのだろうか。

「人」の壁を越える：製品セキュリティ推進体制の構築

　「CRA対応を成功させるためには、全社的な取り組みが不可欠です」と切り出したのは、マクニカの飯田洋平氏だ。続けて、「特に人（People）、プロセス（Process）、システム（System）の3つの要素が重要になります」と指摘する。特に「人」、つまり組織体制の構築がその基盤となる。

マクニカネットワークスカンパニー
営業統括部セキュリティコンサルティング部
部長
飯田洋平氏

　飯田氏が提示するモデルでは、経営層、管理層、実務層の3階層で役割を分担する。まず、経営層には製品セキュリティ担当役員を置き、多くの場合、品質担当役員がその役割を兼任する。これは「製品セキュリティが品質の一環である」という考え方に基づいている。

　その下で、全社の品質管理部門などが管理層として機能し、製品セキュリティ委員会やPSIRT（Product Security Incident Response Team）といった組織を設置する。製品セキュリティ委員会は、各事業部や開発部の代表者が集まり、全社的な方針決定や情報共有、教育計画などを議論する場となる。一方、PSIRTは、製品の脆弱性情報を収集・分析し、対応を主導する専門チームだ。

　「特にPSIRTは、社外からの脆弱性報告の窓口となり、インシデント発生時には迅速な対応を指揮する司令塔の役割を担います。24時間以内の報告義務を遵守するためには、このPSIRTの機能が極めて重要になります」と飯田氏は強調する。

公開脆弱性情報の管理体制

「プロセス」の確立：全社標準と事業部の裁量を両立させる

　次に重要なのが、組織が動くためのルール、すなわち「プロセス」の整備だ。これには、社内規程や開発標準の策定が含まれる。飯田氏は、既存の品質マネジメントシステム（QMS）と連携させる形で、製品セキュリティに関する文書体系を構築することを推奨している。

　この体系は、全社共通の「基本方針」を頂点に、「管理基準」「手順」「ひな型」といった階層構造で構成される。たとえば、「脆弱性管理基準」では脆弱性への対応方針を定め、「脅威分析手順」では具体的な分析手法を定義する。

製品セキュリティの関連プロセス

　ここで課題となるのが、全社的な統一ルールと、各事業部の裁量のバランスだ。飯田氏は、企業の組織構造に応じて3つのパターンを提示する。

パターンA：
全社では基本方針と共通基準のみを定め、具体的な手順は各事業部に委ねる。事業部が少ない企業に向いている。
パターンB：
全社で脆弱性管理手順までを標準化し、設計開発の詳細は事業部に任せる。バランスの取れたモデル。
パターンC：
脆弱性対応からインシデント対応まで、ほとんどのプロセスを全社組織が管理する。中央集権的な統制が求められる場合に有効だ。

　「自社の事業部の数や製品の多様性を考慮し、どこまで標準化し、どこから各事業部の裁量とするかを見極めることが、実効性のあるプロセスを構築する鍵となります」と飯田氏はアドバイスする。

「システム」の実装：セキュア開発とリスクアセスメント

　適切な組織（人）とルール（プロセス）が整ったら、それを実行するための「システム（技術）」を導入する。CRAでは、製品の設計・開発段階からセキュリティを組み込む「セキュア開発ライフサイクル（SDL）」の実践が求められる。

セキュア開発プロセスの全体像

　このプロセスでは、まず「脅威分析」や「リスク評価」を行い、製品に潜む脆弱性を洗い出す。その結果に基づきセキュリティ要件を定義し、設計・実装へと進む。開発段階では、ソースコードの静的解析（SAST）ツールなどを活用して、コーディングレベルでの脆弱性を早期に発見することが重要だ。

　評価フェーズでは、ネットワークスキャンや脆弱性診断、ファジングテストといった動的なテストを実施し、未知の脆弱性も含めて徹底的に洗い出す。飯田氏は、「特にファジングテストやペネトレーションテストは、製品固有の脆弱性を発見する上で有効ですが、コストもかかるため、製品のリスクに応じて実施対象を絞るなど、費用対効果を考慮する必要があります」と語る。

開発プロセスにおいて実施すべきセキュリティテスト

CRAが求める「完全性保護」に必須の技術要素

　CRAが特に重視するのが、データの「完全性（Integrity）」の保護である。これは、データが不正に改ざんされていないことを保証する考え方だ。

　たとえば、「セキュリティアップデートによる脆弱性への対応」では、アップデートファイルが改ざんされていないことを確認するため、デジタル署名による検証が求められる。「不正アクセスからの保護」では、認証情報の通信をTLSなどで暗号化し、盗聴や改ざんを防ぐ必要がある。さらに、「プログラムの完全性の保護」として、ソフトウェア自体が不正に書き換えられていないかを検証する仕組みも要求される。

付属書要件における完全性保護および鍵管理の必要性

　「これらの要件に対応するためには、デジタル署名や暗号化の基盤となる『鍵管理』が非常に重要になります。鍵が漏えい・悪用されれば、せっかくのセキュリティ対策も意味をなさなくなってしまいます」と飯田氏は警鐘を鳴らす。

　EUサイバーレジリエンス法への対応は、単なる法規制遵守にとどまらない。製品のライフサイクル全体にわたってセキュリティを確保する体制を構築することは、企業の信頼性を高め、グローバル市場での競争力を維持するための不可欠な投資と言えるだろう。施行までの限られた時間の中で、自社の状況を正確に把握し、「人・プロセス・技術」の三位一体で着実な準備を進めることが求められている。

【回答目安1分】本記事をご覧いただきアンケートにご協力ください。

※回答者の中から抽選で20名様にAmazonギフト券500円をプレゼント。
※お一人につき1回のみ回答が可能です。複数回の回答をされますと以降のサービスご利用をお断りすることがございますので、ご注意ください。

関連タグタグをフォローすると最新情報が表示されます

法規制・レギュレーション

印刷機能のご利用には
会員登録が必要です。