車載IDPSは自社開発すべきか？ eBPF活用で見落とされがちな運用・保守の課題

要約

eBPFは、LinuxやAndroid Automotive環境においてカーネルレベルの内部の動作を詳細に可視化する技術として注目されています。そのため、一部の自動車メーカーでは、eBPFを活用して独自の侵入検知・防御システム（IDPS）を開発することを検討することもあるでしょう。しかし、自社開発はライセンスコストを抑えられるかもしれませんが、15年以上にわたる車両ライフサイクルを支えるには、継続的な保守・運用、法規制への対応、脅威インテリジェンスの維持、複数プラットフォームへの対応など、多くの見えにくいコストやリスクが伴います。本記事では、自社開発と商用ソリューション導入（Build vs. Buy）の判断において考慮すべきポイントを整理するとともに、自動車向けサイバーセキュリティには、初期開発だけでは実現できない継続的な取り組みが不可欠である理由を解説します。

eBPF（Extended Berkeley Packet Filter）は、この10年でLinuxカーネルにもたらされた技術の中でも特に注目を集める存在です。カーネルのソースコードを変更したり、安定性に影響を及ぼすカーネルモジュールを追加したりすることなく、カーネルレベルの詳細な可視化を実現できます。組込みソフトウェアの開発者にとっては、まさに強力な武器といえる技術です。

この技術の登場により、一部の自動車メーカーでは、自動車向け侵入検知・防御システム（IDPS）の導入方法を見直す動きも出始めています。Linuxベースで柔軟性の高いeBPFを活用すれば、自社の開発チームでAndroid Automotive向けホストIDPSを開発でき、商用IDPS製品のライセンス費用を削減できるのではないか、と考えるケースも少なくありません。

しかし、机上では魅力的に見えるこの選択肢も、現実とは隔たりがあります。開発用評価ボード上で動作するeBPFのプロトタイプと、数百万台規模の車両で15年以上にわたり安定稼働し、各国の規制や認証要件にも対応できる商用レベルのIDPSとでは、求められる要件が異なるからです。

例えば、3年後にAndroid Automotive OS（AAOS）のカーネルが更新された際、自社開発したeBPFプローブは問題なく動作し続けるでしょうか。また、型式認証の監査で脅威検知の根拠や運用実績の提示を求められた場合、誰がその対応を担うのでしょうか。このような運用・保守・コンプライアンスに関わる課題は、システムの総保有コスト（TCO）を大きく左右します。

では、IDPSを自社開発することは本当にコスト削減につながるのでしょうか。それとも、将来的に多額の維持・運用コストを招く選択となるのでしょうか。本記事では、「Build vs. Buy（自社開発か商用ソリューション導入か）」という観点から、自動車メーカーが意思決定を行う際に検討すべき重要なポイントを解説します。

eBPFプローブの維持・運用に潜む高いコスト

組込みソフトウェアアーキテクトの視点から見ると、eBPFはシステム全体のオブザーバビリティを実現するための非常に魅力的な技術です。システムコール（sys_enter、sys_exit）やカーネルトレースポイントにプローブをアタッチすることで、プロセスの実行状況やネットワークソケットの生成、ファイルアクセスなどをリアルタイムに監視できます。しかし、自動車業界のようにプラットフォーム構成が多様な環境では、こうした独自のeBPFプローブを長期間維持・運用するためには、継続的な開発・保守負荷が発生します。

1. カーネルバインディングとCO-REの限界

eBPFプログラムは、カーネル内部のデータ構造にバインドして動作します。そのため、カーネルのバージョンによって内部構造が変更されると、プローブが正常に動作しなくなる恐れがあります。こうした課題に対処するため、エンタープライズLinuxの世界ではCO-RE（Compile Once – Run Everywhere）という仕組みが広く利用されています。Android Automotive OS（AAOS）が採用する最新のGeneric Kernel Image（GKI）上でもCO-REは有効に機能します。GKIカーネルにはBTF（BPF Type Format）が組み込まれており、eBPF Verifierがロード時にフィールドアクセスを適切に再配置（リロケーション）できるためです。そのため、「Android AutomotiveではCO-REが使えないから自社開発は難しい」という説明だけでは十分ではありません。知見のあるアーキテクトであれば、その認識は誤りであると指摘するでしょう。

