機能

スマートACL条件

単なるIPリストではない — 60以上の基準、AND/OR/NOTグループ、スマートファンクションチェーンが単一のルールエンジンにまとまった真のトラフィックインテリジェンス。

TR7 ADCでは、ACLは単に「このIPを許可し、あのIPをブロックする」だけではありません。ソースIP、国、都市、ASN、URLパス、クエリパラメータ、ヘッダー、クッキー、HTTPメソッド、TLS詳細、ユーザーエージェント、ボディコンテンツ、WAAPスコア、ボットクラス、キャッシュ状態、認証状態はすべて同じ条件の一部にできます。 これにより、オペレーターはコードを書くことなく複雑なトラフィック決定を定義できます。「トルコのモバイルユーザーを別のバックエンドに送る」、「WAAPスコアが高く既知の検索エンジンでないリクエストにCAPTCHAを表示する」、または「JWTにrole=adminが含まれる場合に異なるレート制限を適用する」などの決定はすべて一つのルールエンジン内に記述されます。 TR7のスマートACLモデルはAND / OR / NOTロジックで条件をグループ化します。同じACLを複数のルールで再利用できます。セキュリティ、ルーティング、レート制限、レスポンス処理はすべて同じ式エンジンで管理されます。 結果として:ネットワークルール、アプリケーションルール、セキュリティシグナルが同じ決定点で収束します。

60+
ACL基準タイプ:IP、国、ASN、ヘッダー、クッキー、ボディ、TLS、WAAP、ボットなど
40+
スマートファンクション:Base64、JSON、XML、JWT、正規表現、マップ/リスト、変換チェーン
8
シグナルグループ:接続、タイマー、リクエストライン、TLS、WAAP、ボット、コンテンツ、カスタム

モダンなトラフィック決定はIPとポートだけでは行えなくなっています。

クラシックなADCとファイアウォールのACLロジックは長らくIP、サブネット、ポート、プロトコルを基盤としていました。そのモデルはシンプルなネットワークアクセス制御には十分ですが、モダンなWeb、API、ボット、WAAPトラフィックはそれほど単純ではありません。

今日決定を行う際、「ソースIPは何か?」だけを問うのでは不十分です。リクエストはどの国から来ているか?どのASNからか?どのパスに向かっているか?どのクッキーが存在するか?JWTにどんなロールが記述されているか?ヘッダーセットは実際のブラウザに似ているか?TLSフィンガープリントは疑わしいか?このリクエストはWAAPスコアで何点を受けたか?ボットエンジンはこのユーザーをどう分類したか?

ほとんどの製品ではこれらのシグナルが別々の場所に存在します。ルーティングルールは一か所に、WAAPスコアは別の場所に、ボット決定はさらに別の場所に、ヘッダー書き換えも別の場所に、レート制限もまた別の場所にあります。これは運用を複雑にし、一貫性のない決定を生み出します。

より大きな問題は、複雑な条件が通常コードを必要とすることです。「このヘッダーが存在し、このクッキーが欠落し、パスが/api/で始まり、WAAPスコアが5以上だが、ソースが既知のボットではない場合」などのルールを記述するには、ほとんどの製品でスクリプト、独自のポリシー言語、またはベンダー固有のプログラミングが必要です。

TR7 ADCのスマートACL条件レイヤーはこの問題を解決します:トラフィック決定はUIから60以上の基準、スマートファンクションチェーン、AND/OR/NOTグループを使用して定義されます。ルールは単なるIPリストではなく、トラフィックの意味を読み取る決定構造になります。

アプローチ

TR7はACL条件をネットワークアドレスフィルターではなく、アプリケーションとセキュリティ決定の基本単位として扱います。

60以上の基準にわたるトラフィック認識

