ISO 21434（自動車サイバーセキュリティ）とは何か
🧭 はじめに
ISO 21434 は、自動車（車載ECU・車載ネットワーク・ソフトウェア・クラウド連携など）を対象にした サイバーセキュリティの国際規格です。 一言でいうと、「車がネットワークにつながることによって発生する脅威（攻撃）に対して、開発から運用まで一貫して安全性を確保するための“やり方（プロセス）”」を定めます。
ISO 26262（機能安全）が「故障による危険」を扱うのに対し、ISO 21434 は「攻撃による危険」を扱うのが中心です。
ISO 21434 は「セキュリティ機能の実装カタログ」ではなく、組織と開発のプロセスを整える規格です。
🌍 ISO 21434 が必要になった背景
🛰️ コネクテッド化により攻撃面（Attack Surface）が増えた
現代の自動車は、次のような入口（攻撃の入り口）を持っています。
- 車載LAN（CAN / Ethernet）
- OTA（Over-The-Air）アップデート
- スマホ連携（Bluetooth / Wi-Fi）
- クラウドと常時接続（テレマティクス）
- ADAS/自動運転向けの高性能計算機・複雑なソフトウェア構成
これにより「車を物理的に壊す」以外にも「車をリモートから不正操作する」リスクが現実的になりました。
車両に通信経路が増えるほど、攻撃者が入り込める場所も指数的に増えます。
⏳ 自動車は“製品寿命が長い”
自動車は10年以上使われることが普通です。 つまり 出荷後に脆弱性が見つかる前提で設計・運用する必要があります。
「出荷時点で問題がない」だけでは不十分です。出荷後に発覚する脆弱性を直せない設計は、長期的に重大なリスクになります。
🎯 ISO 21434 の適用範囲（ざっくり）
ISO 21434 は、暗号方式や通信仕様のような「技術の正解」を定める規格ではありません。 基本的には、開発～運用を通じたサイバーセキュリティの活動プロセスを定めます。
対象は広く、概ね以下を含みます。
- 車両全体（Vehicle）
- システム、ECU、ソフトウェア
- 車内ネットワーク
- クラウドやバックエンド連携（境界条件として考慮）
- 開発・製造・運用・保守
- サプライチェーン（OEM / Tier1 / Tier2...）
実務では「車載だけ」では完結せず、クラウドやスマホアプリとの境界をどう扱うかが難所になりがちです。
🧠 ISO 21434 の中心概念：リスクベース
⚖️ 「リスク」とは何か
ISO 21434 で扱うリスクは、大雑把に言うと次の組み合わせです。
- 攻撃が成功する可能性
- 攻撃が成功したときの被害の大きさ
これらを元に、対策の優先度を決めます。
サイバーセキュリティでは「絶対安全」は現実的に不可能なので、リスクを合理的に下げる考え方がベースになります。
🧨 TARA（Threat Analysis and Risk Assessment）
ISO 21434 の核になる活動が TARA（脅威分析とリスク評価）です。
- Threat（脅威）を洗い出す
- 攻撃経路（Attack Path）を考える
- 影響（Impact）を評価する
- リスクとして順位づけする
- 必要な対策（セキュリティ要求）に落とす
TARA が弱いと、後工程の「要求・設計・検証」が全部ブレます。TARA は全工程の根拠です。
🔁 ISO 26262（機能安全）との関係
🧩 扱う“原因”が違う
- ISO 26262：故障（ランダム故障、設計不具合）
- ISO 21434：攻撃（悪意ある人間の介入）
🔗 現実には結びつく
例えば、攻撃によってブレーキ制御に介入できるなら、それは安全リスクに直結します。 そのため実務では、次が相互に影響します。
- 21434 のセキュリティ要求
- 26262 の安全要求
機能安全とサイバーセキュリティを“別部門の話”として扱うのではなく、要求・アーキ・検証の整合性を取るのが現実的です。
🏗️ ISO 21434 のライフサイクル観点（開発～運用）
ISO 21434 は「設計・実装時点の安全」だけではなく、運用を含む全期間を対象にします。 ここが ISO 21434 の重要なポイントです。
🧱 1) コンセプト段階
- 何を守るべきか（資産：Asset）
- どこが攻撃されうるか（入口）
- 大枠のセキュリティゴール（Security Goal）
🛠️ 2) 開発段階
- セキュリティ要求定義
- アーキテクチャ設計（分離、最小権限、境界設計）
- 実装（セキュアコーディング）
- 検証（脆弱性診断、侵入テストなど）
🏭 3) 生産・リリース段階
- 製造工程での改ざん防止
- 鍵管理、証明書管理
- 出荷形態（デバッグ口の無効化など）
🧯 4) 運用・保守段階（ここが本質）
- 脆弱性対応（PSIRTなど）
- インシデント監視・対応
- OTAでの修正配布
- 継続的なリスク再評価
運用フェーズが弱いと「脆弱性が見つかったが直せない車」になります。これは設計不備と見なされます。
🧰 “成果物を作る”規格であって、“強い暗号を使う”規格ではない
ISO 21434 は次のような「技術の決め打ち」をする規格ではありません。
- AESを使え
- TLS 1.3必須
- 鍵長は256bit
- 署名方式はこれ
代わりに、以下のような プロセスとして成立しているかを重視します。
- 設計判断の根拠が残っていること
- 攻撃シナリオと対策のトレーサビリティ
- 変更に追随できる運用体制
暗号や認証方式は「その時点のベストプラクティス」が変化します。だからこそ ISO 21434 は仕組み（プロセス）に寄っています。
🔗 サプライチェーン問題：OEMだけでは完結できない
車載ソフトウェアは典型的に、以下の集合体です。
- OEM（完成車メーカー）
- Tier1（システムサプライヤ）
- Tier2（部品サプライヤ）
- OSS利用
つまり「どれか1社が完璧」でも成立しません。
- どの範囲を誰が責任持つか
- どの情報を誰に渡すか（脅威・要求・前提）
- どこで合意するか（契約、成果物）
が整備されていないと破綻します。
サプライチェーンで崩れる典型は「責任分界が曖昧」な状態です。“言った／聞いてない”が起きる構造は危険です。
✅ ISO 21434 を導入する価値（実務メリット）
📌 1) “セキュリティの説明責任”を満たす骨組みになる
後から事故・不正が起きたときに、
- 何を想定して
- どう評価し
- 何を実施したか
を説明できることが重要です。
規格準拠は「事故ゼロ保証」ではなく、合理的な取り組みを行った証明として意味を持ちます。
📌 2) 「とりあえず暗号」「とりあえず診断」を避けられる
よくある失敗として、以下があります。
- 強い暗号を入れたが鍵管理が壊滅
- ペネトレしたが直す仕組みがない
- 脆弱性が出てもOTAできない
点だけ強くても線になっていないと破綻します。 ISO 21434 は「線として成立しているか」を重視します。
📌 3) 出荷後対応まで含めた現実的な品質になる
自動車のサイバー対策は、出荷時に終わりません。 運用フェーズの設計が品質そのものになります。
⚠️ よくある落とし穴（ISO 21434 で崩れるポイント）
🕳️ 1) TARA が形骸化する
テンプレを埋めただけのTARAは意味が薄いです。
- 資産が曖昧
- 攻撃経路が雑
- リスク評価が主観のみ
- 対策が「一般論の羅列」
TARA が「雰囲気」で作られていると、以降の成果物は根拠のない対策集になります。
🕳️ 2) “対策すること”が目的化する
本来の目的は
- リスクを合理的に下げる
- 影響を許容範囲にする
ですが、現場では
- 証跡を埋めることが目的
- 文書を作ることが目的
になりがちです。
成果物の量が増えても、リスクが下がっていないなら意味がありません。
🕳️ 3) 運用を軽視する
PSIRTやOTA体制が弱いと、結局「脆弱性が直せない車」になります。
出荷後に直せない製品は、サイバーセキュリティの観点では未完成です。
🧾 まとめ
ISO 21434 は、自動車サイバーセキュリティにおける
- 脅威を分析し（TARA）
- リスクに基づいて要求を立て
- 開発・製造・運用まで含めて管理する
ための国際規格です。
技術の正解を固定するものではなく、 「長寿命・複雑・サプライチェーン型」の自動車でセキュリティを成立させるための プロセス規格だと捉えると理解しやすいです。