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

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

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

Apigee Sense の検出ルールを表示またはカスタマイズして、望ましくないリクエストのみを確実にキャッチするようにすることができます。Apigee Sense の検出ルールは、望ましくないクライアントリクエストを表すパターンを定義します。

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

チューニングの例

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

ブルートゲッサーパターン（次の表）をカスタマイズすると、必要なリクエストを許可し、そうでないリクエストを検出できるように調整できます。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 つの条件がすべて満たされる必要があります。
ルール条件には、最小しきい値を定義するものと、最大しきい値を定義するものがあります。
ルールを調整して、不要なトラフィックを特定するのに十分なリクエストを検出するか、有用なトラフィックを検出するほど多く検出しないようにするかのバランスを取ります。ベストプラクティスとして、有効なトラフィックのキャプチャを避けるために、取得するリクエストの数を減らすことをおすすめします。
条件の値を少し変更しても、目立った違いは生じない場合があります。どれだけ変更するかは、自分自身で判断してください。

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