モダンなAPIの判断はJSONボディの内部で行われます — URLではなく。
従来のトラフィックルールは通常、ホスト、パス、メソッド、ヘッダーに基づいて判断します。しかしモダンなAPIトラフィックでは、実際の判断値は通常JSONボディ内に存在します。ユーザーのロール、テナントアイデンティティ、トランザクションタイプ、金額、商品コード、GraphQLオペレーション名はURLに現れない場合があります。
これはオペレーターに2つの悪い選択肢を残します。追加のルーティングとセキュリティロジックをアプリケーションコードにプッシュするか、ADCがヘッダーとパスレベルで盲目のままになるかです。どちらのアプローチもモダンなAPIセキュリティには不十分です。
JWTを使用するサービスでは、同じ問題がトークンの内部に存在します。Authorizationヘッダー値のみが表面に見え、判断に必要なロール、グループ、テナント、スコープはJWTペイロードに保存されています。これらのフィールドが読み取れない場合、トラフィックポリシーはアイデンティティコンテキストを使用できません。
正しいモデルはJSONボディとJWTコンテンツを式言語のネイティブな一部にすることです。JSONPathクエリはトラフィック条件、セキュリティルール、ログエンリッチメント、データマスキングアクションと同じ場所で使用できる必要があります。
TR7 JSON Pathオペレーションはこのモデルを提供します。JSONQUERY、JWTHEADER、JWTPAYLOADがAPIコンテンツをADCとWAAP判断に結びつけます。
アプローチ
TR7はFX式エンジンを通じてJSONコンテンツを読み取り、トラフィックルール、セキュリティコントロール、ログエンリッチメント、レスポンス編集へと運びます。
JSONQUERYがボディから直接フィールドを読み取る
JSONQUERYはJSONPath式を使用してリクエストまたはレスポンスボディの特定フィールドをターゲットにします。これらのフィールドはトラフィック条件、ACL入力、またはログ値として使用できます。
JWTHEADERとJWTPAYLOADがトークンコンテンツを可視化
JWT内のヘッダーとペイロードフィールドは同じJSONPathセマンティクスで読み取ることができます。ロール、スコープ、テナント、またはユーザーアイデンティティをトラフィック判断に取り込めます。
JSONフィールドがルール条件になる
ボディ内の値はパスやヘッダーのチェックと同様に自然な条件になります。他の式と同様に`$.tenant_id`、`$.user.role`、`$.operationName`に基づいてアクションを選択できます。
JSONレスポンスフィールドをマスクまたは置換できる
センシティブなJSONフィールドはレスポンス側でマスクまたは置換できます。データ漏洩防止はログだけでなく、クライアントに返されるボディに直接適用されます。
機能
JSON PathオペレーションはJSONボディとJWTコンテンツをTR7のルール、セキュリティ、ログ、マスキングレイヤーに接続します。
JSONQUERYがJSONPathでネストされたフィールドをターゲットにする
JSONQUERYはボディ内のネストされたJSONフィールドを直接クエリします。`$.user.role`、`$.items[0].sku`、`$.payment.amount`などの式をルール条件として評価できます。オペレーターはURLやヘッダーに現れない判断データに対してアクションを取れます。これによりAPIトラフィックを実際のコンテキストで管理することが可能になります。
JSONフィールドがACL条件に直接結びつく
TR7はJSONから読み取ったフィールドをトラフィックルールの条件として使用できます。例えば、`tenant_id`値に基づいて異なるバックエンドプールへトラフィックをルーティングできます。`role`値が許容できない場合はリクエストを拒否できます。アプリケーションコードを変更せずにボディ認識のトラフィックポリシーを確立できます。
JWTペイロードコンテンツがアクセス判断にシグナルを提供
JWTPAYLOAD関数はトークン内のクレームフィールドを読み取ることができます。ユーザーロール、グループ、スコープ、テナント、またはアプリケーションアイデンティティをこの方法でトラフィック判断に取り込めます。これによりAuthorizationヘッダーが生のトークンとしてのみ扱われることを防ぎます。TR7はトークンコンテンツをポリシーシグナルに変換します。
JWTヘッダークエリがアルゴリズムとトークンメタデータチェックを提供
JWTHEADER関数はトークンヘッダーフィールドを読み取ることができます。アルゴリズム、キーID、トークンタイプのメタデータチェックが実行できます。この情報はセキュリティルール、ログエントリ、条件付きアクセスシナリオで使用できます。トークンは単なる通過値ではなく、監査可能なオブジェクトになります。
ヘッダーに含まれるJSON値を解析できる
一部のアプリケーションはカスタムヘッダーフィールドにJSONライクなデータ構造を含めます。TR7はこれらのフィールドも式エンジン内の解析可能なシグナルとして扱えます。ボディだけでなく、ヘッダー内の構造化データもルール評価の一部になります。この柔軟性はレガシー統合シナリオで重要です。
JSONフィールド値によるバックエンド選択が可能
APIゲートウェイシナリオでは、ボディ内の`operation`、`tenant`、`region`、`product`などの値がルーティングシグナルになります。TR7はこれらのフィールドに基づいて異なるバックエンドプールへトラフィックを転送できます。これにより単一エンドポイントの下でマルチアプリケーションまたはマルチテナントの分離が可能になります。ルーティングロジックをアプリケーションコードに埋め込む必要がありません。
JSONフィールドがログエントリを充実させることができる
JSONボディまたはJWTから選択したフィールドをログラインに追加できます。ユーザーメール、テナントアイデンティティ、トランザクションタイプ、リスクスコアをログの専用フィールドとして表示できます。これによりSIEM相関が強化されます。完全なボディをログ記録する代わりに必要なフィールドのみを抽出することでデータ最小化もサポートします。
レスポンスJSON内のセンシティブフィールドをマスクできる
TR7はマスクまたは置換アクションを使用してJSONレスポンスボディ内のセンシティブな値を保護できます。カード番号、国民IDコード、患者ID、メールアドレス、その他のフィールドはregexまたはパスでターゲットにできます。これによりアプリケーションチームからのコード変更なしにデータ漏洩リスクを軽減します。センシティブデータマスキング機能と層状に連携します。
WAAP positive securityルールがJSONキーを制約できる
JSONボディ内の許可されたまたは必須のフィールドをセキュリティポリシーに結びつけることができます。不明なフィールド、欠落した必須パラメーター、過度にネストされた構造をブロックできます。これによりAPIスキーマのドリフトとインジェクションサーフェスを削減します。JSONコンテンツインスペクションはnegative securityシグネチャを超えます。
JSON深度とキーカウント制限がパーサーの安全性を向上
深くネストされたまたは過剰なキーを含むJSONペイロードはアプリケーションとパーサーリソースを枯渇させる可能性があります。TR7はJSONネスト深度とキーカウントなどの制限をセキュリティポリシーとして適用できます。これによりAPIのDoS試行と予期しないボディ構造の影響を軽減します。制限はエンドポイントの感度ごとに調整できます。
不正なJSONリクエストをバックエンドに到達する前に拒否できる
JSONが解析できない場合、リクエストは信頼できるAPIボディとして扱われません。TR7は不正なJSONのリクエストをバックエンドに転送する前に拒否またはログ記録できます。これによりアプリケーション層での予期しない解析エラーを削減します。また攻撃トラフィックと誤動作クライアントを区別するための可視性を提供します。
JSONクエリが他のFX関数と組み合わされる
JSONQUERYの結果は文字列、regex、マップ、リスト、IP、ハッシュ関数と一緒に使用できます。例えば、JSONからテナント値を抽出し、マップテーブルで検索し、その結果がルーティングまたはブロック判断を駆動します。これによりJSONクエリは単独のヘルパーではなく、ポリシーエンジンの一部になります。複雑なAPI判断をビジュアルルールエディターで表現できます。
運用の深み
JSONオペレーションはボディバッファリング、解析エラー処理、JWTフィールドの動作、ログ最小化、レスポンス編集、パフォーマンス制限と合わせて運用されます。
ボディアクセスのタイミング
JSONクエリが実行される前にボディが読み取り可能である必要があります。ボディ認識ルールはヘッダーのみのルールより多くの処理を必要とします。本当に必要なエンドポイントのみに適用する必要があります。
解析エラーの動作
JSONが解析できない場合、ポリシーは拒否、ログエントリ、または別のアクションを生成できます。JSONを期待するAPIエンドポイントでは、不正なペイロードをバックエンドに転送すべきではありません。この動作によりエンドポイントのセキュリティが向上します。
JWT信頼の前提
JWTコンテンツを読み取ることとトークンを検証することは同じ操作ではありません。JWTクレーム値をトラフィック判断に使用する場合、署名検証と信頼ソースポリシーを独立して設定する必要があります。そうしないと攻撃者が偽のクレームを作成できます。
ログ最小化
完全なJSONボディをログ記録する代わりに必要なフィールドのみを抽出する方がセキュリティ上より望ましいアプローチです。テナント、オペレーション、ステータスなどのフィールドはログ記録でき、センシティブなフィールドはマスクする必要があります。これによりSIEMの可視性とデータ保護のバランスを取ります。
レスポンス編集の制限
レスポンスJSONマスキングはボディに対して動作するため、レスポンスサイズとコンテンツタイプが重要です。非常に大きなレスポンスではパフォーマンスとメモリへの影響を計画する必要があります。センシティブデータ保護を効果的に適用するには正確なエンドポイントとフィールドのターゲティングが必要です。
パフォーマンスへの影響
JSON解析とパスクエリはヘッダーチェックよりコストがかかります。同一リクエスト内で複数のJSONクエリを使用する場合、結果の再利用が重要です。ルールは不要な繰り返し解析が発生しないよう設計する必要があります。
利用シナリオ
テナントID値によるバックエンドルーティング
SaaS APIは単一エンドポイントで複数のテナントからトラフィックを受け取る場合があります。TR7は`$.tenant_id`フィールドを読み取り、各テナントの正しいバックエンドプールへトラフィックを転送できます。
JWTロールクレームに対するアクセス制御の適用
Authorizationトークン内のロールまたはスコープ値を読み取ることができます。必要なクレーム値を持つトークンを持つユーザーのみに管理パスへのアクセスを制限できます。
レスポンスJSON内のセンシティブフィールドのマスク
APIレスポンスで返されるカード番号、国民IDコード、またはユーザーデータをマスクできます。TR7はアプリケーションコードの変更なしにアウトバウンドレスポンス内のセンシティブフィールドの露出を削減します。
不正なJSONをバックエンドに到達する前に拒否
JSONを期待するエンドポイントが不正なボディを受け取った場合、TR7はリクエストを早期に拒否できます。これによりアプリケーションの解析エラーを削減し、攻撃サーフェスを縮小します。
オペレーションとテナントデータでログラインを充実させる
完全なボディをログ記録する代わりに、`operationName`、`tenant`、`userId`などのフィールドのみを抽出します。SIEM相関が向上し、データ最小化が維持されます。
よくある質問
JSONQUERYはどのJSONPath構文をサポートしていますか？
JWTコンテンツを読み取る際に署名検証は自動的に行われますか？
同一リクエストで複数のJSONフィールドを読み取る場合、パフォーマンスはどうなりますか？
JSONマスキングはレスポンス側のみに適用されますか？
不正なJSONボディを受け取った場合、TR7はどうしますか？
この機能はセンシティブデータマスキングとどのように関連しますか？
APIボディコンテンツをトラフィックとセキュリティ判断の一部にする
JSONQUERY、JWTHEADER、JWTPAYLOADはJSONボディフィールドとJWTクレームをルール条件、ログエントリ、マスキングアクションに変換します。お客様自身のサービスでライブセットアップをご案内します。