とはいえ、維持・運用コストがなくなるわけではありません。実際の課題は、CO-REではカバーできない領域にあります。

CO-REが解決できるのは、あくまで構造体のフィールドオフセットの違いです。一方で、トレースポイントの名称変更やシステムコールの引数変更、eBPFヘルパーAPIの廃止など、カーネルの仕様そのものが変化した場合には、検知ロジックを人手で修正しなければなりません。さらに、SoCベンダー独自のカーネルモジュールやボード固有のドライバーは、GKIが保証する互換性の対象外です。しかし実際には、こうした領域こそが車載IDPSにとって監視すべき重要な対象となるケースも少なくありません。加えて、量産車両は単一のカーネル環境ではありません。複数世代の車両、異なるSoC、さらにはGKI導入以前のプラットフォームまで含めた幅広い環境を、10年以上にわたってサポートし続ける必要があります。こうした環境では、CO-REだけですべての互換性を維持することはできません。

つまり、CO-REは継続的な保守負荷をなくす技術ではなく、その負荷を限定的かつ専門性の高いものへと変えた技術だと言えます。そして、その専門的な保守作業を15年以上にわたり、提供するすべてのプラットフォームで担い続ける体制を社内で維持する必要があるのです。

2. eBPF Verifierという高いハードル

eBPFプログラムによってカーネルの安定性が損なわれることを防ぐため、LinuxカーネルにはeBPF Verifierと呼ばれる検証機構が組み込まれています。このVerifierは、プログラムを実行前に解析し、ループの複雑さやプログラムサイズ、メモリアクセスなどに厳しい制約を課します。

そのため、複数の攻撃ステップを組み合わせた高度なサイバー攻撃を検知できるだけの検知ロジックを実装しながら、同時にVerifierの厳格な条件をすべて満たすeBPFプログラムを開発するには、高度で専門的な知識が求められます。

さらに注意すべきなのは、開発環境のわずかな変更でも予期せぬ影響が生じる可能性があることです。例えば、ClangやLLVMといったコンパイラツールチェーンをアップグレードしただけで、生成されるeBPFバイトコードが変化し、これまで問題なく動作していたプログラムがVerifierによってロード時に拒否されるケースがあります。この場合、車両そのものが動かなくなるわけではありません。しかし、eBPFプログラムはロードされず、セキュリティ機能だけが停止した状態になる恐れがあります。しかも、その異常をOSやセキュリティ運用担当者がすぐに検知できるとは限りません。結果として、本来は保護されているはずのシステムが、気付かないうちに監視機能を失ったまま稼働し続けるというリスクが生じます。

3. パフォーマンスへの影響と膨大なデータノイズ

システムコールのログを収集するだけでは、テレメトリを取得しているに過ぎず、脅威を検知しているわけではありません。例えば、eBPFプログラムでネットワークパケットやプロセス実行イベントをすべてフックし、その情報をユーザー空間へ転送して解析する設計を採用した場合、次のような大きな課題が生じます。

・CPU負荷の増大

カーネル内でのセキュリティ処理に加え、カーネル空間とユーザー空間の間で継続的にデータをコピーする必要があるため、テレマティクスやインフォテインメントシステムのCPU使用率が15～30％に達することもあります。その結果、本来優先されるべき車載アプリケーションやユーザー向け機能の性能に影響を与える可能性があります。（一方、実運用を前提に最適化された商用セキュリティエージェントでは、カーネル内で不要なデータを事前にフィルタリングする仕組みを採用することで、CPU負荷を3％未満に抑えているケースもあります。）

・データノイズによる運用負荷

