“脆弱性を突くような攻撃を防ぐ”だけではない「WAF」　「AWS WAF」の運用で現場が抱える課題

WAFで困るのは「直して」と言えないこと

清野隼史氏（以下、清野）：ここからはもうちょっと現場レベルまで踏み込んでいきます。その中でも特にWAFのところにフォーカスをしてエピソードを聞きたいなと思います。このトピックでは、AWSの運用で現場が抱えている課題みたいなところを聞きたいなと思っています。こちらも佐竹さんに聞いてもいいですか？

佐竹陽一氏（以下、佐竹）：はい。「AWS WAF」もしくは「WafCharm」を使っているという視点で話します。先ほど臼田さんが「Security Hubを使っている方」というアンケートをして、半分ぐらいの方が手を挙げられたことに「そんなにいるの!?」とむしろちょっとビックリしています（笑）。

（一同笑）

「意識高!!」と思ったんですけど（笑）。こういう課題は、もしかしたら現場の方も持っていると思います。

セッションの1個目のところでBookLiveさんが「正直WAFで一番多いのは、誤検知が多いな」という話をしていました。誤検知の「誤」は「誤る」（という漢字）ですが、これは誤ブロックみたいなもので、「意図しない検出」という意味です。

自社サービスを開発されている方がどれくらいいるかわからないですが、自社サービスを開発してやっている場合、先ほどあったように「スクリプトを使うな」と言えます。しかし、我々が見ているエンタープライズの企業さんは、パッケージを買ってWAFを挟んでいる場合が大半なんですよ。

それで検知された場合、「直して」と言えない（笑）。海外の製品だと、海外のところに「直して」と言っても、直してくれないのは目に見えていますよね。そういう時に、WafCharm には「除外してもらっていいですか？」と言えるのが良いんですよ。こういう話は「WAFを入れると何が起きるのかが不安です」というお客さんによく話しますね。

WafCharmのビジネス以上のサポートプランに入ってもらえれば、すぐに窓口に問い合わせできるじゃないですか。我々をとおしてもらっても良いのですが、直接問い合わせもできるようになっているので、それもけっこうありがたいですね。

販売会社側が24時間365日の窓口を持つのはどうしても厳しい場合があるので、検出が思ったとおりにいっていない時に「すぐに解放してもらえるか」というのが、現場で一番問い合わせが多い認識ですね。

清野：なるほど。ありがとうございます。「そもそもうまく使いこなせてないし、うまく使いこなす手段がない」みたいなシーンがあったりするということですね。

佐竹：そうですね。パッケージ製品に噛ませているのもけっこう大きいですよね。

（一同笑）

WAFの運用をやったことがない顧客も多い

佐竹：逆にクラスメソッドさんはどうしているのかを聞きたいです。

臼田圭祐氏（以下、臼田）：そうですね。僕らはいろいろなお客さんを支援している中で、そこの融通が利きづらいというよりは、単純に「WAFってどうやったらいいですか？」みたいなものがけっこう多いです（笑）。わりと融通が利くケースがどちらかというと多いですかね。

とはいえ「運用はわからない」「やったことがない」みたいな感じのことが多いので、そういう時に「とりあえず迷ったらWafCharmを入れておいてください」みたいな感じで雑に投げちゃったりすることは非常に多いですね。

あとは、「Webアプリケーションを出しています」というお客さんに「WAFを入れていますか？」と聞くと「入れていないです」みたいな（笑）。そもそも入っていないようなパターンが多くて、これはけっこう悩ましいなと僕は思っていますね。

WAFの役割は「脆弱性を突くような攻撃を防ぐ」だけではない

臼田：その時に「なんで入れていないんですか？」と聞くと、よく返ってくる答えは「アプリケーション側の脆弱性対策をしっかりしているので、WAFいらないです」と言われるんですね。

これは半分ぐらい正しいんですが、半分ぐらい間違っているんですね。WAFは確かに脆弱性を突くような攻撃、例えばSQLインジェクションやクロスサイトスクリプティングを突いてくる攻撃を防ぐ役割もあるので、そういった側面で、アプリケーション側がちゃんと堅牢化できているかというところは、もちろん大事な観点の1つなんです。

ですが、WAF自体はそれ以外にも役割があって。先ほどのセッションでも「DDoSに対して対策する」みたいな話がありましたが、大量に飛んでくるリクエストをフロント側で検知したり、止めたりする役割とかもあるんですね。必ずしも脆弱性を突いた攻撃、DoSの攻撃とかだけではなくて。

あるいは、変な細工されたリクエストとかが飛んできた時に止める。いち早く、迅速にアプリケーションの手前で止める役割があるので大事なんですよね。あとは、単純に1つのプロダクトだけだったら、「ちゃんと堅牢化しているので大丈夫です」みたいな感じに言えるかもしれません。

しかし、組織の中にはたくさんのWebアプリケーションがあります。100、200のWebサイトがあって、それらをどうやって守っていくかが課題というような時に、ガバナンスとして、WAFを展開していくということが考え方としてあるんですね。「Webアプリケーションファイアウォールをとりあえず入れてください」という展開をしておいて、一括で「最低限こういうルールを入れておいてくださいね」とやっておくことで、最低限のセキュリティレベルは保てます。

もちろんアプリケーション側も対策していく必要があるのですが、それはそれとして、WAFのレイヤーを使ってガバナンスとして手前に一層入れておくことによって、一定のレベルのセキュリティは保てるようなところがあります。また、それを入れておくことによって、先ほど言ったような、いざという時、「攻撃を受けています」「止めたいです」という時に、「じゃあ今からWAFの導入を始めます」みたいな感じだったら、1テンポ遅くなっちゃいますよね（笑）。

「本当に入れて大丈夫なのか」とかを検証したりしなければいけないので、ふだんから入れておくことが大事です。なので、プロダクトの1つとしても入れておくし、ガバナンスとしても入れておくようなことをやっておいて。単純な脆弱性の対策だけができていればWAFはいらないというわけじゃなくて、そういったところでも合わせて使っていく必要があるということはちょっと意識して入れてほしいなと思っていますね。

佐竹：「ちょっと遅れる」で思い出したのですが、昔とあるWAF製品の営業さんと話した時に、「何年か前にDoSがすごく流行った時期があったんですが、問い合わせがめちゃくちゃ増えた」と。結局日本の企業さんはそういうイベントドリブンから後追いでやるみたいなことが多いんですよね。そこをどうにかしたいなと長年思っているのですが、世の中そういうものなんだなと（笑）。

（一同笑）

佐竹：つまりは解決（策）を投げたということなんですけど（笑）。

清野：ありがとうございます。結局WAFをどうするかという以前に、そもそもWAFに対しての正しい理解や意識をまずはしっかり持つところから始めていく必要があるということですよね。WAFの話をいろいろと聞いてきたところではあるのですが、このタイミングで次のところも見ていきたいなと思います。

（次回に続く）