動向●導入容易なWebアプリケーションの“防衛装置”

Webサイトのアプリケーション・プログラムに潜む脆（ぜい）弱性を保護する「Webアプリケーション・ファイアウォール」。従来からソフトウエア製品はあったが，ここにきてアプライアンス製品が増えてきた。ソフトウエア製品より，導入が容易で投資額が割安という特徴がある。

　Webアプリケーションの脆弱性を減らすには，慎重な設計と実装，多岐にわたるテストが欠かせない。だが，短納期と低予算の圧力が強いシステム構築現場では，脆弱性の評価がおざなりになってしまうことが間々ある。こうして見落とされた脆弱性を突かれ，情報漏えいなどの事件が起きたら，どうなるか。情報システムの主幹部署や，開発の請負業者が責任を追求されることは想像に難くない。

　こうしたリスクを軽減し，Webアプリケーションの脆弱性を保護するのが，「Webアプリケーション（WebAP）ファイアウォール」と呼ばれる製品だ。TCPポートの80番や443番を使い，HTTPの仕様に則して仕掛けられた攻撃からWebアプリケーション・プログラムを保護する機能がある。

　例えば，アプリケーションが利用するメモリー領域をあふれさせて不正コードを実行させる「バッファ・オーバーフロー攻撃」や，OSコマンドやSQL文を不正に呼び出す「インジェクション攻撃」，Webサイトを介して悪意のあるスクリプトをクライアント側で実行させる「クロスサイト・スクリプト攻撃」など，数十種を防御する。

　従来からある一般的なファイアウォール製品で，これらの攻撃を検出/遮断するのは難しい。一般的なファイアウォール製品は，ネットワークの経路を隠し，プロトコルの妥当性を検証することが主目的。アプリケーション・プログラムの脆弱性は対象外になっていることが多い。

脆弱性を迅速に隠す効果

　これまで提供されていたWebAPファイアウォール製品は，ほとんどがソフトウエア製品だった。代表的な製品には，米KaVaDoの「InterDo」や米Sanctumの「AppShield」，キヤノンシステムソリューションズの「NGSecureWeb for Linux」などがあった。

表1●Webアプリケーションの脆弱性を保護する「Webアプリケーション・ファイアウォール」のアプライアンス製品

図1●プロトコル仕様やポリシー設定に準じたアクセスだけをWebアプリケーションに中継する HTTPやHTMLの仕様や用途と照らし合わせて不適切なアクセスや，管理者が設定したURL長/ヘッダー長などのポリシーと一致しないアクセスは，不審なものと見なして破棄する。Webアプリケーションからクライアントに返すエラー・メッセージなどを，別の文字列に書き換える製品もある

画面1●ポリシーの設定画面 サイト全体に同じポリシーを適用する「共通ポリシー設定型」の製品と，各URLやフィールドごとにポリシーを適用できる「個別ポリシー定義型」の製品がある。前者は，“最大公約数”となるURL長やヘッダー長などを設定する。後者は，URLごとに設定する。後者は個別に設定すると手間がかかるので，ワイルド・カードを使ったり，アクセス履歴から学習したりすることが可能である

　最近になり，アプライアンス製品が増えた（表1[拡大表示]）。米NetContinuumの「NC-1000」と米Terosの「Teros 100/200」は2004年3月に，横河電機と日立情報システムズが共同開発した「AW700」は翌4月に出荷した。イスラエルCheck Point Software Technologiesの「Connectra」は，6月に出荷する予定である。

　アプライアンス製品が続々と登場する背景には，「早く安く（WebAPファイアウォールを）導入したいというニーズがある」（日立情報システムズ ネットワークインテグレーション本部 セキュリティソリューション部 部長 本川祐治氏）。数年前から有識者やクラッカが，企業のWebサイトの脆弱性を指摘したり暴露したりするようになった。こうした情報は匿名掲示板やマスメディアを通じて，アッという間に流布する。Webサイトの構築者や運営者の対処が遅れると，被害は拡大し，企業イメージの失墜は免れない。

　脆弱性の発覚前に“保険”としてWebAPファイアウォールを導入していればベターだが，現実には「発覚で慌てた企業や官庁が，プログラムの修正という抜本的な改善に先駆けて，急いで導入する」（日商エレクトロニクス セキュリティ事業推進部 エンジニアリングチーム 松尾敏行氏）ケースがある。このため，迅速に導入できることが重視される。

　アプライアンス製品は「導入にかかる工数がソフトウエア製品より約2～3割は少なく，費用面で割安になる可能性がある」（横河電機 ネットワークセキュリティPJTセンター NS営業グループ チームリーダー 木下弦氏）。サーバー機やOS，WebAPファイアウォール・ソフトを別々に購入してインストールしなくてもよいため，アプライアンス製品の導入の手間はソフトウエア製品のそれより少ない。ソフトウエアに適したハードウエア・リソース（CPUやメモリー容量など）のチューニングに頭を悩ます必要もない。使わないサービスやアカウントを削除し，動作に支障のない範囲でアクセス制御を強化するといったOSの設定作業も不要である。

ホワイト・リストで守る

　導入の敷居が低いとはいえ，WebサイトやWebアプリケーションの特性を考慮し，アクセス・ポリシーを設定する作業は不可欠である。

　特に重要なのは，アクセスを許可する条件（ホワイト・リスト）の定義。WebAPファイアウォールは，基本的には全パケットを破棄し，ホワイト・リストなどのアクセス・ポリシーに合致するパケットだけを，Webアプリケーションに転送する（図1[拡大表示]）。

　バッファ・オーバーフロー攻撃の阻止を例にホワイト・リストの概要を説明しよう。この攻撃を防ぐには，例えばHTTPヘッダーやGET/POSTメソッドの引数として許可するデータ長などを設定する。データ長のほかに，文字コード，文字種（英/数/記号/…）などを指定することもできる。これにより，メモリー領域をあふれさせるための長い文字列や，バイナリで記述された攻撃コードを含んだアクセスを破棄することが可能になる。

設定のきめ細かさに製品差

　ポリシー設定の考え方には2種類ある。一つはWebサイト全体に同じポリシーを適用する「共通ポリシー設定型」，もう一つは各URL（Webページ）やフィールドごとに個別のポリシーを適用する「個別ポリシー設定型」だ。

　それぞれ一長一短ある。共通ポリシー設定型は，一つのポリシーでWebサイト全体をカバーするので高いスループットが期待できる半面，すべてのWebページに対して有効な“最大公約数”のポリシーを見出すのは難しい。一方の個別ポリシー設定型は，きめ細かな制御ができる半面，ポリシー数が多くなるとメモリー不足などに陥り，スループットが低下する恐れがある。

　ポリシー設定の手間を減らすため，各製品ごとに工夫を凝らしている。例えばTerosには，ポリシーを自己学習するモードがある。このモードを有効にすると，ポリシーを学習するために一時的にすべてのアクセスをスルーし，URLごとにフィールド名とデータ長/文字種などを記録する（画面1の右[拡大表示]）。この記録に基づき，推奨するポリシーを自動生成する。NC-1000を開発した米NetContinuumは，脆弱性診断ソフトによる評価結果に基づいたポリシーの自動生成機能を開発中だ。