リソースフィルタリングを使用してNGLクエリを最適化する方法は？- Netskope技術文書

NGLクエリのshould-have式とshould-not-have式で定義された条件チェックが評価されるとき、チェックは指定されたプライマリリソースタイプに一致するすべてのリソースに対して評価されます。クエリを最適化し、最も関連性の高いリソースに焦点を当てることでパフォーマンスを向上させるには、 where式を使用できます。

where式を使用すると、 should-have式とshould-not-have式で定義された条件チェックを適用する前にリソースをフィルタリングできます。評価対象を最も関連性の高いリソースのみに限定することで、不要な計算を削減し、NGLのパフォーマンスを向上させることができます。

構文
```
<app suite> <resource type> should-have/should-not-have <condition> where <scoped condition>
```
サンプル使うケース

SSPM で、マルチファクター認証 (MFA) 機能が有効になっているアクティブな非ゲストユーザーを含むすべての Azure AD ユーザーを検索する NGL クエリを作成します。

解決
1. 構文要素を特定する
  - アプリスイート = AzureAD
  - プライマリリソースタイプ = ユーザー。詳細については、 DOMファイルを確認してください。
  - 表現 = should-have
  - 条件 = ユーザー登録の詳細でアカウントがMFAに対応しているかどうかを確認します
2. 構文に従って基本クエリを作成します。
```
AzureAD User should-have userRegistrationDetails with-attribute {isMfaCapable = true}
```
3. クエリの実行対象をアクティブユーザーおよび非ゲストユーザーのみに制限するには、クエリにwhere式を追加して更新します。AzureAD DOMファイルによると、accountEnabled属性とuserType属性は、それぞれユーザーがアクティブかゲストかを判断するために使用されます。
```
AzureAD User should-have userRegistrationDetails with-attribute {isMfaCapable = true}
where accountEnabled = true and userType != "Guest"
```
  このNGLクエリのwhere式は、まず指定された条件を適用して、関連するユーザーのみを選択します。これは、アクティブな非ゲストユーザーのみが評価プロセスにおいてさらに検討されることを意味します。次に、 should-have式がこの関連ユーザーのより小さなサブセットに対して評価され、各ユーザーに対して多要素認証 (MFA) が有効になっているかどうかを確認します。

技術的考慮事項

where式を正しく理解するには、その詳細を理解する必要があります。以下に、理解しておくべき重要なポイントをいくつか示します。

Two-Step Execution Process – where式は NGL ルールの条件を規定するもので、以下の 2 段階のプロセスに従います。
- リソースのフィルタリング：リソースは、 where式で定義されたスコープ条件に基づいてフィルタリングされます。
- 評価：リソースフィルタリング後、評価が実行されます should-haveまたはshould-not-have式で指定された条件。
Impact of should-have/should-not-have Expressions
- これらの表現は、その直後に続く特定の条件にのみ適用されます。
- これらは、 where式で定義されたスコープ条件には影響を与えません。
Secondary Resource Usage – スコープ条件を持つ二次リソースが関係する場合、それは should-have と共にあるべきです。

Example:
```
AzureAD User should-have userRegistrationDetails with-attribute {  

    isMfaRegistered = true  }  

where groupmember with-attribute {  

    group with-attribute {  

        displayName = "ABC_INACTIVE_USERS"   }  }  

and accountEnabled = true and userType != "Guest"
```
このルールでは：
- 主な目的は、有効なアカウントを持つ非ゲストユーザーに関する調査結果を生成することです。
- スコープ条件は、GroupMemberを介してプライマリリソース（ユーザー）に接続されたセカンダリリソース（グループ）に適用されます。
- ただし、明確化のために、ユーザーとグループ（例：ABC_INACTIVE_USERS）間の関連性は、should-have式の中で明示的に記述する必要があります。
Unmatched where expression in NGL – NGLルールがいずれのリソースにも一致しないwhere式の場合、ルールの実行では何も検出されません。

制限事項

Filtering Primary Resources Based on Secondary Resource Conditions: where式は、二次リソースに適用された条件のみに基づいて一次リソースをフィルタリングすることを直接サポートしていません。

Example: 特定のグループ（例えばグループXYZ）に属するAzureADユーザーの評価結果を生成することはできません。二次資料に対するスコープ条件は、検索範囲を絞り込み、無関係な二次資料を除外することで評価性能を向上させることを唯一の目的としています。しかし、これは一次資料の評価には影響せず、すべての一次資料は引き続き評価されます。一次資料の評価を制限するためには、評価範囲の条件を一次資料の種類に直接適用する必要がある。

AzureAD User should-have any groupmember as g with-attribute {
  group exists
}
and userRegistrationDetails with-attribute { isMfaRegistered = true }
where groupmember with-attribute {
  group with-attribute { displayName = "XYZ" }
}

このケースでは、対象範囲がグループXYZに絞り込まれているにもかかわらず、ルールは依然としてすべてのAzureADユーザーを評価します。 XYZグループに接続されていない、またはMFAが登録されていないユーザーリソースは、すべて失敗として検出されます。

リソースフィルタリングを使用してNGLクエリを最適化する方法は？

構文

サンプル使うケース

解決

技術的考慮事項

制限事項

参考文献