Définir une règle de chiffrement personnalisée

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

    • Il peut être nécessaire d’identifier et de chiffrer les informations sensibles dans les requêtes HTTP sur le chemin de votre instance. Vous pouvez écrire des règles de chiffrement pour identifier, interpréter et chiffrer les données dans de telles demandes, en mappant les champs de la demande aux noms de champ de table sur votre instance.

    Qu’est-ce qu’une règle de chiffrement ?

    Les règles de chiffrement sont des scripts exécutés sur le serveur proxy pour mapper les champs d’une Chiffrement Edge demande aux champs d’une table de votre ServiceNow instance. Une règle de chiffrement indique au serveur proxy comment chiffrer les Chiffrement Edge données dans des charges utiles personnalisées.
    Remarque :
    Les règles de chiffrement prennent uniquement en charge ECMAScript 3 et les versions antérieures.

    Quand utiliser des règles personnalisées

    Un ensemble de règles de chiffrement est inclus dans le Chiffrement Edge module d’extension. Ces règles gèrent de nombreux cas d’utilisation de la plateforme principale, tels que :

    • Modification d’un champ à partir du formulaire de modification de liste
    • Mise à jour d’un enregistrement à partir du formulaire d’enregistrement
    • Gestion du service Web direct
    • Traitement des données à partir de l’interface de programmation de l’application (API) REST

    Les applications créées à l’aide de formulaires et de listes standard doivent fonctionner sans règles de chiffrement personnalisées.

    Si vous développez des scripts qui contiennent des données qui doivent être chiffrées, créez des règles de chiffrement pour trouver et mapper ces données aux noms de champ de table Glide. Par exemple :

    • Processeurs scriptés
    • Services Web basés sur un script
    • API REST, interfaces utilisateur ou scripts Ajax scriptés

    Format d’une règle de chiffrement

    Les règles comprennent trois parties :
    • Condition : identifie le type de demande.
    • Action : mappe les champs de la demande aux champs d’une table, en chiffrant les valeurs qui correspondent aux champs avec des configurations de chiffrement définies.
    • Ordre : priorité de la règle. La règle de priorité inférieure avec une condition satisfaite est la seule règle exécutée. Comme les règles métier, les règles s’exécutent de la plus basse à la plus élevée.

    À l’exception des demandes de pièce jointe, les demandes HTTP sont évaluées par le Chiffrement Edge serveur proxy. Le Chiffrement Edge serveur proxy évalue toutes les conditions de règle de chiffrement par ordre de priorité jusqu’à ce que toutes les conditions retournent la valeur faux, ou qu’une condition renvoie la valeur vrai. Lorsqu’une condition renvoie la valeur vrai, l’action est exécutée sur la demande et le résultat est transmis à l’instance. Aucune autre condition n’est évaluée. Par conséquent, les conditions des règles de chiffrement doivent être aussi spécifiques que possible. Une règle générique peut être évaluée comme vraie pour une demande destinée à être traitée par une autre règle, ce qui entraîne le traitement de la demande par une action incorrecte. Si une condition générique est inévitable, la règle doit être marquée d’une valeur d’ordre élevé afin que les règles plus spécifiques soient évaluées en premier.

    Directives pour la création de règles de chiffrement

    La création de règles de chiffrement efficaces et optimisées peut réduire le temps de traitement pour la validation des scripts.

    Ligne directrice générale : Lorsque les règles deviennent longues, faites de votre mieux pour minimiser le nombre de blocs et décomposer les règles dans la mesure du possible. Idéalement, les règles personnalisées doivent s’appliquer à des cas d’utilisation spécifiques, plutôt que d’englober plusieurs cas, avec des instructions if ou switch dans le script d’action.

    1. Fractionnez les règles dans la mesure du possible. Par exemple :
      • Créez des règles différentes pour différentes tables et assurez-vous que chaque règle s’exécute uniquement sur sa table respective.
      • Créez des règles différentes pour chaque créateur d’enregistrement que vous ciblez, ou au moins pour chaque sous-ensemble de créateurs d’enregistrement. Au lieu d’une règle ciblant des dizaines de sys_ids, vous pouvez créer plusieurs règles différentes ciblant de plus petits sous-ensembles de créateurs d’enregistrements, voire créer une règle par sys_id.
        Remarque :
        La création de plusieurs règles nécessite plus de maintenance. Le compromis est que plusieurs règles plus simples peuvent être validées plus efficacement que des règles plus longues et plus complexes.
    2. Réduisez le nombre de blocs. Étant donné que le moteur de traitement analyse chaque bloc lors de l’évaluation des scripts, un grand nombre de blocs entraîne des retards dans la validation. Par exemple :
      • Remplacez tous les blocs si par une recherche de tableau, et remplacez tous les blocs de la recherche de tableau par un seul bloc si .
      • Combinez les blocs if chaque fois qu’il est possible de les regrouper.

    API de règles de chiffrement

    Les règles de chiffrement sont écrites en JavaScript et utilisent Chiffrement Edge des API pour localiser et chiffrer les informations sensibles dans le corps d’une demande. L’API utilise des expressions similaires à xPath pour naviguer dans le contenu JSON et XML.

    Chiffrement Edge Les API traitent la demande hors du flux au fur et à mesure de son écriture dans le flux de sortie. L’analyse de flux permet aux règles de chiffrement d’être performantes sur le réseau. Cependant, l’extraction et l’analyse multiples du contenu du corps peuvent entraîner des résultats inattendus. Pour éviter ce problème potentiel, les demandes doivent être traitées par l’action en un seul passage.

    Lors de la création de règles de chiffrement, vous ne pouvez pas utiliser les API Glide, les includes de script, les règles métier ou tout autre paramètre global tel que actuel. Étant donné que les règles sont créées pour les objets HTTP, un objet de demande global est disponible.

    Lors de la création de règles de chiffrement, vous ne pouvez pas utiliser les API du gestionnaire de liste d’autorisation ou des applications incluses dans le périmètre.

    Gestion des erreurs

    Si une condition ou une action de règle de chiffrement lève une exception, consultez le journal de proxy pour obtenir des informations de dépannage.