はじめに

こんにちは。アペルザの渥美と申します。アペルザのインフラ・セキュリティ・アカウント周り、DevOpsの旗振りをしています。情シス (社内IT) の担当もやっています。ちなみにコードはほとんど書けませんので、書ける人にお願いする日々です。

今回は、自社サービスを運用するうえで、日々便利に使っている仕組みの中から、レートベースのIP Blockの仕組みを紹介します (AWS WAF標準のレートベースのルールとは別のものです) 。

背景

レートベースのIP Blockの仕組みを自前で準備した背景は次の通りです。

  • 負荷対策を後回しにしてきたので、急なアクセス増加でサイトが不安定になってしまう (行儀の悪いクローラーのせいで…
  • AWS WAF標準のレートベースのアクセス制限は、5分間2000アクセス 以上と、緩すぎる
  • 自社のWebアプリケーションの構成がいくつかあり、今後の変更の可能性も考えると、変更が少なそうなCloudFrontのログを前提としたい
  • スケールアップもスケールアウトもコストに直結するため、そこは最後の手段にしておきたい
  • アクセス解析用のAthena環境使えそう

構成の概要

Overview

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環境を使った、レートベース以外のアラートの紹介などを予定しています。


株式会社アペルザではWeb エンジニアを募集しています