Explorer l’outil de gouvernance de scripting

  • Rversion finale: Australia
  • Mis à jour 6 avr. 2026
  • 6 minutes de lecture

    • L’outil de gouvernance de scripting (SGT) fournit un contrôle unique et centralisé pour la gestion de l’accès aux scripts dans votre ServiceNow AI Platform.

    La version Zurich introduit une fonctionnalité qui donne aux administrateurs un contrôle centralisé sur qui peut modifier les champs de script sur le ServiceNow AI Platform. La fonctionnalité ajoute une nouvelle couche d’autorisation qui s’appuie sur le groupe d’auteurs de scripts conditionnels et son rôle enfant, snc_required_script_writer_permission. Les utilisateurs doivent être membres de ce groupe pour modifier un champ de script, quel que soit leur accès existant basé sur ACL. Cette couche d’autorisation est appliquée par le biais d’ACL de type de données et gérée par les travaux planifiés et les propriétés système.

    Pour gérer cette fonctionnalité, ServiceNow AI Platform fournit l’outil SGT (Scripting Governance Tool), un tableau de bord dans lequel les administrateurs peuvent voir quels utilisateurs ont accès aux scripts, analyser l’instance pour les utilisateurs qui ont modifié les champs de script et ajouter ou révoquer directement l’accès aux scripts des utilisateurs.

    Pourquoi c’est important

    Le scripting peut lire et écrire des données dans des tables, contourner la logique métier et modifier le comportement de la plateforme à un niveau fondamental, ce qui fait de l’accès au scripting l’une des autorisations les plus importantes à régir sur n’importe quelle instance.

    Avant Zurich, l’accès aux scripts était contrôlé uniquement par des ACL sur les champs de script individuels. Pour déterminer quels utilisateurs pouvaient modifier les scripts, les administrateurs devaient vérifier chaque ACL individuellement. Il n’y avait pas d’emplacement unique pour afficher ou gérer l’accès aux scripts dans l’instance.

    La fonctionnalité de gouvernance de scripting résout ce problème en ajoutant une deuxième couche obligatoire de contrôle d’accès en plus des autorisations basées sur ACL existantes. La satisfaction d’une ACL au niveau du champ ne suffit plus pour modifier un champ de script. Désormais, les administrateurs de sécurité peuvent gérer l’accès aux scripts de manière centralisée en ajoutant ou en supprimant des utilisateurs du groupe d’auteurs de scripts conditionnels .

    Modèle d’accès à deux couches

    La fonctionnalité de gouvernance de scripting applique un modèle d’accès à deux couches. Les deux couches doivent passer indépendamment avant qu’un utilisateur puisse modifier un champ de script. Passer une couche seule n’est pas suffisant.

    Couche 1 — ACL au niveau du champ existante
    L’utilisateur doit transmettre l’ACL existante dans le champ de scripting (prêt à l’emploi ou personnalisé). Ce contrôle est inchangé par rapport au comportement antérieur à Zurich.
    Couche 2 — Vérification du rôle SGT

    L’utilisateur doit également détenir le rôle de snc_required_script_writer_permission , qui est accordé par le biais de l’adhésion au groupe d’auteurs de scripts conditionnels .

    Important :

    Un utilisateur qui pouvait modifier des champs de script avant la mise à niveau de Zurich, parce que ses rôles satisfaisaient à l’ACL au niveau du champ, sera bloqué après la mise à niveau, à moins qu’il ne satisfasse également à la couche 2. Le rôle snc_required_script_writer_permission n’accorde pas à lui seul un nouvel accès à l’écriture de scripts. Il ne déverrouille l’accès que pour les utilisateurs qui ont déjà passé la couche 1.

    Le tableau suivant résume les résultats en matière d’accès dans le modèle à deux couches :

    Réussit l’ACL au niveau du champ (couche 1) ? Contient snc_required_script_writer_permission (couche 2) ? Peut modifier le champ de script ?
    Oui Oui ✅ Oui
    Oui Non ❌ Non
    Non Oui ❌ Non
    Non Non ❌ Non

    ACL des types de données

    La fonctionnalité de gouvernance de scripting introduit 9 ACL de type de données pour appliquer la couche 2. Il s’agit d’ACL refusées sauf si elles nécessitent le rôle snc_required_script_writer_permission pour les types de données suivants :

    Type de données
    • script
    • script_client
    • script_plain
    • script_server
    • email_script
    • html_script
    • html_template
    • XML (XML)
    • condition_string
    Remarque :
    Par défaut, le rôle admin n’a pas l’accès à l’écriture de scripts. Les utilisateurs administrateurs sont soumis à la même vérification à deux couches et ne peuvent pas modifier les champs de script, sauf s’ils sont membres du groupe d’auteurs de scripts conditionnels ou s’ils détiennent explicitement le rôle snc_required_script_writer_permission . Pour en savoir plus, reportez-vous à la section ACL de type de données.

    Travaux planifiés et propriétés

    Dans le cadre de la fonctionnalité de gouvernance de scripting, le groupe d’auteurs de scripts conditionnels est introduit, qui a pour snc_required_script_writer_permission rôle d’enfant. Une fois la mise à niveau Zurich terminée, une tâche planifiée ponctuelle s’exécute pour renseigner automatiquement tous les utilisateurs éligibles dans ce groupe, afin que personne ne perde l’accès aux scripts après la mise à niveau. Une fois cette tâche terminée, une tâche hebdomadaire récurrente est créée pour maintenir à jour l’appartenance au groupe. Les deux emplois et leurs critères d’admissibilité sont décrits comme suit :

    Ajouter des utilisateurs au groupe d’auteurs de scripts conditionnels
    Une tâche qui s’exécute une fois immédiatement après la fin de la mise à niveau de Zurich. Cela ajoute tous les utilisateurs qui répondent aux critères d’éligibilité au groupe d’auteurs de scripts conditionnels , garantissant qu’aucun utilisateur ne perd l’accès aux scripts après la mise à niveau. Une fois la tâche terminée, la plateforme la désactive.
    La tâche utilise la propriété glide.security.scripting_role.provisioning_job_running, qui est définie sur vrai pendant l’exécution de la tâche et sur faux une fois qu’elle est terminée. Une fois la tâche terminée, la propriété glide.security.scripting_role.auto_provisioning est créée et la définit sur vrai.
    Mettre à jour les utilisateurs du groupe d’auteurs de scripts conditionnels
    Une tâche hebdomadaire qui ajoute au groupe de nouveaux utilisateurs qui répondent aux critères d’éligibilité et supprime les utilisateurs qui ne répondent plus aux critères d’éligibilité. Il est contrôlé par la propriété glide.security.scripting_role.auto_provisioning :
    Tableau 1. Mettre à jour le comportement en fonction de la propriété
    Valeur Comportement
    vrai (par défaut) La tâche hebdomadaire s’exécute à la date prévue et ajoute automatiquement des utilisateurs éligibles au groupe.
    faux La tâche ne s’exécute pas. Les utilisateurs ne sont ajoutés au groupe que manuellement par un administrateur.
    Pour désactiver la mise en service automatique, définissez glide.security.scripting_role.auto_provisioning sur faux dans les propriétés système.
    Remarque :
    La propriété glide.security.scripting_role.auto_provisioning est créée lors de l’exécution et a une sys_id différente sur chaque instance. Référencez-le toujours par un nom de propriété.

    Critères d'éligibilité

    Les deux travaux planifiés utilisent les mêmes critères pour déterminer quels utilisateurs sont ajoutés au groupe d’auteurs de scripts conditionnels :

    Tableau 2. Critères d'éligibilité
    Module d’extension Explicit Role Type d'utilisateur Besoin Ajouté au groupe ?
    Activée Externe — Non
    Activée Interne Doit avoir snc_internal et au moins un rôle supplémentaire Oui
    Désactivé N’importe quel utilisateur Doit avoir au moins un rôle Oui
    Remarque :
    Le rôle snc_external et le rôle snc_required_script_writer_permission sont des rôles contradictoires. ServiceNow AI Platform n’accorde pas les deux rôles au même utilisateur. Les utilisateurs externes ne peuvent pas avoir accès à l’écriture de scripts.

    Outil de gouvernance de scripting

    L’outil de gouvernance de scripting est un tableau de bord qui aide les administrateurs à gérer l’accès aux scripts sur la plateforme ServiceNow. Il offre une visibilité sur les utilisateurs membres du groupe d’auteurs de scripts conditionnels , ce qui donne une image claire du nombre d’utilisateurs qui peuvent écrire des scripts sur votre instance.

    Vous pouvez également indiquer quels groupes contiennent le rôle de scripting et quels rôles l’incluent en tant que rôle enfant. Il existe deux façons de gérer l’accès aux scripts via l’outil :

    • Configuration manuelle : ajoutez ou supprimez manuellement des utilisateurs du groupe d’auteurs de scripts conditionnels pour contrôler qui a accès aux scripts.
    • Rechercher les utilisateurs qui ont scripté : analysez votre instance pour trouver les utilisateurs qui ont scripté dans un délai spécifique. L’analyse interroge les journaux d’audit et identifie tout utilisateur qui a effectué une écriture ou une mise à jour vers une table comportant un champ de script.

    Tableau de bord de l’outil de gouvernance des scripts

    Remarque :
    Il est recommandé de gérer l’accès au scripting exclusivement par l’intermédiaire du groupe d’auteurs de scripts conditionnels . L’ajout du rôle snc_required_script_writer_permission en tant que rôle enfant à d’autres rôles ou groupes réduit votre capacité à contrôler de manière centralisée qui peut écrire des scripts sur votre instance.