【特集】
ファイアウォールのリモート・マネジメントの機能と運用
〜マネージド・ファイアウォールの考察〜

丸山 龍一郎
ストーンソフト・ジャパン
ネットワークセキュリティーマネージャー
2002/3/23

　特集：ファイアウォール機能の現状と将来の記事では、今後求められるファイアウォールの特徴、主に機能面について記述した。今回は、ファイアウォール導入後、最も重要で負荷がかかる運用管理面について記述する。

マネージド・セキュリティ・サービスから見る 　ファイアウォール

　ファイアウォールに限らずほかのセキュリティ製品についても、本当の作業は導入後から始まる。管理者は導入したソリューションが問題なく継続して動作することに責任を負うことになるのだ。そのために管理者の担うタスクとしては、ファイアウォールソフトウェアの適時更新、パッチの適用、ログ情報の監視、設定情報のバックアップなどがある。

　また、最近では、遠隔地に導入したファイアウォールを統合的に管理するような組織や、サービスとして顧客のロケーション内のファイアウォールを遠隔地から管理する、マネージド・セキュリティ・サービスを提供するプロバイダ（MSP）も多く存在している。この記事では、距離的に離れたロケーションに存在するファイアウォールを管理する、いわゆるリモートマネジメント環境において、運用上、管理者が実際に直面する可能性がある問題点について以降考察していくことにする。

リモートファイアウォールエンジンの管理タスク

　リモートマネジメント環境を構成するコンポーネントには、管理される側のリモートファイアウォールエンジンと管理する側のマネジメントシステムがある。

　まずは、ファイアウォールエンジン側に求められる機能および運用方法について以下のポイントで記述する。

1. ログ・マネジメント
2. ファイアウォールの設定変更
3. ファイアウォール・ソフトウェアのメンテナンス
4. 設定情報のバックアップおよびリストア

1. ログ・マネジメント

●管理するうえで必要な情報は取得できるのか？

　リモート管理のタスクは、その大部分がファイアウォールのログ情報を監視することである。日々記録されるアクセスログを調査し、不正アクセスの有無をチェックする。MSPオペレータの判断はすべてファイアウォールが記録したログ情報に基づいて行われるため、ファイアウォール自身で分析に必要な情報を収集できなければならない。

　最近のファイアウォールでは、自分自身に対するDoS攻撃を検知できる機能を所有している製品もあるが、すべての攻撃を検出できるわけではないので導入している製品がどのような種類の攻撃の検出が可能であるかを事前に把握しておく必要がある。当然、検出できない攻撃もあるので、不正アクセスに関して十分な監視が必要である場合には、専用の侵入検知システムと併用して運用することも検討する必要がある。

●リモートファイアウォールのログ収集上の問題

図1　リモートマネジメント環境におけるログ情報の転送リスクとして、ネットワークリソースの消費、通信の遮断時の対処方法、また通信復帰時の動作なども考慮しなければならない

1. ネットワーク経由
   一般的にファイアウォール・エンジンが生成したログ情報は、ネットワーク経由でマネジメントシステムに送信される。
   
   ここで問題となるのがこのログ収集のための通信が環境に与える影響である。ローカルのサイト内で運用している場合はLAN経由であるためログ転送の負荷については、恐らく管理者側ではあまり問題とならない。
   
   しかし、リモート管理の場合、ログ転送で使用されるネットワークリソース〈帯域〉の消費は大きな問題となる。さらに管理者がログを参照する場合のレスポンスタイムの悪さでフラストレーションに陥ることもある。
   
   
2. ログ転送が停止した！？
   ファイアウォール・エンジンとマネジメントシステム間の通信が途切れた場合の動作については事前に把握しておく必要がある。このような事象は、マネジメントシステムのディスク領域が満杯になったり、マネジメントシステムのソフトウェアのメンテナンス時の停止、あるいは何らかの通信上の問題を理由として発生する可能性がある。
   
   ファイアウォール製品によってログ転送不可時のアクションが異なる。例えば、SYSLOG経由ですべてのログ情報をほかのシステムに転送している場合は、通信不可の間のログ情報はすべて破棄される。つまり、ファイアウォールのステータスが不明ということになる。
   
   また、別のタイプの製品では、ファイアウォール自身のディスク領域にログ情報を蓄積することが可能である。
   
   しかし、この場合もディスク領域は無限ではないので、ファイアウォールのディスク領域が満杯となった場合の動作を把握しておくべきである。アクションには2つ考えられる。
   • ファイアウォール機能自体の停止
   • ログ収集機能のみ停止（ファイアウォールとしては機能する）
     
     

   このアクションの選択指針としては、ファイアウォールが導入されるサイトの特性に依存する。オンラインショップのようなコンシューマ向けのサイトでは、サービス停止時間は直接売上に影響を与えるため、極力システムの停止時間を抑える必要がある。そのようなケースでは“ログ収集機能のみ停止”を選択して、どのような状況でもアプリケーションサーバに対するアクセス環境を維持する。
   
   また、多少のサービス停止が許され、かつセキュリティを維持することが何よりも必要なサイトでは、何か1つでも環境に問題があった場合はシステムをより安全な方向に動作させる、フェイルセーフを実現するために“ファイアウォール機能自体の停止”を選択すべきである。

