機能

レート制限

1つのIP、1つのユーザー、1つのAPIキー、または1つのエンドポイント — 制限をどこに引くかを決めるのはあなたです。

TR7レート制限は、WAAP層でリクエスト数、接続レート、認証失敗数、帯域幅消費を集中ポリシーによって管理します。目的は単に「超過トラフィックに429を返すこと」ではなく、攻撃クラス、アプリケーション動作、バックエンド容量に基づいて適切なスコープと適切なアクションを対応させることです。 TR7はスライディングウィンドウカウンターモデルと、その上に構築された動作パターンを使用して、急激なスパイク、持続的な高負荷、不正使用の試みを検出します。制限は異なるディメンションで適用できます:IP、IPとユーザーエージェント、ユーザー名、カスタムヘッダー、クッキー、APIキー、またはこれらを組み合わせたコンポジットキー。 アクション側では単純な拒否以上の選択肢があります。TR7はHTTP 429でリクエストを停止したり、設定可能な期間の一時ブロックを適用したり、self-hosted CAPTCHAフローにリダイレクトしたり、帯域幅制限ルールで条件付き帯域幅シェーピングを適用したりできます。 結果:TR7はレート制限を単一ディメンションのセキュリティブレーキから、アプリケーションのコンテキストに基づいて不正使用、ボット動作、セッション悪用、リソース消費を管理する運用的なWAAPコントロールへと昇華させます。

5+
制限ディメンション:IP、ユーザー、APIキー、コンポジット、帯域幅
4
アクションオプション:429、一時ブロック、CAPTCHA、帯域幅上限
300 / 100 / 150
組み込みプロファイル閾値 — プロダクション対応の出発点(リクエスト/分)

1つのIPを制限するだけでは、現代の不正使用を止めるには不十分です。

従来のレート制限は通常、IPアドレスごとのリクエスト数として適用されます。このモデルはシンプルですが、NAT、キャリアネットワーク、共有エグレスポイント、匿名ゲートウェイにより、正規ユーザーと不正使用元が同じバケツに入ることがあります。単一IPからの高トラフィックが常に攻撃とは限りませんし、分散した低ボリュームトラフィックが常に無害とも限りません。

アプリケーションの動作は一様ではありません。ページロード中のアセットリクエストの短いバーストは正常ですが、同じレートが決済、ログイン、またはAPIエンドポイントでは不正使用を示す場合があります。単純な「1分あたりNリクエスト」モデルは、ユーザーエクスペリエンスを損ないつつ本物の攻撃を見逃すことがあります。

credential stuffing、アカウント列挙、ボットパターンは生のリクエスト数だけからは読み取れません。認証エンドポイントでの大量のログイン失敗は、総トラフィックでは低く見えることがあります。ユーザー名、セッション、APIキー、カスタムヘッダー、または応答動作と関連付けられていないカウンターはセキュリティコンテキストを失います。

リソース保護は別の問題です。分散クライアントがクライアントあたりの低レートでリクエストを送信しても、総負荷がバックエンドの接続プール、検索インフラ、またはファイルダウンロード容量を枯渇させる可能性があります。レート制限は攻撃者を止めるだけでなく、バックエンド容量を公平かつ管理された状態で配分するためにも必要です。

TR7のアプローチは、レート制限を粗いIPベースの閾値から、ユーザー、エンドポイント、セッション、APIキー、コンポジットキー、帯域幅ディメンションで適用できる制御されたセキュリティポリシーへと引き上げます。

私たちのアプローチ

TR7はレート制限を、スコープ、カウンターモデル、アクション選択が連携して設計された多次元WAAPコントロールとして実装します。

スライディングウィンドウモデルが実際のトラフィック動作を追跡

TR7は設定可能な時間ウィンドウ内でリクエスト、接続、エラー、帯域幅レートを追跡します。異なるウィンドウ長により、短期スパイクと持続的な高負荷を独立して評価できます。

制限キーは攻撃クラスに合わせて選択

IP、IPとユーザーエージェント、ユーザー名、APIキー、クッキー、ヘッダー、またはコンポジットキーを使用して異なるスコープを作成できます。これにより、同じIPの正規ユーザーにペナルティを与えることなく、不正使用をより正確に検出できます。

アクションモデルは重大度に基づいて段階的に適用

ポリシーはリクエストを拒否したり、一時ブロックを適用したり、CAPTCHA認証にリダイレクトしたり、帯域幅上限を課したりできます。すべての違反が同じレベルの対応で処理されるわけではありません。

インプロセスカウンターアーキテクチャがレイテンシを低く保つ

カウンターはデータパス内に維持され、判断時に外部データベース呼び出しは不要です。マルチインスタンスデプロイメントはカウンター同期によりサポートされ、分散環境での一貫したポリシー適用が可能です。

機能

TR7レート制限は、既製のボットポリシーからカスタムコンポジットキーまで、さまざまな不正使用シナリオを単一の管理モデルでカバーします。

