28 septembre 2022 Glossaire informatique de Libelle, partie 17 : Qu'est-ce que l'automatisation des processus informatiques ?
Depuis le lancement de la marque Libelle DataMasking il y a maintenant sept ans, nous avons déjà réalisé de nombreux projets clients différents et intéressants. Chaque projet nous place devant de nouveaux défis passionnants. Mais nous ne serions pas là si nous ne relevions pas ces défis et ne les maîtrisions pas.
Dans cet article de blog, je présente le TOP 10 des erreurs commises lors de l'anonymisation.
L'une des caractéristiques clés de Libelle DataMasking est la préservation de la cohérence des données entre les différents systèmes et paysages, que les systèmes SAP seuls, les autres systèmes ou une combinaison des deux mondes soient pris en compte dans le processus d'anonymisation. Cette fonctionnalité s'effectue par la saisie de ce que l'on appelle la clé d'anonymisation.
Dans la plupart des projets, on attache une grande importance à la préservation de la cohérence entre les systèmes et les paysages, raison pour laquelle une clé d'anonymisation uniforme est définie très tôt dans le projet et s'applique désormais à tous les participants.
Le problème survient lorsque, malgré cette définition, une autre clé est soudainement utilisée ; il suffit alors qu'elle soit déjà utilisée par un seul des systèmes impliqués. Le flux de travail d'un test peut ainsi rapidement s'enrayer car il n'est plus possible de trouver des informations pertinentes sur un cas de test puisque les données anonymisées se dispersent désormais.
Dans les bases de données relationnelles, il existe généralement des dépendances entre les tables sur la base de l'intégrité référentielle. Cela permet de garantir la cohérence et l'intégrité des données. Ces dépendances doivent bien entendu être maintenues dans le cadre de l'anonymisation.
Libelle DataMasking permet de définir un ordre dans lequel les tables à traiter doivent être anonymisées. Le logiciel propose à cet effet jusqu'à dix niveaux différents.
Par exemple, les tables A et B contiennent des enregistrements associés.
Dans une première étape (ordre 0), les champs des deux tables sont anonymisés indépendamment l'un de l'autre. Une deuxième étape doit ensuite servir à rétablir la contiguïté des enregistrements. Cela se fait au moyen d'une instruction SQL SELECT, par laquelle les tables sont jointes l'une à l'autre. Le JOIN doit nécessairement être effectué dans un ordre différent (dans l'exemple, l'ordre 1). Dans le cas contraire, il y a un risque de violation de la cohérence. Dans le cas extrême, un deadlock pourrait même être généré pendant l'anonymisation, car dans certaines circonstances, deux états accèdent aux mêmes enregistrements et veulent les modifier.
L'étendue du produit Libelle DataMasking comprend ce que l'on appelle la base de données de référence. Elle contient des valeurs cibles possibles dans lesquelles l'anonymisation peut être effectuée. Outre la base de données de référence propre à Libelle, il est également possible d'utiliser comme base ses propres fichiers de référence spécifiques au client. Selon le concept du projet, les fichiers de référence peuvent être mis à disposition via un flux de travail séparé, mais aussi être générés automatiquement à l'aide du logiciel. Le risque d'erreur réside dans le fait que le fichier n'est pas enregistré en tant que fichier de référence ou qu'il n'est pas activé dans la configuration dans laquelle le fichier est requis. Une autre source d'erreur possible est que le fichier n'a pas été créé par le logiciel lors de la génération automatique en tant qu'activité dite d'anonymisation.
En standard, le logiciel Libelle DataMasking contient actuellement 40 algorithmes d'anonymisation. Certains algorithmes ne nécessitent pas de paramètres supplémentaires. C'est le cas, par exemple, de l'algorithme du prénom. D'autres, comme l'algorithme d'adresse, nécessitent des paramètres supplémentaires. Les paramètres servent à spécifier exactement comment un champ doit être anonymisé.
Dans nos projets, nous constatons régulièrement que les paramètres sont mal définis ou qu'ils sont indiqués alors que l'algorithme en question ne les prend pas en charge. De plus, certains algorithmes nécessitent l'attribution de valeurs ID. Par exemple, pour les adresses, un ensemble de données composé d'une rue, d'un numéro, d'un code postal et d'une ville forme un groupe. Ce groupe est défini par la valeur ID. Si une table contient par exemple le domicile principal et le domicile secondaire, c'est-à-dire deux groupes d'adresses, un ID unique doit être attribué à chaque groupe.
Je compte ce phénomène parmi les classiques des projets spécifiques à SAP. Il est toujours intéressant et surprenant de voir comment les champs de recherche et de matchcode sont remplis dans les systèmes SAP des clients et quelles peuvent être les manifestations de ce phénomène.
Un exemple assez anodin est que seul le premier champ de recherche est rempli, mais alors avec le prénom et le nom. Dans nos templates SAP standard, nous avons choisi une certaine forme d'occupation des champs. Ce paramètre doit être adapté aux besoins du client.
Les systèmes SAP qui ne fonctionnent pas encore sur la base de SAP HANA contiennent généralement, en plus des tables transparentes, des tables de cluster et de pool qui se caractérisent par le fait qu'elles ne peuvent être sélectionnées qu'au niveau ABAP. Pour effectuer cette opération, un module fonctionnel propre à Libelle doit être transporté dans les systèmes.
Sur ce point, le risque d'erreur réside dans le fait que les mises à jour du logiciel contiennent également des mises à jour du module fonctionnel et que l'on oublie volontiers d'importer le nouveau fichier de transport. Libelle DataMasking vérifie la version du bloc fonctionnel et émet un message d'erreur en cas de divergence.
Un cycle d'anonymisation peut échouer pour diverses raisons. Les causes peuvent également être externes au logiciel, par exemple un système de fichiers saturé ou même un tablespace saturé. Une fois l'erreur corrigée, l'anonymisation peut être poursuivie. Il faut alors vérifier si les points de reprise sont activés. Grâce à eux, l'anonymisation peut être poursuivie exactement au niveau de l'ensemble de données où l'erreur s'était produite auparavant. Si les points de reprise sont inactifs, la dernière table traitée sera à nouveau anonymisée, bien qu'une partie des données ait déjà été anonymisée.
Dans certains projets, nous atteignons un niveau de personnalisation parfois assez élevé. Ces extensions qui s'écartent du standard (par exemple des scripts) sont prises en compte pendant une mise à jour du logiciel. Toutefois, si le logiciel est réinstallé en parallèle, les paramètres de la personnalisation doivent être "péniblement" repris dans le nouvel environnement. C'est-à-dire que des fichiers supplémentaires doivent d'abord être copiés, d'autre part, les paramètres doivent également être adaptés à nouveau dans l'outil lui-même.
Je compte également ce cas parmi les erreurs classiques dans les projets. Il arrive que des champs qui font partie de la clé primaire d'une table doivent être anonymisés. Un exemple typique est la table TIBAN dans SAP. À l'aide de notre algorithme, nous recalculons valablement les valeurs d'un IBAN dans Libelle DataMasking. Mais souvent, la qualité des données d'origine nous met des bâtons dans les roues.
Pour rester dans l'exemple : Ce qui se produit régulièrement, c'est l'absence de chiffres de contrôle. Ainsi, dans les systèmes, il y a des enregistrements avec et sans chiffre de contrôle. Toutefois, l'algorithme recalcule également le chiffre de contrôle de manière valide, bien qu'il soit en fait absent de l'un des enregistrements. Cette constellation entraîne la création de doublons, ce qui a pour conséquence que la clé primaire, qui a été supprimée auparavant pour le traitement de ces champs, ne peut plus être recréée.
Dans de nombreux projets, on attache de l'importance à ce que les données d'adresses ne soient pas modifiées arbitrairement, mais restent dans la région d'origine, ce qui peut également être mis en œuvre avec Libelle DataMasking.
Cela nécessite toutefois une qualité élevée des données d'origine. Si la région (par ex. l'État fédéral) ou le pays ne sont pas gérés proprement, les valeurs anonymisées se retrouvent dans une région complètement différente. Si les données sont incomplètes dans le système, un mapping peut être effectué via une personnalisation , de sorte que les adresses restent dans leur région d'origine même après l'anonymisation.
Libelle IT Group a développé ici, avec Libelle DataMasking, une solution pour l'anonymisation et la pseudonymisation nécessaires. Cette solution a été conçue pour produire des données anonymisées et logiquement cohérentes sur les systèmes de Développement, de Test et d'Assurance Qualité sur toutes les plates-formes. Apprenez-en plus sur nos solutions et consultez notrelivre blanc gratuit.