3. ログ送信復旧時
   前述したログ送信不可の状態が解決し、ファイアウォール・エンジンとマネジメントシステム間の通信が正常な状態に復帰したときの動作にも注意が必要である。ファイアウォール・エンジンは、送信できなかったログ情報を一気にマネジメントシステム側に送信しようとするからである。その処理が終了するまでの間、WAN回線のほとんどがログ情報転送のために使用される事態となる。
   

●ログ取得の柔軟性

1. ルール単位のログ取得プロパティ
   リモート管理環境でのログ転送に関する問題点について記述したが、それを制御するためにはファイアウォールにルール単位で詳細にログ取得方法を定義できるような機能が必要である。つまり、管理上必要とされる情報のみ、ネットワーク経由でファイアウォールからマネジメントシステムに転送するようにし、ネットワーク上のログ情報転送負荷を最小限に抑えるのである。
   
   また、マネジメントシステムとの通信が不可能な状態でも、すべてのログ情報をファイアウォールエンジン上のディスク領域に格納するのでなく最も優先度が高い情報（最も重要な情報）のみを蓄積できるような機能、つまり、生成されるログ情報に対するプライオリティ付け機能が必要である。
   
   
2. ログフィルタリング
   ファイアウォール上に定義されるルールの最後には、暗黙のルールとして先に定義されたルールにマッチしないすべてのパケットをドロップするようなルールが定義される。このルールで処理されたパケットには、後の解析作業で必要であるものとまったく無意味である情報に二分される。
   
   前者は不正アクセスと関連する可能性があるパケットであり、後者はネットワーク上に存在するオペレーティングシステムが暗黙に使用している通信パケット（Windows系のNetBIOSなどが原因）である。
   
   後者のパケットにより生成されるログ情報は、大量であるにもかかわらず、解析作業でまったく無意味な情報である。不必要な情報をネットワーク経由で送信しないためにログ情報を転送する際にフィルタリングできる機能が必要である。
   

2. ファイアウォールの設定変更

●リモートファイアウォールの設定変更

　設定変更を行う場合、当然セキュアなトランスポート上で実行される必要がある。通常はVPNを経由してファイアウォールの専用のGUIを利用して設定内容を変更する。このときファイアウォール製品によっては、GUIからの設定変更以外にオペレーティングシステム上の設定も同時に変更する必要があるものがある。

　例えば、ネットワークアドレス変換（NAT）を定義した場合、変換後のパブリックアドレスに対するプロキシARPエントリを追加する必要がある。しかし、その定義をオペレーティングシステムのコマンドを使用して行う必要があるため、ファイアウォールに対してリモートログインできる仕組みが別途必要となる。

　また、設定変更後にポリシーをインストールしたときには、既存のセッション管理情報がリセットされ、それに伴って現在処理中のセッションが切断される点にも運用上注意が必要である。

3. ファイアウォールソフトウェアのメンテナンス

●ファイアウォールソフトウェアの更新

　ファイアウォール製品のソフトウェアのアップデートは、バグやセキュリティホールによる不具合を解決するためのサービスパックや機能追加など非常に頻繁に実施される。遠隔地のファイアウォールのソフトウェア更新をその都度現地に出向いて実施していたのでは効率が良くないため、リモートサイトからのソフトウェア更新の機能を可能とする機能を必要とする。

　ソフトウェア自身の更新はシステムの再起動を必要とする。従って、再起動中はネットワークアクセスができないということである。また、ソフトウェアを更新することで、逆に不具合が発生するということもよくある。

　このようなリスクを考えた場合、リモート環境で運用されるファイアウォールの構成はクラスタリングが必須と考えられる。複数台のファイアウォールから構成されるクラスタファイアウォールであれば、ソフトウェア更新時の再起動中もほかのシステム経由でネットワークアクセスは維持される。さらに、ソフトウェア更新作業については、1台のシステムの更新作業が正常に終了するまではほかのシステム環境で運用し、完了後はフェイルオーバーして残りのシステムの更新作業を実施することができる。

4. 設定情報のバックアップおよびリストア

●バックアップ

　リモート管理用のGUIには通常、現在のファイアウォールの構成ファイルをバックアップする機能がある。バックアップされる情報にはオペレーティングシステムの設定情報とファイアウォールの設定情報がある。

　バックアップは、ファイアウォールシステムがディスク装置の不具合などで動作不良となった場合、再インストールした後に以前の動作環境を即座に復元できることを目的としている。管理者は、実際に不具合が発生した際の復旧のオペレーションを円滑に進めるため、また問題解決を早急に実施するために、バックアップされている情報に何が含まれるのかを確認しておく必要がある。

　また、一次的な設定内容変更が必要な場合、後で以前動作していた環境に戻したい場合がある。そのためには、設定情報のバージョン管理機能も必要である。

　バックアップ対象となるファイアウォールシステム上の情報には以下のようなものがある。

