大手金融グループが、グループ全体のウェブシステムを刷新することになった。大規模プロジェクトの中、セキュリティ対策の一貫として利用していたウェブアプリケーションファイアウォール(以下、WAF)を、従来導入していたオープンソースWAFのModSecurityからSiteGuardにリプレースした。

検討の経緯から導入・運用時のエピソードについて、同システムの基盤を担う ソフトバンク株式会社(以下、ソフトバンク)の担当者(以下、A氏、B氏)に話を伺った。logo_softbank

ModSecurityの課題、運用負荷とサポート

対象となるシステムは、グループ各社の外部向けホームページで、分散されたデータセンターに100台を超える仮想環境上のサーバー群から構成される。情報公開用サイトが中心ながら、当然システムには高い堅牢性が求められる。中でもオンラインバンキングやオンライントレードへリンクのあるサイトは、社会的影響も大きく極めて重要性が高い。多数のコンペを勝ち抜き、 ソフトバンクはプロジェクトを受注することになる。

A氏
「RFPの段階では、回線、データセンター、サーバー、いわゆるウェブシステムの基盤といわれる部分が対象で、我々キャリアとしては強みを出せる内容でした。要件にセキュリティスタンダードというものがあり、その中にウェブセキュリティも含まれていました。既存システムでは、Apacheのモジュールとして動作するModSecurityを活用されていたのですが、手動による防御ルールの運用が大変という課題がありました。お客様からもっと楽で良いものがないかというご相談を頂いた結果、ブラックリスト型で仕組み的に近く、メンテナンスも楽ということで、SiteGuardを提案することにしました。」

実際には、 ソフトバンクがプロジェクトを受注した後、設計や要件定義を進めていく中で、最終的にSiteGuardの採用が承認されることになる。課題視されていたModSecurityの状況については、その過程でユーザーから相談を受けていたわけだ。

B氏
「ModSecurityは面倒だけど動けばいいじゃないか、という考え方もあります。 ただし、一般的にはオープンソースのためサポートが受けられない。そのため、トラブルが発生した場合に本当の原因を追及することができないことがある。原因を究明できなければ、また同様のトラブルが起こるかもしれない。そういう点は銀行のシステムでは重要視されます。我々には安定したシステムを提供する責任があります。ちゃんとしたメーカの担保が必要だというご説明をした結果、『それでいきましょう!』という話になりました。 」

選定のポイントは『ソフトウェア』・『国産』・『シンプル』

では、ユーザーの課題を解決するために、 ソフトバンクはどのように製品を選定し、SiteGuardを採用するに至ったのでしょうか?

A氏
「まず、ソフトウェア製品がいいと思いました。アプライアンス製品は便利ですが、 一個のシステムにすべて依存してしまう危険性があります。SiteGuardはプロキシとして動作する製品ですが、今回の構成では、すべての仮想サーバー上でウェブサーバーと一対一の関係で導入しました。何かトラブルがあっても影響はそのサーバーだけで済む。結果、ソフトウェアがよいだろうと判断しました。もう一つは国産という点です。 他社製品はほとんどが海外製品のため、メーカのサポートをとても気にしていました。どうしても、海外製品だと日本のマーケットより海外のマーケットを優先するために、日本だけで起きる問題の対応や日本だけで必要となる細かな機能追加などの対応が実現されないことが多くあります。その点、SiteGuardは日本のメーカの製品なので、いろいろな面で安心してお任せできると思いました。お客様に対しても、国産という点は思いのほか評価されましたね。」

とはいえ、主要なWAF製品はSiteGuardだけではない。学習機能と呼ばれる自動でルール作成ができる製品なら、運用が簡単という説明を目にすることもあるが。

B氏
「導入するとなると面倒だと思いました。実際にリアルなパケットを流す必要がありますし、『WAFのレベルで学習している猶予はない』という印象でした。シグネチャベースのSiteGuardではそういう作業が必要なく、結果的にテストは比較的簡単に済みました。」

遅延の許されないウェブトラフィックを処理するWAFでは、必ずといっていいほど性能が問題となる。運用面でのユーザービリティも重要なポイントである。

