衛星にファイアウォールは必要か？～宇宙セキュリティにおける衛星搭載ファイアウォールの研究～

公開日：2026.09.09　更新日：2026.09.09

はじめに

こんにちは、グローバル戦略部の韓欣一（かんしんいち）です。

地上のITシステムでは、セキュリティ機能としてのファイアウォールは一般に広く知られていますが、地球軌道上の衛星にも同じような考え方を適用できるのでしょうか。また、衛星にファイアウォールを搭載するとすれば、どのような通信を監視し、どのように異常を判断するのでしょうか？

今回は、この「衛星におけるファイアウォールをどう考えるか」という課題に着目した我々の研究を紹介します。

本研究の成果は、Kyung Hee Universityとの共同研究論文「CCSDS-based firewall for modern satellite system」として、Elsevierの国際学術誌「Computers & Security」に掲載されました。同誌は情報セキュリティ分野でQ1に区分される国際学術誌です。

本ブログでは、地上のITシステムとは異なる衛星特有の環境や制約を整理したうえで、衛星通信で広く利用されるCCSDSの仕組みと、本研究で衛星にどのようなファイアウォールを考えたのかをご紹介します。ファイアウォールの検知アルゴリズムや実機OBCを用いた詳細な評価結果について興味を持っていただけた方は、ぜひ原著論文もご覧ください。

原著論文は現在、以下のリンクより全文を無料で閲覧できます。

CCSDS-based firewall for modern satellite system（最新の衛星システム向けCCSDSベースのファイアウォール）

※無料公開期間は10月中旬に終了予定です。その後は通常の購読条件での閲覧となります。

なお、本研究でいう「ファイアウォール」は、IPアドレスやポート番号を見て通信を制御する一般的なネットワークファイアウォールを、そのまま衛星へ搭載することを狙うものではありません。CCSDS通信をプロトコルレベルで監視し、設定不備や非標準の実装、通信上の異常などを検知する、衛星向けの軽量なセキュリティ監査機能です。

衛星にファイアウォールという考え方は適用できるのか？

地上のIT環境では、ファイアウォールは一般的なセキュリティ対策の一つです。では、地上ネットワークで一般的なファイアウォールという考え方を人工衛星にも適用し、衛星自身が受け取る通信の状態を監視することはできるのでしょうか。

これが今回の研究の出発点です。

人工衛星も内部にはコンピュータを搭載しており、地上局から送られてきたコマンドを受け取り、姿勢制御、電力管理、ミッション機器の操作などを行っています。一方、人工衛星は地上のITシステムとは異なる環境で運用されています。

その違いの一つが通信環境です。衛星と地上局の通信は無線で行われます。衛星から送信される電波は、物理的には特定の受信機だけに届くものではなく、一定の範囲に広がって伝搬します。また、地球周回衛星の位置はTLE（Two-Line Element）などの公開情報から予測できるため、衛星がいつ観測地点の上空を通過するのかを推定することも可能です。

そのため、十分な無線設備や技術を持つ第三者であれば、対象となる周波数や衛星の通過時刻を把握し、衛星通信の信号にアクセスすること自体は可能です。

もちろん、「衛星の電波を受信できる、あるいは衛星へ電波を届けられる」ことと、「衛星上で不正なコマンドを実行できる」ことは全く別の話です。そのため衛星通信においても、暗号化や認証、過去に送信された正規の通信を再利用するリプレイ攻撃への対策などが重要になります。また、本研究が対象とするのは、第三者が直接無線で衛星へ攻撃するケースだけではありません。

地上システムの侵害や運用上の設定ミス、セキュリティ機能の誤実装などによって、形式上は通信できていても、セキュリティ上問題のある状態が衛星へ届くケースも対象としています。

もう一つ大きく異なるのが、衛星上で利用できる計算資源です。

地上のシステムであれば、必要に応じてCPUやメモリを増強したり、新しいセキュリティ製品を導入したり、機器そのものを交換したりすることもできます。一方、一度宇宙へ打ち上げられた衛星では、そう簡単にはいきません。

衛星では、限られたCPU、メモリ、電力などのリソースの中で、本来のミッションを実行する必要があります。宇宙空間では熱をどのように処理するかも重要な設計要素になります。機材が古くなった、若しくは壊れたからと言って簡単に修理したり交換したりすることは、少なくとも現在の技術では非常に難しいです。

そのため、単に高機能なセキュリティ機能を追加すればよいというわけではありません。セキュリティ機能そのものがCPUや電力を大きく消費したり、本来の衛星ミッションに影響を与えたりしてしまえば、実際の衛星には搭載できません。

こうした衛星特有の通信環境やリソース制約を前提として、地上側だけでなく衛星自身にも通信を監視するセキュリティ機能を持たせることができないか、その一つの方法として衛星搭載ファイアウォールを検討しました。

では、衛星上のファイアウォールは、実際にどのような通信を見ればよいのでしょうか。

