まだIPファイアウォールだけに頼っているのですか？変え時です。
IPアドレスは今も、ネットワークが機能するためのコア技術の一つではあるかもしれませんが、セキュリティ上の価値はもうありません。IPが静的であることは珍しく、現在、モバイル通信事業者はキャリアグレードネットワークアドレス変換（CGNAT）技術を使って、何千もの個別デバイスや個別ユーザー間で同じIPを共用しています。そこでボットが分散型攻撃を仕掛け、さまざまなIPから少量のリクエストを送ってスロットリングを回避します。しかも、IPアドレスを個人データと考える国が多いため、現在IPアドレスに依存して機能しているセキュリティ要素の代替が見つかれば、プライバシー保護における大きな前進となるでしょう。このトレンドの影響を受ける製品がレート制限です。
レート制限は、リクエストによる過剰負荷がサーバーにかからないようにするもので、ルールに依存しています。レート制限のルールは、フィルター（通常は/loginのようなパス）と各ユーザーが一定時間内に送信できるリクエストの上限数で定義されています。この閾値を超えた時は、そのユーザーがその後一定時間に発するリクエストに対してアクション（通常はブロック）が発動します（タイムアウトと呼ばれます）。スロットリングに対する従来のソリューションは、「同じＩＰからのリクエスト＝同じユーザーからのリクエスト」というロジックに基づき、同一IPからのリクエストをまとめるというものでした。しかし、当社はお客様から、IPベースのレート制限はトラフィックの保護には有効でない（特に認証済みAPIの場合）とお聞きしています。
高度なレート制限（Advanced Rate Limiting）はスロットリング技術の大前進であり、ローンチできることを嬉しく思います。高度なレート制限によって、送信元IPにかかわらず、HTTPリクエストのあらゆる特性に基づいてリクエストをカウントすることができます。レート制限は、ブルートフォース攻撃、スクレイピング、標的型DDoS攻撃に対する優れた防衛策です。これらの攻撃は、機密データの漏えいやアカウント乗っ取り、バックエンドリソースの枯渇といった結果をもたらします。リクエスト数を管理することは、呼び出しのたびにコストのかかる計算がオリジンサーバーで行われるAPIに関しては特に重要です。
スロットリングの画期的イノベーション
高度なレート制限は今や、Webアプリケーションファイアウォール（WAF）の一部です。ファイアウォールルールと統合され、IP以外の特性に基づいてリクエストをカウントすることが可能になっています。
高度なレート制限により、以下が可能です。
URI、メソッド、ヘッダー、クッキー、ボディなど、HTTPリクエストのあらゆる特性を用いてルールフィルターを定義できます。ボット管理プランのお客様は、ボットスコアの動的フィールドにもアクセス可能です。また、HTTP応答の２つの特性（ステータスコードと応答ヘッダー）を用いてレート制限を発動することもできます。
IP、国、ヘッダー、クッキー、AS番号（ASN）クエリーパラメーター値、JSONボディフィールド値に基づいて、リクエストをカウントすることができます。これらのフィールドを個別に使うことも、組み合わせて使うこともでき、値が同じであればリクエストをまとめます。許可したいリクエストの上限数ではなく、お客様のオリジンで扱える複雑度の最大値を閾値として設定することも可能です。
お客様のトラフィックすべてに適用できます。Enterpriseプランのお客様は、レート制限をトラフィックの一部について購入することができます。高度なレート制限ならば、上限を気にすることなく、トラフィック全体に使うことができます。最後に、高度なレート制限は、中国を含めCloudflareネットワーク全体でお使いになれます。
お客様のアプリケーションと統合可能な設計
本節では、WebやAPIのトラフィックを高度なレート制限で保護するユースケースをいくつか紹介します。それらの設定は、お客様のセキュリティニーズやアプリケーションに合わせて組み合わせることができます。これらのユースケースはすべて、ダッシュボード、API、Terraformで実現可能です。
ユースケース - きめ細かなルールでWebトラフィックを保護
柔軟なフィルター。レート制限のルール作成に、HTTPリクエストのすべてのフィールドを使うことができます。たとえば、特定のヘッダー（ユーザーエージェントなど）でリクエストに関するルールを発動することもできますし、同一ASNを持つボットからのトラフィックをスロットリングすることもできます。
ミティゲーション表現の分離。ミティゲーション表現をカウンティング表現から分離できるため、Webサイトの中で閾値に達したらユーザーをブロックしたい部分と、カウンターを増やすためにリクエスト（と応答）が満たすべき条件を、定義することができます。たとえば、/loginエンドポイントへのリクエストをカウントして、サイト全体で同じユーザーをブロックすることができます。これは、カウンティング表現に応答フィールドを含めたい（たとえば、特定の応答コードを返すリクエストだけをカウントするなど）が、ブロックしたいトラフィックがそのカウントより大きい場合に、特に有用です。
動的フィールドの使用。お客様は、レート制限と、既知の脆弱性を検知するルール（WAF機械学習スコアなど）を組み合わせることができます。たとえば、SQLi のフラグが立ったリクエストが数回連続してサイトに届いたら、ページ訪問をブロックすることができます。もう一つのユースケースは、ボットが送信した可能性が高いリクエストだけに対して、あるいは盗まれた資格情報でログインが数回試みられた後に、スロットリングルールを発動する場合です（リンク）。また、JA3フットプリントをカウントのディメンションにして、当社のボット機械学習アルゴリズムを使って、同じフィンガープリントを持つボットトラフィックをバケット化することもできます。
ユースケース - レート制限をアプリに統合してAPIを保護
セッションIDに基づいてリクエストをカウント。APIトラフィックは認証済みの場合が多く、セッションをクッキーやヘッダー（たとえばx-api-key）、またはクエリー値で追跡することができます。高度なレート制限によって、リクエスト中のIDの位置を定義し、IPにかかわらず、同一セッションに関連するリクエストの数を追跡できます。これは、機密データ（製品価格、航空機乗客データなど）をスクレイピングする分散型ボット攻撃への防御策として有効です。
リクエストのボディコンテンツに基づいてルールを発動。ルールフィルターでは、rawのボディとJSON-parsedのボディにアクセスできます。ボディのJSONフィールドに特定の値があるリクエストを、ルールフィルターの関数lookup_json_field()を使ってカウントすることができます。これは、エンドポイントは同じでもリクエストのボディで異なるオペレーションを指定して異なる呼び出し（または変異）を実行するようなGraphQL APIに有用です。
複雑度に基づくレート制限（まもなくベータ版を発表予定）。API呼び出しには、比較的容易いものと複雑なものがあります。そのため、リクエスト数だけでは実際のサービスコストを反映しているとはいえません。GraphQL APIがその例です。呼び出しの複雑度は、そのリクエストを実行するためにサーバーが行わなければならない処理の量によって大きく異なります。オリジンサーバーは各リクエストの複雑度を推定し、その値を応答と共に返すことができます。レート制限は、オリジンサーバーが推定した複雑度に応じてカウンターを増やすことができます。そしてルールの複雑度の閾値を設定し、閾値を超えた後のリクエストについてはブロックなどのアクションを発動します。
パッケージング
高度なレート制限は、新しいAdvancedプランをご利用のEnterpriseのお客様を対象に公開されています。各プランの内容など詳細については下記をご覧ください。さらなる情報をご希望の方は、担当のCloudflareアカウントチームか、Customer Successマネージャーにお尋ねください。ProプランまたはBusinessプランのお客様は、高度なレート制限はご利用いただけませんが、何らかの優遇措置を計画中です。
Enterprise Core
Enterprise Advanced
フィルターで指定可能なリクエストフィールド
一部の標準的フィールド：URLメソッドヘッダーソースIP
すべての標準的フィールドボディフィールドアカウント乗っ取りフィールド動的フィールド（ボットスコアを含む *）
カウンティングフィルターで指定可能な応答フィールド
レスポンスコード応答ヘッダー
レスポンスコード応答ヘッダー
カウント指定可能な特性
IP
IPNATで認識されるIPASN国ヘッダーCookieクエリーJA3*
複雑度による指定
不可
可
最大サンプリング周期
10分
1 小时
*ボット管理プランが必要です。
レート制限の今後
今後数か月でお客様からのフィードバックを集め、高度なレート制限にどういった機能を追加すべきかを決定する予定です。検討中のアイデアはいくつかあります。トラフィックプロフィールの自動作成や、ルール作成時の閾値提案などです。