Masquage dans l'interface utilisateur

Identifier les données à masquer

Identifiez les données qui sont stockées sous forme de texte ordinaire mais doivent être masquées lors de l'affichage. Par exemple, supposons qu'il s'agisse des numéros de carte de crédit et des numéros d'identification fédéraux des acteurs (par exemple, aux Etats-Unis, des numéros de sécurité sociale). Chacun de ces champs peut être affiché et tenu à jour dans différentes interfaces du système, mais les règles de masquage d'un champ donné sont probablement les mêmes quel que soit l'endroit où les données sont affichées.

Les clés primaires ne peuvent pas être masquées. Un champ défini en tant qu'identifiant unique d'une ligne ne peut pas être configuré pour le masquage. Le masquage d'un champ de la clé primaire génère un problème lors de la tentative de mise à jour de l'enregistrement. Cette restriction s'applique également aux éléments faisant partie d'une "liste" dans une colonne XML d'un objet de maintenance. Un ou plusieurs éléments de la liste doivent être définis en tant qu'identifiant primaire de la liste. Veillez à ce que les éléments de clé primaire de la liste ne soient pas ceux qui nécessitent un masquage.

Répertoriez les membres contenant des "types" différents. Prenons l'exemple d'une page comportant la liste des numéros d'identification d'un acteur. Vous pouvez configurer le système de façon que les règles de masquage ne soient pas les mêmes pour le numéro de sécurité sociale et pour le numéro de permis de conduire. Si votre implémentation présente ce type d'exigence, la liste des champs masqués doit contenir une entrée pour chaque règle de masquage.

Pour chaque champ, si certains utilisateurs doivent pouvoir voir les données non masquées dans une ou plusieurs interfaces utilisateur, la configuration de la sécurité est requise. Si la valeur d'un champ doit être masquée pour tous les utilisateurs dans toutes les pages de l'application, la configuration de la sécurité n'est pas nécessaire.

Configuration de la sécurité

Définissez un type de sécurité pour chaque champ avec deux niveaux d'autorisation :

• 1 - Peut uniquement voir l'élément masqué

• 2 - Peut uniquement voir l'élément non masqué

Liez tous les types de sécurité à un service applicatif de votre choix. Nous vous recommandons de lier chaque type de sécurité relatif au masquage à un seul service applicatif (par ex., CM_​MASK) car cela facilite la génération des droits d'accès.

Pour chaque type de sécurité, identifiez les utilisateurs qui peuvent voir ses données non masquées et ceux qui peuvent voir uniquement ses données masquées. Si les utilisateurs masqués et non masqués tiennent dans des groupes d'utilisateurs existants, aucun groupe d'utilisateurs supplémentaire n'est requis. Sinon, créez de nouveaux groupes d'utilisateurs pour les utilisateurs masqués et non masqués.

Une fois les groupes d'utilisateurs définis pour chaque type de sécurité, liez chaque groupe au service applicatif défini ci-dessus. Lorsqu'un groupe d'utilisateurs est lié au service applicatif, vous définissez le niveau d'autorisation de chaque type de sécurité lié au service applicatif. Si les utilisateurs d'un groupe doivent voir les valeurs de champs du type de sécurité non masquées, définissez le niveau d'autorisation sur 2. Autrement, définissez-le sur 1.

Configurer un algorithme de masquage

Un algorithme de masquage des données (utilisant la valeur d'entité d'algorithme Configuration Mutualisation paramètres - Masquage données) doit être créé pour chaque combinaison de règles de masquage et de type de sécurité. Ces algorithmes déterminent si un utilisateur dispose des droits appropriés pour voir un champ spécifique non masqué, et, le cas échéant, précisent la façon dont ce champ doit être masqué.

L'installation standard fournit deux types d'algorithme. Les deux prennent en charge la configuration pour permettre à un ensemble d'utilisateurs de voir les données démasquées. Les paramètres capturent le service applicatif, le type de sécurité et le niveau d'autorisation définis ci-dessus pour l'évaluer.

• F1-MASK : permet de masquer les données alphanumériques. Ses paramètres sont conçus pour gérer la plupart des besoins de masquage. Les paramètres vous permettent de configurer la quantité de données à masquer et le caractère de masquage à utiliser. Pour plus d'informations, reportez-vous à la description du type d'algorithme.
• F1-MASKNBR : permet de masquer les nombres. Pour plus d'informations, reportez-vous à la description du type d'algorithme.

Déterminer le mode d'affichage des champs