ソフトウェア・デファインド・ビークル（SDV）では、ホストから生成される未加工ログだけでも膨大なイベントが発生します。これらの一次データをそのままクラウドへ送信すれば、モバイル通信費やクラウドへのデータ取り込み・保存コストは急激に増加します。一方で、クラウドへ送信しない場合は、車載側でイベントを分析・相関付けし、有効な脅威だけを抽出する必要があります。そのためには、高い検知精度と低いリソース消費を両立したローカル検知エンジンが不可欠ですが、そのような仕組みをゼロから開発することは極めて高度で複雑な取り組みとなります。

UN-R155型式認証で見落とされがちな現実

開発部門やコンプライアンス担当者にとって、自社開発は一度限りの研究開発費と捉えられがちです。しかし、現在の法規制環境におけるサイバーセキュリティは、一度実装すれば終わりという機能ではありません。

UN-R155では、自動車メーカーはサイバー脅威を継続的に検知・対応するための体系的なプロセスを構築・運用していることを証明する必要があります。そのため、車両の型式認証においては、自社開発したeBPFスクリプトを提示するだけでは十分な説明とはみなされません。監査では、次のような客観的なエビデンスの提示が求められます。

• ASPICEに準拠した、厳格なソフトウェア開発プロセスを実施していることを示す証跡
• 脅威分析・リスク評価（TARA）と、実装したセキュリティ対策との間で双方向のトレーサビリティが確保されていることを示す資料
• セキュリティエージェントが、極端な負荷条件下においても車両の安全性や性能、システムの安定性へ悪影響を及ぼさないことを証明する検証・妥当性確認（Verification & Validation：V&V）の結果

こうしたIDPSを自社開発する場合、コンプライアンス担当部門は数百ページにも及ぶ安全性・セキュリティ関連の文書を作成し、継続的に維持・更新しなければなりません。つまり、UN-R155への対応で求められるのは、単にソフトウェアを開発することではありません。開発した仕組みを文書化し、その妥当性を監査で継続的に説明・立証できる体制まで含めて維持することが求められるのです。

ソースコードライセンスの購入は「Build」の延長線上にある

こうした課題を踏まえ、一部の自動車メーカーでは「完成したIDPS製品を導入するのではなく、既存のIDPSのソースコードを一度購入し、その後は自社で保守・運用すればよいのではないか」という選択肢を検討することがあります。

一見すると、自社開発と商用製品導入の中間的なアプローチに思えるかもしれません。しかし実際には、保守・運用の責任を自社で負うという点で、「Build（自社開発）」に近い選択と言えます。

ソースコードを購入できたとしても、それは高度で複雑なシステムの一時点の成果物に過ぎません。そのソフトウェアを支えてきた専門知識や開発ノウハウまで引き継げるわけではありません。さらに、複数のハードウェアやOS環境で品質を維持するために必要な、自動テスト環境や継続的インテグレーション（CI）パイプライン、回帰テスト環境なども含まれないケースが一般的です。これらを自社で維持・更新していくには、相応の開発体制と継続的な投資が求められます。

さらに重要なのが、脅威インテリジェンスです。Android Automotiveや特定のSoCを標的とした新たなゼロデイ脆弱性が発見された場合、静的なソースコードだけでは新しい脅威に対応できません。IDPSの検知性能は、最新の攻撃手法に合わせて検知ルールやポリシーを継続的に更新できるかどうかに大きく左右されます。そのため、セキュリティリサーチチームが最新の脅威情報を継続的に収集・分析し、検知ルールや修正プログラムを迅速に提供できる体制がなければ、時間の経過とともにソフトウェアは最新の脅威への対応力を失い、保守負荷やセキュリティリスクが高まる可能性があります。

現実の車載アーキテクチャはマルチプラットフォームで構成されている

Android AutomotiveやLinuxは、インフォテインメントシステムの中核を担うプラットフォームとして広く採用されています。しかし、実際の車両アーキテクチャは、それだけで構成されているわけではありません。

