地上ネットワークのサイバーセキュリティ — RFリンクを守っても、その先が破られたら意味がない

この回で学ぶこと

SDLSの回で、探査機と地上局を結ぶRFリンク——コマンド認証の回で言えばアップリンクのTCフレーム、ダウンリンクのTMフレーム——を、MACによる認証や暗号化でどう保護するかを見ました。Security HeaderとSecurity Trailerをフレームに追加し、SPI(鍵インデックス)で鍵の世代を管理し、アンチリプレイカウンタで再送攻撃を防ぐ——これは間違いなく重要な防御層です。

しかし、ここであえて意地の悪い問いを立ててみましょう。探査機に向かう本物のコマンドは、そもそもどこで作られるのでしょうか。 SLEの回とMOサービスの回で見た通り、コマンドはミッション運用センター(MOC)の中でコマンド計画ソフトウェアによって生成され、MOC内部のネットワークを流れ、SLEのFCLTU(Forward CLTU)サービスなどを通じて地上局に送られ、そこで初めてCLTU化・変調されてRF信号として探査機に向かいます。SDLSが保護しているのは、この長い経路の最後の区間——地上局から探査機までのRFリンク——だけです。

もし攻撃者が、RFリンクにはまったく手を出さずに、MOCの内部ネットワークに不正侵入し、コマンド計画ソフトウェアそのものを乗っ取ってしまったらどうなるでしょうか。攻撃者が作らせたコマンドは、正規のMOCから、正規の鍵で、正規のSDLS認証タグを付けて送信されます。探査機側のFARMも、SDLSの検証も、何の異常も検出できません。なぜなら、そのコマンドは暗号学的には完全に「正規」だからです。 探査機のRFリンクをどれだけ堅牢に守っても、その手前にある地上ネットワークが破られていれば、防御全体が意味を失います。この回では、SDLSがカバーしない「地上局からMOCまでの地上系ネットワーク」というもう1つの攻撃対象領域と、それを守るための古典的なITセキュリティの考え方——多層防御(Defense in Depth)——が、なぜ宇宙ミッションの地上系にもそのまま必要になるのかを整理します。

直感的導入: 「金庫の鍵」と「金庫室に入るまでの道のり」

SDLSの回では、封蝋(ふうろう)と差出人証明シールのたとえを使いました。今回はもう1つ別のたとえで考えてみましょう。

ある銀行が、非常に頑丈な金庫を作ったとします。金庫の扉は最新の暗号技術で守られており、正しい鍵とダイヤル番号がなければ物理的にこじ開けることはほぼ不可能です。この金庫を、SDLSの回で見たRFリンクの認証・暗号化に対応させて考えてください。金庫そのものは非常に堅牢です。

しかし、その金庫が置かれている金庫室にたどり着くまでの道のりはどうでしょうか。銀行の正面玄関、廊下、金庫室のドア、そこに至るまでの警備員の配置——もしこれらのどこかにセキュリティの穴があり、部外者が易々と金庫室の前まで歩いていけてしまうなら、金庫の鍵そのものがどれだけ堅牢でも意味がありません。なぜなら攻撃者は金庫の鍵を偽造する必要すらなく、正規の鍵を持つ職員になりすまして、あるいは職員の隙をついて、正規の鍵で金庫を開けさせてしまえばいいからです。

宇宙ミッションの地上系における「金庫室にたどり着くまでの道のり」に相当するのが、地上局からMOCまでを結ぶ地上系ネットワークです。SLEの回で見たSLE接続、MOサービスの回で見たMOC内部のソフトウェアコンポーネント間の通信、そしてこれらを支える物理的なLAN・WAN配線やルータ・ファイアウォールといったIT基盤——これらはすべて、探査機の「金庫の鍵」であるSDLSとは独立に、それ自体として守られている必要があります。

攻撃対象領域(アタックサーフェス)の整理

まず、地上系ネットワークのどこが攻撃の対象になりうるのかを、地上セグメントアーキテクチャの回で整理した層構造に沿って洗い出してみましょう。攻撃対象領域(attack surface)とは、攻撃者が侵入・妨害を試みうる接点の集合を指す情報セキュリティの標準的な用語です。