La configuration du masquage diffère selon la façon dont un champ est extrait pour accès dans l'interface utilisateur. Par conséquent, il se peut que, pour masquer un champ "logique" (le numéro de sécurité sociale d'un acteur par exemple), plusieurs entrées de configuration soient requises afin de couvrir toutes les méthodes d'accès. Examinez chaque interface utilisateur dans laquelle un champ donné est affiché et créez les catégories suivantes :

• Le champ est un élément extrait par l'appel d'un objet métier, d'un service fonctionnel ou d'un script de service.

• Le champ est stocké en tant que caractéristique ad hoc.

• Le champ est affiché dans une page de maintenance fixe (et est donc extrait par l'appel d'un service de page).

• Le champ est affiché dans une page de recherche fixe (et est donc extrait par l'appel d'un service de recherche).

Créer une configuration Mutualisation de paramètres pour chaque élément masqué

Créez une configuration de mutualisation de paramètres de type Masquage des données. Une entrée d'option ayant le type Masquage de champ est nécessaire pour chaque combinaison champ à masquer/méthode d'affichage des données. Sa valeur contient les mnémoniques faisant référence à l'algorithme de masquage approprié ainsi que la configuration qui diffère selon la façon dont le champ est extrait pour affichage, comme indiqué ci-dessous.

Masquer un champ d'objet basé sur un schéma

Pour les données accessibles via un appel d'objet basé sur un schéma et affichées dans une matrice IU, le champ à masquer doit référencer le nom d'un champ de métadonnées dans sa définition de schéma : field="fld_​name", alg="nom de l'algorithme"

Si l'élément référence un champ mdField dans le schéma, il s'agit du champ utilisé pour identifier la règle de masquage. En 'absence d'une référence à un mdField et en présence d'une référence à un champ mapField, c'est ce champ qui est utilisé pour identifier la règle de masquage. Par exemple, si vous voulez masquer un numéro de carte crédit, supposons que le champ est défini dans le schéma comme suit :

<creditCard mdField="CCNBR" mapField="EXT_ACCT_ID"/>

Dans ce cas, la valeur de l'option doit être field="CCNBR", alg="nom de l'algorithme". La valeur d'option field="EXT_​ACCT_​ID", alg="nom de l'algorithme" n'aboutirait pas à un masquage.

Vous pouvez également spécifier une clause "where". Cela est utile pour les données qui résident dans une liste dans laquelle seules les données d'un certain type doivent être masquées : field="fld_​name", alg="nom de l'algorithme", where="fld_​name='valeur'"

Par exemple, un acteur peut avoir un ensemble d'ID et souhaiter que seuls les ID de type "SSN" (numéro de sécurité sociale) soient masqués. Si les données d'acteur, dont notamment son ensemble d'ID d'acteur, sont affichées dans une matrice IU via un appel d'objet métier, supposons que l'ensemble soit défini comme suit :

<personIDs type="list" mapChild=CI_PER_ID">
  <isPrimaryId mapField="PRIM_SW"/>
  <idType mapField="ID_TYPE_CD"/>
  <personIdNumber mapField="PER_ID_NBR"/>
</personIds>

La valeur d'option peut avoir l'aspect suivant : field="PER_​ID_​NBR", alg="nom de l'algorithme", where="ID_​TYPE_​CD='SSN'"

Notez les points importants suivants relatifs au masquage basé sur un schéma :

• Limitation du champ "where". Bien que la principale fonction d'une clause "where" pour des éléments orientés schéma soit de masquer certains des éléments d'une liste en fonction d'un "type", il est également possible de masquer un champ unique du schéma en fonction de la valeur d'un autre champ. Par exemple, supposons qu'un client soumette un formulaire d'inscription qui définit un type d'ID et une valeur d'ID. Bien que ces données ne figurent pas dans une liste, l'implémentation peut permettre de masquer la valeur d'ID si le type d'ID est "SSN". Le framework est uniquement en mesure de masquer un élément du schéma en fonction d'une clause "where" si l'élément de cette clause "where" est un élément apparenté du schéma.

  • Si l'élément à masquer figure dans une liste, l'élément de la clause "where" doit se trouver dans la même liste.

  • Si un élément à masquer est mappé sur une colonne réelle d'une table, l'élément de la clause "where" doit également être mappé sur une colonne réelle de la table.

  • Si un élément à masquer est mappé avec une colonne XML de la table en tant qu'élément isolé, l'élément de la clause "where" doit être mappé avec la même colonne XML en tant qu'élément isolé.

