ボットや不正利用トラフィックは、多くの場合バースト的ではなく、低速で継続的な行動として現れます。あるIPが毎分30〜50リクエストを送っているとしましょう。これ単独では致命的ではありませんが、10分間続けばスクレイピング、自動化、またはパスワード試行行動に変わり得ます。即時レート制限は、この時間に広がる行動の性質を常に正確には捉えられません。
WAAPシグネチャは別の問いを解決します：このリクエストは既知の攻撃パターンに一致するか？SQL injection、XSS、command injectionといった悪質なコンテンツパターンは捕捉できます。しかし正当に見えながら大量のトラフィックを生成するスクレイピング、価格追跡、アカウント試行、攻撃的なAPI利用は、シグネチャベースの保護をすり抜け得ます。
この2つのアプローチの間に、一時的アイソレーションモデルが必要です。特定のソースが過去N分間にしきい値を超える行動を示した場合、恒久的に禁止することなくM分間隔離すべきです。この期間中、トラフィックはブロックされる、説明ページへ送られる、または別のフローへリダイレクトされ得ます。期限が切れればソースは自動的に解放されます。
このモデルには2つの独立した機構が必要です：行動を測定する監視ウィンドウと、アイソレーションを適用する隔離ウィンドウです。監視は短く、隔離はより長く保つこともできます。あるいはアプリケーションの感度に応じて逆に選択することもできます。アクションも一律であってはなりません：あるソースには静かなブロック、あるソースには説明ページ、あるソースにはリダイレクトがより適切かもしれません。
TR7トラフィック隔離はこのモデルを提供します：監視と隔離のための2つの独立した時間ウィンドウ、4種類のキータイプ、3つのアクションタイプ、隔離状態を他のルールの条件として利用できる仕組み、そしてvService画面からのライブ可視性と手動介入。
TR7トラフィック隔離は、行動監視と一時的アイソレーションを同一のポリシーエンジンで統合します。
各隔離ルールでは、監視ウィンドウと隔離ウィンドウが個別に定義されます。監視ウィンドウはソースの行動を測定し、隔離ウィンドウはしきい値超過後にアクションがどれだけの期間続くかを決定します。
ソースはIPとしてのみ定義する必要はありません。IP、IP+ユーザーエージェント、Host+IP、Host+IP+ユーザーエージェントの選択肢により、マルチドメイン、NAT、マルチテナントのシナリオでより正確な区別が可能になります。
隔離中、トラフィックはブロックされる、別のURLへリダイレクトされる、またはカスタムコンテンツページが表示されます。これにより、攻撃トラフィックには静かなブロック、実ユーザーには説明付きメッセージ、業務フローに沿ったリダイレクトを適用できます。
隔離されたソースは、システム全体で利用可能な状態シグナルに変わります。他のトラフィック、リダイレクト、コンテンツルールは、このシグナルを条件として利用してコンポジットポリシーを構築できます。
トラフィック隔離は、行動監視、一時的アイソレーション、オペレーター制御を単一の動作モデルにまとめます。
各ルールで監視時間と隔離時間を独立して設定します。監視ウィンドウ内でソースの行動がカウントされ、しきい値を超えるとソースは隔離ウィンドウの間、別のリストに保持されます。期限が切れるとレコードは自動的に削除されます。この構造は恒久的な禁止ではなく、制御された期限付きアイソレーションを提供します。
`ip`オプションは古典的なソースIPベースの監視を提供します。`ipUa`は同一IPの背後にある異なるユーザーエージェントを区別します。`hostIp`は、マルチドメイン環境で同一IPが異なるホストへ向かう行動を別々にカウントします。`hostIpUa`は、マルチテナントおよびマルチクライアント環境で最も粒度の細かい区別を実現します。
オペレーターは、特定の時間ウィンドウにおけるリクエスト数のしきい値を定義できます。「過去10分間に100リクエスト超」のようなルールが行動ベースの隔離を開始します。判断は単一のリクエストではなく、ウィンドウ内の総行動に基づきます。このアプローチはレート制限とは異なり、観測に基づきます。
`block`アクションは、隔離されたソースのトラフィックを静かにドロップするために使用されます。ボットや自動化トラフィックでは、この動作が多くの場合より効果的です。攻撃者は明確なアプリケーション応答を得られません。このアクションは、説明を表示する必要のない高リスクなabuseシナリオに適しています。実ユーザーへの影響はvServiceモニター画面から追跡できます。
`showContent`は、隔離されたソースにカスタムHTTPステータスコードとコンテンツを返します。例えば、過剰なリクエストにより一時的に制限されている旨を説明するページを表示できます。このモデルは、偽陽性の可能性がある、またはユーザー体験が重要なシナリオで、ブロックよりも穏やかに振る舞います。メッセージ内容は組織のサポートおよびブランドの言葉遣いに合わせて作成できます。
`redirect`は、隔離されたソースを別のURLへリダイレクトするために使用されます。CAPTCHAページ、説明ポータル、サブスクリプションアップグレードページ、サポートページを宛先にできます。これにより隔離は単なるブロックではなく、ユーザーを正しい業務フローへ運ぶ手段になります。マルチテナントおよびSaaSシナリオで、このオプションは特に価値があります。
あるソースが隔離されていることを、他のルールの条件として利用できます。隔離されたソースは別のbackendへリダイレクトされる、カスタムヘッダーを受け取る、カスタムコンテンツ応答を見る、または第二のより厳格なルールの対象に入り得ます。この機能は、単一の隔離ルールをシステム全体の行動変更を引き起こすシグナルへと変えます。TR7の最も重要な差別化ポイントの一つです。
トラフィック隔離はHTTPサービスとTCPサービスの両方で利用できます。HTTP側ではリクエストベースの行動が監視され、TCP側では接続レベルで判断されます。プロトコルによってアクションの技術的な結果は変わり得ますが、基本モデルは同じです：監視し、しきい値を超えたものを一時的アイソレーションに入れ、期限切れで解放する。
vServiceのライブ監視画面に、隔離中のアクティブなソースが一覧表示されます。オペレーターは、どのキーが、どのルールにより、どれだけの期間隔離されているかを確認できます。偽陽性や優先ユーザーの場合には手動での除外が可能です。期限切れのレコードは自動的に整理されるため、手動介入は必須ではありません。
同一のvService配下で複数の隔離ルールを併用できます。例えば、最初のルールが過剰なリクエストに対して警告ページを表示する一方、第二のルールは依然として継続しているソースをより長くブロックできます。vServiceあたり5つの並列隔離ルールがサポートされます。この構造は、穏やかなものから厳格なものへと進むabuse制御を構築します。
トラフィック隔離は、テーブルのライフサイクル、クラスター動作、リロードの影響、監視画面、監査レコードとともに運用面で管理されます。
各隔離ルールは、監視と隔離のために2つの独立したライブ監視領域を使用します。レコードは期限付きで保持され、TTLが切れると自動的に整理されます。新しいリクエストが来るたびに監視ウィンドウの行動が更新されます。この構造は隔離を恒久的な禁止ではなく、期限付きの行動制御として保ちます。
各リクエストでは、まずキー式が計算され、次に監視値が更新され、隔離条件が評価されます。ソースがすでに隔離中であれば、定義されたアクションが適用されます。ソースが隔離中でなければ、通常のトラフィックフローが続きます。判断はデータパス上で低コストで行われます。
デュアルノード構成では、隔離テーブルはローカルまたは同期で動作するよう設計できます。同期が有効でない場合、フェイルオーバー後に新たなアクティブノードは隔離履歴を最初から再構築します。同期が有効な場合、フェイルオーバー後も隔離状態を保持できます。この選択は運用ニーズと構成モデルに応じて検討すべきです。
隔離テーブルはメモリ上に保持され、恒久的なブラックリストのようには振る舞いません。ソフトリロードやテーブルリセット後、アクティブな隔離状態は消去され得ます。これは許容される動作です。なぜなら隔離は一時的アイソレーション機構だからです。長期的な禁止が必要な場合は、IPレピュテーションフィードと組み合わせて使用すべきです。
vServiceモニター画面でアクティブな隔離レコードを確認でき、オペレーターは特定のソースを隔離から除外できます。この操作はテーブルレコードを削除します。次のリクエストは通常のフローで評価されます。VIPユーザー、偽陽性、またはサポート要求の場合に迅速な介入を提供します。
隔離への追加と隔離からの除外イベントは監査レコードに書き込めます。SIEMログストリーミングが有効であれば、イベントは外部のコレクターへ送信できます。どのキーが、どのルールにより、どのアクションで、どれだけの期間隔離されたかを後から調査できます。
アクティブなキー数とキータイプはメモリ消費に影響します。IPベースのキーはよりシンプルで、Host+IP+ユーザーエージェントのような複合キーはより多くの領域を消費します。vServiceあたり並列5つの隔離ルールがサポートされるため、容量計画はトラフィックプロファイルに応じて行うべきです。
Eコマースサイトは、価格スクレイピングを行うソースを`ipUa`キーで監視できます。5分間に100リクエストを超えるIP+ユーザーエージェントの組み合わせは30分ブロックされます。同一IPの背後にいる異なる実ユーザーは別々のキーとして評価できます。
銀行ポータルは、ログインエンドポイントでの繰り返し試行をIPまたはIP+ユーザーエージェントベースで監視できます。しきい値を超えると、ソースは60分間説明付きページへ送られ、実ユーザーには一時的な制限の理由が表示されます。
複数のドメインをホストするSaaSプラットフォームは、`hostIp`キーで各テナントのトラフィックを別々に監視できます。あるテナントの攻撃的な利用を、他のテナントのトラフィックに影響を与えることなくリダイレクトまたは一時的ブロックのアクションに入れられます。
最初のルールが過剰なリクエストを送るソースを10分間警告ページへリダイレクトします。ソースが隔離中も依然としてトラフィックを生成し続ける場合、第二のルールが作動し60分のブロックを適用します。隔離状態が他のルールの条件になることが、この段階的モデルを可能にします。
行動ベースの一時的アイソレーション、コンポジットルール構造、そしてライブのオペレーター可視性。お客様の環境でどのように動作するかを一緒に確認しましょう。