• ネットワーク構成情報（IPアドレス、経路情報、ARP情報など）
• ユーザー情報（メンテナンス用のアカウント）
• セキュリティポリシー（各種オブジェクト、ルールベース、VPN構成など）
• 証明書情報（CA、鍵など）
• ユーザー固有の情報
• ファイアウォールGUI以外から設定した内容（静的ARPエントリ）
• メンテナンス用に作成した各種スクリプト

●リストア

　障害復旧時のアクションは、導入しているファイアウォールの製品タイプにより異なる。

1. ハードウェア・アプライアンス
   ハードウェア・アプライアンス製品が故障した場合、一般的にハードウェア全体の交換となる。アプライアンス製品はベンダ固有のプラットフォームで実現されているため、代替機を調達するための時間やコストを必要とする。従って、故障発生から復旧完了までの総時間は比較的長くなる。そのために、スタンバイ機を用意して運用する顧客が多いが、本番機とスタンバイ機の間の設定内容の同期を的確に実施する必要がある（特にコールドスタンバイで運用する場合、手動で実施する必要があるため、設定ミスを引き起こしやすい）。
   
   
2. オペレーティングシステム上のアプリケーション
   汎用オペレーティングシステム上のアプリケーションとしてファイアウォールが動作している場合、障害時のオペレーションは複雑である。手順として、
   • ハードウェアの故障を修理
   • オペレーティングシステムおよびパッチソフトウェアのインストール
   • ネットワーク環境の設定
   • 不必要なサービスの削除（チューニング）
   • ファイアウォールソフトウェアおよびパッチソフトウェアのインストール
   • バックアップファイルからの復元
     
     

   となる。復旧作業自体はシステムの再インストール・再構築であるため、担当者のケアレスミスの頻度が当初設定した時点と比較して高くなる。また、障害発生から復旧完了までの時間もハードウェア・アプライアンスと同様に長くなる。

3. オペレーティングシステムへの組み込み
   ファイアウォールエンジンがオペレーティングシステムに組み込まれているタイプは、前者の場合と比較して障害復旧までの時間が短くて済む。それは、ファイアウォールエンジンのインストレーション作業でチューニングされたオペレーティングシステムとファイアウォールエンジンが同時にインストールできるためである。また、ファイアウォール・エンジンの構成情報も、すべてマネジメントシステム側で保持しているため、再度ポリシーをファイアウォール・エンジンにダウンロードすることで設定内容の復旧も完了する。
   

　ここまで、リモートマネジメント環境におけるファイアウォールエンジンに求められる機能とその運用面での懸案点について記述してきた。しかし、ログに関するタスク以外については、その作業自体が顧客が利用しているサービスに影響を与える可能性がある。例えば、ファイアウォールソフトウェアのメンテナンス時間はファイアウォールが利用できない。つまり、サービスが使えない。今後のビジネス形態において、24時間365日のサービス提供は必要条件と考えられるため、顧客のサービス利用に影響を与えないで、円滑に運用管理するためには、ファイアウォールエンジンのクラスタリング構成は絶対条件となる。

　例えば、クラスタリング構成のシステムのメンテナンス作業のステップを以下に記述する。

	1.通常運転中は両ノードがトラフィックを処理
	2.メンテナンスのため、#1をオフラインとする #2のみがトラフィックを処理 メンテナンス作業を実施
	3.メンテナンス作業終了後、#1をオンラインとする 両ノードでトラフィックを処理
	4.メンテナンスのため、#2をオフラインとする #1のみがトラフィックを処理 メンテナンス作業を実施
	5.メンテナンス作業終了後、#2をオンラインとする 両ノードでトラフィックを処理
図2 クラスタ環境でのシステムメンテナンス

1. 通常運用時は、Active-Activeモードで動作している（Hot-Standbyモードでも構わない）。
2. メンテナンス作業のため、1号機をオフラインとする（オフライン指示により、1号機で処理されていたセッションは2号機にフェイルオーバーされる）。 1号機に対してメンテナンス作業を実施（リブートが発生してもオンラインにならないような設定が必要）。
3. 1号機の作業完了が確認された後、オンライン状態に移行する。 もし、1号機の処理になにか問題があれば即座に1号機をオフラインとして対応を図る。
4. 1号機の動作に問題がないことが確認された後、2号機をオフラインとする。 2号機に対してメンテナンス作業を実施（リブートが発生してもオンラインにならないような設定が必要）。
5. 2号機の作業完了が確認された後、オンライン状態に移行する。 もし、2号機の処理に何か問題があれば即座に2号機をオフラインにして対応を図る。

　すべて問題がなければ、ローリングアップデート作業は完了する。この作業の間、顧客側にはファイアウォールエンジンノードの切り替えは完全にトランスペアレントである。

　

「マネジメントシステムに求められる機能」

　

Index 特集：ファイアウォールのリモート・マネジメントの機能と運用

Page 1 マネージド・セキュリティ・サービスから見るファイアウォール リモートファイアウォールエンジンの管理タスク 　 Page 2 マネジメントシステムに求められる機能 リモートマネジメントソリューションへの期待

　

関連記事

特集：ファイアウォール機能の現状と将来 （前編）

特集：ファイアウォール機能の現状と将来 （後編）

　

Security&Trust記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）