• Plusieurs entrées d'option mutualisation de paramètres pour un même champ. Différents schémas du système peuvent avoir un type de données similaire pouvant être masqué en fonction de différentes conditions. Par exemple, supposons qu'une implémentation possède différents schémas ayant capturé ou référencé des identifiants d'acteur de différentes manières :

  • Un schéma capture un ID d'acteur unique sans enregistrement de "type" correspondant et doit toujours être masqué à l'aide de l'algorithme CM_​SSN_​MASK :

    <personSSN mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>

  • Un schéma capture un ID d'acteur et un type d'ID correspondant et doit toujours être masqué avec l'algorithme CM_​SSN_​MASK si le type est "SSN", et être masqué avec l'algorithme CM_​FEIN_​MASK si le type est "FEIN".

    <personIdType mapXML=BO_DATA_AREA mdField=ID_TYPE_CD/>
    <personId mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>

  • Un schéma capture un ID d'acteur et un type d'ID correspondant et possède les mêmes règles de masquage que le schéma précédent, mais un nom de champ différent est utilisé pour le code de type d'ID. (Ce scénario peut se produire si, par exemple, une autre étiquette est souhaitée pour le type d'ID dans l'interface utilisateur de ce schéma.)

    <personIdType mapXML=BO_DATA_AREA mdField=CM_ID_TYPE/>
    <personId mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>

  Pour ce scénario, les options mutualisation de paramètres peuvent avoir l'aspect suivant :

  1. field="PER_​ID_​NBR", alg="CM_​SSN_​MASK"

  2. field="PER_​ID_​NBR", alg="CM_​SSN_​MASK", where="ID_​TYPE_​CD='SSN'"

  3. field="PER_​ID_​NBR", alg="CM_​FEIN_​MASK", where="ID_​TYPE_​CD='FEIN'"

  4. field="PER_​ID_​NBR", alg="CM_​SSN_​MASK", where="CM_​ID_​TYPE='SSN'"

  5. field="PER_​ID_​NBR", alg="CM_​FEIN_​MASK", where="CM_​ID_​TYPE='FEIN'"

  Pour chaque schéma, le système recherche si l'élément s'applique à une option de masquage. Il trouve 5 options de masquage pour le champ PER_​ID_​NBR. Il détermine ensuite si des éléments apparentés correspondent à la clause "where".

  • Si plusieurs éléments apparentés correspondent à une clause "where", une erreur d'exécution est renvoyée. Par exemple, si un schéma a un élément qui référence "mdField=ID_​TYPE_​CD" et un élément qui référence "mdField=CM_​ID_​TYPE", il s'agit d'une erreur. De plus, si plusieurs éléments référencent "mdField=CM_​ID_​TYPE", il s'agit d'une erreur.

  • Si un et seulement un élément apparenté correspond à une clause "where", la valeur de l'élément est comparée aux valeurs définies dans la clause "where". Si une concordance est trouvée sur la valeur, l'algorithme de masquage approprié est appliqué. Si aucune correspondance n'est trouvée (par exemple, le type d'ID d'acteur est "LICENSE") l'élément est affiché tel quel.

  • Si aucun élément apparenté ne correspond à une clause "where" et qu'il existe une option de mutualisation de paramètres sans clause "where" (option 1 ci-dessus), l'algorithme de masquage de l'option sans clause "where" est appliqué.

• Modifier la valeur de la clause "where". Si des utilisateurs de votre implémentation sont autorisés à modifier les enregistrements dans lesquels certaines données sont masquées en fonction d'une condition, il est recommandé de concevoir l'interface utilisateur pour réinitialiser la valeur masquée lorsque la valeur de la clause "where" change. Par exemple, si un utilisateur est empêché de visualiser le numéro de sécurité sociale d'un acteur, mais qu'il est autorisé à mettre à jour l'enregistrement de l'acteur, le fait de modifier la valeur du type d'ID d'acteur devrait réinitialiser le numéro d'ID de l'acteur. Ceci assure que l'utilisateur ne "démasque" pas le numéro de sécurité sociale en modifiant simplement le type d'ID.

Enregistrements tenus à jour à l'aide de la maintenance de page

Pour les données accessibles via un appel de service de maintenance de page, indiquez le nom de la table et le nom du champ dans lesquels les données résident : table="table_​name", field="fld_​name", alg="nom de l'algorithme"

Par exemple, si l'enregistrement d'acteur et son ensemble d'identifiants sont affichés et tenus à jour à l'aide de la maintenance de page, la valeur de l'option doit être table="CI_​PER_​ID", field="PER_​ID_​NBR", alg="nom de l'algorithme"

Une clause "where" peut également être spécifiée : table="table_​name", field="fld_​name", where="fld_​name='value'", alg="nom de l'algorithme"

Cela est utile pour les données qui résident dans une table enfant dans laquelle seules les données d'un certain type doivent être masquées. Pour l'exemple d'ID d'acteur, table="CI_​PER_​ID", field="PER_​ID_​NBR", alg="nom de l'algorithme", where="ID_​TYPE_​CD='SSN'"

