WP.29法規対応とCSMS/SUMSの実装ガイド - 半導体事業

条件を指定して絞り込む

現在2026件がヒットしています。check

基礎ソフトウェア端末セキュリティネットワーク ETAS

こちらのページでは、WP.29とは何か、関連する法規のUN-R155やUN-R156の詳細と実装方法などを説明し、マクニカとして取り扱いのあるイータス社での具体的なソリューションを紹介しております。

WP.29とは何か？

WP.29は、国連欧州経済委員会（UNECE）が定める自動車関連の国際法規の枠組みです。近年、自動車のソフトウェア依存度が高まる中で、サイバーセキュリティやソフトウェアアップデートに関する法規制が強化されており、UN-R155（CSMS）およびUN-R156（SUMS）が新たに導入されました。

また、日本国内でも、国土交通省が型式認証制度にこれらの法規を取り入れていることもあり、自動車メーカーの実施要件と監査要件を確立することで、これらのリスクに対処するために4つの異なる分野にわたって対策を実施することが求められています。

車両のサイバーセキュリティの管理
バリューチェーンに沿ったリスクを軽減するための設計による車両の保護
保有車両全体のセキュリティインシデントの検出、対応
安全でセキュアなソフトウェアアップデートの提供、及び車両の安全性が損なわれないようにすることでの車両ソフトウェアの法的準拠の明確化

WP.29法規の構成と要件

冒頭に、UN-R155（サイバーセキュリティ管理システム：CSMS）とUN-R156（ソフトウェアアップデート管理システム：SUMS）について触れていますが、これらは自動車メーカーやサプライヤーが型式認証を取得する上で不可欠な要件となっています。

このセクションでは、WP. 29の法規体系とCSMSとSUMSが求める体制・技術・運用のポイントを理解することで、法規対応の全体像を把握し、実装に向けた準備を進めることを目的に、実務的な観点から整理して説明します。

UN-R155：サイバーセキュリティ管理システム（CSMS）

UN-R155は、自動車のサイバーセキュリティ対策を体系的に管理するための国際法規です。近年の車両はインターネットや外部デバイスと接続されることが増え、サイバー攻撃のリスクが高まっています。CSMSでは、こうしたリスクに対して「どのように評価し、どのような体制で管理するか」が求められます。

脅威分析（TARA）	車両の機能や通信経路に対して、どのような脅威があるかの分析（TARA：Threat Analysis and Risk Assessment）。
セキュリティ要件の定義	開発部門・品質管理部門・IT部門などが連携し、開発プロセスにおけるセキュリティゲートの設置。
監査と継続的改善	開発（設計段階）、生産（製造段階）、運用（市場投入後）それぞれで、CSMSのPDCAサイクルの確立。

UN-R156：ソフトウェアアップデート管理システム（SUMS）

UN-R156は、車両のソフトウェアアップデートを安全かつ確実に管理するための法規です。現代の車両は、走行後もソフトウェアの更新が必要となるため、アップデートの履歴や安全性の確保が重要です。

管理体制と記録保持	どの車両に、いつ、どのソフトウェアが更新されたかを記録し、追跡できるようにする。
OTAアップデートの安全性	無線通信によるソフトウェア更新を指すOTA（Over-the-Air）での、通信の暗号化や改ざん防止の仕組みを構築。
RxSWINの管理	RxSWIN（ソフトウェア識別番号）は、各ソフトウェアバージョンを一意に識別するための番号となり、アップデートの整合性とトレーサビリティを確保するため正確に管理。

このように、UN-R155とUN-R156はそれぞれ「セキュリティ管理」と「アップデート管理」に焦点を当てた法規であり、WP.29対応には両方の体制構築が不可欠です。
次のセクションでは、具体的な実装方法と要件について説明します。

サイバーセキュリティ管理システム（CSMS）の実装方法

以下では、具体的なCSMSの実装方法について紹介します。

脅威分析（TARA）

TARAは、脅威分析・リスク評価の略語となり、車両の使用シナリオに応じてどのようなサイバー脅威が存在するかを洗い出し、それに対するリスクを評価するプロセスです。

具体的な実装例：

走行中の車両が外部と通信する場面（例：V2X通信、OTAアップデート）を洗い出す。

