上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
実際の訪問者の多くは、住宅用またはモバイルのネットワークから接続します。自動化されたトラフィックの多くは、データセンターやクラウドホスティング事業者から接続します。この違いは、IP検索のasnとorgのフィールドにはっきりと表れます。
GET /v1/ip?ip=203.0.113.99{
"status": "ok",
"ip": "203.0.113.99",
"version": 4,
"found": true,
"country": "United States",
"country_code": "US",
"region": "Virginia",
"city": "Ashburn",
"postcode": "20147",
"lat": 39.0438,
"lon": -77.4874,
"timezone": "America/New_York",
"asn": 16509,
"org": "Example Cloud Hosting"
}自社のトラフィック履歴をもとに、クラウドホスティングや既知の自動化プラットフォームと結び付く組織名のパターンや特定のASN番号の短いリストを管理し、それらのネットワークからのトラフィックは即座にブロックするのではなく、CAPTCHAによる確認や信頼スコアの引き下げなど、追加のチェック対象としてフラグを立てます。企業のVPNやモバイル通信事業者のインフラなど、クラウドのIP範囲にも正当な用途があるため、このシグナルは単独で使うよりも、行動に基づくシグナルと組み合わせたほうが効果的です。
ASNのチェックとcountry_codeフィールドを組み合わせると、別のパターンを捉えられます。ある国を拠点としていると申告しながら、別の国で登録されたデータセンターのアドレスから常にサインインしてくるアカウントは、どちらかの事実だけよりも、2つが揃ったときのほうが強いシグナルになります。実際の顧客も旅行をしたり、ごく普通の理由でVPNを使ったりするため、どちらのフィールドも単独では何も証明しません。しかし、スコアリングの仕組みでは、この組み合わせを個別のチェックよりも重く評価する価値があります。
ASNのチェックは事後ではなく、登録フォームやログインの試行など、トラフィックが最初にアプリケーションに到達した時点で実行してください。そうすれば、そのシグナルが次に起こることに実際に影響を与えられます。アドレスのASNはセッションの途中で変わらないため、結果はセッションの間キャッシュしておきます。
登録時に一度スコア化され、後日同じネットワークアドレスから戻ってきた訪問者については、毎回新たに検索する必要はありません。特定のアドレスのasnとorgのフィールドはセッションをまたいでも変わらないからです。分類結果はセッションだけでなくアドレスそのものに紐づけてキャッシュし、安全とわかっている住宅用アドレスが今後の訪問のたびに再評価されることもないようにします。
既知のホスティングやクラウドのASNからのリクエストを、スコア化せずにすべて即座にブロックすると、本来止めたかった自動化トラフィックとともに、正当なトラフィックの一部も確実に締め出してしまいます。企業のVPNの出口、一部のモバイル通信事業者、プライバシー重視のブラウザーはいずれも、ホスティング事業者と同じように見えるインフラを経由することがあります。ASNとorgのフィールドは、それ単独で自動的にブロックするルールとしてではなく、スコアリングや確認の判断に使う入力の1つとして利用してください。
新しいセッションごとに1回検索し、その後キャッシュすれば、訪問者が行うリクエストごとではなく、訪問者1人につき1件のリクエストで済みます。登録やログインがそれなりに多いサイトでも、中程度のトラフィックであれば、すべてのキーに含まれる1日あたりの無料リクエスト2,500件の範囲に収まり、量がそれを超えて増えればプリペイドクレジットやUnlimitedキーに移行できます。
ネットワークの発信元は複数あるシグナルの1つであり、それだけで結論が出るものではありませんが、登録やログインのフローに低コストで追加できます。IPv4検索のドキュメントとIPv6検索のドキュメントに、エンドポイントが返すすべてのフィールドが説明されています。