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

  • Rversion finale: Yokohama
  • Mis à jour 30 janv. 2025
  • 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 de ces demandes, en mappant les champs de la demande aux noms de champs 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 Chiffrement Edge serveur proxy pour mapper les champs d’une 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 ne prennent en charge que 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 module d’extension Chiffrement Edge . Ces règles gèrent de nombreux cas d’utilisation de la plateforme principale, tels que :

    • Modifier un champ à partir du formulaire de modification de liste
    • Mettre à jour un enregistrement à partir du formulaire d’enregistrement
    • Gestion du service Web direct
    • Traitement des données à partir de l’interface de programmation d’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 champs de table Glide. Par exemple :

    • Processeurs de script
    • 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 dont les configurations de chiffrement sont définies.
    • Ordre : priorité de la règle. La règle de priorité la plus basse avec une condition satisfaite est la seule règle qui s’exécute. 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èces jointes, 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 de la règle 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 des 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 de 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 briser les règles dans la mesure du possible. Idéalement, les règles personnalisées devraient 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. Séparez 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’enregistrements que vous ciblez, ou au moins pour chaque sous-ensemble de créateurs d’enregistrements. 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, ou même 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. Minimisez 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 de validation. Par exemple :
      • Remplacez tous les blocs if par une recherche de tableau, et remplacez tous les blocs de la recherche de tableau par un seul bloc if .
      • 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 du contenu du corps plusieurs fois peuvent entraîner des résultats inattendus. Pour annuler 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 globale 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.