AWSの新サービス「AWS WAF」がリリース～re:Invent 2015 速報～ Webアプリケーションのセキュリティがより強固に

  • f
  • t
  • p
  • h
  • l
title_ReInvent_1

AWS WAFは既存サービスであるCloudFrontを「中継サーバ」として、その中で稼働するWAFサービス

こんにちは。技術チームの岩谷です。2015年10月6日～9日アメリカのラスベガスでクラウド大手Amazon Web Services(AWS)さんの世界最大のイベントである「re:Invent 2015」が開催されています。AWSテクノロジーパートナーである弊社からも参加させていただいていますが、残念ながら私は居残りです(泪)。

現地ではさきほど開幕したre:Inventですが、そこで早速AWSの新サービスが発表されました。それが「AWS WAF」です。本日の記事ではこの「AWS WAF」についての速報をお伝えさせてください。まず、いつも通り申し上げたいことを先に書きます。

  • AWS WAFはAWSが提供する「WAF(Web Application Firewall)」のサービス
  • AWS WAFの導入によって内部のWebアプリケーションに対して「SQLインジェクション」に代表されるWebアプリケーション脆弱性に対する対策機能が提供される
  • 「AWS WAF」に限らず「WAF」の機能は「リバースプロキシーサーバ(Reverse proxy)≒内部中継サーバ」として提供されることが多い
  • この「内部中継サーバ」はAWS既存サービスである「CloudFront」によって実現されており、これゆえ「AWS WAF」の機能は「CloudFront」の付加サービスとして提供される

WAFとは「正しい入り口から入ってきた悪意のあるデータ」を排除する機能

WAFは「Web Application Firewall」の略で
言葉通り和訳すると「Webアプリケーション用のファイアーウォール」です。「ファイアーウォール」の名前からもなしかしらの悪意からコンピュータを守るものであることは想像がつきますが、わざわざ「Webアプリケーション」とアタマにつける意味は何なのでしょうか？

実は、通常システムで使用される「ファイアーウォール」は「通信経路の安全性」を高める役割をメインとしているのです。インターネット上の通信の多くは「IPアドレスとポート番号」を一つの「入り口」として、

  • この入り口はいつも閉じていなければダメ！
  • この入り口に対しては「○○のIPアドレス」からは入ってきちゃダメ！
  • この入り口に対しては「○○のIPアドレス」以外からは入ってきちゃダメ！
  • この入り口に対しては「1秒間に???以上の通信要求」は入ってきちゃダメ！

上記のような防御を行っている製品なのです。

しかしこれでは「不正な通信経路」に対する防御は高められても「正しい通信経路から来る不正なデータ」に対しては無力であるわけです。この不正なデータの代表格は「SQL文字列」です。多くのWebシステムが内部で、

  1. 利用者からの入力値をパラメータとして受け取り、
  2. パラメータをSQL文字列に変換し、
  3. SQL文字列をDBに送信して結果データを取得し、
  4. 取得したデータを利用者のブラウザ画面へ送信しています。

ここで悪意のある攻撃者は上記aのパラメータに「SQLの文法構造を破壊するSQL文字列」を入力し上記cからシステムが意図しないデータを取得することを試みます。この結果、例えば「システム内の個人情報を含むデータを全て攻撃者に盗まれる」という被害も起こりえます。これが「SQLインジェクション」といわれる攻撃方法です。

この「正しい通信経路から来る不正なデータ」は「Webアプリケーション脆弱性攻撃」とよばれており有名な攻撃手法としては、

  • SQLインジェクション：SQLの文法構造破壊データを用いた攻撃
  • クロスサイトスクリプティング：HTMLの文法構造破壊データを用いた攻撃
  • ディレクトリトラバーサル：ディレクトリ表記法(C:\aaa\bbb…など)の構造破壊データを用いた攻撃
  • OSコマンドインジェクション：OSコマンドの文法構造破壊データを用いた攻撃

などが挙げられます。上記でも説明させていただきました通り、通常のファイアウォールではこれらの「Webアプリケーション脆弱性攻撃」には対応できません。

NOTE:
今回紹介するAWS WAFがこれらすべての脆弱性対策に対して効果を発揮するかはわかりません。

ここでWAFの登場です

WAFはこれら「Webアプリケーション脆弱性攻撃」に対して有効な対策手段を提供します。すなわち、

  • 自分自身を通過するデータの中身を解析してより詳細なデータ検査を行う
  • 具体的には上記の構文破壊が持つデータパターンと入力データを突合することによりマッチしたデータの通信を遮断する
  • データパターンはカスタマイズ可能

といったことを主な機能として持っています。

WAFは魔法の杖ではない。Webアプリケーション個々の対策との併用が絶対。本来はWAFを必要としないWebアプリケーションの作成が理想。でも現実的にそれだけでは不十分なケースもある

これはとても重要なことです。「Webアプリケーション脆弱性攻撃」に対する本質的な対策は「Webアプリケーションの脆弱性を低減させること」です。「バグをなくす事」です。極端に申し上げれば開発したWebアプリケーションに脆弱性が無ければWAFは必要ありません。具体的には「入力値の厳密なチェック機能」と「文法構造破壊を防ぐ構文作成機能」があれば問題は解決されるのです。ところが悲しい事に現実はそうはいきません。人はミスを犯します。バグのないシステムは存在しません。しかしてデータ漏えいをはじめとするセキュリティ事故の被害はこのミスを許容できないところにまで深刻化しているのです。

WAFは「Webアプリケーションのそのものの脆弱性対策」を補完する製品です。すなわち個々のアプリケーションに対する対策では見落とす傾向の強い不正データをWAFがファイアウォールとしてアプリケーションの前面に立つことによりパターン的に排除しようという取り組みなのです。

ここで上記で「魔法の杖ではない」と申し上げた事には以下の理由があります。

  • WAFのパターンマッチでは全ての不正データ排除は不可能。パターンを厳しくすれば正しいデータまでも遮断してしまう。
  • WAFは一時的にせよWAF内部で「データを蓄積して評価する」ということを繰り返す為システム全体のレスポンスは程度問題としては劣化する

よって今日のWebアプリケーション脆弱性対策には「Webアプリケーション個々の対策」を限界まで高めつつ「WAFによるパターンマッチ」をシステムレスポンスを低下させない範囲で適宜設定することで両者を組みあわせて実施する事が求められるのです。

AWS WAFはCloudFrontと一緒に使う

上記説明の通り、WAFはWebアプリケーションの前段に壁として配置されることにより機能します。ここで登場するのが既存のAWSサービスであるCloudFrontです。

CloudFrontは「クラウドのコンテンツ配信サービス」をして知られているサービスで、画像等のコンテンツを「キャッシュ」として自身の領域に蓄積しユーザからの要求に応じて送信するサービスです。このCloudFrontは実は「中継サーバ」としての機能も持っており、技術的には「リバースプロキシサーバ」と呼ばれる役割を果たします。

「AWS WAF」はこの「リバースプロキシサーバ」の役割を担うCloudFrontサービスの中で「Web Application Firewall」の機能を提供するサービスなのです。

AWS WAFの登場により既存のセキュリティ対策に加え新たな取り組みがAWSから提供されたことになります。AWS WAFの登場によりWebアプリケーションシステムセキュリティの一層の向上が期待されます。(でも！一番大切なのは個々のアプリケーションのセキュリティ対策ですよ！！笑)

【AWS re:Invent 2015 参加レポート・関連記事】
  • f
  • t
  • p
  • h
  • l

RECOMMEND