我々は、衛星通信で広く利用されているCCSDSに着目し、これに準拠した通信を行う衛星システムを対象に、ファイアウォールの考え方や実装の可能性について検討しました。

衛星通信を理解するための「CCSDS」

このファイアウォールを理解するうえで、避けて通れないのが「CCSDS」です。

CCSDS（Consultative Committee for Space Data Systems）は、宇宙機と地上システムの間でデータをやり取りするためのさまざまな標準を策定している国際的な組織です。現在、多くの宇宙ミッションで、地上から衛星へ送るTelecommand（TC）や、衛星から地上へ送るTelemetry（TM）にCCSDSが策定した通信規格が利用されています。

ここで重要なのは、地上から送るコマンドが、そのまま一つのデータとして衛星へ飛んでいくわけではないという点です。

例えばTelecommandの場合、大まかには「Flight SoftwareのCommand」「Space Packet」「TC Transfer Frame」「CLTU（Communications Link Transmission Unit）」といった複数の構造に包まれて送信されます。

図：CCSDS Telecommandのカプセル化構造
出典：Im et al., “CCSDS-based firewall for modern satellite system,” Computers & Security, 2026, Fig. 1

例えばTC Transfer Frameのヘッダには、どの衛星向けの通信なのかを示すSpacecraft IDや、Frame Length、Frame Sequence Counterなどの情報が含まれています。このファイアウォールでは、こうしたCCSDSのプロトコル構造を利用して通信の状態を確認します。

また、CCSDSには通信を保護するための「SDLS（Space Data Link Security）」という仕組みがあります。SDLSでは、暗号化や認証、リプレイ防止などのセキュリティ機能をデータリンク層で提供します。一般的にはTransfer FrameのData Fieldが保護対象となる一方、ルーティングやプロトコル処理に必要なヘッダ情報などは観測可能な形で残ります。

「それならSDLSで暗号化しておけば、ファイアウォールはいらないのでは？」と思われるかもしれません。

しかし、暗号化機能が存在することと、それが常に正しく設定、実装、運用されていることは別の問題です。実際のシステムでは、設定ミス、独自のカスタマイズ、セキュリティ機能の誤実装なども考えられます。このファイアウォールはSDLSを置き換えるものではなく、暗号化や認証とは別のレイヤーで、衛星が受け取っている通信の状態を監視するための仕組みです。

※CCSDSパケット構造の詳細については原著論文もしくはCCSDSの仕様を参照ください。

CCSDS-based firewall for modern satellite system（最新の衛星システム向けCCSDSベースのファイアウォール）

衛星側に搭載するファイアウォールはどこで何をみるのか？

ファイアウォールを地上局側ではなく衛星側に搭載することを想定しています。地上側では、衛星と比較してCPUやメモリなどの計算資源に余裕があり、ネットワーク監視やログ分析、侵入検知など、利用できるセキュリティソリューションにも多くの選択肢があります。

一方で衛星側では、利用できるセキュリティ機能や計算資源が限られています。そこで、地上側での対策だけではなく、実際にコマンドを受け取る衛星自身にも通信を監視する機能を持たせることができないかを検討しました。（もちろん地上側にファイアウォール機能を持たせることも可能です）

設計したファイアウォールは、衛星のOBC（On-Board Computer）上で動作します。地上局から送られた信号が衛星側で受信、復調され、Flight Softwareなどへ渡される前の段階でCCSDS通信を確認します。また、衛星から地上へ送信するTMについても、変調・送信される前の段階で監視します。

ここで重要なのが、我々の考えるファイアウォールは、受信したコマンドの意味を一つひとつ理解して、「このコマンドは攻撃者が送った悪意のあるコマンドである」と判断する仕組みではないという点です。

ファイアウォールはCCSDSのフレームやパケットを解析し、CCSDSとして想定した構造になっているか、通信に不自然な状態が発生していないか、セキュリティ上問題となる設定や挙動が見られないか、といった点をあらかじめ設定したルールや閾値に基づいて確認します。

つまり、「誰が、どのような意図でこの通信を送ったのか」を推定するのではなく、「現在の通信がセキュリティ上問題のある状態になっていないか」を確認するという考え方です。

例えば、本来暗号化されるべき通信に暗号化されていない可能性がある状態が見られないか、TCのシーケンス番号に不自然な繰り返しや巻き戻り、ジャンプが発生していないか、といった複数のシナリオを設定して評価しました。各シナリオの詳細や検知アルゴリズムについては、原著論文をご覧ください。ここでは、その中からTCのシーケンス番号を利用した異常検知を一例として紹介します。

衛星ミッションごとに「異常」の基準も変わる

CCSDSのTC Transfer Frameには、通信の順序を管理するためのシーケンス情報があります。通常の通信では一定のルールに従って番号が進みます。一方、同じ番号が何度も繰り返されたり、過去の番号へ戻ったり、想定しない形で番号が大きく変化したりする状態が続けば、通信上で何らかの異常が起きている可能性があります。