スマートACLエンジンはIPとポートをはるかに超えます。ソースIP、国、都市、宛先IP、宛先ポート、HTTPメソッド、URL、パス、クエリ、ヘッダー、クッキー、リクエストボディ、レスポンスボディ、TLS SNI、TLS暗号、TLSプロトコル、JA3フィンガープリント、WAAP攻撃ID、WAAP攻撃グループ、ボットクラス、ブラックリストカテゴリ、キャッシュ状態はすべて条件として使用できます。これにより、セキュリティとルーティングの決定が完全なアプリケーションコンテキストで行えます。

AND / OR / NOT条件グループ

ACLは単独で使用することも、論理グループ内の他のACLと組み合わせることもできます。内部グループはANDまたはORで動作し、条件を反転させてNOT動作にできます。例えば:「パスが/loginで始まる」AND「ソース国が許可リストにない」AND「ボットスコアが高い」BUT「既知のボットではない」— この構造により複雑なセキュリティポリシーが読みやすくなります。

スマートファンクションチェーニング

TR7スマートファンクションは生のトラフィック値をアクション可能な入力に変換します。Base64デコード、JSONパスクエリ、JWTヘッダー/ペイロードパース、XMLクエリ、正規表現マッチ、文字列置換、小文字/大文字変換、ダイジェスト、IPマスク、IP→国変換、マップ/リストルックアップ操作をすべてチェーニングできます。ACLは「このヘッダー値はマッチするか?」を問うだけでなく、ヘッダー内のJSONを解析し、JWTクレームを抽出し、ボディ内のフィールドをクエリします。

再利用可能なACLグループ

よく使われる条件を一度定義して異なるルールで再利用できます。「静的ファイル拡張子か?」、「認証クッキーが存在するか?」、「キャッシュヒットか?」、「WAAPでブロックされたか?」などの組み込みまたはカスタムACLを多くのルールで共有できます。このパターンによりルールの重複が減り、変更が集中管理され、運用エラーのリスクが低下します。

機能

スマートACL条件は60以上の基準にわたってトラフィックシグナルを読み取り可能な条件と強制可能なアクションに変換します。

HTTPパス、URL、メソッドマッチング

TR7はパス、パス+クエリ、完全URL、HTTPメソッドに対して条件を記述できます。マッチタイプはプレフィックス、サフィックス、部分文字列、正規表現が使用できます。/api/で始まるリクエスト、/adminパス、POSTメソッド、またはクエリ文字列を含む特定のURLパターンはすべて単一のACL定義内に表現できます。

ヘッダーとクッキー検査

リクエストヘッダー、レスポンスヘッダー、ユーザークッキー、バックエンドからのクッキーはすべてACL内で使用できます。X-Tenant-IDヘッダーに基づくルート選択、session_idクッキーが欠落している場合のログインへのリダイレクト、User-Agentコンテンツに基づくボットチェック、レスポンスクッキーに基づくカスタムセキュリティ動作はすべてこのレイヤーで記述されます。

ソースIP、国、都市、ASN

ACL基準はソースIPまたはCIDRに限定されません。国、都市、ASNベースの条件も定義できます。特定の国へのアクセス制限、特定の都市のユーザーへのカスタムルーティング、特定のASNからのトラフィックへの追加検証、またはデータセンターASNへのより積極的なボットポリシーはすべてサポートされます。

TLSとフィンガープリント条件

TLS SNI、TLS暗号、TLSプロトコル、SNIの存在、JA3フィンガープリントシグナルを条件に含めることができます。TLS 1.0を使用するクライアントに低い信頼スコアを割り当てる、SNIなしの接続を拒否する、既知の悪意あるJA3フィンガープリントリストにマッチするトラフィックをCAPTCHAに送る、または弱い暗号を使用するクライアントをモニターモードに配置することはすべて表現可能です。

リクエストとレスポンスボディ検査

ACLはリクエストまたはレスポンスボディのサンプリングされたコンテンツで動作できます。ボディ内の文字列または正規表現マッチングがサポートされています。JSONボディ内の高額トランザクションチェック、フォームフィールド内の特定パターンのキャプチャ、レスポンスボディに特定のマーカーが存在する場合のヘッダー追加、またはAPIペイロードコンテンツに基づくレート制限はすべて可能です。

