Types de ressources

Un type de ressource est le type de configuration ou de ressource dans l'application SaaS. Le type de ressource possède des propriétés qui peuvent être utilisées dans la condition NGL ou vous pouvez vous référer aux types de ressources liés dans la condition. Par exemple, dans Okta app suite, "Account", "ApplicationUsers", "ApplicationUser", etc. sont les types de ressources. Les types de ressources sont spécifiques à l'App Suite. Pour consulter la liste des types de ressources qui peuvent être utilisés dans votre LGN, jetez un coup d'œil aux fichiers DOM de votre App Suite. Le type de ressource est associé à des métadonnées de propriétés, telles que l'attribut, le type, la référence et la description de l'attribut du type de ressource. Par exemple, le type de ressource ApplicationUser possède les propriétés lastUpdated, appId, scope, etc.

Type de ressource primaire

Le type de ressource mentionné immédiatement après la suite logicielle est appelé type de ressource primaire. Lorsque votre LGN s'exécute en tant que règle dans votre politique, tous les résultats seront associés au type de ressource primaire. Par exemple, 

microsoft365 remotedomain should-have autoforwardenabled = false

Ici, remotedomain est un type de ressource primaire.

Type de ressource secondaire

Les types de ressources secondaires sont des types de ressources liés auxquels il est fait référence dans les règles ; ils font partie de la section "conditions" de la règle. Par exemple, 

Okta ApplicationUser should-have Application with-attribute { lastUpdated > 30 } 

That is, ApplicationUser resource type of the Okta app suite should have Application resource, where Application resource type should have LastUpdated property with > 30 result. While Application is a secondary resource type.

Namespace Resource Type

Les types de ressources de l'espace de noms sont créés pour organiser les types de ressources sous un type unique. Ceux-ci n'ont pas de métadonnées. Par exemple, ApplicationUsers de la suite d'applications Okta est un type de ressource de l'espace de noms sans métadonnées.

Par exemple, ApplicationUsers, Application, Roles, etc. dans Okta sont des types de ressources de l'espace de noms. Ces ressources permettent d'éviter les conflits d'espace de noms, car plusieurs services ont tendance à utiliser des noms similaires pour leurs ressources de différentes manières.

Prenons un exemple, dans cette requête NGL, on s'assure qu'il y a au moins une politique anti-phishing configurée dans Microsoft 365 :

microsoft365 defenderforoffice365 should-have antiphishpolicy exists

Le type de ressource defenderforoffice365 est un nœud d'espace de noms qui est lié à un nœud de type de ressource antiphishpolicy avec des propriétés. La règle n'est évaluée comme vraie que lorsqu'il existe au moins un nœud pour antiphishpolicy lié au defenderforoffice365.

Utilisation de plusieurs types de ressources

Les conditions dans NGL peuvent utiliser plusieurs types de ressources liées pour exprimer des conditions complexes. Les types de ressources liés les uns aux autres peuvent être utilisés dans NGL pour valider une configuration. Cela permet d'évaluer le degré de sécurité des différents types de ressources fonctionnant à l'unisson. Consultez la liste des DOM pour obtenir plus d'informations sur les types de ressources. Vous trouverez ci-dessous quelques exemples d'utilisation de plusieurs types de ressources dans votre LGN :

• Lorsque tous les liens doivent répondre à une condition. Par exemple,

  azuread conditionalaccess should-have conditionalaccesspolicy with-attribute { state = "enabled" }

  Cette requête NGL sera évaluée à true pour la ressource ConditionalAccess si toutes les ConditionalAccessPolicy liées ont un attribut state = "enabled".

  

  – To view the ConditionalAccess resource, access the Microsoft Entra ID DOM, then expand IdentityAndSignIn > ConditionalAccess.
  – To view the ConditionalAccessPolicy resource, access the Microsoft Entra ID DOM, then expand IdentityAndSignIn > ConditionalAccess > ConditionalAccessPolicy

  La table de vérité pour les résultats des évaluations de la règle sera la suivante :

  	Cp2-state = enabled	État Cp2 = désactivé
  Cp1–state = enabled	Success	Fail
  État Cp1 = désactivé	Fail	Fail

• Lorsque l'une des ressources liées correspond à une condition. Par exemple,

  azuread conditionalaccess should-have any conditionalaccesspolicy as c with-attribute { c.state = "enabled" }

  Cette requête NGL sera évaluée à true pour la ressource ConditionalAccess lorsque l'une des ConditionalAccessPolicy liées satisfait à la condition.

  

  – To view the ConditionalAccess resource, access the Microsoft Entra ID DOM, then expand IdentityAndSignIn > ConditionalAccess.
  – To view the ConditionalAccessPolicy resource, access the same Microsoft Entra ID DOM, then expand IdentityAndSignIn > ConditionalAccess > ConditionalAccessPolicy.

  La table de vérité pour les résultats des évaluations de la règle sera la suivante :

  	Cp2-state = enabled	État Cp2 = désactivé
  Cp1-state = enabled	Success	Success
  État Cp1 = désactivé	Success	Fail

• Les ressources peuvent être liées à l'aide d'une relation de référence. Par exemple, dans la suite d'applications Salesforce, DelegateGroup est lié à DelegateGroupMember, qui est également lié à User.

  

  – Pour afficher la ressource DelegateGroup , accédez au DOM Salesforce, puis développez Metadata > DelegateGroups > DelegateGroup.
  – Pour afficher la ressource DelegateGroupMember , accédez au DOM Salesforce, puis développez Tooling > DelegateGroupMembers > DelegateGroupMember.
  – Pour afficher la ressource User , accédez au DOM Salesforce, puis développez SObjects > Users > User.

Le lien entre DelegateGroup et DelegateGroupMember est assuré par l'attribut DelegateGroupId. Avec ces trois types de ressources en action, NGL pour trouver DelegateGroup si l'un des utilisateurs liés a un nom "demo user1" est écrit comme suit :

salesforce DelegateGroup should-have DelegateGroupMember with-attribute {any user as u with-attribute { u.Name = "demo user1" }}

La table de vérité pour les résultats des évaluations de la règle sera la suivante :

Comprendre les fichiers DOM

Les fichiers DOM sont un dictionnaire des types de ressources pris en charge par Netskope SSPM. Les types de ressources sont spécifiques à une App Suite et peuvent être de nature hiérarchique. Vous trouverez des informations détaillées sur la hiérarchie des types de ressources et sur la manière dont ils sont liés dans les fichiers DOM. Vous pouvez vous référer aux fichiers DOM lorsque vous écrivez des requêtes et des règles NGL.

List of DOM files

• Atlassian Confluence
• Atlassian Jira
• Box
• GitHub
• Google Workspace
• Microsoft 365
• Microsoft Azure AD
• Microsoft Copilot
• Okta
• Salesforce
• ServiceNow
• Slack Enterprise
• Jour ouvrable
• Zoom

Erreurs courantes

Cette section décrit les erreurs qui peuvent se produire en raison de types de propriétés incorrects. Reportez-vous aux fichiers DOM pour plus de détails sur les types de propriétés spécifiques à l'application.