各通信経路に対して、盗聴・改ざん・なりすましなどの脅威をリストアップ。

脅威ごとに「発生可能性」「影響度」をスコア化し、優先順位を決定。

具体的な対策例：

暗号化通信、認証機構、ファイアウォールの導入。

セキュリティ要件の定義

開発プロセスの各段階で、セキュリティ対策を明示的に設けることが求められます。これにより、設計ミスや脆弱性の早期発見が可能になります。

具体的な実装例：
要件定義フェーズ：	セキュリティ要件を機能要件と並列で定義（例：ECUはセキュアブートを必須とする）。
設計フェーズ：	セキュリティゲートを設置し、設計レビューで脅威対策の有無をチェック。
実装フェーズ：	暗号ライブラリの使用、セキュアな通信プロトコルの採用。
テストフェーズ：	ペネトレーションテストやファジングテストを実施。

監査と継続的改善（PDCAサイクル）

CSMSは一度構築して終わりではなく、継続的に改善していく必要があります。PDCA（Plan-Do-Check-Act）サイクルを回すことで、セキュリティレベルの維持・向上が可能です。

具体的な実装例：
Plan：	セキュリティ方針の策定、リスク評価の更新。
Do：	対策の実施（例：ソフトウェア更新、脆弱性修正）。
Check：	監査・レビューの実施。インシデント発生時の対応状況を評価。
Act：	改善策の導入。新たな脅威への対応方針の見直し。

運用例：

半期ごとにCSMSレビュー会議を開催し、リスク評価と対策状況を更新。

インシデント発生時には、原因分析と再発防止策をCSMSに反映。

ソフトウェアアップデート管理システム（SUMS）の実装方法

以下では、具体的なSUMSの実装方法について紹介します。

管理体制と記録保持

SUMSでは、どの車両に、いつ、どのソフトウェアが更新されたかを記録し、追跡できる体制の構築が求められます。これは型式認証や法規対応の根幹であり、トレーサビリティの確保に不可欠です。

具体的な実装例：

車両のライフサイクル（企画・設計・開発・生産・市場・廃車）に応じたアップデート管理フローを構築。

ECUごとのRxSWIN（ソフトウェア識別番号）を一元管理し、更新履歴を記録。

更新実施後は、記録保持システムに「更新日時」「対象ECU」「RxSWIN」「バージョン」「更新理由」などを自動登録。

OTAアップデートの安全性

OTA（Over-the-Air）アップデートは、無線通信によるソフトウェア更新方式です。通信の暗号化、改ざん防止、署名検証、リカバリ機能などのセキュリティ対策が必須です。

具体的な実装例：

通信経路にTLSなどの暗号化技術を導入。

アップデートパッケージに電子署名を付与し、ECU側で検証。

更新失敗時のロールバック機能（A/Bバンク構成）を実装。

RxSWINの管理

RxSWIN（Rx Software Identification Number）は、各ソフトウェアバージョンを一意に識別するための番号です。これを正確に管理することで、アップデートの整合性とトレーサビリティが確保されます。

具体的な実装例：

ECUごとにRxSWINを割り当て、更新時に変更の要否を判定。

RxSWINの一貫性とトレーサビリティを確保するため、構成管理システムと連携。

型式認証に必要なRxSWIN履歴を提出できる体制を整備。

実装事例と業界動向

欧州の動向

欧州の自動車メーカーでは、CSMS（Cyber Security Management System）、SUMS（Software Update Management System）の導入が義務化されています。2022年7月以降に型式認証を取得する新型車両に対して、これらのシステムの導入が必須となっており、主要な自動車メーカーではすでに体制構築を進めています。

国内の動向

国土交通省がUNECEの規制に準拠する形で制度整備を進めており、CSMS/SUMSの導入が型式認証取得の要件となる方向で動いています。2022年以降、新型車両に対してCSMS/SUMSの導入が求められるようになり、国内の自動車メーカーやサプライヤーも対応を急いでいます。特に、OTAアップデートやコネクテッドカーの普及に伴い、ソフトウェアの安全性と更新管理の重要性が増しているため、SUMSの整備が急務となっています。

サイト内検索

目次