JSON / XML / JWTクエリ

スマートファンクションにより、JSON、XML、JWTコンテンツをACL条件に変換できます。JWTペイロードのrole == "admin"、JSONボディのtransaction.amount > 10000、XMLに特定のパスが存在するかチェック、またはJWTヘッダーのアルゴリズム検証はすべてAPIセキュリティとアクセスポリシーに大きな柔軟性を提供する条件です。

WAAP統合

スマートACLエンジンはWAAP決定も条件として使用できます:WAAP攻撃ID、WAAP攻撃グループ、WAAPスコア、WAAPがリクエストをブロックしたか、WAAP攻撃としてフラグされたか。WAAPスコアが5以上の場合にCAPTCHAを表示する、SQLインジェクショングループのリクエストを特別なログ形式にルーティングする、またはモニターモードのWAAP検出結果を別のバックエンドに送るといったシナリオが例として挙げられます。

ボットとクライアントの分類

ブラウザ、モバイル、ボット、ユーザーエージェントの分類をACL内で使用できます。モバイルユーザーをモバイルバックエンドに送る、ボットとフラグされたトラフィックに低いレート制限を適用する、既知の検索エンジンへの例外を許可する、非ブラウザクライアントに異なるセキュリティプロファイルを適用することはすべて定義できます。

レートとサイズ基準

ACLエンジンはトラフィック量とサイズシグナルを使用できます:リクエストサイズ、レスポンスサイズ、フロントエンド接続数、リクエストレート、セッションレート、レスポンス時間、バックエンドのライブサーバー数、HTTPステータスコード。ライブバックエンド数が1に減った時に新しいトラフィックをフォールバックプールに移す、またはレスポンス時間が上昇した時に特定のエンドポイントをキャッシュするなどはすべてこれらの基準で表現できます。

カスタムマップとリストの使用

マップとリストベースのマッチングがサポートされています。大規模なIPリスト、ドメインリスト、URLリスト、顧客IDリスト、カスタムキーバリューテーブルに使用されます。VIP顧客リストに基づく異なるルーティング、ブロックリスト上のIPのブロック、パートナードメインリストに基づくCORSポリシーの適用はすべてこのパターンで管理されます。

ブラックリストIPカテゴリマッチング

IPレピュテーションまたはブラックリストカテゴリを条件に含めることができます。ボットネット、プロキシ、Tor、マルウェア、スパムカテゴリを異なる動作に結びつけることができます。オープンプロキシカテゴリのIPにCAPTCHAを提供する、TorのExitノードをモニターモードに配置する、マルウェアカテゴリのIPを直接拒否するといった使用例があります。

組み込みACL

TR7はすぐに使える一般的なACLをいくつか提供します:静的ファイル拡張子か、認証クッキーが存在するか、キャッシュヒットか、WAAPでブロックされたか。これらの組み込みACLにより、最もよく必要とされる条件をオペレーターが書き直す手間を省き、ルールセットをよりコンパクトに保ちます。

マニュアル条件 — エキスパートモード

標準UI基準が不十分なエッジケースでは、エキスパートユーザーがマニュアル条件を記述できます。これにより、TR7のビジュアルルールエンジンを保持しながら抜け道となる柔軟性が提供されます。このモードは日常使用向けではなく、高度な運用とカスタム統合を目的としています。

ユーザーベースのレート制限条件

ユーザーベースのリクエストレート、接続レート、エラーレート値をACL内で使用できます。JWTクレーム、クッキー、ヘッダー、ユーザーIDと組み合わせることで、テナントレベルまたはユーザーレベルのレート制限ポリシーを構築できます。

キャッシュ状態と認証状態の条件