攻撃対象	具体例	想定される脅威
地上局の制御システム	アンテナ制御装置(ACU)、受信機・復調器の設定用端末、地上局運用の自動化の回で見た自動運用シーケンスを実行する制御ソフトウェア	不正アクセスによるアンテナ誤指向、受信機設定の改ざん、制御ソフトウェアへのマルウェア感染
SLE接続を流れるデータ	SLEの回で見たBIND-START-TRANSFER-DATA-STOP-UNBINDのやり取り、地上局(プロバイダ)とMOC(ユーザ)間のネットワーク経路	通信の盗聴、フレームデータの改ざん、正規のBINDセッションへのなりすまし(セッションハイジャック)
MOC内部ネットワーク	MOサービスの回で見た監視制御・コマンド計画・軌道決定・アーカイブといった各ソフトウェアコンポーネント間のLAN	内部ネットワークへの不正侵入、ある1つのコンポーネントの脆弱性を足がかりにした横展開(ラテラルムーブメント)、コマンド計画ソフトウェアの乗っ取り
商用地上局サービス(GSaaS)との接続	地上局運用の自動化の回で見たGround-Station-as-a-Serviceを利用する場合の、事業者のWebベース予約システムやAPIとの接続	第三者委託先(サプライチェーン)の設備・アカウントを踏み台にした侵入、事業者側のセキュリティ水準がミッション側の要求を下回るリスク

この4つの攻撃対象を並べて見ると、共通する性質が浮かび上がります。どれも「探査機とのRFリンク」ではなく、地上の、しかも多くの場合は普通のIT機器・普通のネットワーク技術(イーサネット、TCP/IP、汎用OS上で動くソフトウェア)で構成された系であるという点です。つまりこれらは、探査機特有の脅威モデルというよりも、企業の社内ネットワークやデータセンターが日常的にさらされているのとまったく同じ種類の脅威——不正侵入、マルウェア、DDoS(Distributed Denial of Service、分散型サービス妨害)攻撃、フィッシングによる認証情報の窃取——にさらされます。

特に商用GSaaSの利用は、地上局運用の自動化の回で見た通り、大学の超小型衛星プロジェクトや予算の限られた新興事業者が地上局網を自前で持たずに運用を成立させることを可能にした一方で、セキュリティの観点からは「自組織が直接統制できない第三者の設備・ネットワークが、ミッションのコマンドパスの一部を構成する」というサプライチェーンリスクを新たに持ち込むことにも注意が必要です。この論点は後述の実務の節でもう一度扱います。

一番弱いところが全体の強度を決める

なぜ地上系のセキュリティが軽視できないのかを、もう少し定量的に考えてみましょう。ミッション全体のコマンドパスを、SDLSの回やSLEの回で見た区間ごとに分解すると、次のような直列の連なりとして描けます。

$$\text{コマンド計画} \;\longrightarrow\; \text{MOC内部LAN} \;\longrightarrow\; \text{SLE接続} \;\longrightarrow\; \text{地上局制御系} \;\longrightarrow\; \text{RFリンク(SDLS保護)}$$

地上セグメントアーキテクチャの回では、この種の直列系の可用性(故障しない確率)を扱いました。ある系が直列に並んでいるとき、系全体の可用性は各区間の可用性の積になり、どれか1区間の可用性が低ければ全体の可用性はその低い区間に強く引きずられます。セキュリティについても、これと同じ構造の議論が成り立ちます。ただし今回問題にするのは「壊れない確率」ではなく「破られない強度」です。

各区間 $i$ の防御強度を、突破に必要な労力やコストの目安として $S_i$ と表すことにすると、攻撃者は必ずしも一番手強い区間に正面から挑む必要はありません。攻撃者は防御強度が最も低い区間を選んで攻撃するため、実効的な全体の防御強度は、素朴には次のように見積もるのが自然です。

$$S_{\text{system}} = \min_i S_i$$

