このページは Cloud Translation API によって翻訳されました。

検出ルールのカスタマイズ

Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントをご確認ください。情報

Apigee Sense の検出ルールを表示またはカスタマイズして、不要な可能性のあるリクエストのみをキャッチできます。Apigee Sense の検出ルールは、望ましくないクライアントリクエストを表すパターンを定義します。

検出ルールの結果の表示の詳細については、Apigee Sense コンソールスタートガイドをご覧ください。

調整の例

たとえば、検出レポートで、一部の不要なリクエストが Brute Guessor パターンに準拠していることに気付いたとします。このパターンでは、24 時間の間に多くのレスポンスエラーが報告されます。しかし、このパターンが、API プロキシ経由で許可したいリクエストをキャッチしていることにも気付きました。

Brute Guessor パターン（次の表）をカスタマイズすることで、必要なリクエストを許可し、必要のないリクエストをキャッチするように調整できます。Brute Guessor パターンは、次の表に示す条件と値を定義します。一連のリクエストが 24 時間でこれらの条件を満たしている場合、Apigee Sense はそれらのリクエストがブルートゲッサーパターンに準拠していると報告します。

条件	値
IP からの呼び出しの最小数	100
エラーのしきい値の最小パーセント	90

シナリオによっては、24 時間以内に 90% を超えるエラーが許容される設計になっている場合もあります。この場合、ルールの保護設定により、正規の送信元がブロックされることがあります。この機能を使用すると、条件値を変更できます。上記の例では、最初に条件の値を次のように変更します。

条件	値
IP からの呼び出しの最小数	100
エラーのしきい値の最小パーセント	95

カスタマイズの具体的な変更は、有効なクライアントによる API の使用状況に関するリクエストデータの内容によって異なります。しかし、このプロセスは反復的であり、有用なルール定義が見つかるまで少しずつ変更を加えることになる場合があります。

検出の反復的な調整

調整が必要な検出ルールでは、段階的かつ反復的なアプローチを取るのが最善策である場合もあります。Apigee Sense の検出と分析サイクルの仕組みにより、各反復処理に 1 日程度かかる場合があります。このサイクルでは、Apigee Sense はクライアントリクエストに関するメタデータを保存し、そのデータをバッチで分析して、結果を Apigee Sense コンソールに表示します。

たとえば、次のようなプロセスを使用できます。

Apigee Sense コンソールの検出レポートを使用して、調整を使用できる検出ルール（実際に有用なリクエスト過多を検出しているルールなど）を特定します。
不要なリクエストの割合が高くなるように、ルールの条件のうち、調整が必要な条件を特定します。
Apigee Sense コンソールでルールを編集して、特定した条件値を少しずつ段階的に変更します。
1 時間後、検出レポートを使用して、変更によって期待どおりの効果があったかどうかを評価します。
有益な結果が得られるまで、必要に応じてテストを繰り返します。

ガイドラインとベストプラクティス

検出ルールをカスタマイズする場合は、次の点に注意してください。

ルールの条件は論理 AND 関係で結合されます。つまり、3 つの条件がある場合、リクエストがルールのパターンに一致するには、3 つの条件がすべて満たされる必要があります。
最小しきい値を定義するルール条件もあれば、最大しきい値を定義するルール条件もあります。
ルールを調整して、不要なトラフィックを特定するのに十分な数のリクエストを捕捉し、有用なトラフィックを捕捉できるほど多くは捕捉しないようにバランスを取ります。ベストプラクティスとして、捕捉するリクエストの数を減らし、有用なトラフィックが取得されないようにすることをおすすめします。
条件の値を少し変更しても、目立った違いは生じない場合があります。変更の大きさは、各自で判断してください。

パターン、条件、期間について詳しくは、不審なアクティビティへの対処をご覧ください。