Définir une règle de chiffrement personnalisée
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 ?
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 :
- Modification d’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 de l’interface de programmation (API) de l’application 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 à des noms table-champ Glide. Par exemple :
- Processeurs avec script
- Services Web basés sur un script
- API REST, interfaces utilisateur ou scripts Ajax basés sur un script
Format d’une règle de chiffrement
- Condition : identifie le type de demande.
- Action : mappe les champs de la demande aux champs d’une table, en chiffrant les valeurs qui sont mappées aux champs avec des configurations de chiffrement 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 vont du plus bas au plus haut.
À 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 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 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 censé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.
Instructions 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.
Règle générale : Lorsque les règles deviennent longues, faites de votre mieux pour minimiser le nombre de blocages et séparez-les 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.
- Divisez les règles dans la mesure du possible. Par exemple :
- Créez différentes règles pour différentes tables et assurez-vous que chaque règle ne s’exécute que 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 des sous-ensembles plus petits de créateurs d’enregistrements, ou même créer une règle parsys_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.
- 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 dans la validation. Par exemple :
- Remplacez tous les blocs if par une recherche de tableau, et remplacez tous les blocs
dela recherche de tableau par un seul blocif. - Combinez
les blocs ifchaque fois qu’il est possible de les regrouper.
- Remplacez tous les blocs if par une recherche de tableau, et remplacez tous les blocs
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 qu’elle est écrite dans le flux de sortie. L’analyse de flux permet aux règles de chiffrement d’être performantes sur le réseau. Cependant, la récupération 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 une seule passe.
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 requête 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 du proxy pour obtenir des informations de dépannage.