組み込みレート制限プロファイルがプロダクション対応の出発点を提供

TR7は一般的なボット・不正使用シナリオ向けの既製ポリシーを内蔵しています。`bot_rateLimit`プロファイルはIPあたり300リクエスト/分でHTTP 429を返せます。`bot_rateLimitStrict`は100リクエスト/分後に5分間の一時ブロックを適用できます。`bot_rateLimitCaptcha`は150リクエスト/分後にself-hosted CAPTCHAフローにリダイレクトできます。

トリガータイプがプレーンリクエスト、ログイン失敗、リスクスコアを分離

`requests`タイプは生のリクエストレートを追跡します。`failedAuthAttempts`は専用カウンターで認証失敗を処理します。`riskScore`はボットまたは動作スコアに基づいて判断できます。`static`は特定フローでの必須CAPTCHAなど無条件コントロールに使用されます。

IP、ユーザー、コンポジットキースコープを同時使用可能

`global`スコープはサービス全体の総負荷を監視します。`ip`、`ip+ua`、`username`、`composite`スコープはより的を絞った制限を作成します。コンポジット構造は、カスタムヘッダー、クッキー、APIキー、またはリクエストボディのフィールドを組み合わせてカスタムカウンターキーを生成できます。この柔軟性により、B2B APIとマルチテナントアプリケーションが実際の使用制限をより正確に反映できます。

同一リクエストを複数のレートポリシーで同時評価可能

サービスプールには複数のレート制限ポリシーを同時にアクティブにできます。例えば、同じリクエストがIPスコープのDDoS上限とユーザースコープの公正使用制限の両方の対象になれます。各ポリシーは独自の独立カウンターを追跡します。この構造により、単一閾値ではなく階層型保護モデルが構築できます。

一時ブロックアクションはレートが下がってもキーをブロック状態に保持

`block`アクションが発動すると、影響を受けたキーは設定された期間ブロックテーブルに保持されます。これにより、攻撃者が短いバーストを生成してすぐに速度を下げて復帰することを防ぎます。`blockDuration`はポリシーごとに設定されます。このモデルは激しいボット波と繰り返しの不正使用元に対してより強力な制御を提供します。

Self-hosted CAPTCHAが疑わしいトラフィックをハードブロックではなく認証に誘導

`captcha`アクションは閾値を超えたトラフィックやリスクありとフラグされたトラフィックを完全に遮断するのではなく認証フローにリダイレクトできます。デフォルトプロバイダーは`tr7Standard`です。認証成功後にユーザーのリクエストは継続されます。このアプローチは、自動化と実ユーザーの区別が優先される場面でブロックより均衡のとれた代替策を提供します。

帯域幅制限ルールで条件付きトラフィックシェーピングが可能

TR7はリクエスト数に加えてインバウンド・アウトバウンドの帯域幅レートも追跡できます。`bwLimit`アクションにより、特定の条件に一致するトラフィックを独自の帯域幅上限下に置けます。これはファイルダウンロードエンドポイント、大きなレスポンスを生成するエンドポイント、または単一ソースからの大量データ消費に有用で、バックエンドを完全に遮断せずに利用可能状態を維持できます。

AAMセッション変数でユーザーごとのレート制限が可能

AAMセッションからのユーザー名などの情報をレート制限キーとして使用できます。これにより、ログイン後に各ユーザーに別々の公正使用制限を割り当てられます。無料プランと有料プラン、内部ユーザーグループと外部ユーザーグループ、または異なるロールレベルをそれぞれ異なる制限で管理できます。IPベースの制限が不十分なAPIとポータルシナリオでより正確な制御を提供します。

運用の深さ

レート制限ポリシーが有効であるためには、カウンターのライフタイム、テーブルサイズ、クラスター同期、可観測性、ロールバック動作をすべて運用上明確に管理する必要があります。

01

アダプティブカウンターテーブルサイジング

異なるスコープは異なるテーブルサイズで動作します。グローバルスコープは単一キーを使用し、IPとコンポジットスコープはより多くのエントリを保持できます。IPとユーザーエージェントの組み合わせなど長いキーはより多くのメモリを消費する可能性があるため、スコープ選択は期待されるトラフィックプロファイルに基づいて行う必要があります。

02

マルチインスタンス同期

クラスターデプロイメントではインスタンス間のカウンター同期がサポートされます。同じポリシーキーを持つインスタンスはお互いを発見してカウンター状態を共有できます。これにより、攻撃者が負荷分散環境でインスタンスを切り替えて制限を回避することが難しくなります。

03

リロード間のカウンター継続性

ポリシーIDに紐づいた安定したテーブル命名がリロードサイクル間でカウンター状態の保持に役立ちます。同じポリシーが同じ名前で継続する場合、カウンターは不必要にリセットされません。これにより、メンテナンスや設定更新中にセキュリティギャップが発生するリスクを低減します。

04

ポリシー検証レイヤー

