Pendant l’enquête sur la faille de sécurité d’ACME, plusieurs points vulnérables ont été détectés. Les développeurs d’applications demandent de plus en plus de données pour le test et le débogage. Malheureusement, pour satisfaire cette demande, des données « réelles » ont été simplement copiées dans les bibliothèques
Les défauts de la base de données
de test des développeurs. C’était un grave danger et l’un des nombreux défauts du processus de développement applicatif : en tout cas, trop pour en discuter dans le cadre de cet article. Nous nous concentrons ici sur la réingénierie de la base de données employés existante.
Deux défauts principaux de la base de données employés ont provoqué la faille de sécurité chez ACME. Le premier était l’usage de la colonne numéro employé (employee number column, EMPNO) à la fois comme clé unique et primaire. (Pour en savoir plus sur les différences entre primaire et unique, lisez la newsletter Centerfield Technology, février-mars 2009 à www.centerfieldtechnology.com. Cette négligence a fait que les valeurs contenues dans la colonne EMPNO se sont propagées comme clés étrangères dans toute la base de données. Le second défaut de conception consistait à combiner deux genres d’informations – biographiques et paie – dans un stockage de données unique, la table EMPLOYEE dans le cas présent. Cette anomalie est devenue apparente au DBE dès lors que la base de données employée a été analysée à l’aide d’outils de conception et de développement modernes.
La figure 1 contient un instantané d’écran provenant du diagramme RDA Physical Data Model (PDM) pour la base de données employée. Heureusement pour le DBE, les champs de la base de données utilisaient des noms descriptifs, commodes pour identifier rapidement les points litigieux. Dans la figure 1, vous pouvez voir qu’il existe plusieurs vues ne contenant pas l’information paie (VEMP, VEMPLP, VEMPDPT1). C’est une première bonne tentative pour protéger des données sensibles des esprits trop curieux. En outre, le DBE était uniquement responsable pour créer les vues et pour fournir les permissions requises : une autre bonne pratique. Hélas, cela n’a pas empêché les données sensibles d’être copiées des tables de production dans les versions de test des tables. Pour corriger les défauts de conception, le DBE a proposé un projet de réingénierie pour la base de données employée existante.
Le dictionnaire Wikipedia définit le reengineering comme « the application of technology and management science to the modification of existing systems, organizations, processes et products in order to make them more effective, efficient et responsive » (l’application de la technologie et de la science du management à la modification des systèmes existants, aux organisations, aux processus et aux produits, pour les rendre plus efficaces et réactifs). Autrement dit, un bon projet de réingénierie demande de bons outils et un bon plan. Voici quelques-unes des tâches qui font partie du plan de réingénierie de la base de données Employee mis en place par le DBE d’ACME. Utilisez des outils de développement modernes pour effectuer les tâches suivantes :
• Diviser la table EMLOYEE en deux tables
• Réunifier la table EMPLOYEE comme une vue jointe
• Accorder des permissions sur les tables et les vues à des utilisateurs autorisés
• Permettre des mises à jour, des suppressions et des inserts de la vue EMPLOYEE à l’aide de déclencheurs INSTEAD OF
Téléchargez cette ressource

EDI : Pratiques de Performance Opérationnelle
Comment mieux satisfaire les directions métiers, rationaliser les échanges, améliorer la qualité des données et gérer l’obsolescence ? Découvrez dans ce livre blanc, les principaux enjeux autour de l’échange de données informatisé, les technologies complémentaires à l’EDI pour gagner en efficacité et les innovations d’offres de services fournis par Generix Group pour digitaliser vos processus.