Configuration d’une règle ACL

Configurez une règle ACL personnalisée pour sécuriser l’accès à de nouveaux objets ou pour modifier le comportement de sécurité par défaut.

Avant de commencer

Rôle requis : security_admin

Pourquoi et quand exécuter cette tâche

Pour créer des règles ACL, vous devez élever les privilèges au rôle security_admin.

Pour les tables qui sont dans un champ d’application différent de l’enregistrement de règle ACL, les types de règles sont limités. Pour que les tables principales du champ d’application dérivent le champ d’application et exécutent des ACL incluses dans le champ d’application, définissez la glide.enforce_security_scope.<scope_name> propriété sur true. Cela garantit que les ACL du champ d’application global ne correspondent pas lorsque des ACL spécifiques au champ d’application sont créées dans la table pertinente. Par exemple, lors de la sécurisation des données dans des tables d’applications partagées dans le périmètre global, telles que les tables sys_attachment ou question_answer.

Procédure

1. Rôles de privilège élevés au rôle security_admin.
2. Accédez à la Sécurité de système > Contrôle d'accès (ACL).
3. Conseil :

   Lors de la création d’une ACL, il est utile d’examiner le Refuser à moins qu’ACLfichier .
   Cliquez sur Nouveau.
4. Renseignez le formulaire.

   Tableau 1. Champs de contrôle d’accès

   Champ	Description
   Type	Sélectionnez le type d’objet sécurisé par cette règle ACL. Le type d’objet détermine la façon dont l’objet est nommé et les opérations disponibles. Ce champ passe en lecture seule une fois la règle ACL créée. Si vous souhaitez modifier le type, vous devez supprimer l’ACL et en créer une nouvelle avec le type approprié.
   Opération	Sélectionnez l’opération sécurisée par cette règle ACL. Chaque type d’objet possède sa propre liste d’opérations. Une règle ACL ne peut sécuriser qu’une seule opération. Pour sécuriser plusieurs opérations, créez une règle ACL distincte pour chacune d’elles.
   Remplacement administrateur	Cochez cette case pour que les utilisateurs dotés du rôle administrateur passent automatiquement la vérification des autorisations pour cette règle ACL. Les utilisateurs administrateurs transmettent, quelles que soient les restrictions de script ou de rôle qui s’appliquent. Toutefois, le rôle personne , que seul ServiceNow le personnel peut affecter, a priorité sur l’option de remplacement administrateur. Si le rôle personne est affecté à une ACL, les utilisateurs administrateurs ne peuvent pas accéder à la ressource, même lorsque l’option Remplacements administrateur est sélectionnée. Reportez-vous à la section Rôles système de base. Décochez cette case si les administrateurs doivent satisfaire aux autorisations définies dans cette règle ACL pour accéder à l’objet sécurisé. Étant donné que les administrateurs réussissent toujours les vérifications de rôle (voir la description du champ Requiert un rôle ), utilisez le créateur de conditions ou le champ Script pour créer une vérification des autorisations que les administrateurs doivent passer.
   Actif	Cochez cette case pour appliquer cette règle ACL.
   Avancés	Cochez cette case pour afficher le champ de script . Important : S’il y a un script dans le champ Script . Ce script s’exécute même si le champ n’est pas affiché sur le formulaire.
   Nom	Saisissez le nom de l’objet sécurisé, soit le nom de l’enregistrement, soit les noms de table et de champ. Plus le nom est spécifique, plus la règle ACL est spécifique. Vous pouvez utiliser le caractère générique astérisque (*) à la place d’un nom d’enregistrement, de table ou de champ pour sélectionner tous les objets qui correspondent à un type d’enregistrement, toutes les tables ou tous les champs. Vous ne pouvez pas combiner un caractère générique et une recherche de texte. Par exemple, inc* n’est pas un nom de règle ACL valide, mais incident.* et *.number sont des noms de règles ACL valides. Remarque : Cliquez sur le triangle bleu pour entrer manuellement le nom de l’enregistrement ou les noms de table et de champ de l’objet sécurisé. Utilisez cette option pour sécuriser un objet qui n’apparaît pas dans la liste déroulante.
   Description	Entrez une description de l’objet ou des autorisations que cette règle ACL sécurise.
   Demande un rôle	Utilisez cette liste pour spécifier les rôles qu’un utilisateur doit avoir pour accéder à l’objet. Si vous répertoriez plusieurs rôles, un utilisateur disposant de l’un des rôles répertoriés peut accéder à l’objet. La liste Requiert un rôle apparaît sous la forme d’une liste connexe. Remarque : Les utilisateurs disposant du rôle administrateur réussissent toujours cette vérification d’autorisation, car le rôle administrateur accorde automatiquement aux utilisateurs tous les autres rôles.
   Condition	Utilisez ce créateur de conditions pour sélectionner les champs et les valeurs qui doivent être vrais pour que les utilisateurs puissent accéder à l’objet.
   Script	Saisissez un script personnalisé décrivant les autorisations requises pour accéder à l’objet. Le script peut utiliser les valeurs des variables globalesactuelles et précédentes dans les règles métier ainsi que dans les propriétés système. Le script doit générer une réponse vrai ou faux de l’une des deux façons suivantes : Renvoyer un jeu de variables de réponse sur une valeur vrai ou faux Évaluer à vrai ou faux Dans les deux cas, les utilisateurs n’ont accès à l’objet que lorsque le script est défini sur vrai et que l’utilisateur remplit toutes les conditions de la règle ACL. Les conditions et le script doivent être définis sur vrai pour qu’un utilisateur puisse accéder à l’objet. Remarque : Si l’élément évalué se trouve dans une liste connexe, current pointe vers l’élément sur lequel se trouve la liste associée, et non vers l’élément actuel auquel l’ACL est destinée. Toutefois, si l’élément dont vous évaluez l’ACL ne se trouve pas dans une liste connexe, actuel pointe vers l’élément réel.

5. Cliquez avec le bouton droit sur l'en-tête du formulaire, puis sélectionnez Enregistrer.