はじめに
こんにちは。アペルザの渥美と申します。アペルザのインフラ・セキュリティ・アカウント周り、DevOpsの旗振りをしています。情シス (社内IT) の担当もやっています。ちなみにコードはほとんど書けませんので、書ける人にお願いする日々です。
今回は、自社サービスを運用するうえで、日々便利に使っている仕組みの中から、レートベースのIP Blockの仕組みを紹介します (AWS WAF標準のレートベースのルールとは別のものです) 。
背景
レートベースのIP Blockの仕組みを自前で準備した背景は次の通りです。
- 負荷対策を後回しにしてきたので、急なアクセス増加でサイトが不安定になってしまう (行儀の悪いクローラーのせいで…
- AWS WAF標準のレートベースのアクセス制限は、5分間2000アクセス 以上と、緩すぎる
- 自社のWebアプリケーションの構成がいくつかあり、今後の変更の可能性も考えると、変更が少なそうなCloudFrontのログを前提としたい
- スケールアップもスケールアウトもコストに直結するため、そこは最後の手段にしておきたい
- アクセス解析用のAthena環境使えそう
構成の概要
Blcokまでの大きな流れとしては、CloudFrontのログを毎分集計し、閾値を越えた場合にAWS WAFのConditionにIPアドレスを登録することで、CloudFtontでアクセス拒否をしています。
これを実現するために、大きく2つの仕組みがあります。
Athenaのログ集計基盤
CloudFrontのログを対象にAthenaでログ調査するための環境です。
CloudFront の機能をつかって S3 にアクセスログを保存。そのアクセスログを、Athenaで集計しやすいよう別のS3にLambdaを使ってコピー、当該のS3に対してAthenaからQsueryを投げられるようにしてあります。
アクセス数の集計とBlock
ここはほぼLambdaの説明になります。
毎分ログを集計し、閾値を越えたIPをAWS WAFの自動Block 用のIP Match Conditonに追加します。
このIP Match Conditonを対象にBlock する ルールを作成しておき、CloudFrontのWAFに設定しておくことで、レートベースのIP Blockを実現しています。
BlockしてはいけないIPの管理も実施しています。AWS WAFのWhite List (IP Match Conditon) を作成し予め登録しておき判定基準につかっています。 GoogleBot,BingBotなど主要なBotのIPも除外するようにしています。
まとめ
日々の運用のなかで意識しているは、自動化 (究極は運用不在に) 、シンプルに、低コストで、AWSに (いい意味で) 依存しまくる事。
そんな意識の中で生まれてきた仕組みのご紹介でした。何かの参考になれば幸いです。
次回は、同じAthena環境を使った、レートベース以外のアラートの紹介などを予定しています。