リクエストまたはレスポンスがキャッシュヒットかどうかに基づいて異なる動作をトリガーできます。認証クッキーの存在またはHTTP認証値もACLエンジンで使用できます。これによりAAMとADCの動作が同じルールロジックの下に統合されます。

運用の深み

スマートACL条件はルール構文だけでなく、条件グループ構造、マッチタイプ、更新モデル、ボディサンプリング制限もカバーします。

01

条件グループ構造

スマートACL条件はグループで定義されます。グループ内の条件はANDまたはORで組み合わされます。条件を反転させてNOT動作にできます。外部グループはより広い論理構造を形成します。このアプローチにより複雑なポリシーを小さく読みやすいピースに分解できます。

02

ACL IDと再利用

すべてのACLはユニークなIDで識別されます。ルールはこのIDを参照します。同じACLを異なるトラフィックルール、レート制限ポリシー、リダイレクトルール、セキュリティアクションで再利用できます。ACLが変更されると、更新はバインドされたすべてのルールに自動的に伝播されます。

03

マッチタイプ

テキストベースの条件にはさまざまなマッチタイプがサポートされています:プレフィックスマッチ、サフィックスマッチ、部分文字列マッチ、正規表現マッチ、大文字/小文字区別あり/なしのマッチング。この柔軟性はシンプルと複雑の両方のルール構造をカバーします。

04

スマートファンクションチェーニング

スマートファンクションは個別に使用することも、チェーニングすることもできます。例えば:JWTペイロードを解析し、ロールフィールドを抽出し、小文字に変換し、特定のリストと比較します。これにより生のトラフィックデータが意味のある決定入力に変換されます。

05

ボディサンプリング制限

リクエストとレスポンスのボディ検査はサンプリングされたコンテンツサイズで動作します。これによりパフォーマンスとコンテンツ認識のバランスが取れたモデルが提供されます。非常に大きなボディに対しては、専用のボディ変更またはマスキング機能が別途使用されます。

06

L7とL3の更新モデル

スマートACL条件は異なるレイヤーで使用できます。L7側のルールは設定変更時にソフトリロードが必要な場合があります。L3ファイアウォール側のルールは独自のファイアウォール同期サイクルを通じて適用されます。すべての変更が同じメカニズムで適用されるわけではなく、レイヤーごとの更新モデルが適用されます。

07

組み込み静的ファイル拡張子ACL

静的コンテンツ検出のための一般的な拡張子がすぐに使える形で提供されています:.css、.js、.jpg、.png、.svg、.woff、.pdf、.mp4、.webp、.docx、.xlsxおよび類似のファイルタイプ。これはキャッシュ、ログ削減、レート制限除外シナリオで頻繁に使用されます。

08

Luaコンバーターの柔軟性

一部のスマートファンクションは組み込みトラフィックエンジンと直接連携し、一部の専門的な関数は追加のコンバーターレイヤーを通じて実行されます。これによりJSON、XML、JWT、カスタム文字列操作により広い表現面が提供されます。

利用シナリオ

JWTクレームによるAPIレート制限

APIレイヤーでは、管理者ユーザーは高い制限を受け、一般ユーザーは低い制限を受けます。スマートACLはJWTペイロードからロールフィールドを読み取り、それに応じてレート制限ポリシーを選択します。JWTPAYLOAD(role) == admin → 高いレート制限;それ以外 → 標準レート制限。

WAAPスコアに基づくCAPTCHA

リクエストがWAAPによって疑わしいとフラグされたが、完全にブロックするほど明確ではない。スマートACLはWAAPスコアとボットクラスを合わせて評価します。wafScore >= 5 AND NOT knownBotの場合、CAPTCHAが提示されます。

モバイル対デスクトップのバックエンド分離

モバイルユーザーは一つのバックエンドに、デスクトップユーザーは別のバックエンドにルーティングされます。スマートACLはユーザーエージェントとモバイル分類シグナルを使用します。mobile == true → モバイルバックエンド;mobile == false → デスクトップバックエンド。