セーフティークリティカルなドメインや高性能コンピューティング（HPC）領域、先進的なテレマティクスシステムでは、QNXをはじめとするマイクロカーネルOSが現在も数多く採用されています。しかし、QNXはeBPFをサポートしていません。そのため、Linuxとは異なる仕組みを用い、カーネルコールアウトやシステムページ監視、専用のリソースマネージャーなどを組み合わせた別のアプローチが必要になります。

つまり、Linux、Android、QNXといった異なるOS環境に対して、一貫したセキュリティポリシーを適用できる統合型のセキュリティエージェントを構築するには、各OSの内部実装まで理解した高度なクロスプラットフォーム開発の知見が不可欠です。こうした専門性を長期にわたって社内だけで維持することは、多くの自動車メーカーにとって容易ではありません。

PlaxidityXが自動車メーカーの開発・運用負荷を支援します

PlaxidityXは、10年以上にわたり、世界中で数百万台規模の車両をサイバー脅威から保護するとともに、自動車メーカーのコンプライアンス対応を支援してきました。その経験を通じて、車載セキュリティには、高い防御性能だけでなく、車載システムの制約を考慮した軽量性や運用性が不可欠であると考えています。こうした考えのもと、PlaxidityXは、自社開発に伴う運用・保守負荷を抑えながら、現代の車載プラットフォームへ導入しやすい統合型の車載サイバーセキュリティアーキテクチャを提供しています。

このASPICE準拠のアーキテクチャでは、LinuxおよびAndroid Automotive向けには、本番環境での利用を前提に最適化したeBPFベースの実行層セキュリティエージェントIDPXを採用しています。一方、QNX環境では、マイクロカーネル向けのネイティブ計測技術を利用し、それぞれのOSに最適な形で監視・保護を実現します。さらに、IDXMが車両全体のセキュリティ情報を集約・分析する中核コンポーネントとして機能します。AUTOSAR IdsMなどのように標準的な車載ログをリッチOS環境まで拡張するとともに、エッジ側でインテリジェントにイベントをフィルタリングすることで、不要なデータを削減し、通信量やクラウド処理コストを最大80％削減できます。

自社開発と比較した場合、PlaxidityXのIDPSは、実運用を想定したAPIを備えており、既存の開発プロセスへスムーズに統合できます。これにより、開発チームはセキュリティ基盤の維持ではなく、ユーザー価値を高める車両機能やサービスの開発へ注力できます。また、継続的なサブスクリプションサービスとプラットフォームSLAを通じて、保守・運用やアップデートにも対応しています。車載エージェントは、世界中から収集される自動車向け脅威インテリジェンスと連携し、新たな脅威に対応する検知ルールやセキュリティアップデートを継続的に受け取ることができます。さらに、UN-R155への対応に必要な監査向けドキュメントやコンプライアンス関連資料も整備されているため、認証取得や監査対応に伴う文書作成・維持の負荷軽減にも貢献します。

まとめ：開発リソースを本来の競争力に集中させるために

eBPFを用いたパケットフィルタやシステムコールロガーの開発は、技術的には非常に有益な取り組みです。しかし、それを15年以上にわたって運用可能な、自動車向けのIDPSへと発展させるには、マルチプラットフォーム対応や継続的な保守・アップデート、法規制対応まで含めた長期的な取り組みが必要になります。

そして、eBPF Verifierへの対応やコンパイラ変更への追従、UN-R155監査に必要な文書整備といった作業に開発リソースを割くことは、本来であればユーザー体験の向上やADAS、SDV機能など、製品の競争力を高める開発に充てられる時間を減らすことにもつながります。

eBPFは優れたオープンソース技術ですが、その導入コストだけでなく、長期的な運用・保守やセキュリティ対策に伴う総保有コスト（TCO）まで含めて評価することが重要です。自動車サイバーセキュリティに特化したパートナーを活用することで、OEMは技術的・運用的・法規制上の負担を軽減しながら、開発リソースを本来注力すべき製品価値の向上へ集中できるようになります。