自社WebサーバにAWS WAFを適用しました(5)～運用後の経過～

ホーム
AWS/Azure, 実践記事
自社WebサーバにAWS WAFを適用しました(5)～運用後の経過～

AWS/Azure

2024.06.14

この記事は投稿日から1年以上経過しています。

こんにちは。
タイトルの通り、自社WebサーバにAWS WAFを適用しまして、
正常に稼働していることが確認できた頃合いだったので、
社内への技術的な共有も兼ねて寄稿することにしました。

全5回以下のような構成となります。

運用フェーズに入ってからやったこと

導入作業後に以下のことを実施していました。
・ALBアクセスログ確認
・AWS WAFのログ確認
・運用にかかる費用確認

ALBアクセスログの確認

LogStare Quintでは、取得したALBのアクセスログをもとに、日次・週次・月次でレポートを作成します。
以下のようなレポートが用意されています。
002_アクセスページ別ALB200-399応答集計
003_アクセスページ別ALB200-399応答除外集計
004_アクセスページ別Target200-399応答集計
005_アクセスページ別Target200-399応答除外集計
010_Desync軽減対象リクエスト集計
020_アクセスページ別リクエスト処理時間平均集計

これらを見て、異常が起きていないかを確認します。
ALBのトラブルシュート記事があったため、これらに該当するものがないのかを基本的に見ています。

AWS ALBのトラブルシューティングを行う
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html

上記の記事において、取り上げられている以下の項目を確認していきます。

ロードバランサーが処理時間の増加を示しています

020_アクセスページ別リクエスト処理時間平均集計　を確認します。
ALBのアクセスログでは以下の時間が取得可能です。
（以下引用）
request_processing_time ：ロードバランサーがリクエストを受け取った時点からターゲットにリクエストを送信するまでの合計経過時間 (ミリ秒精度の秒単位)。
target_processing_time ：ロードバランサーがターゲットにリクエストを送信した時点から、そのターゲットが応答ヘッダーの送信を開始した時点までの合計経過時間 (ミリ秒精度の秒単位)。
response_processing_time ：ロードバランサーがターゲットから応答ヘッダーを受け取った時点から、クライアントへの応答の送信を開始した時点までの合計経過時間 (ミリ秒精度の秒単位)。

レポートを見て、気になることがあれば、クローズアップ分析を用いて意図した情報を取得できます。
URIごとの応答速度はウェブサイトでは重要な要素ですので、これを見れば重いURIが一目でわかります。

ロードバランサーは、レスポンスコード 000 を送信します。

003_アクセスページ別ALB200-399応答除外集計を確認します。
200～300番台を除外したURIへのリクエストがレポートとして閲覧できますので、
それから [ 000 ] の有無を確認します。

ロードバランサーが HTTP エラーを生成する

003_アクセスページ別ALB200-399応答除外集計を確認します。
外部からの不正なリクエストもあり、HTTPエラーを0にすることはできません。
エラーメッセージの内容を見ながら、減らせるものを減らしていくことになります。

ターゲットが HTTP エラーを生成する

005_アクセスページ別Target200-399応答除外集計を確認します。
ターゲットの応答状況がはっきりするため、500番台エラーをサーバの処理をいじりつつ減らしていきます。

AWS WAFのログ確認

誤検知/誤遮断の確認

AWS WAFのログ確認は、誤検知/誤遮断を確認するために行います。

あらゆる場所からスキャンや攻撃が来る昨今において、
必要のないリクエストを弾いたうえで分析をすることが重要です。
LogStare Quintを使って下記のような条件を入れて分析をします。
・送信元国 [ 日本 ]
・ホスト名 [ www.secuavail.com ]
※IPアドレスでのリクエスト、ALBのFQDN宛のリクエストがくるので、それらを意図的に除外します。

分析対象のリクエストを限定したら、次に検知内容を確認します。
AWS WAFのマネージドルールに引っかかったリクエストのログには、それ特有のラベルが残ります。
ラベルを見ることで、どのマネージドルールに該当したのかがわかります。
ラベルとURIを参考に、誤検知/誤遮断かの見立てを付けます。
判断方法は、リクエストによってケースバイケースなので、詳細については割愛いたします。

他のWAFとは異なり、HTTPリクエストボディの情報が全て見れるわけではないので、
誤検知/誤遮断が発生してもどういった文字列が原因だったのかがはっきりわからないことがあります。
ある程度見切りをつける必要があります。

WAFのチューニング

誤検知/誤遮断の判断をベースに、チューニングをしていきます。
チューニングでは、原則遮断設定への切替、誤検知と思われるものは許可するように設定します。
AWS WAFのチューニングは、気を付けたとしても、他のWAF製品に比べて許可をする範囲が広がってしまいます。
許可ルールを作成するときには、ラベルのほかにも [ URI ] [ 送信元 ] なども条件に入れて、
許可する範囲を限定するとよいです。

運用にかかる費用確認

見積もっていた費用と、実際にかかった費用を確認します。
当初見積もり費用：50USD/月
実際の費用：71USD/月

21USD上回ってしまった大きな要因はAWS WAFでした。
・リクエスト件数1万件→リクエスト件数700万件
0.01USDで見込んでいたものが、実際は5.56USDとなっていました。
弊社IRサイトへ頻繁に更新状況の確認をするボットらしきものや、海外からの不審なアクセス全てが計上されるので、思った以上にリクエスト件数がありました。

・AWS WAFのルール数9個→AWS WAFのルール数27個
チューニング時の穴を大きくしないようにルールを再設計したところ、
3倍くらいの数になってしまいました。9USDの見込みが27USDになっていました。

・Cloud Watch PutLogEvents
ALBのログをCloudWatchへ保管するときの費用が掛かりました。
これは当初の費用算出において、含まれていないものだったので、個人的にあまり気にしていません。

ALBのアクセスログ及び、AWS WAFのログ量は3ヶ月の運用において、以下のようになりました。

AWS WAFログ量： 20GB
ALBアクセスログ量 : 8.5GB

まとめ

5回にわたり自社WebサーバへAWS WAFを適用するまでの過程や結果を紹介させていただきました。
サービスの仕様が透明化されているので、やり易かったほか、
金額面で驚くほど安くなったことに驚きました。
今回は利用しませんでしたが、AWSの技術サポートを頼ることもできるそうですので、
必要に応じて相談してみてもよいかと思います。

費用算出にて、20USDほど当初の見込みから増えていることは、上司にまだ言えていません。