これは、可用性の直列系の式($A_{\text{system}} = \prod_i A_i$、積で悪化する)とは形が異なりますが、含意は同じ方向を向いています。どれだけ1つの区間を強化しても、他の区間が弱ければ、システム全体の防御力はその弱い区間の水準までしか上がらない。 RFリンクをSDLSの回で見たAuthenticated Encryption(AES-GCM相当)まで堅牢化しても、MOC内部LANのファイアウォールが未設定であったり、SLE接続が平文の旧式プロトコルのまま運用されていたりすれば、$\min_i S_i$ はそちらに支配され、探査機側の暗号強度は事実上意味を持たなくなります。

これが実際にどう危険につながるかを具体的に想像してみましょう。攻撃者がMOC内部ネットワークへの侵入に成功し、コマンド計画ソフトウェアの端末を乗っ取ったとします。この端末は、コマンド認証の回やSDLSの回で見たMACの鍵 $K$ そのものを保持しているわけではないかもしれませんが、その鍵を正しく使ってタグを計算する権限を持つ正規のソフトウェア一式を保持しています。攻撃者はMACの暗号解析を試みる必要すらなく、乗っ取った端末に「この不正なコマンドに対して正規の手順でタグを計算し、送信キューに載せよ」と実行させるだけで済みます。探査機のFARMやSDLSの検証ロジックにとっては、これは区別のしようがない完全に正規の手続きを踏んだフレームとして届きます。RFリンクの暗号強度は、この攻撃経路に対しては何の防御にもなっていません。

多層防御(Defense in Depth)の考え方

では地上系ネットワークはどう守ればよいのでしょうか。ここで導入されるのが、宇宙分野に限らず地上のITセキュリティ全般で標準的に使われる**多層防御(Defense in Depth)**という設計思想です。多層防御とは、単一の防御機構に依存せず、性質の異なる複数の防御層を重ねることで、どれか1層が突破されても他の層が攻撃を食い止める、あるいは検知するという考え方です。地上系ネットワークに典型的に適用される主要な技術要素を整理します。

ファイアウォール(Firewall)

ネットワークの境界に置かれ、あらかじめ定められたルール(送信元・宛先のIPアドレス、ポート番号、プロトコルの組み合わせなど)に基づいて、通過を許可する通信と拒否する通信を仕分ける装置・ソフトウェアです。地上セグメントアーキテクチャの回で見た4層構造——地上局のRFフロントエンド、SLEによる伝送層、MOC内部の各ソフトウェアコンポーネント——それぞれの境界にファイアウォールを配置することで、たとえばMOC内部の監視制御ソフトウェアが動くセグメントと、外部のGSaaS事業者と接続するセグメントを分離し、必要な通信だけを明示的に許可する、という設計が一般的です。この「境界ごとに区画を分け、区画間の通信を最小限に絞る」という発想は、ネットワークセグメンテーションとも呼ばれます。

VPN(Virtual Private Network)

地理的に離れた拠点間——たとえば遠隔地にある地上局とMOC、あるいは複数国にまたがる国際相互運用の回で見たクロスサポート先の地上局——を結ぶ通信を、暗号化されたトンネルとして保護する技術です。SLEの回で見たBIND-START-TRANSFER-DATAのやり取りが、公衆インターネットや専用線を経由する場合、その経路上でVPNによる暗号化トンネルを張ることで、通信内容の盗聴や改ざんに対する保護を、SDLSがRFリンクに対して提供するのと同じ発想で、地上区間に対して提供します。VPNは通常、IPsec(IP層での暗号化・認証)やTLS(Transport Layer Security、アプリケーション層に近い位置での暗号化)といった、地上のインターネットで広く使われている標準プロトコルの上に構築されます。

侵入検知システム(IDS: Intrusion Detection System)