Données de caractéristique

Pour les données stockées en tant que caractéristique, indiquez simplement le type de caractéristique : CHAR_​TYPE_​CD='char type', alg="nom de l'algorithme"

Celui-ci doit être défini une seule fois, quelle que soit l'entité de caractéristique dans laquelle le type de caractéristique peut résider. Notez que seules les caractéristiques ad hoc sont prises en charge.

Masquer les champs dans les zones de l'explorateur ou les chaînes d'informations

Dans les zones de l'explorateur, les données sont souvent extraites par une utilisation directe de SQL à partir de la base de données. Aucun masquage n'est appliqué automatiquement dans ce cas. Si des données doivent être masquées dans les résultats apparaissant dans les zones de l'explorateur, vous devez appliquer le masquage en appelant un service fonctionnel.

De même, un algorithme d'informations sur l'objet de maintenance ne peut pas passer par l'interaction d'un objet métier pour obtenir des données. Pour une meilleure efficacité, il peut accéder aux données à l'aide de SQL. Aucun masquage n'est appliqué lors de l'extraction de données via SQL. Pour appliquer un masquage à une chaîne avant son inclusion dans une chaîne d'informations, vous devez appliquer un service fonctionnel.

Le système offre deux services fonctionnels à appeler pour déterminer si les règles de masquage sont applicables à un champ spécifique.

• F1-TableFieldMask. Masquer un champ de table. Ce service fonctionnel reçoit un nom de table, un nom de champ et une ou plusieurs valeurs de champ. Si le masquage est applicable, il renvoie la valeur masquée.

• F1-SchemaFieldMask. Masquer un champ de schéma. Ce service fonctionnel reçoit un nom, un type de schéma et un XPath de schéma et une valeur de champ. Si le masquage est applicable, il renvoie la valeur masquée.

Résultats du service de recherche

Les données affichées dans une page de recherche fixe sont extraites par l'appel d'un service de recherche. Indiquez le nom de la recherche et le champ à masquer, ainsi que l'algorithme de masquage. Par exemple : search="NomDuServiceDeRecherche", field="PER_​ID_​NBR", where="ID_​TYPE_​CD='SSN'", alg="nom de l'algorithme"

Pour trouver le nom du service de recherche, lancez la recherche en question, cliquez avec le bouton droit dans la zone de filtre et sélectionnez Inspecter. Recherchez "serviceName". pour afficher le nom du service. Pour rechercher le nom du champ à masquer, recherchez "Widget Info". Deux résultats doivent être trouvés : un pour la zone de filtre et un pour la zone de résultats. Cette zone de résultats affiche le texte "SEARCH_​RESULTS" comme préfixe pour chaque champ. Les noms de champ sont situés après x$. Ne faites pas référence à x$ lors de la définition du nom du champ. Notez que l'instruction "where" est uniquement applicable aux champs qui font également partie des résultats de la recherche.

Informations supplémentaires sur le masquage

Les points suivants fournissent des informations supplémentaires sur la configuration du masquage :

• Si la base de données de démonstration contient une configuration de mutualisation des paramètres Masquage des données, vérifiez les paramètres, car elle contient probablement des règles de masquage correspondant aux vôtres.

• Dans les pages de saisie de données, un utilisateur peut être en mesure d'entrer ou de modifier des données masquées, comme par exemple un numéro de compte bancaire, mais ne pas pouvoir voir ensuite ce qu'il a ajouté ou changé.

• Les systèmes tiers peuvent demander des informations en effectuant un appel de service via un service Web. Gardez à l'esprit que certaines requêtes de service Web exigent le masquage des données, tandis que d'autres non. Ainsi, une requête provenant d'un système tiers pour synchroniser les informations d'un acteur nécessite que le numéro de sécurité sociale de l'acteur ne soit pas masqué, tandis qu'une requête d'une application en libre-service sur le Web permettant d'extraire les informations du même acteur à des fins d'affichage requiert que le numéro de sécurité sociale de l'acteur soit masqué. Pour implémenter ce type d'exigence, différents utilisateurs doivent être associés à chaque requête et ces utilisateurs doivent appartenir à des groupes distincts possédant des droits d'accès différents.

• Si un objet de maintenance contient un champ comportant un document XML et qu'un appel de service invoque directement le programme de service de l'objet de maintenance, le système masque les éléments XML individuels dans le champ si un algorithme Déterminer l'objet métier a été rattaché à l'objet de maintenance et que les éléments du schéma d'objet métier concerné ont été sécurisés comme décrit ci-dessus.