Log Management Module with the Blockchain Technology

Set up a system to manage server application log events based on Blockchain technology. In order to implement this system we have used a set of technologies like the BigchainDB and Tendermint frameworks that allow to create a Blockchain network. Then, we created a server interface and a human-machine interface allowing communication with the network using the Spring Boot and Angular frameworks respectively.

Transcript

1. République Tunisienne Ministère de l’Enseignement Supérieur et de la Recherche Scientifique Université de Tunis El Manar Institut Supérieur d’Informatique d’El Manar Rapport de Projet de Fin d’Année Présenté en vue de l’obtention du Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques Spécialité : Génie Logiciel et Systèmes d’Information Par Saifeddine ESSID Coffre-fort : Module de Gestion des Logs avec la Technologie de la Blockchain Encadrant professionnel : Encadrant académique : Monsieur Abdessattar FEHRI Monsieur Sahbi BAHROUN Ingénieur TechLead Maître Assistant Réalisé au sein de Be-softilys Année Universitaire 2018 - 2019
3. République Tunisienne Ministère de l’Enseignement Supérieur et de la Recherche Scientifique Université de Tunis El Manar Institut Supérieur d’Informatique d’El Manar Rapport de Projet de Fin d’Année Présenté en vue de l’obtention du Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques Spécialité : Génie Logiciel et Systèmes d’Information Par Saifeddine ESSID Coffre-fort : Module de Gestion des Logs avec la Technologie de la Blockchain Encadrant professionnel : Encadrant académique : Monsieur Abdessattar FEHRI Monsieur Sahbi BAHROUN Ingénieur TechLead Maître Assistant Réalisé au sein de Be-softilys Année Universitaire 2018 - 2019
4. J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance. Encadrant professionnel, Monsieur Abdessattar FEHRI Signature et cachet J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance. Encadrant académique, Monsieur Sahbi BAHROUN Signature
5. Dédicaces Je dédie ce travail à : Monsieur Abdessattar FEHRI, Monsieur Sahbi BAHROUN pour m’avoir encadré et fait de leurs mieux afin de m’aider. Saifeddine ESSID ii
6. Remerciements Au terme de ce rapport, il est de mon devoir de présenter mes profondes gratitudes à tous ceux qui m’ont aidé, encouragé et dirigé pour l’élaboration de ce travail. Je tiens à exprimer mes sincères remerciements à toutes les personnes dont l’intervention, de près ou de loin au cours de ce projet, a favorisé son aboutissement. À M. Abdessattar FEHRI, pour m’avoir prodigué l’honneur de travailler dans son équipe, pour ses conseils et sa disponibilité. À toutes les personnes qui ont contribué à l’élaboration de ce travail. Je leur adresse mes plus profonds remerciements. iii
7. Table des matières Introduction générale 1 1 Contexte général 2 1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1 Be|softilys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.2 Be|ys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Objectifs et contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Choix méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 Étude préalable 8 2.1 Concepts clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.2 Bloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.3 Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.4 Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.1 Log Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.2 Log Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3 Frameworks Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.1 Openchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.2 Multichain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.3 BigchainDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3 Analyse et spécification des besoins 15 3.1 Utilisateurs du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2 Collecte des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 iv
8. 3.3.1 Gestion des nœuds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.3.2 Gestion des regroupements d’évènements . . . . . . . . . . . . . . . . . . . . . 24 3.3.3 Diffusion du journal d’évènements . . . . . . . . . . . . . . . . . . . . . . . . 28 3.3.4 Gestion des secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4 Architecture et conception détaillée 35 4.1 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.1.1 Architecture générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.1.2 Architecture applicative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.2 Paquetages de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.3 Diagrammes de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.3.1 Diagramme de classe de la couche entité (api.entities) . . . . . . . . . . . . . 40 4.3.2 Diagramme de classe de la couche repository (api.repositories) . . . . . . . . . 41 4.3.3 Diagramme de classe de la couche service (api.services) . . . . . . . . . . . . . 42 4.3.4 Diagramme de classe de la couche contrôleur (api.controllers) . . . . . . . . . 43 4.3.5 Diagramme de classe de la couche aspects (api.aspects) . . . . . . . . . . . . . 44 4.3.6 Diagramme de classe de la couche utilis (api.utils) . . . . . . . . . . . . . . . 45 4.3.7 Diagramme de classe de la couche validators (api.validators) . . . . . . . . . . 46 4.3.8 Diagramme de classe de test de la couche repository (api.repositories) . . . . 47 4.3.9 Diagramme de classe de test de la couche service (api.services) . . . . . . . . 48 4.3.10 Diagramme de classe de test de la couche contrôleur (api.controllers) . . . . . 49 4.4 Aspect dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.4.1 Créer Nœud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.4.2 Modifier Stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.4.3 Diffuser Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.4 Gérer Secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5 Réalisation 56 5.1 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.1.1 Environnement Matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.1.2 Environnement Logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.1.3 Technologies de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . 58 v
9. 5.1.4 Frameworks et outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2 Principaux de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.2.1 Interaction avec le réseau Blockchain . . . . . . . . . . . . . . . . . . . . . . . 60 5.2.2 Réalisation des fonctionnalités procurées à l’administrateur . . . . . . . . . . 68 5.2.3 Réalisation des fonctionnalités procurées une application serveur . . . . . . . 74 Conclusion générale 76 Annexes 78 Annexe 1. Entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 vi
10. Table des figures 1.1 Application logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Blockchain vs Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Fonctionnement d’un réseau Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Structure de la Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3 Interface du logiciel Log Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4 Interface du logiciel Log Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5 Openchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.6 Multichain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.7 BigchainDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1 Diagramme de cas d’utilisation système . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2 Raffinement du cas d’utilisation « Gérer Nœuds » . . . . . . . . . . . . . . . . . . . . 20 3.3 Diagramme de séquence relatif au cas d’utilisation « Créer Nœud » . . . . . . . . . . 22 3.4 Raffinement du cas d’utilisation « Gérer Streams » . . . . . . . . . . . . . . . . . . . 24 3.5 Diagramme de séquence relatif au cas d’utilisation « Modifier stream » . . . . . . . . 26 3.6 Raffinement du cas d’utilisation « Diffuser Logs » . . . . . . . . . . . . . . . . . . . . 28 3.5 Diagramme de séquence relatif au cas d’utilisation « Diffuser Logs » . . . . . . . . . 29 3.8 Raffinement du cas d’utilisation « Gérer Secrets » . . . . . . . . . . . . . . . . . . . . 30 3.9 Diagramme de séquence relatif au cas d’utilisation « Gérer Secrets » . . . . . . . . . 32 4.1 Architecture générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.2 Architecture applicative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.3 Diagramme de paquetages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.4 Diagramme de classe de la couche entité . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.4 Diagramme de classe de la couche repository . . . . . . . . . . . . . . . . . . . . . . . 41 4.5 Diagramme de classe de la couche service . . . . . . . . . . . . . . . . . . . . . . . . 42 4.6 Diagramme de classe de la couche contrôleur . . . . . . . . . . . . . . . . . . . . . . . 43 4.7 Diagramme de classe de la couche aspects . . . . . . . . . . . . . . . . . . . . . . . . 44 4.8 Diagramme de classe de la couche utils . . . . . . . . . . . . . . . . . . . . . . . . . . 46 vii
11. 4.9 Diagramme de classe de la couche validators . . . . . . . . . . . . . . . . . . . . . . . 47 4.10 Diagramme de classe de test de la couche repository . . . . . . . . . . . . . . . . . . 47 4.11 Diagramme de classe de test de la couche service . . . . . . . . . . . . . . . . . . . . 48 4.12 Diagramme de classe de test de la couche contrôleur . . . . . . . . . . . . . . . . . . 49 4.13 Diagramme de séquence objet du cas d’utilisation « Créer Nœud » . . . . . . . . . . 51 4.14 Diagramme de séquence objet du cas d’utilisation « Modifier Stream » . . . . . . . 52 4.15 Diagramme de séquence objet du cas d’utilisation « Diffuser Logs » . . . . . . . . . 53 4.16 Diagramme de séquence objet du cas d’utilisation « Gérer Secrets » . . . . . . . . . 53 5.1 Diagramme de séquence objet du cas d’utilisation « Gérer Secrets » . . . . . . . . . . 57 5.2 Configuration par défaut du module BigchainDB . . . . . . . . . . . . . . . . . . . . 61 5.3 Configuration par défaut du module Tendermint . . . . . . . . . . . . . . . . . . . . 61 5.4 Réponse de l’end-point « GET transactionId » . . . . . . . . . . . . . . . . . . . . . 63 5.5 Réponse de l’end-point « GET transactions assetId » . . . . . . . . . . . . . . . . . . 64 5.6 Requête de l’end-point « POST transactions mode » . . . . . . . . . . . . . . . . . . 65 5.7 Requête de l’end-point « GET block height » . . . . . . . . . . . . . . . . . . . . . . 65 5.8 Réponse de l’end-point « GET genesis » . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.9 Réponse de l’end-point « GET transaction hash » . . . . . . . . . . . . . . . . . . . . 67 5.10 Réponse de l’end-point « GET validator height » . . . . . . . . . . . . . . . . . . . 68 5.11 Interface de gestion des nœuds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.12 Interface aperçu de stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.13 Interface de gestion des streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.14 Interface aperçu de stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.15 Interface aperçu d’évènements par niveau de sévérité . . . . . . . . . . . . . . . . . 71 5.16 Interface aperçu d’évènements par regroupement d’évènements . . . . . . . . . . . . 71 5.17 Interface dashboard 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.18 Interface dashboard 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.19 Interface gestion des secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.20 Interface responsive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.21 Interface de paramétrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.22 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.23 BlockchainAppender.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 viii
12. Table des figures Annexe 1.1 Logo d’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 ix
13. Liste des tableaux 1.1 Tableau comparatif entre une base de données et un réseau Blockchain . . . . . . . . 6 3.1 Description textuelle du cas d’utilisation « Créer Nœud » . . . . . . . . . . . . . . . 20 3.2 Description textuelle du cas d’utilisation « Consulter Nœuds » . . . . . . . . . . . . 22 3.3 Description textuelle du cas d’utilisation « Modifier stream » . . . . . . . . . . . . . 24 3.4 Description textuelle du cas d’utilisation « Consulter streams » . . . . . . . . . . . . 26 3.5 Description textuelle du cas d’utilisation « Diffuser Logs » . . . . . . . . . . . . . . . 29 3.6 Description textuelle du cas d’utilisation « Gérer Secrets » . . . . . . . . . . . . . . . 31 x
14. Liste des abréviations — API = Interface de Programmation Applicative — CLI = Interface en Ligne de Commande — CRUD = Create - Read - Update - Delete — CSS = Cascading Style Sheets — DOM = Document Object Model — DTO = Data Transfert Object — HTTP = Hypertext Transfer Protocol — IHM = Interface Homme-Machine — JDK = Java Development Kit — MVVM = Model View ViewModel — P2P = Peer-to-Peer — REST = Representational State Transfer — RUP = Rational Unified Process — UML = Unified Modeling Language xi
15. Introduction générale Nous vivons aujourd’hui l’aire de la numérique où la mise en place d’un système de sécurisation de l’information est indispensable. Ce système doit assurer l’intégrité, la traçabilité ainsi que la confidentialité des données, en se basant sur des mécanismes de chiffrement. L’entreprise Be-softilys décide de mettre en place un système informatisé qui permet de sécuriser l’accès à l’information et simplifier la vie des employés qui sont les futurs utilisateurs de ce système, tout en gardant les données dans un endroit protégé de toute menace de vole ou de modification aléatoire, d’où l’appellation du sujet intitulé "coffre-fort". Dans ce cadre, l’entreprise nous a confié la tâche de réaliser une solution qui permet en premier lieu d’assurer la traçabilité de l’historique des événements du journal des applications serveurs. L’idée est la construction d’un système que se base sur la technologie de la blockchain, ce qui nous a amené au cours du projet à avoir recours à un ensemble de modules logiciels permettant son implémentation sur le plan technique. Ce système est composé de trois modules principaux ; un module qui concerne l’interface serveur qui sert comme intermédiaire entre les applications serveurs et le réseau Blockhcain, un module front-end qui sert comme une interface utilisateur graphique pour qu’un administrateur puisse gérer les entités du système de manière simple et assurer une bonne expérience utilisateur, et enfin un module qui contient trois autres sous modules qui concernent l’implémentation d’un réseau Blockchain. Ce rapport se divise en cinq chapitres. Dans le premier chapitre nous exposons une idée sur l’organisme d’acceuil et le cadre général, dans le deuxième nous présentons les définitions de plusieurs aspects qui concernent le travail demandé et qui font partie de l’étude préalable. Dans le troisième et le quatrième chapitre nous montrons l’architecture générale du projet et la conception détaillée des différents composants du système. Enfin, le dernier chapitre concerne la partie réalisation qui s’intéresse à l’implémentation technique des composants précédemment conçus. Ce travail est fait dans le cadre d’un stage d’initiation à la vie professionnelle. 1
16. Chapitre 1 Contexte général Plan 1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3 Objectifs et contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4 Choix méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
17. Chapitre 1. Contexte général Introduction Nous focalisons dans ce premier chapitre sur la présentation du contexte du projet et l’organisme d’accueil avec ses différentes marques, ensuite nous montrons notre objectif et nos contributions ainsi que la méthodologie de travail choisit. 1.1 Organisme d’accueil L’organisme d’acceuil « Be-softilys » appartient un groupe appelé « Be-ys » que nous allons présenter dans les sections qui suivent. 1.1.1 Be|softilys Be|softilys est l’éditeur de logiciel du groupe be|ys dont la vocation est de développer des produits pour l’ensemble des acteurs du marché ouvert par les domaines d’activité du groupe. Les activités de développement de cet éditeur sont réalisées avec l’approche DevOps qui favorise la collaboration et procure de l’assistance depuis le processus de développement jusqu’au support en production. C’est une entreprise qui est organisée en des équipes de développement Scrum faisant aussi de l’assurance qualité et métier dont les activités sont assistées par une plate-forme de développement et d’intégration continue. L’entreprise propose son produit pour le bénéfice des marchés de services d’assurance, de santé, de confiance numérique, de logement et bientôt de la mobilité, dont l’ensemble des offres provient du groupe be|ys mais qui peuvent aussi provenir de certains partenaires.[1] Be|softilys met en priorité dans ses activités le respect des exigences liées aux différentes réglementations telles que le RGPD et les normes internationales liées aux métiers couverts par le groupe be|ys. L’entreprise essaye de répondre aux besoins du marché mondial en termes de produits innovants en offrant des solutions pour la confiance numérique et la gestion de données sensibles. Les projets délivrés sont automatiquement déployés sur son cloud privé hébergé dans les datacenters HADS du groupe be|ys et adossés à son centre de cybersecurité.[1] 3
18. Chapitre 1. Contexte général 1.1.2 Be|ys Le groupe be-ys considéré comme un expert dans le traitement, le stockage et la sécurisation en masse de données sensibles, propose une offre universelle pour toute activité économique nécessitant la maîtrise de l’identité numérique, du traitement des flux de données personnelles et confidentielles, au service et en support, de personnes physiques et morales ainsi que des objets connectés. be-ys répond ainsi au besoin d’un mandataire numérique universel, capable d’accompagner les personnes, en sécurisant leurs transactions digitales. Le groupe, qui s’organise autour d’entreprises structurées par offres et savoir-faire, s’appuie sur des partenariats avec le monde académique et des organisations professionnelles internationales pour renforcer son développement en Europe et dans le monde. Avec ses équipes de recherche, be-ys participe à de grands projets internationaux dont notamment Human Brain (Anonymisation des données), le projet Junker H2020 (Block Chain Santé pour l’Europe), UIT (Global SME Award pour la sécurisation des échanges de données). Le Groupe participe également à un projet de Coopération stratégique avec l’Ecole Normale Supérieure (chaire académique sur la sécurité des S.I et cryptographie) ou avec l’Université d’Auvergne (chaire académique sur l’IoT santé et sur l’industrie 4.0), ainsi qu’au projet Matrice Confiance Numérique, un programme d’innovation, de formation et de production lancé avec l’école 42, de l’université Paris Descartes (spécialisée en droit et data science) ainsi que des étudiants en design.[2] 1.1.2.1 Les marques du Groupe Chaque marque fournit des outils technologiques de pointe permettant la maîtrise de l’identité numérique et du traitement des flux de données personnelles et confidentielles. En effet, les activités de recherche assurent aux clients du Groupe une conformité constante aux standards technologiques et réglementaires de la confiance numérique.[2] Le Groupe dispose des huit marques suivantes : • be-idys, la marque dédiée aux services de confiance numérique, • be-optilys, la marque dédiée aux solutions santé, • be-stydys, la marque dédiée à la recherche et à l’innovation, • be-kortalys, la marque dédiée à l’ingénierie de la sécurité de l’information et des centres de données, 4
19. Chapitre 1. Contexte général • be-itys, la marque dédiée à l’hébergement, la sécurisation, les traitements et la gestion des données sensibles, • be-clearys, la marque dédiée aux solutions de traitement industriel de données et à la relation client, • be-almerys, la marque dédiée aux solutions de gestion du Tiers Payant Santé et du traitement des flux d’informations Santé, • be-softilys, la marque dédiée à l’édition et au développement logiciel. 1.2 Contexte du projet Le concept de journalisation signifie l’enregistrement d’une manière séquentielle sur un support de données un historique d’événements qui affecte un processus particulier. Dans le cas du système existant, ce dernier est conservé soit dans des fichiers, soit dans une base de données classique. Figure 1.1 : Application logging Dans ce cadre, notre travail aura la mission de maximiser la sécurisation de l’endroit de conservation des données et assurer leur traçabilité. Pour cela nous avons choisit d’adopter la solution d’un serveur Blockchain. Chaque méthode de stockage de données a son propre ensemble d’avantages et de limites que nous allons développer dans le tableau 1.1. 5
20. Chapitre 1. Contexte général Tableau 1.1 : Tableau comparatif entre une base de données et un réseau Blockchain Base de données Blockchain Existe sur des serveurs centralisés. Existe sur des réseaux P2P. Un accès administrateur permet de manipuler librement les données (contrôle centralisé). Les données ne peuvent pas être modifiées mais uniquement ajoutées ou lues. Chaque changement est approuvé après un consensus ente les différents nœuds (contrôle décentralisé). Ne contient souvent que les informations les plus récentes, sujettes à changement. Mieux adaptée pour contenir des éléments d’information qui nécessitent un historique. Stockage de données rapide. Stockage de données tardif. Une simple faille dans le serveur central, permet d’accéder aux données. Imperméables au piratage (nécessite une attaque à 51%). La figure 1.2 illustre la difference au niveau architectural entre les bases de données et les réseaux Blockchain. Figure 1.2 : Blockchain vs Database 1.3 Objectifs et contributions La Blockchain est une technologie dont l’utilisation est actuellement en croissance dans le monde entier. Elle peut être implémentée dans des différents contextes dont l’objectif est d’assurer l’intégrité des données. L’entreprise Be-softilys connue comme un acteur principal dans le secteur 6
21. Chapitre 1. Contexte général du stockage et la sécurisation en masse de données sensibles, veut intégrer cette technologie dans ses projets afin de rediriger l’enregistrement des données vers le réseau Blockchain. Dans ce contexte, l’équipe DevOps nous a confié la responsabilité de réaliser un système basé sur la technologie Blockchain afin de rediriger tous les évènements des journaux d’applications serveurs ainsi que toute information qui doit être gardée secrète vers ce dernier. Dans le but d’atteindre cet objectif, nous devons comme première tâche choisir un framework qui correspond mieux aux besoins de l’entreprise. Puis, nous commençons par préparer la configuration adéquate afin de mettre en place notre réseau Blockchain. La tâche suivante consiste à réaliser un socle backend qui permet d’intercepter le flux des données à partir des applications serveurs et le rediriger vers le réseau Blockchain. Enfin, nous devons réaliser un module d’intégration dans les applications tierces et un module frontend pour un accès administrateur. 1.4 Choix méthodologique Afin de s’assurer de la présence de bonnes conditions pour la réalisation de notre projet et obtenir un résultat qui le plus satisfiable en terme de qualité, nous essayons de choisir la méthodologie de développement qui soit la plus adéquate avec le contexte du projet tenant compte de plusieurs facteurs. Entre les méthodologies de travail qui existent, nous distinguons deux grandes familles qui sont les méthodes agiles d’une part et les méthodes classiques d’une autre part, ainsi que la méthode du processus unifié celle que nous avons choisi comme notre méthodologie de travail. En effet, la méthode RUP qui est une variante du processus unifié est caractérisée par un aspect incrémental et itératif qui convient aux besoins du développement de notre projet. Ainsi, cette méthode permet de répondre aux besoins d’utilisation dans délais courts et précis. Conclusion Dans ce premier chapitre, nous avons essayé de présenter le contexte du projet ainsi que l’organisme d’accueil. Pour mieux clarifier notre objectif, les chapitres qui suivent vont être réservés pour l’étude des différents aspects du projet et la conception du nouveau système. 7
22. Chapitre 2 Étude préalable Plan 1 Concepts clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2 Solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3 Frameworks Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
23. Chapitre 2. Étude préalable Introduction Avant de commencer la réalisation de notre projet, nous avons dû passer par une phase d’étude préalable afin d’analyser l’ensemble des technologies que nous pouvons utiliser afin d’implémenter la solution. Dans ce chapitre, nous montrons une étude des concepts importants du domaine ainsi qu’une étude afin de comparer les frameworks présents dans le marché. 2.1 Concepts clés Dans cette section, nous présentons des notions génériques à propos du projet. 2.1.1 Blockchain Comme son appellation l’indique, une « Blockchain » est en effet une chaîne de blocs qui représente un registre partagé entre les membres du réseau dont l’infrastructure est pair à pair. Ce dernier est composé de plusieurs nœuds dont le rôle de chacun est l’exécution de certaines opérations afin de faire la vérification du contenu des blocs avant d’être ajoutés à la chaîne. Un bloc peut contenir une transaction ou un ensemble de transactions signées numériquement à l’aide des algorithmes de cryptographie asymétrique afin de s’assurer de leur intégrité. La figure 2.1 décrit le fonctionnement d’un réseau Blockchain. Figure 2.1 : Fonctionnement d’un réseau Blockchain 9
24. Chapitre 2. Étude préalable Les blocs d’une Blockchain peuvent être considérés comme des enregistrements au sein d’une base de données contenant les transactions effectuées sous un ensemble de contraintes. Parmi les contraintes d’une Blockchain, il y a l’immutabilité qui est une caractéristique du réseau et qui assure qu’une fois un bloc est ajouté à la chaîne ne sera plus modifié ou supprimé. La deuxième caractéristique du réseau est le contrôle décentralisé qui fait qu’une manipulation de la chaîne à partir d’une seule partie nécessite le contrôle au minimum de 51% des nœuds. Il existe deux types de réseaux Blockchain selon l’accessibilité du registre ; • Blockchain publique ; un réseau P2P dont l’accès au registre ainsi que la participation à la création et la validation des transactions est libre. • Blockchain privée ; un réseau P2P dont l’accès au registre est réservé aux membres inscrits ainsi que la validation des transactions. 2.1.2 Bloc Une chaîne de blocs est composée de blocs qui contiennent des transactions valides. Dans un bloc, il y a le hash de son contenu et le hash du bloc qui le précède, ceci rend qu’une simple modification d’un bloc nécessite la modification de l’ensemble des blocs de la chaîne. La figure 2.2 illustre la structure de la Blockchain. Le hash est considéré comme une empreinte unique calculée à Figure 2.2 : Structure de la Blockchain 10
25. Chapitre 2. Étude préalable partir des données qui se trouvent dans le bloc utilisant un algorithme de hashage. Afin d’ajouter un bloc, nous devons passer par la création du bloc puis l’ajout de ce dernier à la chaîne par un nœud du réseau. L’ensemble des nœuds du réseau vérifie le contenu et la structure du bloc si ça respecte les contraintes de la Blockchain. Dans le cas où le bloc ne sera pas validé, il sera rejeté. 2.1.3 Peer Dans un réseau Blockchain un nœud est appelé Peer où chaque Peer a une copie du registre qui est partagé. Il existe deux types de nœuds dans le réseau ; • Nœud non mineur ; un nœud non mineur ne participe pas à la validation des transactions mais agit comme une passerelle de connexion aux autres nœuds. • Nœud mineur ; un nœud mineur se charge de faire le consensus entre l’ensemble des nœuds du réseau et valider les transactions. 2.1.4 Consensus Le consensus est un processus fait par les nœuds du réseau afin de vérifier la validité des transactions et des blocs qui s’ajoutent à la chaîne. Afin de participer au consensus un nœud doit exécuter un algorithme qui permet de résoudre des problèmes mathématiques qui nécessitent une haute puissance de calcul. Ce processus permet de s’assurer qu’une transaction n’est ajoutée à la chaîne que si elle respecte les contraintes imposées. Si la majorité des nœuds du réseau vote pour la conformité et l’exactitude de la transaction, le bloc qui contient cette transaction sera inclue dans la chaîne. Il existe des théories différentes utilisées pour établir le consensus. Parmi ces théories il y a la « BFT » ou "Byzantine fault tolerance" inspirée du problème des généraux byzantins. Dans une "Byzantine fault", une entité tel qu’un serveur peut apparaître à la fois défectueuse et fonctionnant pour les systèmes de détection de panne. Ceci crée des confusions pour les observateurs à cause de la présence de différents symptômes contradictoires, ce qui rend la tâche difficile pour les autres composants de déclarer un échec et de l’exclure du réseau, car ils doivent d’abord parvenir à un consensus sur le composant défaillant. Le consensus "Byzantine fault tolerance" (BFT) tolère x fautes byzantines si x est inférieur à 1/3 des réponses. 11
26. Chapitre 2. Étude préalable 2.2 Solutions existantes Après avoir fait une analyse sur le marché, nous trouvons qu’il existe quelques solutions permettant de gérer les évènements des journaux des applications serveurs. Ces exemples que nous avons trouvés utilisent des serveurs centralisés afin de stocker les données et non pas la technologie de la Blockchain ce qui augmente le risque de perdre les informations à jamais. 2.2.1 Log Analyzer Log Analyzer est un logiciel qui permet de rechercher et filtrer les données de journal provenant de plusieurs sources et faire la visualisation en temps réel. Figure 2.3 : Interface du logiciel Log Analyzer 2.2.2 Log Manager Log Manager est un logiciel qui collecte et fait l’analyse des journaux générés à partir de plusieurs nœuds et procure des méthodes pour faire la surveillance et la gestion. 12
27. Chapitre 2. Étude préalable Figure 2.4 : Interface du logiciel Log Manager 2.3 Frameworks Blockchain Afin d’implémenter le réseau Blockhain, nous allons avoir recours à un ensemble de modules ou de frameworks. Il existe plusieurs frameworks disponibles dans le monde open source qui peuvent être utilisés dans le développement de notre solution. Dans les sous-sections qui suivent, nous allons présenter les frameworks un par un. 2.3.1 Openchain Openchain est un framework qui permet la mise en place d’un système distribué et open source pour l’émission et la gestion d’actifs numériques. Figure 2.5 : Openchain 13
28. Chapitre 2. Étude préalable 2.3.2 Multichain Multichain est une plate-forme open-source pour les transactions financières multi-actifs basée sur la Blockchain de bitcoin. Figure 2.6 : Multichain 2.3.3 BigchainDB BigchainDB adopte une base de données avec les caractéristiques d’une Blockchain comme l’immutabilité et le contrôle décentralisé. Figure 2.7 : BigchainDB Conclusion Dans ce chapitre, après avoir fait l’analyse de l’existant nous avons constaté que les solutions existantes dans le marché utilisent un contrôle centralisé sur les données, ce qui met les informations dans un risque élevé de perte. Dans le chapitre suivant, nous commençons à faire la spécification des besoins fonctionnels et non fonctionnels de notre système. 14
29. Chapitre 3 Analyse et spécification des besoins Plan 1 Utilisateurs du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2 Collecte des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
30. Chapitre 3. Analyse et spécification des besoins Introduction Dans ce chapitre, nous allons montrer les utilisateurs du système à concevoir ainsi que les différentes fonctionnalités qu’il procure. Par la suite, nous allons avoir recours à l’outil de modélisation yUML, qui utilise le fameux langage UML afin de modéliser les diagrammes de cas d’utilisation et de séquence d’un point de vue système. 3.1 Utilisateurs du système Ce système est utilisé par deux utilisateurs finaux ; • l’administrateur du système ; c’est celui qui gère les évènements du journal des applications serveurs ainsi que les différents nœuds au sein du réseau. • les applications serveurs ; ce sont les composants logiciels qui diffusent leurs journaux d’évènements à travers le système. 3.2 Collecte des besoins Dans cette partie, nous distinguons entre des besoins de nature fonctionnelle et d’autres non fonctionnels dont le système doit satisfaire. 3.2.1 Besoins fonctionnels Ce sont les besoins qui sont en relation étroite avec les différentes fonctionnalités demandées au système à mettre en place. L’administrateur doit avoir sous son contrôle les fonctionnalités qui suivent ; Gestion des nœuds ; • Ajouter un nœud, • Modifier un nœud, • Supprimer un nœud, • Consulter les nœuds, • Avoir un aperçu des regroupements d’évènements de chaque nœud. Gestion des regroupements d’évènements ; • Ajouter un stream, 16
31. Chapitre 3. Analyse et spécification des besoins • Modifier un stream, • Supprimer un stream, • Consulter les streams, • Avoir un aperçu des évènements de chaque stream. Gestion des évènements ; • Filtrer les évènements par niveau de sévérité, • Filtrer les évènements par regroupement. Gestion des secrets ; • Crypter un secret, Affichage des derniers évènements diffusés, Affichage des transactions enregistrées dans le serveur Blockchain, Affichage de l’ensemble des nœuds dans le réseau. Une application serveur doit avoir à sa disposition les fonctionnalités qui suivent ; Créer un évènement, Associer un regroupement d’évènements, Associer un nœud, Diffuser les évènements du journal. 3.2.2 Besoins non fonctionnels Ce sont les besoins qui sont en relation avec la qualité du code source de l’application en termes de maintenabilité, modularité et extensibilité, sécurité, ainsi que l’ergonomie. L’application est dotée d’une API de réflexion faisant un couplage très faible entre la partie back-end et la partie front-end, afin d’assurer mieux la maintenabilité du projet, Le projet est équipé d’une documentation détaillée pour chaque module et une CLI pour automatiser certaines tâches comme l’ajout de nouvelles fonctionnalités. Le module back-end contient ; un système d’authentification pour le contrôle d’accès, un système de validation pour contrôler le flux de données entrant, et un sous-module pour réaliser les tests unitaires et les tests d’intégration, Le module front-end est totalement responsive dont l’apparence est personnalisable en temps réel. 17
32. Chapitre 3. Analyse et spécification des besoins 3.3 Spécification des besoins Nous entamons la partie spécification des besoins après avoir présenté les utilisateurs potentiels de notre système dans la section qui précède. Nous montrons dans cette partie la manière dont ces derniers interagissent avec le système, en modélisant un diagramme de cas d’utilisation global qui nous donne une vision des fonctionnalités principales que ce dernier procure, sans donner des détails qui semblent superflus dans cette étape de modélisation. L’ensemble des fonctionnalités sous le contrôle de l’administrateur ; Gestion des nœuds du réseau, Gestion des regroupements d’évènements de chaque nœud, Gestion des évènements diffusés par les applications serveurs, Affichage de la liste des derniers évènements diffusés, Affichage de la liste des dernières transactions sauvegardées, Affichage de la liste de tous les nœuds au sein du réseau. Gestion des secrets L’ensemble des fonctionnalités sous le contrôle de l’application serveur ; Création d’un évènement, Liaison d’un évènement à un regroupement, Liaison d’un regroupement à un nœud, Diffusion des évènements. La figure 3.1 présente le diagramme de cas d’utilisation système. 18
33. Chapitre 3. Analyse et spécification des besoins Figure 3.1 : Diagramme de cas d’utilisation système 19
34. Chapitre 3. Analyse et spécification des besoins 3.3.1 Gestion des nœuds C’est une fonctionnalité présentée dans le diagramme de cas d’utilisation système qui donne à l’utilisateur le contrôle des opérations faites sur les nœuds telles que la création et la consultation. Figure 3.2 : Raffinement du cas d’utilisation « Gérer Nœuds » 3.3.1.1 Création d’un nœud Le séquencement des tâches effectuées dans les scénarios du cas d’utilisation « Créer Nœud » est décrit par le tableau 3.1. Tableau 3.1 : Description textuelle du cas d’utilisation « Créer Nœud » Titre : Créer Nœud Utilisateur : Administrateur Pré-condition : L’utilisateur doit passer par le module d’authentification. Description : Ce cas d’utilisation donne la possibilité à l’administrateur d’ajouter un nœud. Scénario principal : 1. L’administrateur consulte l’onglet destiné à la gestion des nœuds. 2. Le système affiche entre autre le formulaire permettant la création du nouveau nœud. 3. L’administrateur saisit l’identifiant du nœud et son adresse IP. 4. L’administrateur confirme les informations saisies en clinquant sur le bouton « Create ». 5. Le système procède à la vérification des informations saisies par l’administrateur. 6. Le nouveau nœud est enregistré dans la base de données. 7. Le système confirme à l’administrateur la création du nœud. 20
35. Chapitre 3. Analyse et spécification des besoins Scénario alternatif : 1. L’administrateur saisit une adresse IP déjà existante ou essaye d’envoyer un champ vide. 2. Le système renvoie une erreur indiquant l’invalidité des données saisies. Dans ce qui suit, la figure 3.3 illustre le diagramme de séquence qui montre le processus de création d’un nœud. Pour créer un nœud, l’utilisateur doit d’abord s’authentifier en tant qu’administrateur. Par la suite, il demande le formulaire d’ajout d’un nœud où il va remplir les champs relatifs au nœud comme l’adresse IP et l’identifiant. Les données saisies passent par une étape de vérification de la validité des valeurs des champs. Dans le cas où les valeurs respectent certains critères imposés par le système, les données seront mises à jour dans la base de données, sinon le système affichera un message d’erreur comme une réponse à la requête. 21
36. Chapitre 3. Analyse et spécification des besoins Figure 3.3 : Diagramme de séquence relatif au cas d’utilisation « Créer Nœud » 3.3.1.2 Consultation des nœuds Le séquencement des tâches effectuées dans le scénario du cas d’utilisation « Consulter Nœuds » est décrit par le tableau 3.2. Tableau 3.2 : Description textuelle du cas d’utilisation « Consulter Nœuds » Titre : Consulter Nœuds Utilisateur : Administrateur Pré-condition : L’utilisateur doit passer par le module d’authentification. Description : Ce cas d’utilisation donne la possibilité à l’administrateur de consulter les nœuds. 22
37. Chapitre 3. Analyse et spécification des besoins Scénario principal : 1. L’administrateur consulte l’onglet destiné à la gestion des nœuds. 2. Le système affiche entre autre la liste des nœuds inscrits. 3. L’administrateur peut sélectionner un nœud afin de le modifier ou le supprimer. 23
38. Chapitre 3. Analyse et spécification des besoins 3.3.2 Gestion des regroupements d’évènements C’est une fonctionnalité présentée dans le diagramme de cas d’utilisation système qui permet à l’utilisateur d’effectuer des opérations telles que l’édition et la consultation. Figure 3.4 : Raffinement du cas d’utilisation « Gérer Streams » 3.3.2.1 Modification d’un regroupement Le séquencement des tâches effectuées dans les scénarios du cas d’utilisation « Modifier stream » est décrit par le tableau 3.3. Tableau 3.3 : Description textuelle du cas d’utilisation « Modifier stream » Titre : Modifier stream Utilisateur : Administrateur Pré-condition : L’utilisateur doit passer par le module d’authentification. Description : Ce cas d’utilisation donne la possibilité à l’administrateur d’éditer un stream. Scénario principal : 1. L’administrateur consulte l’onglet destiné à la gestion des regroupements d’évènements. 2. Le système affiche entre autre le formulaire permettant l’édition du stream existant. 3. L’administrateur saisit l’identifiant du stream et son nom. 4. L’administrateur confirme les informations saisies en clinquant sur le bouton « Update ». 5. Le système procède à la vérification des informations saisies par l’administrateur. 6. Le stream existant est mis à jour dans la base de données. 7. Le système confirme à l’administrateur la modification du stream. 24
39. Chapitre 3. Analyse et spécification des besoins Scénario alternatif : 1. L’administrateur essaye d’envoyer un champ vide. 2. Le système renvoie une erreur indiquant l’invalidité des données saisies. Dans ce qui suit, la figure 3.5 illustre le diagramme de séquence qui montre le processus d’édition ou de modification d’un regroupement d’évènements, appelé aussi "stream". En effet, afin d’éditer un stream, l’utilisateur doit d’emblée s’authentifier en tant qu’administrateur. Ensuite, il demande la liste des streams parmi laquelle il va choisir un seul regroupement pour commencer à modifier ses champs. Les données saisies passent par une étape de vérification de la validité des valeurs des champs. Dans le cas où les valeurs respectent certains critères imposés par le système, les données seront mises à jour dans la base de données, sinon le système affichera un message d’erreur comme une réponse à la requête. 25
40. Chapitre 3. Analyse et spécification des besoins Figure 3.5 : Diagramme de séquence relatif au cas d’utilisation « Modifier stream » 3.3.2.2 Consultation des regroupements Le séquencement des tâches effectuées dans le scénario du cas d’utilisation « Consulter streams » est décrit par le tableau 3.4. Tableau 3.4 : Description textuelle du cas d’utilisation « Consulter streams » Titre : Consulter streams Utilisateur : Administrateur Pré-condition : L’utilisateur doit passer par le module d’authentification. Description : Ce cas d’utilisation donne la possibilité à l’administrateur de consulter les streams. 26
41. Chapitre 3. Analyse et spécification des besoins Scénario principal : 1. L’administrateur consulte l’onglet destiné à la gestion des streams. 2. Le système affiche entre autre la liste des streams associés à tous les nœuds. 27
42. Chapitre 3. Analyse et spécification des besoins 3.3.3 Diffusion du journal d’évènements C’est une fonctionnalité présentée dans le diagramme de cas d’utilisation système qui permet à une application serveur de diffuser les logs vers le réseau Blockchain, ce qui est illustré par la figure 3.6. Figure 3.6 : Raffinement du cas d’utilisation « Diffuser Logs » Le séquencement des tâches effectuées dans les scénarios du cas d’utilisation « Diffuser Logs » est décrit par le tableau 3.5. 28
43. Chapitre 3. Analyse et spécification des besoins Tableau 3.5 : Description textuelle du cas d’utilisation « Diffuser Logs » Titre : Diffuser Logs Utilisateur : Application serveur Pré-condition : Une application serveur doit passer par le module d’authentification. Description : Ce cas d’utilisation donne la possibilité à une application serveur de diffuser son journal d’évènement vers le réseau Blockchain. Scénario principal : 1. L’application serveur crée un évènement puis associe un regroupement et un nœud à cet évènement. 2. L’application serveur diffuse cet évènement vers l’interface serveur. 3. L’interface serveur vérifie les valeurs d’attributs de l’évènement et envoie ce dernier vers l’un des nœuds du réseau Blockchain. 4. Le nœud du réseau Blockchain créé une transaction contenant les informations de l’évènement. 5. Le réseau Blockchain vérifie la transaction à travers un système de vote et un consensus entre les nœuds. 6. Un bloc est créé contenant la transaction puis ajouté à la chaîne. Scénario alternatif : 1. Le nœud du réseau Blockchain crée une transaction invalide. 2. Le réseau Blockchain vérifie la transaction à travers un système de vote et un consensus entre les nœuds. 3. Aucun bloc n’est créé. Dans ce qui suit, la figure 3.7 illustre le diagramme de séquence qui montre le processus de diffusion des logs. En effet, afin de diffuser des évènements du journal, une application doit d’emblée s’authentifier en tant qu’un utilisateur du système. Ensuite, elle commence à diffuser les évènements à travers un module d’intégration avec ce dernier. Ce module interagit avec une interface serveur qui à son tour interagit avec le réseau blockchain. L’ensemble des nœuds du réseau vérifie la validité de la transaction, dans le cas où les valeurs respectent certains critères imposés par le système, un bloc contenant la transaction sera ajouté à la chaîne, sinon le système affichera un message d’erreur comme une réponse à la requête. 29
44. Chapitre 3. Analyse et spécification des besoins Figure 3.7 : Diagramme de séquence relatif au cas d’utilisation « Diffuser Logs » 3.3.4 Gestion des secrets C’est une fonctionnalité présentée dans le diagramme de cas d’utilisation système qui permet à l’administrateur de gérer les secrets, ce qui est illustré par la figure 3.8. 30
45. Chapitre 3. Analyse et spécification des besoins Figure 3.8 : Raffinement du cas d’utilisation « Gérer Secrets » Le séquencement des tâches effectuées dans les scénarios du cas d’utilisation « Gérer Secrets » est décrit par le tableau 3.6. Tableau 3.6 : Description textuelle du cas d’utilisation « Gérer Secrets » Titre : Gérer Secrets Utilisateur : Administrateur Pré-condition : L’administrateur doit passer par le module d’authentification. Description : Ce cas d’utilisation donne la possibilité à l’administrateur de stocker des données secrètes dans la chaîne du réseau Blockchain. 31
46. Chapitre 3. Analyse et spécification des besoins Scénario principal : 1. L’administrateur accède à l’onglet "crypto". 2. L’administrateur choisit un fichier à partir de sa machine puis télécharge ce dernier vers le serveur. 3. L’interface serveur vérifie les valeurs d’attributs du fichier. 4. L’interface serveur crypte les données et la clef de cryptage avec un cryptage symétrique. 5. Le système envoie les données et la clef qui sont cryptés vers l’un des nœuds du réseau Blockchain. 6. Le nœud du réseau Blockchain crée deux transactions contenant les données et la clef de cryptage. 7. Le réseau Blockchain vérifie ces deux transactions à travers un système de vote et un consensus entre les nœuds. 8. Deux blocs sont créés contenant les deux transactions puis ajoutés à la chaîne. Scénario alternatif : 1. Le nœud du réseau Blockchain crée une transaction invalide. 2. Le réseau Blockchain vérifie la transaction à travers un système de vote et un consensus entre les nœuds. 3. Aucun bloc n’est créé. Dans ce qui suit, la figure 3.9 illustre le diagramme de séquence qui montre le processus de l’envoi des secrets. Pour envoyer un secret, un administrateur doit s’authentifier en tant qu’un administrateur du système. Ensuite, il télé-charge un fichier contenant l’information secrète. Ce dernier passe par l’étape de vérification puis il sera crypté par une clé de cryptage symétrique qui à son tour sera cryptée. L’ensemble des nœuds du réseau vérifie la validité des transactions, dans le cas où les valeurs respectent certains critères imposés par le système, des blocs contenant les transactions seront ajoutés à la chaîne, sinon le système affichera un message d’erreur comme une réponse à la requête. 32
47. Chapitre 3. Analyse et spécification des besoins Figure 3.9 : Diagramme de séquence relatif au cas d’utilisation « Gérer Secrets » 33
48. Chapitre 3. Analyse et spécification des besoins Conclusion Dans ce chapitre, nous avons mis en évidence la spécification des besoins de notre solution en détectant l’ensemble des cas d’utilisation et des acteurs qui participent au fonctionnement du système. Ensuite, nous avons essayé de raffiner les cas d’utilisation en question et bien montrer l’interaction entre les acteurs et le système. Dans le prochain chapitre, nous commençons par établir l’architecture et la conception détaillée de l’application. 34
49. Chapitre 4 Architecture et conception détaillée Plan 1 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2 Paquetages de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3 Diagrammes de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4 Aspect dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
50. Chapitre 4. Architecture et conception détaillée Introduction Ce chapitre se concentre sur l’architecture au niveau applicatif et au niveau général de notre système ainsi que le côté statique et dynamique de ce dernier. 4.1 Architecture de la solution À ce stade, nous distinguons entre deux types d’architecture ; d’une part, une architecture générale ou opérationnelle qui définit les différentes parties du système qui interagissent entre eux et d’une autre part, une architecture au niveau applicatif qui montre les couches logicielles de notre application. 4.1.1 Architecture générale L’architecture générale de notre application est composée de ; • Une IHM ; c’est une interface homme-machine qui permet l’interaction du navigateur web avec le système, • Une interface serveur ; qui représente l’intermédiaire entre le client et le réseau Blockchain et qui couvre les couches de notre application. • Les tiers de données ; il existe au moins deux lieux de stockage des données, le premier est destiné pour le stockage des données locales réservé à l’interface serveur et le deuxième est destiné pour le stockage de la chaîne du réseau Blockchain. • Un réseau Blockchain ; c’est un réseau de nœuds connectés pair à pair et équipés de trois modules permettant l’ajout des blocs à la chaîne. • Une application serveur ; c’est un client de notre interface serveur qui diffuse ses évènements à travers le système, C’est une architecture n-tiers illustrée par la figure 4.1. 36
51. Chapitre 4. Architecture et conception détaillée Figure 4.1 : Architecture générale 4.1.2 Architecture applicative Une architecture qui représente les différentes couches de l’application illustrées par la figure 4.2. Ces couches sont ; • La couche présentation ; c’est une couche qui assure la réception des requêtes envoyées par le client HTTP, leur traitement par les méthodes du contrôleur qui représentent les end-points de l’interface serveur REST, ainsi responsables des retours de réponse vers le client. Cette couche communique avec la couche métier afin d’exécuter la logique métier derrière la demande de la requête en utilisant pour fournir la réponse des modèles de données appelés DTOs ; "objets de transfert de données". • La couche métier ; cette couche représente la partie où il y a les différentes fonctionnalités de l’application. Elle est responsable de la gestion des différentes entités de notre application en fournissant les opérations nécessaires à la création et la consultation. Elle communique avec la couche présentation afin de retourner le résultat des traitements exécutés. • La couche données ; c’est la couche qui assure l’interaction avec les données persistantes au sein du système. Elle se base sur une couche d’abstraction gérée par le framework "Spring Data" qui procure un ensemble de méthodes permettant l’accès à la base de données NoSQL. 37
52. Chapitre 4. Architecture et conception détaillée Figure 4.2 : Architecture applicative 4.2 Paquetages de l’application L’architecture au niveau applicatif est composée de couches. Chaque couche possède un rôle différent de l’autre, ce qui nous mène vers le regroupement des classes en paquetages pour mieux différencier entre les différentes parties et assurer la maintenabilité du code source. Le langage UML fournit une spécification permettant de concevoir un diagramme de paquetages qui montre l’aspect statique de l’application. 38
53. Chapitre 4. Architecture et conception détaillée Figure 4.3 : Diagramme de paquetages • api.aspects ; ce paquetage englobe les classes aspects qui sont responsables de l’exécution de certains traitements lors du déclenchement d’évènements nommés "joinpoints", • api.controllers ; fournit les points d’entrées consommés par le client appelés les end-points de l’interface serveur, • api.dtos ; regroupe les modèles de données retournés par l’application vers le client et qui correspondent aux données de formulaires et des vues, • api.entities ; regroupe les entités de notre application. Ces entités sont gérées par le framework "Spring Data" qui assurent le mapping avec les objets persistants, • api.logging ; contient les modules d’intégration au niveau de la librairie du logger qui permettent d’assurer l’interaction des applications tierces avec notre application, • api.repositories ; regroupe l’ensemble des repositories qui représentent une couche d’abstraction 39
54. Chapitre 4. Architecture et conception détaillée permettant de communiquer avec la couche de données et exécuter certaines opérations comme la création et la consultation, • api.security ; c’est le module qui assure l’authentification des utilisateurs en se basant sur le framework "Spring Security", • api.services ; c’est le paquetage qui regroupe les services contenant la logique métier de l’application. Les services interagissent avec la couche de données par l’intermédiaire des repositories, • api.utils ; regroupe les classes utilitaires qui permettent de réaliser certains traitements récurrents, • api.validators ; contient les classes de validation permettant de contrôler les données envoyées par le client. 4.3 Diagrammes de classes Dans cette section, nous commençons par montrer l’ensemble des classes qui correspondent à chaque couche. 4.3.1 Diagramme de classe de la couche entité (api.entities) Le diagramme de classe de la couche entité est illustré par la figure 4.4. Figure 4.4 : Diagramme de classe de la couche entité 40
55. Chapitre 4. Architecture et conception détaillée Ce diagramme est composé des classes suivantes ; • User ; c’est une entité qui contient les informations relatives à un utilisateur de l’application, • Node ; une entité qui représente un nœud et qui en-capsule les informations relatives aux serveurs d’application inscrits au système, • Stream ; c’est l’entité qui contient les données qui correspondent à un regroupement d’évènements selon un certain critère, • Event ; définit les valeurs d’attributs relatives à un évènement provenant de la librairie du logger, • Level ; définit les niveaux de sévérité relatifs à un évènement, • UserDetails ; c’est une classe qui appartient au framework "Spring". 4.3.2 Diagramme de classe de la couche repository (api.repositories) Le diagramme de classe de la couche repository est illustré par la figure 4.4. C’est une couche d’abstraction basée sur le framework "Spring Data" qui permet d’exécuter certaines opérations basiques et simplifier l’accès aux données. En ayant recours à cette couche, nous minimisons l’effort d’implémentation des méthodes CRUD. Figure 4.4 : Diagramme de classe de la couche repository 41
56. Chapitre 4. Architecture et conception détaillée • L’interface MongoRepository ; c’est l’interface mère de toutes les interfaces repositories qui offre un ensemble d’opérations CRUD qui seront utilisées avec une base de données "MongoDB". Chaque interface dispose de ses propres méthodes spécifiques à l’entité. • L’interface PageAndSortingRepository ; c’est l’interface mère de l’interface EventRepository et qui implémente un système de pagination des résultats retournés. • Autres interfaces ; ce sont les interfaces responsables de communiquer avec la couche entité. 4.3.3 Diagramme de classe de la couche service (api.services) La couche service illustrée par la figure 4.5 est la couche intermédiaire entre la couche présentation et celle qui est en communication avec la base de données. Elle présente la logique métier de notre application. Figure 4.5 : Diagramme de classe de la couche service 42
57. Chapitre 4. Architecture et conception détaillée Cette couche contient un service pour chaque entité du système ; • UserDetailsService ; une interface fournit par le framework "Spring Security" afin de gérer l’authentification des utilisateurs. • UserService ; c’est un service qui contient les opérations d’identification d’un utilisateur dans le système. • Autres services ; des services qui englobent des méthodes spécifiques afin de réaliser des opérations relatives à une entité. • AuthentificationProvider ; c’est l’interface qui définit la méthode qui permet d’authentifier un utilisateur. • SecurityConfig ; c’est une classe qui appartient au framework "Spring Security" et qui fournit la configuration relative à la sécurité de l’application. 4.3.4 Diagramme de classe de la couche contrôleur (api.controllers) La couche contrôleur est une sous-couche de la couche présentation qui est la partie frontale face aux requêtes des clients. Elle fournit les résultats retournés par la couche métier. La figure 4.6 montre les différentes classes de cette couche. Figure 4.6 : Diagramme de classe de la couche contrôleur 43
58. Chapitre 4. Architecture et conception détaillée Cette couche contient des contrôleurs qui représentent les points d’entrées pour un client ; • HomeController ; c’est le contrôleur qui contient les points d’entrées pour les requêtes génériques qui servent à l’auto documentation ainsi que l’api de réflexion, • ErrorController ; responsable de gérer les erreurs HTTP retournées par l’application et transformer la réponse native du système en une réponse personnalisée, • EventController ; comme son nom l’indique, c’est le contrôleur qui fournit les points d’entrées afin de diffuser les évènements vers le système, • Autres contrôleurs ; ce sont les contrôleurs qui contiennent les points d’entrée afin de gérer les entités du système. 4.3.5 Diagramme de classe de la couche aspects (api.aspects) La couche aspects contient un ensemble de classes composantes relatives aux couches contrôleur, service et repository. Leur rôle est d’exécuter un certain traitement suite à la détection des évènements nommés "joinpoints". Ces composants utilisent l’interface du "logger" pour générer les logs suite à l’exécution d’une méthode qui appartient à une des couches déjà mentionnées dans la partie qui précède. Les évènements du "logger" sont redirigés vers le réseau Blockchain grâce au module BlockchainAppender. La figure 4.7 montre les différentes classes de cette couche. Figure 4.7 : Diagramme de classe de la couche aspects 44
59. Chapitre 4. Architecture et conception détaillée Cette couche contient les classes suivantes ; • ControllerAspect ; c’est une classe aspect qui détecte l’exécution des méthodes qui appartiennent aux différents contrôleurs de l’application grâce aux "joinpoints", • OneMethodAspect ; c’est un composant Spring responsable de générer un évènement du log suite à l’exécution d’une méthode bien précise, • Autres aspects ; ce sont des classes aspect qui permettent de détecter l’exécution des méthodes qui appartiennent aux couches service et repository, ensuite générer des évènements du log. • L’interface Logger ; c’est une interface qui appartient à la librairie du logger permettant de générer les logs. • BlockchainAppender ; c’est le module responsable de la redirection des évènements vers le réseau Blockchain. Ce module est une sorte d’extension pour la librairie du logger pouvant être intégré dans des applications serveurs tierces et qui définit un certain traitement personnalisé. 4.3.6 Diagramme de classe de la couche utilis (api.utils) La couche utilis contient un ensemble de classes utilitaires permettant de réaliser certains traitements récurrents. Parmi les traitements réalisés, il y a la conversion des classes modèles et la détection des attributs des classes entités au moment de l’exécution. Cette couche contient les classes suivantes ; • Conversion ; c’est une classe utilitaire permettant la conversion des modèles de données appelés DTO vers des entités et inversement, • Conversion ; la classe utilitaire qui assure l’envoie des évènements via l’interaction avec les modules installés dans les nœuds du réseau Blockchain, • FormUtils ; une classe utilitaire qui permet de détecter les attributs des classes entités tenant compte de leurs types, des annotations qui les précèdent, ainsi que les modificateurs de la portée, • Form ; c’est une classe java qui représente les données d’une entité. Elle est composée des attributs d’une classe entité, • FormFieldValue ; c’est la classe qui représente les valeurs par défaut des attributs, • FormFieldLabel ; c’est la classe qui représente les noms des attributs, • FormFieldDropDown ; c’est une classe particulière qui vise les attributs de type énuméré. 45
60. Chapitre 4. Architecture et conception détaillée La figure 4.8 montre les différentes classes de cette couche. Figure 4.8 : Diagramme de classe de la couche utils 4.3.7 Diagramme de classe de la couche validators (api.validators) La couche validators contient les validateurs de données envoyées par le client. Cette couche est responsable du contrôle de flux entrant vers le système en vérifiant si les données respectent certaines contraintes et règles mises par le système. Cette couche contient les classes suivantes ; • NameValidator ; c’est une classe de validation qui s’assure de l’unicité du nom d’un évènement lors du traitement de la requête, • PublicIpValidator ; c’est une classe de validation qui permet de vérifier le format d’une adresse 46
61. Chapitre 4. Architecture et conception détaillée IP ainsi que l’unicité, • ConstraintValidator ; une interface fournit par le framework "Spring" permettant de réaliser certains tests sur les données au moment du traitement de la requête. La figure 4.9 montre les différentes classes de cette couche. Figure 4.9 : Diagramme de classe de la couche validators 4.3.8 Diagramme de classe de test de la couche repository (api.repositories) Le diagramme de classe de test de la couche repository est illustré par la figure 4.10. Il représente l’ensemble des classes de test unitaire permettant de tester les méthodes de base d’une classe repository. Figure 4.10 : Diagramme de classe de test de la couche repository 47
62. Chapitre 4. Architecture et conception détaillée • UserRepositoryUnitTest ; c’est la classe de test unitaire relative à l’interface UserRepository qui permet de gérer les utilisateurs du système, • StreamRepositoryUnitTest ; une classe de test unitaire relative à l’interface StreamRepository permettant de tester les opérations de base sur les regroupements d’évènements, • NodeRepositoryUnitTest ; une classe de test unitaire relative à l’interface NodeRepository permettant de vérifier la demande, l’ajout, la mise à jour, et la suppression d’un nœud, • EventRepositoryUnitTest ; une classe de test unitaire relative à l’interface EventRepository. 4.3.9 Diagramme de classe de test de la couche service (api.services) Le diagramme de classe de test de la couche service est illustré par la figure 4.11. Il représente l’ensemble des classes de test unitaire permettant de tester les méthodes de base d’une classe service. Figure 4.11 : Diagramme de classe de test de la couche service 48
63. Chapitre 4. Architecture et conception détaillée Ce diagramme contient une classe de test pour chaque service ; • UserServiceUnitTest ; c’est la classe de test unitaire qui fournit des méthodes de test pour la classe UserService, • UserRepositoryMock ; c’est une interface permettent de simuler le comportement de la classe originale UserRepository utilisée pour des fins de test, • Pageable ; une interface qui permet de transformer le résultat retourné en un ensemble de pages, 4.3.10 Diagramme de classe de test de la couche contrôleur (api.controllers) Le diagramme de classe de test de la couche contrôleur est illustré par la figure 4.12. Il représente l’ensemble des classes de test unitaire et d’intégration qui permet de s’assurer du bon fonctionnement du système en vérifiant le résultat retourné pour chaque requête. Ce diagramme contient une classe de test unitaire et d’intégration pour chaque contrôleur ; • StreamControllerUnitTest ; une classe de test unitaire permettant de vérifier les résultats retournés par les méthodes du contrôleur StreamController, • MockMvc ; c’est une interface fournit par le framework "Spring" afin de simuler l’exécution d’une méthode du contrôleur, • StreamServiceMock ; une interface mock qui sert à simuler les appels au service StreamService par le contrôleur, • NodeControllerTest ; c’est une classe de test d’intégration, qui permet de s’assurer du bon fonctionnement du système en ce qui concerne les opérations sur les nœuds, • EventControllerTest ; une classe de test d’intégration pour simuler la diffusion des évènements, • TestRestTemplate ; une interface fournit par le framework "Spring" afin de simuler les requêtes d’un client REST. 49
64. Chapitre 4. Architecture et conception détaillée Figure 4.12 : Diagramme de classe de test de la couche contrôleur 50
65. Chapitre 4. Architecture et conception détaillée 4.4 Aspect dynamique C’est la vue du système qui permet de visualiser les interactions entre les objets de la couche logicielle. Pour modéliser cette vue, nous avons eu recours au diagramme de séquence objets qui montre les échanges entre les objets sur un axe temporel. Dans cette section nous montrons les diagrammes de séquence objets des cas d’utilisation ; « Créer Nœud », « Modifier Stream », « Diffuser Logs », « Gérer Secrets ». 4.4.1 Créer Nœud La figure 4.13 illustre le scénario d’exécution du cas d’utilisation création du nœud. Figure 4.13 : Diagramme de séquence objet du cas d’utilisation « Créer Nœud » 51
66. Chapitre 4. Architecture et conception détaillée 4.4.2 Modifier Stream La figure 4.14 illustre le scénario d’exécution du cas d’utilisation modification du stream. Figure 4.14 : Diagramme de séquence objet du cas d’utilisation « Modifier Stream » 52
67. Chapitre 4. Architecture et conception détaillée 4.4.3 Diffuser Logs La figure 4.15 illustre le scénario d’exécution du cas d’utilisation diffusion des logs. Figure 4.15 : Diagramme de séquence objet du cas d’utilisation « Diffuser Logs » 4.4.4 Gérer Secrets La figure 4.16 illustre le scénario d’exécution du cas d’utilisation gestion des secrets. 53
68. Chapitre 4. Architecture et conception détaillée Figure 4.16 : Diagramme de séquence objet du cas d’utilisation « Gérer Secrets » 54
69. Chapitre 4. Architecture et conception détaillée Conclusion Nous avons essayé dans ce chapitre de faire une conception de la solution envisagée en présentant d’abord une architecture générale et ensuite la détailler en s’appuyant sur des diagrammes de classes. Nous commençons dans le chapitre 5, la partie réalisation de la solution. 55
70. Chapitre 5 Réalisation Plan 1 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . 57 2 Principaux de développement . . . . . . . . . . . . . . . . . . . . . . . . . 60
71. Chapitre 5. Réalisation Introduction Dans cette partie, nous entamons la phase de réalisation de l’application où nous allons passer à l’implémentation de tout ce que nous avons conçu dans les chapitres qui précèdent. Nous commençons en premier lieu par la description de l’environnement matériel et logiciel puis en second lieu, l’exposition du travail réalisé avec des captures d’écran à l’appui tout en détaillant les différentes fonctionnalités de l’application. 5.1 Environnement de développement 5.1.1 Environnement Matériel • marque ; DELL OptiPlex 5050, • processeur ; CORE I7-7700 3.6GHz, • capacité de disque dur ; 1 To, • RAM ; 16.0 G0, • système d’exploitation ; Windows 10 x64. 5.1.2 Environnement Logiciel L’implémentation au niveau technique de notre projet a nécessité l’utilisation d’un certain nombre de logiciels illustré par la figure 5.1. Figure 5.1 : Environnement Logiciel » 57
72. Chapitre 5. Réalisation 5.1.2.1 MongoDB Compass C’est un logiciel qui fournit une interface graphique utilisateur pour MongoDB permettant de gérer les différents composants d’une base de données NoSQL tels que les collections et les documents, en les explorant visuellement et exécutant des requêtes en ayant recours à des fonctionnalités CRUD prédéfinies.[3] 5.1.2.2 Git Un logiciel de gestion de versions qui permet à une équipe de collaborer entre eux et travailler sur un même code source en fournissant des méthodes pour la gestion des conflits. Des termes comme "commit", "merge", "branch", "master", "push", "pull", font partie du jargon du Git. Il existe plusieurs logiciels libres qui sont basés sur Git comme GitLab qui propose des fonctionnalités comme le système de suivi des bugs et l’intégration continue.[4] 5.1.2.3 Visual Studio Code Un éditeur de code source qui permet une visualisation meilleure d’un code écrit en un langage de programmation pris en charge par l’éditeur. Il fournit des fonctionnalités comme la coloration syntaxique et l’analyse statique du code. Ainsi VScode est l’un des éditeurs de code source les plus utilisés grâce à la possibilité de faire étendre les fonctionnalités natives en ajoutant des extensions à l’éditeur.[5] 5.1.3 Technologies de programmation Dans cette partie, nous avons eu recours à un certain nombre de langages de programmation permettant de développer les modules logiciels de notre application. 5.1.3.1 Java Java est un langage de programmation orienté objet fortement typé qui nécessite une machine virtuelle afin d’exécuter le code qui est le résultat de la compilation du code source. Il est équipé d’un ensemble de librairies qui sont intégrées nativement dans le kit de développement java appelé JDK. Nous avons utilisé ce langage pour le développement de la partie back-end qui s’exécute par l’interface serveur.[6] 58
73. Chapitre 5. Réalisation 5.1.3.2 Node.js Il peut être considéré comme un nouveau langage de programmation qui ressemble syntaxiquement au fameux langage JavaScript. Il est particulièrement doté d’une API permettant de communiquer directement avec un système d’exploitation grâce à un interpréteur Node.js multiplate-forme utilisant les fonctionnalités offertes par le moteur V8 de chrome. Nous avons utilisé ce langage afin d’organiser le processus de construction de la partie front-end, ainsi que le développement d’une interface en ligne de commande destinée à réaliser certaines tâches récurrentes.[7] 5.1.3.3 TypeScript Un langage de programmation qui permet de développer les fonctionnalités d’une application front-end. Ce langage est transpilé vers le langage JavaScript afin de pouvoir être interprété par les navigateurs qui jusqu’à nos jours ne permettent pas d’exécuter nativement ce langage. 5.1.4 Frameworks et outils Dans le but de réaliser notre projet, nous avons utilisé aussi un ensemble de frameworks et de librairies. 5.1.4.1 Spring Boot Spring Boot est l’un des derniers projets réalisé par l’équipe de développement derrière le framework "Spring". Ce projet vise à aider les développeurs afin de mieux se focaliser sur les fonctionnalités et la logique métier de l’application, au lieu de se soucier de la configuration et la gestion des conflits de versions entre les différentes dépendances ainsi que le déploiement de l’application. Spring Boot fournit des regroupements de dépendances préalablement définis pour chaque type de projet qui permettent de profiter des différentes librairies du framework "Spring".[8] 5.1.4.2 BigchainDB C’est un module logiciel parmi trois autres modules permettant l’implémentation de notre réseau Blockchain. Il est responsable de concevoir l’état de machine et l’ensemble des transitions possibles d’un système à un état particulier. Ce module s’intègre avec le module Tendermint. 59
74. Chapitre 5. Réalisation 5.1.4.3 Tendermint Tendermint est le module le plus important parmi les modules du réseau Blockchain, car c’est celui qui permet de faire le consensus entre les nœuds du réseau grâce à un système de vote. 5.1.4.4 MongoDB MongoDB est une base de données NoSQL que nous avons utilisé afin de stocker les données locales à l’interface serveur ainsi que les données de la chaîne. 5.1.4.5 Angular Angular est un framework front-end permettant de réaliser des interfaces web réactives grâce aux mécanismes de virtualisation du DOM fournis par ce dernier. Il est doté d’une architecture de programmation déclarative utilisant les composants. Parmi les patrons de conception sur lesquels se base le framework Angular il y a le MVVM pattern. 5.1.4.6 Bootstrap Bootstrap est une collection de classes CSS préalablement définies aidant un développeur à la création des applications web. Il est compatible avec les nouvelles versions des navigateurs comme aux anciennes versions et permet de transformer le processus de développement web en un processus simple et rapide. C’est un ensemble de bibliothèques qui est open source. 5.2 Principaux de développement Nous allons présenter dans cette partie un ensemble de captures d’écran afin de donner une vue globale et une idée générale sur les différentes fonctionnalités de l’application. 5.2.1 Interaction avec le réseau Blockchain Dans cette section, nous allons voir les moyens d’interaction avec les modules du réseau Blockchain. 5.2.1.1 Configuration du réseau Blockchain Dans le but de configurer notre réseau, nous devons mettre en place un fichier de configuration relatif au module BigchainDB montré par la figure 5.2 qui définit les connexions avec les serveurs de 60
75. Chapitre 5. Réalisation base de données, le serveur WebSocket et le module Tendermint. Figure 5.2 : Configuration par défaut du module BigchainDB Ensuite, nous passons à la configuration du module Tendermint qui va établir les connexions P2P entre les différents nœuds du réseau. La figure 5.3 présente l’un des fichiers de configuration de ce dernier appelé « genesis.json ». Ce fichier de configuration définit les contraintes sur les blocs et les transactions ainsi que les validateurs participants dans le consensus. 61
76. Chapitre 5. Réalisation Figure 5.3 : Configuration par défaut du module Tendermint 62
77. Chapitre 5. Réalisation 5.2.1.2 End-points testés avec l’API REST du module BigchainDB L’end-point « GET transactionId » permet de retourner la transaction ayant l’identifiant mentionné dans les paramètres. Figure 5.4 : Réponse de l’end-point « GET transactionId » 63
78. Chapitre 5. Réalisation L’end-point « GET transactions assetId » permet de retourner la liste des transactions ayant l’identifiant de l’asset mentionné dans les paramètres. Figure 5.5 : Réponse de l’end-point « GET transactions assetId » 64
79. Chapitre 5. Réalisation L’end-point « POST transactions mode » permet d’envoyer une transaction vers le réseau Blockchain en choisissant le mode qui peut être soit "async", soit "sync", soit "commit". Figure 5.6 : Requête de l’end-point « POST transactions mode » 5.2.1.3 End-points testés avec l’API REST du module Tendermint L’end-point « GET block height » permet de retourner un bloc ayant la hauteur de bloc mentionnée dans les paramètres. 65
80. Chapitre 5. Réalisation Figure 5.7 : Réponse de l’end-point « GET block height » 66
81. Chapitre 5. Réalisation L’end-point « GET genesis » permet de retourner le fichier genesis. Figure 5.8 : Réponse de l’end-point « GET genesis » L’end-point « GET transaction hash » permet de retourner la transaction en précisant le hash. Figure 5.9 : Réponse de l’end-point « GET transaction hash » 67
82. Chapitre 5. Réalisation L’end-point « GET validator height » permet de retourner le validateur d’un bloc en précisant la hauteur. Figure 5.10 : Réponse de l’end-point « GET validator height » 5.2.2 Réalisation des fonctionnalités procurées à l’administrateur Dans cette section, nous présentons le module front-end qui regroupe un ensemble de fonctionnalités proposées à l’administrateur. 5.2.2.1 Gestion des nœuds du réseau L’administrateur peut accéder à une interface qui permet de choisir un nœud afin d’exécuter des opérations de type CRUD sur les nœuds et d’avoir un aperçu sur les streams, illustrée par les figures 5.11 et 5.12. Figure 5.11 : Interface de gestion des nœuds 68
83. Chapitre 5. Réalisation Figure 5.12 : Interface aperçu de stream 5.2.2.2 Gestion des regroupements d’évènements L’administrateur peut accéder à une interface qui permet de choisir un stream afin d’exécuter des opérations de type CRUD sur les streams et d’avoir un aperçu sur les évènements, illustrée par les figures 5.13 et 5.14. Figure 5.13 : Interface de gestion des streams 69
84. Chapitre 5. Réalisation Figure 5.14 : Interface aperçu d’évènement 5.2.2.3 Gestion des évènements diffusés par les applications serveurs Cette interface procure à l’administrateur un aperçu des évènements par niveau de sévérité et par regroupement d’évènements illustrée par les figures 5.15 et 5.16. 70
85. Chapitre 5. Réalisation Figure 5.15 : Interface aperçu d’évènements par niveau de sévérité Figure 5.16 : Interface aperçu d’évènements par regroupement d’évènements 5.2.2.4 Tableau de bord Une page d’accueil qui permet de donner une vision globale sur l’ensemble des entités gérées par le système illustrée par les figures 5.17 et 5.18. 71
86. Chapitre 5. Réalisation Figure 5.17 : Interface dashboard 1 Figure 5.18 : Interface dashboard 2 5.2.2.5 Gestion des secrets Cette partie de l’application illustrée par la figure 5.19 est destinée pour l’envoi des secrets vers le réseau Blockchain tout en cryptant les données ainsi que les clés de cryptage. Il suffit de télé-charger le fichier contenant les informations. 72
87. Chapitre 5. Réalisation Figure 5.19 : Interface gestion des secrets 5.2.2.6 Autres aspects non fonctionnels Notre module front-end est responsive, personalisable en temps réel et restreint au niveau de l’accès. Ceci est illustré par les figures 5.20, 5.21 et 5.22. Figure 5.20 : Interface responsive 73
88. Chapitre 5. Réalisation Figure 5.21 : Interface de paramétrage Figure 5.22 : Interface d’authentification 5.2.3 Réalisation des fonctionnalités procurées une application serveur Dans cette partie, nous montrons les fonctionnalités qui sont offertes à une application serveur. 5.2.3.1 Diffusion des évènements La diffusion des évènements se fait grâce à un module que nous avons développé et qui s’intègre au niveau des librairies de log. Son rôle est de rediriger tous les évènements du journal d’application qui sont générés par le système vers le réseau Blockchain par l’intermédiaire de l’interface serveur. Ce fichier est exposé par la figure 5.23. 74
89. Chapitre 5. Réalisation Figure 5.23 : BlockchainAppender.java Conclusion Ce dernier chapitre a été consacré pour l’exposition de la partie réalisation avec son environnement logiciel et matériel, en se basant sur des captures écran relatives aux interfaces utilisateurs. 75
90. Conclusion générale La réalisation de notre projet de fin d’études s’est déroulé au sein de l’entreprise Be-softilys. Notre mission est la conception et l’implémentation d’une interface serveur qui permet la gestion des évènements des journaux des applications serveurs utilisant la technologie de la Blockchain. Pour commencer, nous avons été confrontés à un ensemble de défis ; la création d’un module back-end qui représente une interface serveur permettant la redirection des évènements vers le réseau Blockchain, un module front-end offert à l’administrateur pour pouvoir gérer graphiquement les entités, ainsi que l’implémentation du réseau Blockchain. Afin d’atteindre nos objectifs, nous avons entamé notre travail par l’étude préalable des aspects les plus importants qui concernent l’ensemble de notre projet et les différentes technologies utilisées. Ensuite, nous avons extrait les besoins fonctionnels et non fonctionnels suivis de l’élaboration d’une architecture générale et la conception détaillée des différents composants du système. La dernière étape a été la phase de réalisation de notre application qui consiste à passer à l’implémentation technique en se basant sur les technologies choisies. Notre période de stage a été très enrichissante au niveau de la recherche et des technologies testées. Elle a été une très bonne opportunité pour découvrir la technologie de la Blockchain, qui est considérée comme l’une des technologies innovantes avec une utilisation croissante chez les grandes firmes qui s’intéressent à la sécurisation des données sensibles. Ce projet nous a permis aussi de voir en profondeur les différentes techniques afin de protéger l’accès aux informations et garantir leur intégrité et confidentialité. Par ailleurs, ce stage a été bénéfique au niveau de l’intégration au sein d’une entreprise et ainsi que le travail et la collaboration avec les membres d’un groupe. Enfin, nous pensons que nous avons consacré tous nos efforts afin d’atteindre les objectifs fixés par l’entreprise dans ce projet. Comme perspectives, nous devons faire l’intégration du module de diffusion des logs au niveau de toutes les applications serveurs existantes au sein du réseau et substituer l’architecture centralisée (serveur central) par une architecture décentralisée pour le stockage des données sensibles. 76
91. Bibliographie [1] B. SOFTILYS. (2018). La marque du groupe be-ys dédiée à l’édition et au développement logiciel. [Accès le 31-Mai-2019], Linkedin, adresse : https://www.linkedin.com/company/be- softilys/about/. [2] O. E. OUDI. (Février. 2019). L’éditeur de logiciels be-softilys célèbre son premier anniversaire et affiche ses ambitions. [Accès le 31-Mai-2019], Ilboursa, adresse : https://www.ilboursa.com/ marches/l-editeur-de-logiciels-be-softilys-celebre-son-premier-anniversaire- et-affiche-ses-ambitions_16135. [3] TYLER. (Janvier. 2018). MongoDB Atlas Intro to MongoDB Compass Community Tool 7 of X. [Accès le 20-Mai-2019], Medium, adresse : https://medium.com/@tyler_48883/mongodb- atlas-intro-to-mongodb-compass-community-tool-7-of-x-1607e14cd804. [4] M. NEBRA. (Octobre. 2017). Gérez vos codes source avec Git. [Accès le 20-Mai-2019], Openclassrooms, adresse : https://openclassrooms.com/fr/courses/1233741-gerez-vos-codes-source- avec-git. [5] A. CROCHET-DAMAIS. (Février. 2019). Visual Studio Code, l’IDE open source que les devs s’arrachent. [Accès le 20-Mai-2019], Journaldunet, adresse : https://www.journaldunet.com/ web-tech/developpeur/1204957-visual-studio-code-l-ide-open-source-que-les- devs-s-arrachent/. [6] C. HERBY. (Octobre. 2019). Apprenez à programmer en Java. [Accès le 20-Mai-2019], Openclassrooms, adresse : https://openclassrooms.com/fr/courses/26832-apprenez-a-programmer-en- java. [7] M. NEBRA. (Décembre. 2018). Des applications ultra-rapides avec Node.js. [Accès le 20-Mai-2019], Openclassrooms, adresse : https : / / openclassrooms . com / fr / courses / 1056721 - des - applications-ultra-rapides-avec-node-js/1056866-node-js-mais-a-quoi-ca-sert. [8] S. AMAR. (Août. 2018). Découvrez le framework Spring Boot. [Accès le 20-Mai-2019], Openclassrooms, adresse : https://openclassrooms.com/fr/courses/4668056-construisez-des-microservices/ 5122425-decouvrez-le-framework-spring-boot. 77
92. Annexes Annexe 1. Entreprise La figure annexe 1.1 présente le logo entreprise. Figure annexe 1.1 : Logo d’entreprise 78
93. .Be-softilys BigchainDB .Blockchain .Blockchain Tendermint .Angular Spring Boot Blockchain, Spring Boot, Angular, BigchainDB, Tendermint : Résumé Ce rapport est le fruit d’un travail tout au long d’une période de stage chez l’entreprise Be-softilys. Notre travail concerne la mise en place d’un système qui permet de gérer les évènements des journaux des applications serveurs en se basant sur la technologie de la Blockchain. Afin d’im- plémenter ce système nous avons eu recours à un ensemble de technologies comme le framework BigchainDB et Tendermint qui permettent de créer un réseau Blockchain. Ensuite, nous avons créé une interface serveur et une interface homme-machine permettant la communication avec le réseau utilisant respectivement le framework Spring Boot et Angular. Mots clés : Blockchain, Spring Boot, Angular, BigchainDB, Tendermint Abstract This report is the result of a work throughout a period of internship at the company Be-softilys. Our job is to set up a system to manage server application log events based on Blockchain tech- nology. In order to implement this system we have used a set of technologies like the BigchainDB and Tendermint framework that allow to create a Blockchain network. Then, we created a server interface and a human-machine interface allowing communication with the network using the Spring Boot and Angular framework respectively. Keywords : Blockchain, Spring Boot, Angular, BigchainDB, Tendermint contact@be-softilys.com : ** *** *** : 70 028 621 : Z.A. Kheireddine, La Goulette, Tunisie Tél : 70 028 621 Fax : ** *** *** Email : contact@be-softilys.com isi@isim.rnu.tn : 71 706 698 : 71 706 164 : 2080 2 2, Abou Raihane Bayrouni 2080 l’Ariana Tél : 71 706 164 Fax : 71 706 698 Email : isi@isim.rnu.tn