ただし、一度だけ想定外の番号が届いたからといって、それだけでサイバー攻撃と判断することはできません。再送や通信上の問題など、正当な理由によって同じような状態が発生することも考えられます。そのため一定の「時間窓」の中で、こうした異常がどの程度発生したのかを確認します。

ここで衛星ミッション特有の条件が関係してきます。

シーケンス番号を監視するという考え方自体は、宇宙特有のものではありません。一方、どのくらいの時間を観測し、何回発生したら異常と判断するのかは、衛星ミッションの運用に強く依存します。

低軌道衛星では、一つの地上局と24時間常時通信できるわけではありません。衛星がその地上局から見える間だけ通信でき、通常どの程度の頻度でコマンドを送るのか、どの程度の通信エラーが発生し得るのかもミッションによって異なります。

そのため、時間窓や異常回数の閾値をすべての衛星で同じ値に固定するのではなく、対象となる衛星ミッションに合わせて設定する考え方を採用しています。また、このファイアウォールは、ペイロードを復号してコマンドのミッション固有の意味まで理解することを前提としていません。

CCSDSの構造や通信挙動を中心に解析し、それぞれのミッションに応じたパラメータや閾値を設定することで、異なる衛星システムにも検知ロジックを適用しやすい設計としています。

セキュリティ機能を衛星に載せても、本当に動くのか

ここまでの話で、「考え方は分かったが、そのようなファイアウォールの処理を本当に衛星上で動かせるのか？」という疑問を持たれる方もいると思います。

これ非常に重要なポイントです。ファイアウォールが高い検知能力を持っていても、CPUを大量に消費したり、電力消費が増えたり、処理遅延や発熱によって衛星本来のミッションへ影響してしまっては、本末転倒です。

そこでまずNASAのcFSをベースとしたシミュレーション環境を用いてファイアウォールを実装、評価したうえで、さらに実際のCubeSat級ミッションで利用される2種類のOBCでも動作を検証しました。

一つがEnduroSat OBC、もう一つがGomSpace NanoMind A3200です。

写真：評価に使用したEnduroSat OBC

写真：評価に使用したGomSpace NanoMind A3200

評価では単に「ファイアウォールが動作したか」だけではなく、

・CPU負荷

・処理時間

・電力消費

・OBCの温度

・メモリ使用量

・通信処理性能

など、実際に衛星へセキュリティ機能を搭載するうえで重要となる項目を確認しました。特に、衛星に新しい機能を搭載する場合、CPUや電力だけでなく、発熱によって衛星の熱設計にどの程度影響を与えるかも考える必要があります。宇宙空間では地上のように大気の対流によって熱を逃がすことができないためです。また、EnduroSatとGomSpaceではCPUアーキテクチャや利用可能なリソースも異なるため、それぞれのハードウェア条件に合わせて実装を最適化しました。

その結果、今回評価した環境では、CubeSatのようなリソース制約のあるハードウェア上でも、既存の衛星処理と両立しながらCCSDS通信を監視できる実現可能性を確認しました。各セキュリティチェックがCPU、電力、温度などへ具体的にどの程度影響したのかについては、原著論文のPerformance Evaluationで詳しく評価しています。

さいごに

本研究に関連する技術については、例年8月に米国ラスベガスで開催されるDEFCON Aerospace VillageでKyung Hee Universityと共同でデモ展示を行いました。

DEFCONでは、衛星通信を題材としたセキュリティデモとして来場者の方々に研究内容の一部を紹介しました。その後、検知ロジックの整理や異なるOBCへの実装、CPU、電力、温度などの性能評価を進め、研究成果として本論文の発表につながっています。

研究室・会議室の中だけで検証するのではなく、研究、実装、セキュリティコミュニティでの展示を経て、さらに評価を深め、論文化するという形で取り組みを進めてきました。

　本研究では、「地上ネットワークでは一般的なファイアウォールという防御の考え方を、衛星にも適用することはできないか」という問いから、CCSDS通信を監視する衛星搭載型ファイアウォールを設計し、シミュレーション環境だけでなく、実際のCubeSat向けOBCを用いて性能を評価しました。このファイアウォールは、SDLSなどの暗号化や認証機能を置き換えるものではありません。暗号化や認証に加えて、衛星自身が受け取る通信の状態を監視することで、衛星システムのセキュリティを多層的に考えるための一つの仕組みとして位置づけています。

本ブログでは、衛星システム特有の環境、CCSDSの通信構造、衛星搭載ファイアウォールの基本的な考え方、そして衛星へセキュリティ機能を実装する際の性能評価についてご紹介しました。ここでは取り上げなかった検知シナリオの詳細、検知アルゴリズム、実機OBCへの最適化方法、CPU、電力、温度等の具体的な評価結果について興味を持っていただけた方は、ぜひ原著論文をご覧ください。