【ITニュース解説】Edge management concentration turns one appliance into a portfolio risk

システムエンジニアを目指す初心者の皆さん、ITシステムの管理における「集中」が持つメリットと、そこから生まれる大きなリスクについて解説する。複数のネットワーク機器を一つの場所からまとめて管理できる「集中管理システム」は、日々の運用を非常に効率的にする。しかし、この便利さの裏には、もしその管理システム自体が攻撃者に狙われ、乗っ取られてしまった場合、広範囲に甚大な被害が及ぶ可能性が潜んでいるのだ。

具体的な例として、セキュリティ製品大手Fortinet社の「FortiManager」と「FortiGate」を使ったシステムが挙げられる。FortiManagerは、たくさんのFortiGate（外部からの不正アクセスを防ぐ「ファイアウォール」と呼ばれる機器）の設定をまとめて管理できる便利なシステムだ。ところが、ある通信事業者で発生したサイバー攻撃では、このFortiManagerが攻撃者に侵入されたことで、単一の管理システムから500台以上ものFortiGateファイアウォールの「設定情報」「ログイン情報（認証情報）」「ネットワークアドレス」「信頼関係」といった、非常に機密性の高い情報が盗まれてしまったことが明らかになった。

これは、管理者が持っている「マスターキー」が盗まれたようなものだ。マスターキーがあれば、たくさんの部屋に自由に出入りできるようになる。この場合、FortiManagerはマスターキーであり、それが不正に利用されることで、攻撃者は管理下にある無数のFortiGateファイアウォールを自由に操作したり、さらにその奥にある企業ネットワークにまで侵入したりできるようになった可能性がある。

この事実は、企業が持つシステム全体の「集中管理リスク」を真剣に見直す必要があることを示している。もし、自社のシステムで同じような事態が起きたらどうなるのか、その被害範囲はどこまで広がるのか、そしてどのように復旧するのかを、今一度検討し直すことが求められているのだ。

まず、どのシステムが「きわめて重要」なインフラであるかを明確に定義することが重要だ。今回の事例では、FortiManager、管理対象のFortiGateファイアウォール、そしてそれらのファイアウォールの背後にあるネットワークの三つが攻撃経路となった。FortiManagerは、セキュリティポリシー（通信を許可するかどうかといったルール）を配下のファイアウォールに一括で適用したり、各ファイアウォールの設定情報を収集したりできる。また、他のデバイスとの「信頼関係」を築くための情報も持っているため、FortiManagerが乗っ取られると、攻撃者は管理者のふりをして他のファイアウォールを操作できるようになる可能性もある。そのデータベースには、多数のデバイスを一括で管理するための情報が詰まっている。

このように、たとえ利用者からの直接の通信（ユーザーデータ）を扱わないシステムであっても、ネットワーク全体の「司令塔」として機能する「管理プレーン」と呼ばれるシステムは、きわめて重要なインフラだと認識すべきだ。経営層や技術リーダーは、このような管理システムに対しても、他の重要な基幹システムと同じように、ソフトウェアの更新（パッチ適用）、ネットワーク上の隔離、常に監視を行うこと、アクセスできる人を厳しく制限すること、定期的なバックアップ、そして万が一の際にどう対応するかという訓練を行う必要があるかどうかを判断しなければならない。

次に、実際に被害が及ぶ範囲（「ブラスト半径」と呼ばれる）を正確に把握することが重要だ。単に「ファイアウォールが何台あるか」という製品の数だけでは不十分だ。外部のインターネット検索サービス「ZoomEye」の調査では、FortiGate製品がインターネット上に100万台以上も存在することが確認されているが、これはあくまで製品の検出数であり、どの組織が所有し、どの管理システムに紐付いているかはこれだけでは分からない。

組織ごとの本当の被害範囲は、その集中管理システムが実際にどれだけのデバイスと管理上の関係を持っているかによって決まる。リーダーは、中央管理プラットフォームに登録されている下流デバイスの数、その所有者や利用クライアントの数、管理システムに保管されている認証情報や証明書の種類、そして承認された管理経路を通じてアクセスできるデバイスの割合といった具体的な数字を把握する必要がある。また、攻撃者によって情報が「公開された可能性がある」だけの状態と、「実際に侵害が確認された」状態とを明確に区別することも重要だ。管理システムのパッチを適用しただけでは、その下流にあるクライアントネットワークまで安全になったとは限らず、個別に評価が必要な場合がある。