JA3フィンガープリントによるボット検出

既知の悪意あるクライアントフィンガープリントのカスタムマップがACLとして定義されます。受信TLSフィンガープリントがこのリストにマッチすると、トラフィックはブロックされるかCAPTCHAに送られます。ja3 in bad_fingerprint_list → deny / captcha。

JSONボディ内の金額に基づく追加制御

金融APIでは、振込金額がJSONボディの内部から読み取られます。金額が定義された閾値を超えると、AAM側で追加のMFAがトリガーされるか、トランザクションが別のバックエンドにルーティングされます。JSONQUERY(transaction.amount) > 10000 → ステップアップMFA。

国、ASN、WAAPシグナルの組み合わせ

特定の国からのトラフィックは通常許可されていますが、同じトラフィックがホスティングASNから来て、WAAPスコアが高い場合、追加のチャレンジが適用されます。country in allowedCountries AND asn in hostingProviders AND wafScore >= 4 → challenge。

よくある質問

スマートACLでは何種類の基準を使用できますか?
TR7スマートACLエンジンは60以上の基準タイプをサポートします。ソースIPとCIDRに加え、国、都市、ASN、HTTPメソッド、URL、パス、クエリパラメータ、ヘッダー、クッキー、リクエストボディ、レスポンスボディ、TLS SNI、TLS暗号、JA3フィンガープリント、WAAPスコア、WAAP攻撃グループ、ボットクラス、ブラックリストカテゴリ、キャッシュ状態、認証状態をすべて基準として使用できます。
AND/OR/NOT条件グループはどのように設定しますか?
各ACLはIDで識別されます。ルールはconditionsリストとop(and/or)フィールドを使用するconditionGroups配列の下にグループ化されます。条件はnegateフラグによってNOT動作を得ることができます。内部グループはANDまたはORで動作し、外部グループはより複雑な論理構造を形成します。このアプローチにより、小さく読みやすいピースに分解されたポリシーが可能になります。
スマートファンクションチェーニングは何をしますか?
スマートファンクションは生のトラフィック値をアクション可能な入力に変換します。単一のACL条件内で、Base64デコード、JSONパスクエリ、JWTペイロードパース、XMLクエリ、正規表現マッチ、文字列置換、小文字/大文字変換、IPマスク、IP→国変換、マップ/リストルックアップ操作をすべてチェーニングできます。例えば、JWTペイロードを解析し、ロールフィールドを抽出してリストと比較できます。
同じACLを複数のルールで再利用できますか?
はい。一度定義されたACLはIDで参照され、異なるトラフィックルール、レート制限ポリシー、リダイレクトルール、セキュリティアクションで再利用できます。ACL定義が変更されると、そのIDにバインドされたすべてのルールに更新が自動的に伝播されます。このモデルにより集中管理と運用の一貫性が確保されます。
ACLの更新はライブトラフィックにどのような影響を与えますか?
スマートACL条件はレイヤーによって異なる更新モデルで適用されます。L7側のルールは設定変更時にソフトリロードが必要な場合があります。L3ファイアウォール側のルールは独自の同期サイクルで適用されます。レイヤーごとの更新モデルが適用され、これは正直に提示されます。
WAAPスコアとボットシグナルはACL内でどのように使用されますか?
スマートACLエンジンはWAAP決定を直接条件として読み取れます:waf_attack_id、waf_attack_group、wafScore、isWafBlocked、isWafAttack基準がすべて利用可能です。ボット分類には、browser、mobile、bot基準が利用できます。これらのシグナルはルーティング、レート制限、またはCAPTCHAアクションと組み合わせることができます;WAAPとADCの決定が同じルールエンジンに収束します。

トラフィック決定をIPアドレスを超えたものへ

一つのルールエンジンでセキュリティ、ルーティング、レート制限 — 60以上の基準、スマートファンクションチェーン、AND/OR/NOTグループ。お客様自身の環境でのライブセットアップをご案内します。