ネットワークを流れるトラフィックやホスト(サーバ・端末)上の挙動を継続的に監視し、既知の攻撃パターンとの照合や、通常とは異なる異常な挙動(アノマリ)の検出によって、侵入の兆候を検知する仕組みです。ファイアウォールが「入り口で通す・通さないを判定する」のに対し、IDSは「入り込んだ後の異常な振る舞いを見つける」という補完的な役割を担います。より能動的に、検知した攻撃的な通信を自動的に遮断するものは侵入防止システム(IPS: Intrusion Prevention System)と呼ばれます。MOC内部ネットワークにIDS/IPSを配置しておくことで、たとえ何らかの経路で境界のファイアウォールが突破されたとしても、内部での不審な活動(通常はアクセスしないはずのコマンド計画ソフトウェアへの異常なログイン試行など)を検知し、被害が拡大する前に対応できる可能性が生まれます。

多層防御の全体像

これらの技術要素を、地上セグメントアーキテクチャの回の4層構造に重ねて図式化すると、次のようになります。

$$\underbrace{\text{探査機}}_{\text{SDLS(RFリンク保護)}} \;\longleftrightarrow\; \underbrace{\text{地上局}}_{\text{FW + 制御系アクセス管理}} \;\longleftrightarrow\; \underbrace{\text{SLE接続}}_{\text{VPN/TLS}} \;\longleftrightarrow\; \underbrace{\text{MOC内部LAN}}_{\text{FW + セグメンテーション + IDS/IPS}}$$

重要なのは、これらの層のどれか1つが「唯一の防御」ではなく、複数の層が互いに独立した仕組みで重なり合っているという点です。ある層が(未知の脆弱性の悪用や設定ミスによって)突破されたとしても、その内側にもう1つの層があれば、攻撃はそこで食い止められる可能性があります。これは地上セグメントアーキテクチャの回で見た並列冗長化の可用性設計——1系統が故障しても予備系が生き残る——と発想の骨格が似ていますが、対象が「偶発的な故障」ではなく「意図的な攻撃」である点が異なります。意図的な攻撃者は、可用性設計が想定する確率的な故障モデルとは異なり、弱点を能動的に探し出して突くため、防御側は個々の層の強度だけでなく、層と層の間に想定外の抜け道(たとえば、ファイアウォールルールの設定ミスで意図せず開いたままのポート)がないかを継続的に点検する必要があります。

実務での使われ方

地上系のサイバーセキュリティは、近年、宇宙機関・規制当局の双方で急速に要求水準が引き上げられている分野です。

政府機関によるガイドライン整備。 米国では、コマンド認証の回でも触れたCISA(Cybersecurity and Infrastructure Security Agency)とNISTが、Foundational Practices for Space Systems Cybersecurity をはじめとする宇宙システム向けサイバーセキュリティガイドラインを発行しており、探査機のRFリンクだけでなく地上系(ミッション運用センター、地上局、それらを結ぶネットワーク)を含めたシステム全体をスコープとした防御を要求しています。米国大統領府が2020年に発出した宇宙政策指令SPD-5(Space Policy Directive-5, Cybersecurity Principles for Space Systems)も同様に、宇宙システムのサイバーセキュリティは宇宙機単体ではなく地上系・リンク・ユーザ端末を含めたエンドツーエンドで確保されるべきという原則を明記しています。

認証・監査プロセス。 NASAやESAといった主要宇宙機関は、新規ミッションのMOC・地上局の構築にあたり、NISTのサイバーセキュリティフレームワーク(識別・防御・検知・対応・復旧の5機能)に準拠したセキュリティ管理策の実装を調達要求に含めることが増えています。具体的には、ネットワーク構成図のレビュー、ファイアウォールルールの監査、侵入テスト(ペネトレーションテスト、実際に侵入を試みて脆弱性を洗い出す評価手法)の定期実施、アクセス権限の最小化(必要な人員だけが必要な範囲でシステムにアクセスできるようにする最小権限の原則)といった管理策が、ミッション運用開始前後を通じて継続的に監査されます。

