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

  • Rversion finale: Washingtondc
  • Mis à jour 1 févr. 2024
  • 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 vers 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 table-champ 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 sur 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 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
    • Mise à jour d’un enregistrement à partir du formulaire d’enregistrement
    • Gestion du service Web direct
    • Traitement des données de l’interface de programme 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 table-champ Glide. Par exemple :

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

    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, chiffrant les valeurs qui sont mappées 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. À l’instar des règles métier, les règles vont 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ègles 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 true, 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 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 pour la validation des scripts.

    Règle générale : Lorsque les règles deviennent longues, faites de votre mieux pour minimiser le nombre de blocs et séparez 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 ifs ou switch dans le script d’action.

    1. Divisez 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’enregistrements. Au lieu d’une règle ciblant des dizaines de sys_ids, vous pouvez créer plusieurs règles différentes ciblant des sous-ensembles plus petits 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. La contrepartie 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 contenues dans le corps d’une demande. L’API utilise des expressions similaires à xPath pour parcourir le contenu JSON et XML.

    Chiffrement Edge Les API traitent la demande au fur et à mesure qu’elle est écrite dans le flux de sortie. L’analyse des flux permet aux règles de chiffrement d’être performantes sur le réseau. Toutefois, l’extraction et l’analyse du contenu à partir 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 script includes, 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 listes 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 du proxy pour obtenir des informations de dépannage.