A氏
「性能は気にしていました。例えば、同時プロセス数をどれくらいあげられるのか、性能の限界値はないのか、といったことです。また、メーカから随時新しいシグネチャが提供されるわけですが、手放しで更新される運用は避けたいと考えていました。そこをうまくコントロールしたい。製品によっては、一つのデーモンが自動処理してしまい、よくわからず勝手に更新されることもあります。そのような製品は避けたいと考えていました。この点は事前に評価版で検証した結果、性能はもちろんのこと、非常にシンプルな構造で動作を確認できたので、安心できました。もう一つは管理用インタフェース。多数のサーバーがあるため、各サーバーをGUIで管理というよりは、コンフィグを直接編集したかった。コマンドラインの作業ですね。SiteGuardはこの点も可能な仕様でした。本当にシンプルだったので、運用面の細かい課題はクリアできると判断しました。」

構築からテストへ、誤検出への対処

入念な設計・要件定義を経て、いよいよ構築がはじまる。コンフィグはあらかじめ決定しておき、仮想環境上に導入されたSiteGuardにSCP等で流し込む”バッチ的”な手法をとった。特別に工夫した点などはあるのだろうか。

A氏
「当初はいろいろ検討しましたが、結果的にはあまり複雑な設定はしていません。リバースプロキシとして動作するSiteGuardの課題として、アクセスログの送信元IPアドレスの扱い(※1)があります。SiteGuardではデフォルトでX-Forwarded-For(※2)を取得できるので、解決の余地はありました。そこで、ログを見やすいようにApacheのログ設定を若干変えて、FromアドレスでX-Forwarded-Forを見れるようにしています。」

ソフトバンクの責任範囲である基盤構築が完了し、いよいよコンテンツ担当への引き渡し、テストフェーズへと移行する。シグネチャ更新は、慎重を期して自動更新でなく、ユーザーと調整しながら手動更新する運用を採用した。メーカより提供されたシグネチャリストは、誤検出への対処で有効だったという。

A氏
「SiteGuardでは検出時にアラートが出るので、アラートが出たら当社に相談していただくよう、あらかじめお客様と調整していました。”変なオペレーションはしてないけどブロックされたんですが”といったご連絡をいただくわけです。その都度、状況を確認して対応していく。誤検知の件でそれほど紛糾したことはありませんでしたね。」

B氏
「よく覚えているのがcsvファイルの件です。csvファイルのダウンロードができないという事象があり、なんでだろうと。メーカサポートに問い合わせてすぐに解決(※3)しましたが、我々としても”csv?”という印象で。お客様には必要な仕組みだったんですね。」

A氏
「ご連絡を受けて実際にSiteGuardの設定を変えたのは、csvの件ともう一件くらいだったでしょうか。もちろん、SiteGuardが筒抜けというわけではありません。誤検出をあまり心配しなくてもいい作りになっているのかなぁと感じました。別の観点で、脆弱性診断を受けたことがありました。診断を担当されたベンダさんが”とてもやりにくいのでWAFを止めてくれませんか”と言ってきます。例えば、診断リクエストを送ると一定時間アクセスが遮断されたりするのです。”エンジニアが待たなくてはならず仕事にならない”という話になります。この点はお客様と相談して、診断中はWAFを止めることにしました。我々としては、WAFがちゃんと機能していることを確認できたわけです。」

安心したシステム提供を支援するメーカサポート

プロジェクトを進めていく過程で、メーカの技術サポートは重要なポイントだ。特に ソフトバンクが重視していた点でもある。

B氏
「素晴らしいです(笑)。まじめな話、本当に問題ないです。導入からテストまでいろいろと対応していただきました。案外、そういうベンダってないんですよ。そのベンダがわかってることは、当然即答で返ってくる。そうでない場合の対応は、ものすごく時間がかかったり、結果わからなかったり。実際に作った人がそこにいれば別ですけど、普通いないじゃないですか。SiteGuardに関しては、非常にクイックな対応をしていただけました。結果、我々としても非常に安心してお客様にシステムをご提供できている。」