そして、万が一の事態に備えて、以下の四つの復旧策を具体的に準備しておくことが求められる。

一つ目は、「管理プレーンの隔離」である。FortiManagerのような管理システムには、承認された特定のネットワークや、限られた管理者だけがアクセスできるように厳しく制限すべきだ。また、管理システムから外部への通信も監視し、必要なものだけに限定することで、攻撃者がシステムを乗っ取ったとしても、その影響が広がりにくくする。

二つ目は、「迅速な認証情報の失効」だ。もし管理システムが侵害された場合、攻撃者が利用する可能性のある管理証明書、秘密鍵、管理者アカウントのパスワード、VPN接続の認証情報、システム間の自動連携に使う秘密情報などを、迅速に無効化し、新しいものに置き換える手順を事前に準備し、訓練しておく必要がある。パスワードをリセットしただけでは不十分で、古い証明書やセッションが引き続き使えないことを確実に確認することが重要だ。

三つ目は、「証拠の保全」である。攻撃を受けてクリーンアップを行う前に、FortiManagerのメモリ情報、データベースのスナップショット（特定の時点の状態を保存したもの）、設定の変更履歴、デバイスの登録履歴、ログなどの証拠を必ず保全することだ。今回の事例では、攻撃者が攻撃に使ったスクリプトや作成したアカウント、システム障害の記録などを削除していたことが報告されており、システムを再構築した後に証拠を探しても手遅れになる可能性があるため、迅速な対応が不可欠となる。

四つ目は、「独立した復旧」だ。これは、侵害された管理システムに頼らずとも、個々のファイアウォールを復元したり、その正しさを検証したりできる能力を持つことを意味する。管理システムとは別の経路（「アウトオブバンドアクセス」と呼ばれる）でデバイスにアクセスする方法を確保し、正常時の設定記録を常に保持しておく。そして、管理システムが使えない状況でも、オペレーターが個々のデバイスに到達し、その状態を確認できるかどうかを実際に訓練しておくことが重要だ。

さらに、外部の発見ツールを活用して、自社の資産管理台帳の完全性を確認することも有効だ。ZoomEyeのようなサービスを使えば、インターネット上に公開されているFortiGateやFortiManagerが、自社が把握している資産リストに漏れなく登録されているかをチェックできる。重要なのは、インターネット上に見つかったデバイスの数ではなく、外部から発見されたデバイスのうち、どれだけを自社の責任範囲にあるものとして正確に特定し、現在の管理記録と紐付けられるかという割合だ。この割合を高めることで、資産管理の精度が向上し、万が一のインシデント発生時にも、どのデバイスが影響を受けているかを迅速に特定できるようになる。

最後に、インシデント対応を「完了」とするための明確な基準を設定すべきだ。経営層に提出する最終報告では、以下の五つの具体的な結果が達成されたことを必須とするべきだ。それは、すべての管理対象デバイスとの関連性が再確認されたこと、侵害された信頼関係がすべて新しいものに置き換えられたこと、関連する認証情報やセッションがすべて無効化されたこと、現在の設定が過去の正常な設定履歴と比較検証されたこと、そして下流のクライアント環境がすべて評価されたか、あるいは対応範囲外として明確に分類されたこと、である。

そして、最終報告では、まだ残っているリスク（例えば、サポートが終了した古いデバイス、過去の古い証明書が残っている状態、まだ十分に検査できていないクライアントネットワークなど）があれば、それを明確に示し、次のアクションプランを割り当てるべきだ。

Fortinet製品に見つかった脆弱性（CVE）は、もちろん直ちに技術的な対応が必要な問題だ。しかし、今回の件で最も重要なのは、一度管理システムが侵害された場合、その直接的な脆弱性が修正された後も、その「管理アーキテクチャ」（システムの構成や管理の仕組み）自体が、何百ものネットワークへの「持続的な侵入経路」になり得るという点だ。このアーキテクチャに関する決定と、それに対する責任は、組織のリーダーシップが持つべきものである。