Comment optimiser les requêtes NGL avec le filtrage des ressources ?

Lorsque les contrôles conditionnels définis dans les expressions should-have et should-not-have d'une requête NGL sont évalués, les contrôles sont évalués par rapport à toutes les ressources correspondant au type de ressource primaire spécifié. Pour optimiser la requête et améliorer les performances en se concentrant sur les ressources les plus pertinentes, vous pouvez utiliser l'expression where.

L'expression where vous permet de filtrer les ressources avant d'appliquer les contrôles conditionnels définis dans les expressions should-have et should-not-have. En limitant l'évaluation aux ressources les plus pertinentes, vous pouvez réduire les calculs inutiles et accélérer les performances de votre LGN.

Syntaxe
```
<app suite> <resource type> should-have/should-not-have <condition> where <scoped condition>
```
Exemple de cas d'utilisation

Créez une requête NGL pour rechercher dans le SSPM tous les utilisateurs Azure AD dont la capacité d'authentification multifactorielle (MFA) est activée, où les utilisateurs sont actifs et ne sont pas des invités.

Solution
1. Identifier les composants de la syntaxe
  - App suite = AzureAD
  - Type de ressource primaire = Utilisateur. Consultez les fichiers DOM pour en savoir plus.
  - Expression = aurait dû
  - Condition = vérifier si le compte est compatible avec l'AMF dans les détails de l'enregistrement de l'utilisateur
2. Créez une requête de base conformément à la syntaxe.
```
AzureAD User should-have userRegistrationDetails with-attribute {isMfaCapable = true}
```
3. Pour limiter l'exécution de la requête aux seuls utilisateurs actifs et non invités, mettez à jour la requête avec l'expression where. Selon le fichier DOM d'AzureAD, les attributs accountEnabled et userType déterminent si l'utilisateur est actif ou invité, respectivement.
```
AzureAD User should-have userRegistrationDetails with-attribute {isMfaCapable = true}
where accountEnabled = true and userType != "Guest"
```
  L'expression where de cette requête NGL sélectionne d'abord uniquement les utilisateurs pertinents en appliquant la condition spécifiée. Cela signifie que seuls les utilisateurs actifs et non invités sont pris en compte dans le processus d'évaluation. Ensuite, l'expression should-have est évaluée sur ce sous-ensemble réduit d'utilisateurs pertinents afin de vérifier si l'authentification multifactorielle (MFA) est activée pour chaque utilisateur.

Considérations techniques

Pour utiliser correctement l'expression where, il faut en comprendre les détails. Vous trouverez ci-dessous quelques points importants à comprendre.

Two-Step Execution Process – L’expression where définit les conditions de la règle NGL, qui suit un processus en deux étapes :
- Filtrage des ressources : Les ressources sont filtrées en fonction des conditions de portée définies dans l'expression where.
- Évaluation : Après le filtrage des ressources, l'évaluation est effectuée à l'aide des conditions spécifiées dans l'expression "à avoir" ou "à ne pas avoir".
Impact of should-have/should-not-have Expressions
- Ces expressions ne s'appliquent qu'à la condition spécifique qui les suit directement.
- Elles n'affectent pas la condition délimitée définie dans l'expression where.
Secondary Resource Usage – Lorsqu'il s'agit d'une ressource secondaire soumise à des conditions de portée, il convient de l'utiliser avec la mention "devrait".

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"
```
Dans cette règle :
- L'objectif premier est de générer des résultats pour les utilisateurs non invités disposant de comptes activés.
- Une condition de délimitation est appliquée à la ressource secondaire (groupe), connectée à la ressource primaire (utilisateur) par l'intermédiaire de GroupMember.
- Toutefois, le lien entre un utilisateur et un groupe (par exemple, ABC_INACTIVE_USERS) doit être explicitement mentionné dans l'expression "il faut" pour plus de clarté.
Unmatched where expression in NGL – Si une règle NGL utilise une expression where qui ne correspond à aucune ressource, l'exécution de la règle ne produira aucun résultat.

Limites

Filtering Primary Resources Based on Secondary Resource Conditions: L'expression where ne prend pas directement en charge le filtrage des ressources primaires uniquement sur la base de conditions appliquées aux ressources secondaires.

Example: Il n'est pas possible de générer des résultats d'évaluation pour les utilisateurs d'AzureAD qui appartiennent à un groupe spécifique, tel que le groupe XYZ. Les conditions de délimitation de la portée des ressources secondaires ont pour seul but de restreindre le champ de la recherche et d'améliorer les performances de l'évaluation en excluant les ressources secondaires non pertinentes. Toutefois, cela n'a pas d'incidence sur l'évaluation des ressources primaires ; toutes les ressources primaires sont toujours évaluées. Pour limiter l'évaluation des ressources primaires, les conditions de délimitation du champ d'application doivent être appliquées directement au type de ressource primaire.

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" }
}

Dans ce cas, bien que le champ d'application soit limité au groupe XYZ, la règle évalue toujours tous les utilisateurs d'AzureAD. Toute ressource utilisateur qui n'est pas connectée au groupe XYZ ou qui n'a pas d'AMF enregistrée générera un échec de recherche.

Comment optimiser les requêtes NGL avec le filtrage des ressources ?

Syntaxe

Exemple de cas d'utilisation

Solution

Considérations techniques

Limites

Références