Journaux de débogage d’analyseur d’accès

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 3 minutes de lecture

    • Les journaux de débogage de l’analyseur d’accès fournissent des informations détaillées sur l’évaluation des contrôles d’accès pour une opération spécifique. Ces journaux aident les administrateurs et les développeurs à résoudre les problèmes d’accès, à optimiser les configurations de sécurité et à s’assurer que les utilisateurs disposent d’un accès approprié aux ressources de la plateforme ServiceNow.

    Champs dans les journaux de débogage

    Pour une opération donnée, les journaux de débogage affichent une vue granulaire de la façon dont les ACL, les règles métier et les autres attributs de sécurité sont évalués.

    Champs dans le journal des débogages

    Voici les champs et leur description dans les journaux de débogage :

    Tableau 1. Journaux des débogages
    Champs Description
    Nom Détails sur la règle métier ou l’ACL. Vous pouvez sélectionner la règle métier ou l’ACL pour plus d’informations.
    Concerne Indique le niveau auquel l’ACL est appliquée, par exemple, Champ, Enregistrement ou Table.
    Statut État de l’ACL pour le rôle et l’autorisation associés, par exemple, Réussi, Bloqué ou Ignoré.
    Rôles ACL requis Spécifie les rôles nécessaires pour accéder à la ressource.
    Rôle Fournit des détails sur l’état des rôles en termes de contrôle d’accès, par exemple, bloqué, réussi ou ignoré.
    Attribut de sécurité Détails de l’attribut de sécurité évalué comme Bloqué, Réussi ou Ignoré pour le contrôle d’accès.
    Condition Les détails de la condition évaluée comme bloquée, transmise ou ignorée pour le contrôle d’accès.
    Script Détails du script évalués comme bloqués, réussis ou ignorés pour le contrôle d’accès.
    Personnalisé Indique si des ACL personnalisées sont incluses dans le contrôle d’accès.
    Application État de l’application. global ou Store.

    Hiérarchie d’évaluation

    Les autorisations pour l’utilisateur, le groupe ou le rôle sélectionné sont évaluées dans la hiérarchie suivante :

    1. Règle métier : une règle métier est un script côté serveur qui s’exécute lorsqu’un enregistrement est lu, inséré, mis à jour ou supprimé, ou lorsqu’une table est interrogée.
    2. Gestionnaire d’accès : vérification interne du système à l’aide du code source masqué sur la plateforme.
    3. Filtration des données : un filtre de données est une forme de contrôle d’accès conçu pour fonctionner avec les règles de contrôle d’accès (ACL) existantes sur votre instance. Les filtres de données ne prennent en charge que les opérations de lecture.
    4. Liste de contrôle d’accès (ACL) : les règles des listes de contrôle d’accès (ACL) restreignent l’accès à des données spécifiques en exigeant que les utilisateurs satisfassent à un ensemble d’exigences avant de pouvoir interagir avec ces données. Dans une ACL, la hiérarchie suivante est évaluée :
      1. Rôle
      2. Attribut de sécurité
      3. Condition
      4. Script

    Évaluation de la liste de contrôle d’accès

    Les ACL pour les opérations sont évaluées dans l’ordre suivant :

    1. Rôle
    2. Attribut de sécurité
    3. Condition
    4. Script

    Présence d'un script

    L’icône d’alerte quel que soit l’état indique la présence d’un script dans l’ACL. Examinez les ACL en surbrillance pour comprendre l’accès final.

    Remarque :
    Lors d’une requête d’analyseur d’accès, les règles métier sont exécutées en premier, puis la liste de contrôle d’accès.

    Séquence d’exécution

    L’ordre d’exécution pour déterminer l’accès dans différents scénarios est le suivant :

    1. Présence d’une ACL héritée ou d’un caractère générique : au cours de la séquence d’exécution, les ACL héritées sont évaluées en premier, puis les ACL génériques.
    2. Si une ACL est transmise, les autres sont ignorées : lors de l’exécution et de l’évaluation des autorisations, si une ACL est transmise, l’exécution et les évaluations des autres ACL sont ignorées. Ils sont ignorés, car les autorisations globales pour l’opération sélectionnée ne nécessitent qu’une seule ACL pour accéder à un champ, un enregistrement ou une table pour une identité.
    3. Exécution des ACL au niveau du champ et au niveau de la table : pendant l’exécution, les ACL au niveau du champ sont exécutées en premier, suivies des ACL au niveau de la table. Cela fournit des résultats plus granulaires lors de l’analyse de l’accès pour une identité.
    4. Évaluation en présence d’une ACL scriptée : lorsqu’un script est présent, l’accès global à l’opération est transmis avec une icône d’alerte pour indiquer qu’il existe un script dans l’ACL.