レート制限ポリシーはデプロイ前にスキーマ検証を通過します。無効なスコープ、トリガータイプ、アクション定義はプロダクション設定に入れません。このチェックにより、誤設定されたセキュリティルールがライブトラフィックを妨害するリスクを低減します。

05

アクションチェーンの互換性

ボットポリシー、アカウントロックアウトルール、WAAP判断はすべて同一リクエスト上で同時に動作できます。優先順位とマッチング動作は設定によって管理されます。したがってレート制限は単独ではなく、広義のWAAP判断パイプラインの一部として動作します。

06

監査と可観測性

トリガーごとに、ルールID、アクション、キー、レート情報をログに記録できます。これらのレコードはインシデント分析とレポートのためにSIEMに転送できます。運用チームは最も頻繁にトリガーされるキー、最も混雑したエンドポイント、ブロッキングトレンドを時系列で監視できます。

活用シナリオ

APIゲートウェイでのユーザーとIPの階層制限

B2B APIを提供する組織は、ユーザーごとのプラン制限とIPごとの不正使用上限を同時に適用できます。TR7はユーザースコープの公正使用ポリシーとIPスコープのハード上限を並行して実行します。

ログインエンドポイントでの失敗試行制御

認証画面での大量のクレデンシャル入力失敗はブルートフォースの指標になります。TR7はユーザー名とIPの組み合わせキーで失敗を追跡し、段階的なアクション(最初にCAPTCHA、次に一時ロック)を適用できます。

Eコマースフローでのエンドポイントごとの保護

商品ページでの短いリクエストバーストは正常ですが、決済エンドポイントでの同じパターンはリスクです。TR7はエンドポイント条件と異なる時間ウィンドウを使用して、ページロード体験を低下させることなくチェックアウト悪用を制限できます。

ファイルダウンロードトラフィックの帯域幅制御

単一ソースが大量ダウンロードによってバックエンドのI/O容量を消費することがあります。TR7は帯域幅制限ルールを使用してそのトラフィックを条件付きで上限設定し、他のユーザーへのサービスを維持します。

よくある質問

IPごとのレート制限はNATや共有エグレスを使用する実際のユーザーに影響しますか?
IPベースの制限は、NATやCGNAT背後のすべてのユーザーを同じカウンターに含める可能性があります。このリスクを低減するため、TR7はコンポジットキースコープ(ユーザー名、APIキー、クッキー、またはIPとユーザーエージェントの組み合わせ)を提供します。これにより、同じIP背後の正規ユーザーにペナルティを与えることなく、不正使用をより正確に検出できます。
ブロックアクションと拒否アクションの違いは何ですか?
`deny`アクションはHTTP 429を返し、攻撃者はウィンドウが切れたら再試行できます。`block`アクションはトリガーされたキーを設定した`blockDuration`の間ブロックテーブルに保持します — レートを下げても攻撃者はその期間が終わるまで復帰できません。繰り返しの不正使用元には`block`がより強力で持続的なコントロールを提供します。
self-hosted CAPTCHA統合はどのように機能しますか?
`captcha`アクションは閾値を超えたまたはリスクありとフラグされたトラフィックを遮断するのではなく認証フローにリダイレクトします。デフォルトプロバイダーは`tr7Standard`です。認証成功後にユーザーのリクエストは継続されます。このアプローチは、自動化と実ユーザーの区別が目標のシナリオでブロックへのより均衡のとれた代替策です。
同じエンドポイントに複数のレートポリシーを適用できますか?
はい。サービスプールには複数のレート制限ポリシーを同時にアクティブにできます。例えば、同じリクエストがIPスコープのDDoS上限とユーザースコープの公正使用制限の両方の対象になれます。各ポリシーは独自の独立カウンターテーブルを追跡し、ポリシーは互いに干渉しません。
帯域幅制限ルールはリクエストカウントと異なる動作をしますか?
はい。`bwLimit`アクションはリクエスト数ではなく、インバウンドとアウトバウンドの帯域幅レート(`bytes_in_rate`、`bytes_out_rate`)を追跡します。条件に一致するトラフィックは独自の帯域幅上限下に置かれ、ハードカットオフなしにバックエンドを利用可能な状態に保ちます。これはファイルダウンロードエンドポイントと大きなレスポンスを生成するエンドポイントに特に適しています。
クラスター内の異なるインスタンスが同じカウンターを共有できますか?
はい。マルチインスタンスデプロイメントでカウンター同期がサポートされます。同じポリシーキーを持つインスタンスは自動的にお互いを発見してカウンター状態を共有します。このメカニズムにより、攻撃者がインスタンスを切り替えて制限を回避することが難しくなり、分散環境で一貫したポリシー適用を保証します。

アプリケーションのコンテキストに合わせたレート制限の設計

IP、ユーザー、APIキー、帯域幅ディメンションにわたる多層レートポリシー。お客様自身のサービスでのライブセットアップをご案内します。