A氏
「心配になるくらいです(笑)。わかっている方に対応してもらえるのがいいですね。私自身、UNIX系を細かく触っている方で、Apacheなども”ソースコードを読めばわかるよね”という性分なので。仕様的にどうかと質問させてもらって、”こういう風に動きます”と回答してもらえると、なるほどと。非常にありがたいと感じています。」

想定外の効果「Apache Killerの対応」、課題

本番運用をはじめてから2年が経とうとしている。改めて振り返り、導入効果や課題についてどのようなお考えだろうか?

A氏
「効果という点で、Apache Killerの問題(※4)がありました。RedHatのApacheがバージョンアップするまでの間の対応に苦慮したんです。当時ジェイピー・セキュアさんに問い合わせたところ、”明日にでも対応”という回答(※5)でした。お客様と相談した結果、最終的には対応シグネチャをすぐ適用はせず万が一に備えることになったんです。ですが、このような攻撃に対する”盾”として、WAFを使っていく運用を考えるきっかけになりましたね。」

B氏
「ファイアウォールでは当然カバーできないレイヤで、Apacheとの間にあるWAFで対応できた。我々としてはまったく想定していなかったんですね、そういう対応(サーバーの脆弱性をつく攻撃をWAFで防ぐ)ができるとは。Apacheはなるべくいじりたくない。WAF側で対応できるというのは、今後同様の問題が発生した際に非常に有効な手段になると思っています。結果的には対応を見送ったものの、お客様からすると”保険の上には保険をかけて”という思いが強くあったんです。金融機関だから特にということかもしれません。ですが、触らなくても済むなら、今動いてるシステムを触りたくはない。この件は、お客様から安心してお任せいただけるシステムと評価いただけた一例でもあったので、我々としては感謝しています。」

一方で、みえてきた課題もあった。その一つはバージョンアップ。メーカから新しいバージョンがリリースされても、運用の事情からすぐにバージョンアップとはいかないケースがある。製品の機能面では、レポート機能の弱さを指摘いただいた。ユーザーへWAFの導入効果を説明する上で、レポートは必要不可欠である。この点は弊社の課題として真摯に受け止めている。


最後に、今回のご経験を踏まえ、今後WAFの導入を検討される方へのアドバイスを両氏にお聞きした。

A氏
「個人的には、WAFというものに目をつけられた時点で、そもそもハードルを越えている気がするんです。今回SiteGuardを選んだ一番のポイントは、単機能、非常にシンプルでメンテしやすいということ。 逆に、オールインワンでやりたい方には、アプライアンス型やUTMの方がフィットする場合もあるでしょう。ですが、大規模なケース、今回のお客様やホスティング事業者さんなど、規模が大きくなると、できる限りシンプルであることが必須になってくると思います。そういう意味で、SiteGuardのような製品は、大規模なシステムに有効なんじゃないでしょうか。初めての方やあまり詳しくない方にとっては、ソフトウェアだと難しいと感じられる方もいらっしゃるかもしれませんがね。」

B氏
「(WAFを試すことが可能であれば)すぐにでも使うと効果が見えるんじゃないかと。いまって、見えないと思うんですよ。例えばSQLインジェクションを受けていても、気づかなければわからないという話です。アクセスログの一行にしかならない。使ってみることが、インターネットに公開するとこんなに攻撃が来るのだと、実態というのがわかるんじゃないかと思うんです。すごく大事な場所にあるんですよね、WAFって。何かあったら ウェブが見えなくなってしまうので。」


(※1)標準ではウェブサーバーから見た送信元IPアドレスがiteGuardのIPアドレスになる。
(※2)HTTPヘッダフィールドの一つで、プロキシサーバー等を介してHTTPアクセスする送信元のIPアドレスを特定する。
(※3)意図しないファイルのダウンロードを防ぐ目的でシグネチャ化している。
(※4)Apacheの脆弱性を悪用したDoSの問題。(CVE-2011-3192)
(※5)問題の重要性を考慮し、かつSiteGuardの検査仕様で対処可能なためシグネチャ対応した。
https://www.jp-secure.com/alert-20110830/

導入事例Topへ


SiteGuardシリーズに関するお問い合わせはこちら044-201-4036受付時間:平日9:30~17:30

お問い合わせフォームご質問や資料請求、評価版など