サプライチェーンのセキュリティ要求。 地上局運用の自動化の回で見た商用GSaaSの利用が広がるにつれて、委託先事業者のセキュリティ水準そのものがミッション全体のリスクに直結するという認識が強まっています。ミッション側がどれだけ堅牢な多層防御を自組織のMOC内に構築していても、GSaaS事業者側のネットワークが脆弱であれば、そこが$\min_i S_i$を規定する弱点になりかねません。このため、GSaaS事業者との契約においては、単なるサービスレベル合意(SLA、可用性や応答時間の保証)だけでなく、暗号化通信の要求、アクセスログの提供、インシデント発生時の通知義務といったセキュリティ要求事項を契約条項として明記することが一般的になりつつあります。これは地上の企業間のITサプライチェーンセキュリティで確立してきた実務慣行——委託先のセキュリティ水準を契約と監査でガバナンスする——が、宇宙分野にもそのまま輸入されている例と言えます。

インシデントの実例。 商用の静止通信衛星や地球観測衛星の地上系に対する不正アクセスの試みは過去に複数報告されており、なかにはネットワーク経由でのコマンド送出経路への侵入が疑われた事例も指摘されています。こうした事例の多くは、探査機のRFリンク自体の暗号を破ったのではなく、地上系のIT基盤(公開されたリモートアクセス用サーバの脆弱性、認証情報の窃取など)を足がかりにしたものであったとされ、まさにこの回で見た「一番弱いところが全体の強度を決める」という原則を裏づける教訓として、業界内のセキュリティガイドライン整備を後押ししてきました。

演習問題

1. SDLSの回で学んだSDLSが保護するのはコマンドパスのどの区間か、そしてこの回で見た地上系ネットワークが保護すべきなのはどの区間か、両者を図式で整理し、なぜ両方が必要なのかを説明してください。
2. この回で導入した $S_{\text{system}} = \min_i S_i$ という考え方を使って、「RFリンクの暗号強度だけを極端に強化する」という投資判断がセキュリティ上なぜ非効率になりうるかを、限られたセキュリティ予算をどう配分すべきかという観点から論じてください。
3. ファイアウォール・VPN・IDSの3つの技術は、それぞれ「何を」「どの段階で」防御・検知しているかという観点で役割が異なります。この回の説明をもとに、3つの技術それぞれの役割の違いを表にまとめてください。
4. ある小型衛星ミッションが、自前の地上局を持たず商用GSaaSのみで運用することを計画しています。この回で述べたサプライチェーンリスクの観点から、GSaaS事業者を選定する際にミッション側が確認すべきセキュリティ要求事項を3つ挙げ、それぞれがどのような攻撃シナリオを防ぐためのものかを説明してください。

まとめと次回予告

SDLSの回で学んだ探査機と地上局を結ぶRFリンクの保護は、コマンドパス全体のごく一部を守っているに過ぎません。この回では、SLEの回で見た地上局-MOC間の接続や、MOサービスの回で見たMOC内部ネットワークが、通常のインターネットと同じ攻撃対象領域(制御システム、SLE接続、MOC内部LAN、GSaaSサプライチェーン)を持ち、不正侵入・マルウェア・DDoSといった一般的なサイバー攻撃にさらされうることを見ました。ファイアウォール・VPN・IDSといった多層防御の技術要素を重ねることで、どれか1層が破られても被害を食い止められるようにする——この設計思想の根底には、探査機のRFリンクをどれほど堅牢にしても、地上系という「一番弱いところ」が全体の防御強度を決めてしまうという原則があります。

次回は、この地上系ネットワークを構成するソフトウェアコンポーネントどうしが、実際にどのようなAPI(Application Programming Interface)設計のもとでセキュアにやり取りするのか、MOサービスの回で見たMALのようなメッセージング基盤の上に、認証・認可の仕組みをどう組み込むかという、より実装に近い話題に軽く触れます。

参考文献

• CISA/NIST, Foundational Practices for Space Systems Cybersecurity
• The White House, Space Policy Directive-5: Cybersecurity Principles for Space Systems (SPD-5), 2020
• NIST, Framework for Improving Critical Infrastructure Cybersecurity (Cybersecurity Framework)
• CCSDS 355.0-B, Space Data Link Security Protocol, Blue Book
• CCSDS 911.1-B, Space Link Extension — Return All Frames Service Specification
• Aerospace Corporation, Defending Spacecraft in the Cyber Domain
• J. R. Wertz, D. F. Everett, J. J. Puschell (eds.), Space Mission Engineering: The New SMAD