Rapport Final - Amani

Traduit de Anglais vers Français - www.onlinedoctranslator.
com
2019 - 2020
INFORMATIQUE
Mise en place et déploiement du système de

gestion de la sécurité de l'information (SGSI)
Réalisé par : Harizi Amani
Superviseurs :
 ESPRIT: Dr Aouini Imen
 QWEEBY : Monsieur Mersel Dalí

Signature de
La Directrice Académique, Dr.Imen Aouini
Signature de
Le superviseur professionnel, M.Dali Mersel

4 novembre 2020
Dalí MERSEL
Dalí MERSEL
En tant que superviseur professionnel d'Amani pendant ce stage, je voudrais partager avec vous
mon point de vue. Amani a été une étudiante brillante tout au long de ce stage. Elle a en effet une
très bonne éthique de travail et suit bien les consignes. Elle apprend aussi vite et est capable de se
lancer très rapidement dans le sujet. Elle a terminé les tâches comme demandé et en a fait
d'autres. Ce fut un plaisir de travailler avec Amani. Je lui souhaite le meilleur dans son
cheminement privé/professionnel.
Dédicaces
Chaque travail difficile nécessite des efforts personnels ainsi que les
conseils des aînés, en particulier ceux qui étaient très proches de notre
cœur.
Mon humble effort que je consacre à
Ma mère Nadia
Pour avoir été mon premier professeur, une femme forte et douce qui
m'a appris à faire confiance à Dieu et à croire au travail acharné.
Mon père Fathi
Pour gagner honnêtement notre vie pour nous et pour nous soutenir et
nous encourager.
Mes chers frères Mazen et Mohamed
pour leur soutien et leur amour.
A toute ma famille.
A tous mes amis pour leur soutien et leur amitié.
A tous ceux que j'aime et à tous ceux qui m'aiment.
A tous ceux qui m'ont aidé et j'ai oublié de mentionner .

Amani Harizi.
Reconnaissance
Je tiens à exprimer ma plus profonde gratitude à tous ceux qui ont
contribué de près ou
Loin du dénouement de ce travail en particulier :
Mon superviseur chez QWEEBY, M. Dali Mersel, pour
m'encourageant à faire un travail correct et efficace
Travail. Son aide infinie et ses grands efforts m'ont fourni le parfait
environnement pour terminer mon travail.
Mon encadrant à l'Ecole Supérieure Privée d'Ingénieurs et de Technologie
ESPRIT, Dr Imen Aouini pour les conseils et l'assistance qu'elle m'a apportés
dans la réalisation de ce travail.
Les membres du jury qui ont évalué mon travail avec leur sagesse et
Connaissance.
Et je tiens à remercier tous ceux qui ont contribué d'une manière ou

un autre au bon déroulement de mon stage.
Table des matières

Introduction générale ........................................................................................................................................... 1
CHAPITRE 1 : CONTEXTE GÉNÉRAL ................................................................................................3
introduction .......................................................................................................................................................... 4
1 Contexte du projet...................................................................................................................................... 4
2 Organisme d'accueil ................................................................................................................................... 4
2.1 Présentation générale ......................................................................................................................... 4
2.2 L'organisation de Qweeby .................................................................................................................. 5
3 Etat de l'existant......................................................................................................................................... 6
4 Énoncé du problème .................................................................................................................................. 7
4.1 Énoncé du problème Sprint 1 ............................................................................................................. 7
5 Notre solution ............................................................................................................................................ 9
5.1 Solution Sprint 1.............................................................................................................................. 10
5.2 Solution Sprint 2.............................................................................................................................. 10
5.3 Solution Sprint 3.............................................................................................................................. 12
6 Choix de la méthodologie ........................................................................................................................ 12
6.1 Choix de la méthodologie ................................................................................................................ 13
6.2 Présentation de SCRUM .................................................................................................................. 13
6.3 Rôles de l'équipe.............................................................................................................................. 14
Conclusion .......................................................................................................................................................... 15
CHAPITRE 2 : ÉTAT DE L'ART ....................................................................................................... 16
introduction ........................................................................................................................................................ 17
1 Système de gestion .................................................................................................................................. 17
1.1 modèle PDCA ................................................................................................................................. 17
1.2 Système de gestion de la sécurité de l'information ............................................................................ 18
1.3 Sécurité des informations................................................................................................................. 19
2 Processus de mise en œuvre du SMSI ....................................................................................................... 19
2.1 Phase du plan PDCA ....................................................................................................................... 20
2.1.1 La portée du SMSI ...................................................................................................................... 20
2.1.2 L'évaluation des risques ............................................................................................................... 20
2.1.3 Traitement des risques ................................................................................................................. 20
2.2 Phase d'exécution du PDCA............................................................................................................. 21
2.2.1 Plan de traitement des risques ...................................................................................................... 21
2.2.2 Mise en œuvre du SMSI .............................................................................................................. 21
2.2.3 Maintenance du SMSI ................................................................................................................. 22
2.3 Phase de contrôle PDCA.................................................................................................................. 22
2.3.1 Évaluation du SMSI .................................................................................................................... 22
2.3.2 Audits internes ............................................................................................................................ 22
2.3.3 revues de direction ...................................................................................................................... 22
2.4 Phase d'acte PDCA .......................................................................................................................... 22
2.4.1 mesures correctives ..................................................................................................................... 23
2.4.2 Actions d'amélioration ................................................................................................................. 23
3 Normes ISO/CEI 27000 ........................................................................................................................... 23
3.1 ISO/CEI 27001 ................................................................................................................................ 24
3.2 ISO/CEI 27002 ................................................................................................................................ 25
3.3 ISO/CEI 27003 ................................................................................................................................ 26
3.4 ISO/CEI 27005 ................................................................................................................................ 27
4 Processus de gestion des risques ............................................................................................................... 28
4.1 Établir le contexte............................................................................................................................ 28
4.2 L'évaluation des risques ................................................................................................................... 29
4.2.1 Identification des risques ............................................................................................................. 29
4.2.2 Analyse de risque ........................................................................................................................ 29
4.2.3 Évaluation du risque .................................................................................................................... 30
4.3 Traitement des risques ..................................................................................................................... 30
4.4 Acceptation des risques ................................................................................................................... 31
4.5 Communication des risques ............................................................................................................. 31
4.6 Suivi et revue des risques ................................................................................................................. 32
5 Méthodologies d'évaluation des risques .................................................................................................... 32
5.1 EBIOS............................................................................................................................................. 32
5.2 MEHARI......................................................................................................................................... 33
5.3 CRAMM ......................................................................................................................................... 33
5.4 OCTAVE ........................................................................................................................................ 33
5.5 Comparaison des méthodologies d'analyse des risques ..................................................................... 34
6 Mise en place du SMSI ISO 27001 dans Qweeby ..................................................................................... 34
6.1 Phase de planification ...................................................................................................................... 34
6.1.1 La portée de la mise en œuvre du SMSI ....................................................................................... 34
6.1.2 Politique de sécurité de l'information ........................................................................................... 35
6.1.3 L'évaluation des risques ............................................................................................................... 35
6.1.4 Mesure de sécurité....................................................................................................................... 36
6.2 Faire la phase .................................................................................................................................. 36
6.2.1 Formation et sensibilisation des employés .................................................................................... 36
Conclusion .......................................................................................................................................................... 36
CHAPITRE 3 : PREMIER SPRINT « METTRE EN ŒUVRE UNE SOLUTION D'AUTHENTIFICATION

UNIQUE » .................................................................................................................................. 38
introduction ........................................................................................................................................................ 38
1 Objectif de sprint ..................................................................................................................................... 39
2 Carnet de commandes de sprint ................................................................................................................ 39
3 Branche fonctionnelle .............................................................................................................................. 40
3.1 Identification des acteurs ................................................................................................................. 40
3.2 Exigences fonctionnelles ................................................................................................................. 41
3.3 Prérogatives non fonctionnelles ....................................................................................................... 41
4 Concevoir ................................................................................................................................................ 41
4.1 Diagramme de cas d'utilisation ......................................................................................................... 41
4.2 Diagramme de classes...................................................................................................................... 42
4.3 Diagramme de séquençage............................................................................................................... 43
4.3.1 Autorisation OAuth2 ................................................................................................................... 43
4.3.2 Authentification .......................................................................................................................... 45
5 Branche technique ................................................................................................................................... 46
5.1 Solutions d'authentification unique................................................................................................... 46
5.1.1 Justification du choix :................................................................................................................. 48
5.2 Protocoles d'authentification unique utilisés ..................................................................................... 48
5.2.1 Comparaison des protocoles d'authentification unique .................................................................. 49
5.3 Architecture logique ........................................................................................................................ 51
5.4 Architecture physique ...................................................................................................................... 51
5.5 Choix technologiques ...................................................................................................................... 52
5.5.1 Frameworks et technologies utilisés ............................................................................................. 52
5.5.2 Outils et serveurs d'occasion ........................................................................................................ 53
6 Mise en place et validation du First Sprint ................................................................................................ 54
6.1 Enregistrer une nouvelle application sur Azure AD .......................................................................... 55
6.2 Implémenter un client OAuth 2.0 dans notre application ................................................................... 56
6.3 Mettre en œuvre l'authentification .................................................................................................... 57
6.4 Résultats des tests ............................................................................................................................ 57
Conclusion .......................................................................................................................................................... 61
CHAPITRE 4 : DEUXIÈME SPRINT « METTRE EN ŒUVRE UN SYSTÈME DE POINT DE TERMINAISON

DE GESTION DES IDENTITÉS INTERDOMAINES » .......................................................................... 62
introduction ........................................................................................................................................................ 63
3.3 Prérogatives non fonctionnelles ....................................................................................................... 66
4 Concevoir ................................................................................................................................................ 66
4.1 Diagramme de cas d'utilisation ......................................................................................................... 66
4.2 Diagramme de classes...................................................................................................................... 69
4.3 Diagramme de séquençage............................................................................................................... 70
4.3.1 Système d'autorisation ................................................................................................................. 71
4.3.2 Provisionnement des utilisateurs .................................................................................................. 71
4.3.3 Approvisionnement SCIM ........................................................................................................... 72
5 Branche technique ................................................................................................................................... 73
5.1 Solutions SCIM ............................................................................................................................... 73
5.1.1 Comparatif des solutions SCIM ................................................................................................... 74
5.2 Architecture logique ........................................................................................................................ 74
5.3 Architecture physique ...................................................................................................................... 75
5.4 Choix technologiques ...................................................................................................................... 76
5.4.1 Frameworks et technologies utilisés ............................................................................................. 76
5.4.2 Outils et serveurs d'occasion ........................................................................................................ 76
6 Étapes de développement ......................................................................................................................... 78
6.1 Phase 1 : Concevoir un schéma d'utilisateur et de groupe. ................................................................. 79
6.2 Phase 2 : comprendre l'implémentation d'Azure AD SCIM ............................................................... 82
6.2.1 Requêtes et réponses du protocole SCIM : ................................................................................... 82
6.3 Phase 3 : création d'un point de terminaison SCIM ........................................................................... 83
6.3.1 Gestion de l'authentification des points de terminaison ................................................................. 83
6.4 Phase 4 : Intégrer le point de terminaison SCIM avec le client Azure AD SCIM ............................... 84
6.5 phase 5 : publier l'application dans la galerie d'applications Azure AD.............................................. 85
7 Mise en place et validation du deuxième Sprint ........................................................................................ 85
7.1 Tester la connexion.......................................................................................................................... 85
7.2 Provisionnement des utilisateurs : .................................................................................................... 88
7.2.1 Ajouter un utilisateur ................................................................................................................... 89
7.2.2 Mettre à jour le rôle de l'utilisateur ............................................................................................... 92
7.2.3 Désactiver l'utilisateur ................................................................................................................. 93
7.2.4 Supprimer l'utilisateur ................................................................................................................. 94
Conclusion .......................................................................................................................................................... 95
CHAPITRE 5 : TROISIÈME SPRINT « METTRE EN PLACE UNE SOLUTION DE CENTRALISATION DES

LOGS »....................................................................................................................................... 97
introduction ........................................................................................................................................................ 97
3.3 Prérogatives non fonctionnelles ..................................................................................................... 100
4 Branche technique ................................................................................................................................. 100
4.1 Solutions de gestion des journaux .................................................................................................. 100
4.1.1 Comparatif des solutions de gestion de logs : ............................................................................. 101
4.1.2 Justification du choix :............................................................................................................... 101
4.2 Architecture de vitesse ................................................................................................................... 102
4.3 Choix technologiques .................................................................................................................... 103
4.3.1 Technologies utilisées................................................................................................................ 103
4.3.2 Outils d'occasion ....................................................................................................................... 104
5 Les composants de la pile ELK .............................................................................................................. 104
5.1 Recherche élastique ....................................................................................................................... 104
5.1.1 Présentation d'Elasticsearch ....................................................................................................... 104
5.1.2 Les fonctionnalités d'Elasticsearch ............................................................................................. 104
5.2 Logstash ........................................................................................................................................ 105
5.2.1 Présentation de Logstash ........................................................................................................... 105
5.2.2 Le principe fonctionnel de Logstash........................................................................................... 106
5.3 Kibana........................................................................................................................................... 107
5.3.1 Présentation de Kibana .............................................................................................................. 107
5.3.2 Le principe fonctionnel de Kibana ............................................................................................. 108
6 Mise en place et Validation du troisième sprint ....................................................................................... 108
6.1 Mise en place de l'environnement................................................................................................... 108
6.1.1 Installation de machine virtuelle ................................................................................................ 108
6.2 Installation de la pile ELK ............................................................................................................. 108
6.2.1 Installation de Java 8 ................................................................................................................. 108
6.2.2 Installation d'Elasticsearch ......................................................................................................... 108
6.2.3 Installation de Kibana ................................................................................................................ 109
6.2.4 Installation de Logstash ............................................................................................................. 109
6.3 Configuration de la pile ELK ......................................................................................................... 109
6.3.1 Configuration d'Elasticsearch..................................................................................................... 109
6.3.2 Configuration Kibana ................................................................................................................ 110
6.3.3 Configuration de Logstash ......................................................................................................... 110
6.4 Analyse du journal......................................................................................................................... 110
6.4.1 Configurations de script de journal ............................................................................................ 110
6.4.2 Test d'analyse de log.................................................................................................................. 111
Conclusion ........................................................................................................................................................ 113
Conclusion générale.......................................................................................................................................... 114
Bibliographie .................................................................................................................................................... 115

Liste des figures
FIGURE 1 : LOGO QWEEBY............................................................................................................5
FIGURE 2 : ORGANIGRAMME DE QWEEBY.....................................................................................6
FIGURE 3 : GESTION DES UTILISATEURS DANS L'APPROCHE TRADITIONNELLE ................................8
FIGURE 4 : GESTION DES UTILISATEURS AVEC SCIM..................................................................... 11
FIGURE 5 : PROCESSUS SCRUM [1] .............................................................................................. 15
FIGURE 6 : MODÈLE PDCA APPLIQUÉ AUX PROCESSUS SMSI [3] ................................................... 18
FIGURE 7 : LA FAMILLE D'ISO 27000............................................................................................ 23
FIGURE 8 : PROCESSUS DE GESTION DES RISQUES ....................................................................... 28
FIGURE 9 : MATRICE D'ÉVALUATION DES RISQUES ...................................................................... 30
FIGURE 10 : OPTIONS DE TRAITEMENT DES RISQUES ................................................................... 31
FIGURE 11 : DIAGRAMME DE CAS D'UTILISATION DU PREMIER SPRINT ........................................ 42
FIGURE 12 : DIAGRAMME DE CLASSES DU PREMIER SPRINT ........................................................ 43
FIGURE 13 : DIAGRAMME DE SÉQUENCE D'AUTORISATION OAUTH2 ........................................... 45
FIGURE 14 : DIAGRAMME DE SÉQUENCE D'AUTHENTIFICATION .................................................. 46
FIGURE 15 : LOGO MICROSOFT AZURE........................................................................................ 47
FIGURE 16 : LOGO OKTA ............................................................................................................. 47

FIGURE 17 : LOGO ONELOGIN..................................................................................................... 48
FIGURE 18 : ORGANIGRAMME DES MÉTHODES SSO DANS AZURE AD .......................................... 50
FIGURE 19 : ARCHITECTURE LOGIQUE DU PREMIER SPRINT ......................................................... 51
FIGURE 20 : ARCHITECTURE PHYSIQUE DU PREMIER SPRINT........................................................ 52
FIGURE 21 : LOGO SYMFONY ...................................................................................................... 52
FIGURE 22 : LOGO AZURE AD...................................................................................................... 53
FIGURE 23 : LOGO PHP STORM ................................................................................................... 53
FIGURE 24 : LOGO DU SERVEUR WAMP ...................................................................................... 54
FIGURE 25 : LOGO MICROSOFT TEAMS ....................................................................................... 54
IMAGE 26 : LOGO TRELLO........................................................................................................... 54
FIGURE 27 : INSCRIPTION D'APPLICATION DANS AZURE AD ......................................................... 56
FIGURE 28 : CONFIGURATION DU FOURNISSEUR ......................................................................... 56
FIGURE 29 : PAGE DE CONNEXION À L'APPLICATION ................................................................... 57
FIGURE 30 : LIEN DE REDIRECTION.............................................................................................. 58
FIGURE 31 : PAGE DE CONNEXION DU FOURNISSEUR .................................................................. 58
FIGURE 32 : ENTREZ LES INFORMATIONS D'IDENTIFICATION POUR LE FOURNISSEUR ................... 59
FIGURE 33 : SÉJOUR SIGNÉ EN QUESTION ................................................................................... 59
FIGURE 34 : AUTORISATION DEMANDÉE ..................................................................................... 60
FIGURE 35 : CONNEXION DE L'UTILISATEUR AVEC AZURE AD ....................................................... 60

FIGURE 36 : UTILISATEUR AJOUTÉ À LA BASE DE DONNÉES.......................................................... 61
FIGURE 37 : JOURNAUX DE CONNEXION AZURE AD ..................................................................... 61
FIGURE 37 : DIAGRAMME DE CAS D'UTILISATION DU DEUXIÈME SPRINT...................................... 67
FIGURE 38 : DIAGRAMME DE CLASSES SCIM................................................................................ 70
FIGURE 39 : DIAGRAMME DE SÉQUENCE (SYSTÈME D'AUTORISATION) ........................................ 71
FIGURE 40 : DIAGRAMME DE SÉQUENCE (APPROVISIONNEMENT UTILISATEUR) .......................... 72
FIGURE 41 : DIAGRAMME DE SÉQUENCE (APPROVISIONNEMENT SCIM) ...................................... 73
FIGURE 42 : ARCHITECTURE LOGIQUE SECOND SPRINT ............................................................... 75
FIGURE 43 : ARCHITECTURE PHYSIQUE SECOND SPRINT .............................................................. 75
FIGURE 44 : LOGO DU SERVEUR WEB APACHE ............................................................................ 77
FIGURE 45 : LOGO HEIDI SQL ...................................................................................................... 77
FIGURE 46 : LOGO WINSCP ......................................................................................................... 77
FIGURE 47 : LOGO DU FACTEUR.................................................................................................. 78
FIGURE 48 : APPROVISIONNEMENT SCIM AVEC AZURE AD [14] ................................................... 78
FIGURE 49 : ÉTAPES D'APPROVISIONNEMENT SCIM .................................................................... 79
FIGURE 50 : RESSOURCES SCIM .................................................................................................. 79
FIGURE 51 : SCHÉMA JSON ......................................................................................................... 81
FIGURE 51 : AUTHENTIFICATION DU PORTEUR ............................................................................ 84
FIGURE 52 : GÉNÉRATION DU JETON DU PORTEUR DANS L'APPLICATION WEB............................. 86

FIGURE 53 : CONNEXION DE TEST VALIDE AU POINT DE TERMINAISON SCIM ............................... 87
FIGURE 54 : CONNEXION DE TEST NON VALIDE EN RAISON D'UNE URL DE LOCATAIRE NON VALIDE
................................................................................................................................................. 87
FIGURE 55 : CONNEXION DE TEST NON VALIDE EN RAISON D'UN JETON NON VALIDE .................. 88
FIGURE 56 : DÉMARRER L'APPROVISIONNEMENT ........................................................................ 89
FIGURE 57 : AJOUTER UN UTILISATEUR À L'INTERFACE DES UTILISATEURS ET DES GROUPES ........ 89
FIGURE 58 : AJOUTER UNE AFFECTATION.................................................................................... 90
FIGURE 59 : FOURNITURE À LA DEMANDE POUR AJOUTER UN UTILISATEUR ................................ 90
FIGURE 60 : PROVISION ON DEMAND CRÉE AVEC SUCCÈS UN UTILISATEUR ................................. 91
FIGURE 61 : UTILISATEUR AJOUTÉ À LA BASE DE DONNÉES DE NOTRE APPLICATION .................... 92
FIGURE 62 : JOURNAUX DE PROVISIONNEMENT AZURE AD (CRÉER)............................................. 92
FIGURE 63 : MODIFIER L'UTILISATEUR DANS L'INTERFACE DES UTILISATEURS ET DES GROUPES.... 92
FIGURE 64 : MODIFIER L'AFFECTATION ....................................................................................... 93
FIGURE 65 : EDITÉ PAR L'UTILISATEUR DANS LA BASE DE DONNÉES DE NOTRE APPLICATION........ 93
FIGURE 66 : JOURNAUX DE PROVISIONNEMENT AZURE AD (MISE À JOUR) ................................... 93
FIGURE 67 : SUPPRESSION LOGICIELLE DE L'UTILISATEUR DANS L'INTERFACE UTILISATEURS ET

GROUPES ................................................................................................................................... 94
FIGURE 68 : SUPPRESSION LOGICIELLE DE L'UTILISATEUR DANS LA BASE DE DONNÉES DE NOTRE

APPLICATION ............................................................................................................................. 94
FIGURE 69 : JOURNAUX DE PROVISIONNEMENT AZURE AD (DÉSACTIVER).................................... 94
FIGURE 70 : CRÉER UN UTILISATEUR DE TEST À SUPPRIMER DÉFINITIVEMENT ............................. 95

FIGURE 71 : SUPPRESSION DÉFINITIVE D'UN UTILISATEUR DU FACTEUR....................................... 95
FIGURE 72 : LOGO ELK STACK ................................................................................................... 100
FIGURE 73 : LOGO GRAYLOG .................................................................................................... 101
FIGURE 74 : ARCHITECTURE DU TROISIÈME SPRINT ................................................................... 102
FIGURE 75 : LOGO LOGSTASH ................................................................................................... 103
FIGURE 76 : LOGO ELASTICSEARCH ........................................................................................... 103
FIGURE 77 : LOGO KIBANA........................................................................................................ 104
FIGURE 78 : LOGO VMWARE WORKSTATION............................................................................. 104
FIGURE 79 : PRINCIPE DE FONCTIONNEMENT DU LOGSTASH..................................................... 106
FIGURE 80 : CONFIGURATION D'ELASTICSEARCH....................................................................... 109
FIGURE 81 : CONFIGURATION DE KIBANA ................................................................................. 110
FIGURE 82 : CRÉER UN MODÈLE D'INDEX DANS KIBANA ............................................................ 112
FIGURE 83 : AFFICHER L'INDEX DANS KIBANA............................................................................ 112
FIGURE 84 : TEST D'ANALYSE DU JOURNAL ELK-STACK............................................................... 113

Liste des tableaux
TABLEAU 1 : COMPARAISON DES MÉTHODOLOGIES .................................................................... 13
TABLEAU 2 : COMPARAISON DES MÉTHODES D'ANALYSE DES RISQUES........................................ 34
TABLEAU 3 : BACKLOG DU PREMIER SPRINT ................................................................................ 40
TABLEAU 4 : COMPARAISON DES PROTOCOLES D'AUTHENTIFICATION UNIQUE ........................... 49
TABLEAU 5 : BACKLOG DU DEUXIÈME SPRINT ............................................................................. 65
TABLEAU 6 : DESCRIPTION TEXTUELLE DE « TEST DE LA CONNEXION D'APPROVISIONNEMENT » .. 68
TABLEAU 7 : DESCRIPTION TEXTUELLE DE « PROVISIONNEMENT UTILISATEUR » .......................... 69
TABLEAU 8 : COMPARAISON DES SOLUTIONS SCIM ..................................................................... 74
TABLEAU 9 : DÉCRIVEZ LES ATTRIBUTS NÉCESSAIRES ................................................................... 80
TABLEAU 10 : DÉTERMINER LES CRITÈRES D'ÉVALUATION À DÉVELOPPER.................................... 82
TABLEAU 11 : SCÉNARIOS DE CONNEXION DU DEUXIÈME TEST DE SPRINT ................................... 86
TABLEAU 12 : BACKLOG DU TROISIÈME SPRINT ........................................................................... 99
TABLEAU 13 : COMPARAISON DES SOLUTIONS DE GESTION DES LOGS ....................................... 101

Introduction générale
Aujourd'hui, il est essentiel de maintenir et de garantir la sécurité du système d'information d'une
entreprise par une analyse exhaustive des intrusions possibles, et la protection de son
environnement informatique interne et externe contre toute éventuelle intrusion ou surveillance
malveillante.
Dans ce contexte, la société française QWEEBY nous a fait confiance pour améliorer son système
de sécurité de l'information en concevant et en mettant en œuvre un Système de management de
la sécurité de l'information (SMSI) afin d'obtenir la certification ISO 27001.
La mise en œuvre du SMSI nécessite que l'entreprise se conforme à l'annexe A de la norme ISO
27001. Cette annexe nécessite des mesures et des contrôles de sécurité qui doivent être satisfaits
des solutions techniques que nous réaliserons au cours de ce projet, telles que la mise en œuvre de
certains systèmes de gestion des identités et des accès. (IAM) et autres qui assureront un meilleur
contrôle du stockage des données, empêcheront les accès risqués inutiles, détecteront les menaces
internes et externes et maintiendront la conformité en matière de confidentialité des données.
Ce rapport présente l'ensemble des démarches entreprises pour développer la solution proposée
par l'entreprise. Il contient six chapitres organisés comme suit :
 CHAPITRE 1 : CONTEXTE GÉNÉRAL: présenter une étude introductive du projet,

qui contient une description des produits existants, ses problèmes et la solution proposée.
 CHAPITRE 2 : ETAT DE L'ART: présente les systèmes de gestion de la sécurité de
l'information et les normes ISO.
 CHAPITRE 3 : PREMIER SPRINT « METTRE EN UVRE UN SINGLE SIGN ON
SOLUTION »: présenter l'architecture, l'explication et la mise en œuvre du premier sprint.
1
 CHAPITRE 4 : DEUXIÈME SPRINT « METTRE EN UVRE UN SYSTÈME DE
GESTION DES IDENTITÉS INTERDOMAINES ENDPOINT »: présenter
l'architecture, les étapes de développement et la mise en œuvre du deuxième sprint.
 CHAPITRE 5 : TROISIÈME SPRINT « METTRE EN UVRE UNE SOLUTION DE
CENTRALISATION DES LOGS » : présenter l'architecture, les technologies utilisées
et la mise en œuvre du dernier sprint.
2
Chapitre 1 : Contexte général
3
introduction
Dans ce chapitre, nous commencerons par présenter le contexte général du projet et notre
organisation d'accueil QWEEBY. Ensuite, nous passerons par une étude introductive du projet,
qui contient une description des produits existants, ses problèmes et la solution proposée.
1 Contexte du projet
Le sujet introduit par ce rapport est intitulé « Implémentation et déploiement du système de gestion
de la sécurité de l'information (SMSI) » qui consiste à mettre en œuvre un système de gestion de
la sécurité de l'information au sein de QWEEBY afin d'assurer la confidentialité, l'intégrité et la
disponibilité des informations, des données et des TI de l'organisation. prestations de service.
Il est obtenu pour obtenir le diplôme national d'Ingénieur Informatique à l'Ecole Supérieure Privée
d'Ingénierie et de Technologie ESPRIT pour l'année académique 2019/2020, réalisé à QWEEBY.
Au cours de cette expérience de stage, j'ai pu développer les compétences que j'ai acquises lors de
mes études d'ingénieur, Aussi j'ai eu la chance de les mettre en pratique dans le monde
professionnel.
2 Organisme d'accueil
Dans cette partie, nous allons présenter une présentation générale de l'entreprise et de son
organisation.
2.1 Présentation générale

Qweeby conçoit et exploite des solutions de dématérialisation qui permettent aux entreprises de
dématérialiser leurs factures à des fins fiscales. La dématérialisation permet une transmission
4
tracée et sécurisée des factures au client destinataire sous forme de données directement
exploitables dans ses outils.
C'est un « pure player » sur le marché B to B (business to business) et B to G (business to

gouverner). Autrement dit, Qweeby s'adresse aux entreprises privées vendant des produits ou
services à d'autres entreprises privées B to B ou publiques (B to G).
Qweeby SAS, a été fondée en janvier 2009 par Eric Wanscoor et Mohamed Aymen Ben Abdallah.
L'entreprise a levé plus de 1,5 million d'euros depuis sa création auprès d'acteurs majeurs du
Capital Innovation Français.
Figure 1 : Logo QWEEBY
2.2 L'organisation de Qweeby

Le siège social de Qweeby est situé à Saint-Étienne, en France, et possède deux autres bureaux
basés en Tunisie. Son effectif est compris entre 11 et 50 salariés.
Il existe plusieurs services au sein de Qweeby. Chaque service contribue à la vie quotidienne de
l'entreprise à différents niveaux :
 Opérations :Il contient deux éléments principaux. Développement des affaires, qui est
responsable de l'acquisition de nouveaux clients et de nouveaux projets. et Customer
Success, pour assurer la satisfaction des clients Qweeby.
 Couler:Répondre aux demandes des utilisateurs et configurer l'accès pour les nouveaux
clients.
 Technique:Il contient trois éléments principaux. Architecture applicative, qui définit les
axes techniques pour améliorer le produit en fonction des demandes des clients internes
(marketing, succès client ou exploitation). Développement, Développer les produits selon
5
les demandes de l'architecte applicatif. Et la Production, pour assurer la continuité des
services proposés par Qweeby pour les clients et les internes.
 ERP :Mise en place et gestion de l'Enterprise Resource Planning.
 Commercialisation:Assurer la promotion et la valorisation de l'entreprise et de ses
produits auprès des clients et prospects.
President
Dir. Dir. ERP project Dir.

Marketing Opérations manager Technique
Application
Product Customer Flow Application Resp
Business Dev project
manager Success manager architect Production
manager
Communicati Pilot
Data Pilot Pilote MEP
ons officer Connections
Pilote
Pilote SGBD
Exploitation
Figure 2 : Organigramme de Qweeby
3 Etat de l'existant
Les mesures mises en œuvre au fil des ans dans Qweeby consistent en plusieurs types de systèmes
visant à réduire l'accès aux données des clients. Qweeby dispose d'une politique de sécurité et
d'une charte de bonnes pratiques qui rassemble une liste de pratiques générales concernant le
patrimoine de l'entreprise. Mais il n'y a pas de norme bien structurée et il n'y a pas de description
pratique et détaillée de la mise en œuvre des objectifs et des mesures de sécurité.
Qweeby propose une méthode d'authentification traditionnelle pour ses employés où ils utilisent
un nom d'utilisateur et un mot de passe pour accéder aux applications internes. ainsi, l'entreprise
6
n'a pas de solution de connexion sécurisée ou de solution de contrôle d'accès pour ses applications
internes.
De plus, Qweeby ne dispose pas de solution de gestion des identités pour ses applications internes
où il peut gérer les informations d'identité des employés et contrôler l'accès aux ressources de
l'entreprise. D'autre part, Qweeby dispose d'une solution de centralisation des journaux pour
collecter et analyser les données, il a implémenté la pile ELK comme solution mais le problème
est que cette solution n'est pas configurée de manière requise et doit être améliorée.
4 Énoncé du problème
Aujourd'hui, les entreprises sont sur le point d'être attaquées par des pirates informatiques qui ont
l'intention d'attaquer des informations confidentielles sur l'entreprise et les clients. Pour cette
raison, tous les employeurs doivent être conscients de l'importance de comprendre les bonnes
pratiques de sécurité de l'information dans l'entreprise pour garantir la sécurité des données
confidentielles et sensibles.
QWEEBY est toujours conscient de la valeur de la sécurité de l'information, toutes ses activités
affectent également le système de gestion de la sécurité de l'information (SMSI). C'est dans ce
cadre que nous mettrons en place un SMSI au sein de QWEEBY.
Dans un environnement de plus en plus concurrentiel, cette implantation contribuera à instaurer la

confiance entre QWEEBY et ses clients, partenaires et fournisseurs.
4.1 Énoncé du problème Sprint 1

Dans Qweeby, les employés utilisent le nom d'utilisateur et le mot de passe comme méthode
d'authentification pour accéder aux applications internes de qweeby.
Chaque fois qu'un utilisateur se connecte à une nouvelle application. C'est une opportunité pour
les pirates d'accéder à cette application, car cette méthode augmente le risque d'accès non autorisé
à l'application et aux informations.
Les mots de passe ne sont pas sécurisés pour plusieurs raisons :
7
 Les mots de passe peuvent être trop faibles, partagés entre différentes applications.
 Les utilisateurs écrivent parfois des mots de passe, par exemple sur des notes.
 Les mots de passe sont parfois envoyés sur des réseaux non sécurisés, ce qui les rend faciles
à voler.
De plus, il n'est pas facile de mémoriser de nombreux mots de passe qui sont régulièrement
modifiés et qui doivent contenir une combinaison alphanumérique minuscule/majuscule d'au
moins huit caractères et symboles.
Tout cela prouve que cette méthode n'est pas sécurisée et nous avons besoin d'un meilleur
remplacement afin de sécuriser notre application.
Dans ce contexte, l'authentification unique est apparue pour éclairer ces problèmes.

Aujourd'hui, les entreprises informatiques fusionnent vers un environnement basé sur le cloud. si
une entreprise a besoin d'envoyer des données utilisateur à plusieurs services cloud. la figure ci-
dessous explique la méthode traditionnelle de ponçage des données sur différents systèmes.
Figure 3 : Gestion des utilisateurs dans l'approche traditionnelle
8
De cette façon, nous devrons développer des plug-ins de provisionnement / gestion des utilisateurs
pour chaque service avec lequel nous voulons communiquer puisque chaque système a sa propre
API.
Dans ce cas, les entreprises seront mises au défi de gérer la synchronisation des identités des
utilisateurs sur différents magasins de données. où sont les données ? pourquoi il n'a pas été
supprimé ? etc.
La gestion de l'identité des utilisateurs devient un facteur critique car de nombreux pays ont des
politiques et des réglementations sur la façon dont la date de l'utilisateur doit être traitée en raison
de la sécurité et de la confidentialité des données de l'utilisateur. Alors, comment allons-nous gérer
nos données utilisateur de manière sécurisée, c'est là que SCIM apparaît.

De nombreuses applications s'exécutent sur les services Qweeby, ce qui signifie que des centaines
et des millions de journaux sont des enregistrements. Le processus de débogage et de recherche
dans ce journal est devenu un véritable défi. L'entreprise traite des centaines de factures
électroniques, ce qui signifie des millions de journaux, c'est un défi de journaliser, d'indexer, de
rechercher, de stocker, de visualiser et d'analyser ces journaux chaque jour.
Qweeby a déjà implémenté la pile ELK comme solution de centralisation des journaux, pour
collecter et analyser les données, mais le problème est que cette solution n'est pas configurée de la
manière requise. en particulier la méthode de recherche mise en œuvre, ce n'est pas simple à
utiliser, c'est pourquoi l'équipe a besoin d'une méthode de recherche facile, simple et dynamique
qui facilite le processus de centralisation des journaux.
5 Notre solution
9
Pour renforcer sa sécurité, Qweeby s'est engagé dans une démarche de mise en place d'un système
de management de la sécurité de l'information (SMSI) dans l'ensemble des business units de
l'entreprise afin d'obtenir la certification ISO 27001.
La mise en œuvre du SMSI nécessite que l'entreprise se conforme à l'annexe A de la norme ISO
27001. L'annexe A impose certaines mesures et contrôles qui doivent se satisfaire de solutions
techniques.
Les solutions techniques que nous allons mettre en œuvre dans ce projet sont :
 Implémentez une solution d'authentification unique (SSO) via Azure Active Directory.
 Mettre en œuvre une solution de gestion des identités SCIM (System for Cross-domain
Identity Management)
 Mettre en place une solution de centralisation des logs avec Stack ELK pour faciliter les
audits.
5.1 Solution Sprint 1

Il n'est pas facile de se débarrasser complètement des menaces et de la vulnérabilité des systèmes
d'authentification.
Malgré cela, les organisations tentent de réduire ces risques en mettant en place des mécanismes
de sécurité afin de les éviter.
Dans notre cas, nous avons choisi de mettre en œuvre l'authentification unique (SSO) comme
solution d'authentification et d'autorisation des utilisateurs.

Le système de gestion des identités interdomaines (SCIM) développé pour gérer les identités des
utilisateurs dans les applications et les services basés sur le cloud.
SCIM automatise la gestion du cycle de vie de l'identité de l'utilisateur, y compris la création, la

mise à niveau, la désactivation et la suppression du compte utilisateur de manière plus sécurisée,
plus fluide et moins chère sur une ou plusieurs applications.
10
La première version de SCIM 1.0 a été publiée en 2011 par un groupe de travail sur la norme
SCIM organisé. La version 2.0 de SCIM a été achevée en septembre 2015 et elle a été utilisée par
de nombreuses entreprises telles que Microsoft, Google, Cisco, Nexus, Salesforce, VMWare,
Oracle, etc.
Nous pouvons considérer SCIM comme un protocole d'approvisionnement léger ;

L'approvisionnement des comptes d'utilisateurs est une méthode qui garantit que les comptes
d'utilisateurs sont créés, dotés des autorisations appropriées, mis à jour, désactivés et supprimés
dans plusieurs applications et systèmes.
SCIM est composé de deux choses, un schéma et un protocole. schéma présente à quoi ressemble
la ressource (objet utilisateur/groupe). le protocole présente comment la ressource va être
transférée vers un autre système. les fournisseurs d'identité, les applications basées sur le cloud
s'accordent sur un mode de communication commun à l'aide de SCIM.
Figure 4 : Gestion des utilisateurs avec SCIM
avec SCIM, nous pouvons gérer les données de l'identité, ainsi que la création, la mise à jour et la
suppression des comptes utilisateurs avec le service cloud.
11
Afin de faciliter le processus de débogage et de recherche dans les journaux Qweeby, nous avons
amélioré la solution de centralisation des journaux mise en œuvre avec les fonctionnalités et le
plug-in de la pile ELK pour permettre à l'utilisateur de rechercher facilement dans les données de
manière structurée et simple.
6 Choix de la méthodologie
Le processus de gestion de projet est guidé par une méthodologie et le choix de la bonne aura un
effet sur le flux de travail et la communication au sein de l'équipe.
Il existe de nombreuses méthodologies de gestion de projet, chacune a ses avantages et ses

inconvénients et peut être appliquée à différents projets.
Nom de la Points clés Particularités Faiblesse identifiée

méthode
2TUP Une méthodologie de isole les aspects Détection d'erreur tardive.
travail présenté par fonctionnels
un cycle de et les aspects techniques.
développement en Y. Fait beaucoup de place
Cible des projets pour
toutes les tailles. technologie et
gestion des risques.
12
SCRUM Équipes de Imposez un changement Alors que Scrum détaille
développement de paradigme de la vision en particulier comment
indépendantes, petites de développement gérer le cycle de
et auto-organisées, « défini et reproductible » publication de 30 jours, les
cycles de publication à la « nouveau produit » tests d'intégration et
de 30 jours. de Scrum. d'acceptation ne sont pas
détaillés.
TSA Culture adaptative, Les organisations sont ASD concerne davantage
collaboration, considérées comme des les concepts et la culture
développement itératif systèmes adaptatifs. que la pratique du logiciel.
de base de composants Créer un ordre émergent à
axé sur la mission. partir d'un réseau
d'individus
interconnectés.
Tableau 1 : Comparaison des méthodologies
6.1 Choix de la méthodologie

Sur la base de cette étude, nous avons choisi de travailler avec la méthodologie Scrum car c'est
l'un des frameworks les plus populaires et les plus simples pour mettre les principes d'Agile en
pratique. L'entreprise hébergée l'utilise également pour gérer les projets.
6.2 Présentation de SCRUM

Le système de gestion de projet que nous avons utilisé dans ce projet est la méthodologie Agile, et
SCRUM est la méthode. Scrum est un cadre de gestion de projet qui repose sur un développement
incrémental et itératif afin d'atteindre un objectif spécifique.
L'objectif principal de SCRUM est de s'assurer que l'équipe accomplit un ensemble de tâches dans
une itération temporelle bien définie, chaque itération se compose de deux à quatre semaines
appelées sprints, où le but de chaque sprint est de développer une fonctionnalité afin de sortir avec
un produit livrable.
13
Une réunion régulière est organisée chaque jour où les membres de l'équipe tentent de répondre à
ces questions :
• Qu'est-ce que vous avez fait hier?
• Que vas-tu faire aujourd'hui?
• Avez-vous été confronté à quelque chose bloquant votre progression ?
6.3 Rôles de l'équipe
 Propriétaire du produit:Le Product Owner sert de contact entre l'équipe de

développement et ses clients. Il gère le backlog produit et garantit que chacun connaît les
priorités.
Le Product Owner dans ce projet est : M. Aymen Ben Abdallah
 Scrum Master :Le Scrum Master est au service de l'Equipe, ses rôles sont de diriger et
diriger le groupe, il travaille en tant que superviseur et consultant. Il fixe les tâches et
assume la responsabilité des délais et des révisions.
Le scrum master de ce projet est : M. Dali Mersel
 Équipe de développement:L'équipe de développement est un groupe qui travaille
ensemble pour produire et tester le produit fini pour la version finale.
L'équipe de développement de ce projet est : Amani Harizi.
14
Figure 5 : Processus SCRUM [1]
Conclusion
Nous avons atteint la fin de ce premier chapitre où nous avons présenté le contexte général de notre
projet, l'organisation d'accueil, et une brève étude du projet.
Dans le chapitre suivant, nous allons présenter l'état de l'art, où nous entrerons plus en détail sur
les méthodes de mise en œuvre d'un système de gestion de la sécurité de l'information.
15
Chapitre 2 : État de l'art
16
introduction
Dans ce chapitre, nous allons introduire les concepts abordés dans notre projet tels que le système
de management, le processus de mise en œuvre du SMSI, la famille ISO 27000, le processus de
gestion des risques, les méthodologies d'évaluation des risques et notre participation à la mise en
œuvre du SMSI ISO 27001. polices à Qweeby
1 Système de gestion
Un système de management est un ensemble de politiques, de processus et de procédures utilisés
par une organisation pour s'assurer qu'elle peut accomplir les tâches requises pour atteindre ses
objectifs. Ces objectifs couvrent de nombreux aspects des opérations de l'organisation (y compris
la réussite financière, la sécurité d'exploitation, la qualité des produits, les relations avec les clients,
la conformité législative et réglementaire et la gestion des travailleurs). Par exemple, un système
de gestion environnementale permet aux organisations d'améliorer leur performance
environnementale et un système de gestion de la santé et de la sécurité au travail (SGSST) permet
à une organisation de contrôler ses risques pour la santé et la sécurité au travail. [2]
1.1 modèle PDCA

Le modèle « Plan-Do-Check-Act » (PDCA) est une approche orientée processus pour
l'amélioration continue des processus organisationnels. Son but est d'améliorer le processus ou
d'éliminer les problèmes dans le cadre d'un processus interactif contenant des phases de
planification, d'évaluation, de mise en œuvre et d'amélioration.
ISO 27001 adopte le modèle « Planifier-Faire-Vérifier-Agir » (PDCA) qui est appliqué pour
structurer le processus SMSI. La figure (3) ci-dessous montre comment le système de gestion de
la sécurité prend les exigences et attentes en matière de sécurité de l'information comme entrées
et, tout au long du cycle PDCA, produit des résultats de sécurité de l'information gérée qui
répondent à ces exigences et attentes.
17
Figure 6 : Modèle PDCA appliqué aux processus SMSI [3]
 Planifier (établir le SMSI) : Établir la politique, les objectifs, les processus et les
procédures du SMSI relatifs à la gestion des risques et à l'amélioration de la sécurité de
l'information afin d'obtenir des résultats conformes aux politiques et objectifs généraux
d'une organisation.
 Faire (mettre en œuvre et exploiter le SMSI): Mettre en œuvre et exploiter la politique,
les contrôles, les processus et les procédures du SMSI.
 Vérifier (surveiller et réviser le SMSI) : Évaluer et, le cas échéant, mesurer la
performance des processus par rapport à la politique, aux objectifs et à l'expérience pratique
du SMSI et communiquer les résultats à la direction pour examen.
 Agir (maintenir et améliorer le SMSI) :Prendre des mesures correctives et préventives,
sur la base des résultats de l'audit interne du SMSI et de la revue de direction ou d'autres
informations pertinentes, pour parvenir à une amélioration continue du SMSI. [3]
1.2 Système de gestion de la sécurité de l'information

Un système de gestion de la sécurité de l'information est une approche systématique pour gérer les
informations commerciales sensibles afin qu'elles restent sécurisées. Un SMSI inclut des
personnes, des processus et des systèmes informatiques en appliquant un processus de gestion des
risques. Il existe trois types de SMSI :
18
 Mise en œuvre : consiste à mettre en place un SMSI.
 Audit : consiste à évaluer la maturité du SMSI.
 Certification : consiste à assurer la conformité du SMSI d'une organisation à la norme
internationale ISO 27001.
1.3 Sécurité des informations

La sécurité de l'information est un ensemble de pratiques conçues pour protéger les données sous
quelque forme que ce soit, par exemple numérique, imprimée ou sous toute autre forme, contre
tout accès ou modification non autorisé. Qu'il soit stocké ou transféré d'une machine ou d'un
emplacement physique à un autre.
Les organisations, comme les gouvernements, les entreprises privées et autres, stockent et traitent
de grandes quantités d'informations sur des ordinateurs. La perte ou la divulgation de données à la
mauvaise personne ou sans protection appropriée peut entraîner des problèmes juridiques et
éthiques pour l'organisation. La sécurité de l'information est principalement axée sur la protection
équilibrée de la confidentialité, de l'intégrité et de la disponibilité des données :
 Confidentialité: Pour garantir la confidentialité, vous devez être en mesure d'identifier qui
essaie d'accéder aux données et empêcher les tentatives de personnes sans autorisation.
 Intégrité: Cela signifie conserver les données dans leur état correct et éviter qu'elles ne
soient modifiées de manière incorrecte (par exemple, ajouter, supprimer ou modifier) par
accident ou par malveillance.
 Disponibilité: Cela signifie que les données doivent être disponibles quand elles sont
nécessaires. Le système informatique qui stocke ces informations, les contrôles de sécurité
utilisés pour les protéger et le système de support doivent fonctionner correctement et
garantir que les données sont entièrement disponibles à ce moment-là.
2 Processus de mise en œuvre du SMSI

Pour pouvoir mettre en place un système de management de la sécurité de l'information selon la
norme ISO 27001, les étapes suivantes doivent être suivies :
19
Tout d'abord, il est important d'identifier et de prioriser les objectifs afin de comprendre les
intentions et les intérêts de la direction, les principaux objectifs de l'organisation peuvent être
extraits de la mission de l'entreprise, de ses objectifs informatiques et autres plans stratégiques.
Ensuite, la direction doit s'engager à établir, mettre en œuvre, exploiter, surveiller, réviser,
maintenir et améliorer le système de gestion de la sécurité de l'information.
Cet engagement doit inclure des activités telles que la garantie que les ressources appropriées sont
disponibles pour travailler sur le SMSI et que tous les employés concernés par le SMSI ont la
formation, la sensibilisation et les compétences appropriées.
2.1 Phase du plan PDCA

Après avoir fixé les objectifs et fourni les ressources nécessaires à la mise en place d'un SMSI,
nous passons maintenant à la phase de planification du modèle PDCA, qui consiste à identifier les
étapes suivantes.
2.1.1 La portée du SMSI

La norme ISO 27001 n'impose pas d'exigences sur le périmètre, elle peut être restreinte ou couvrir
l'ensemble des activités de l'organisation, il est nécessaire de déterminer le périmètre dans lequel
la direction souhaite mettre en place le système de management de la sécurité informatique.
Dans notre cas, le périmètre ISMS s'applique aux sites Qweeby. Il couvre la gestion des
informations et des activités de Qweeby à l'intérieur et à l'extérieur du bureau. Le champ
d'application comprend le personnel, les biens, les informations et toutes les ressources appartenant
au site.
2.1.2 L'évaluation des risques

L'évaluation des risques est la partie la plus importante et la plus complexe lors de la mise en œuvre
de la norme ISO 27001, cette phase aide les organisations à identifier, analyser et évaluer les
faiblesses de leurs processus de sécurité de l'information et si le risque n'est pas identifié
correctement, cela peut conduire à des résultats incorrects.
2.1.3 Traitement des risques
20
Malgré cela, l'évaluation des risques pourrait être la partie la plus complexe lors de la mise en
œuvre de l'ISO 27001, mais le traitement des risques est certainement la partie la plus stratégique
et la plus coûteuse.
Le traitement des risques a pour objectif de maîtriser les risques identifiés lors de l'évaluation des
risques, c'est-à-dire de diminuer le risque en diminuant la probabilité d'un incident et de minimiser
l'impact sur le patrimoine informationnel de l'organisation.
Après avoir dressé une liste des risques inacceptables, ces options sont généralement appliquées
pour les traiter :
 Diminuer le risque: cette option est la plus courante et elle inclut la mise en place de
mesures de contrôle de sécurité.
 Éviter le risque: en l'éliminant complètement.
 Partager le risque: avec un tiers. (via l'assurance)
 Conserver le risque: accepte le risque sans rien faire.
Tout en travaillant sur le traitement des risques, l'organisation doit se concentrer sur les risques qui
sont autrement inacceptables, il serait difficile de déterminer les priorités de tous les risques
identifiés.
2.2 Phase d'exécution du PDCA

Cette phase consiste à mettre en place des mesures de sécurité sélectionnées lors de la phase de
planification.
2.2.1 Plan de traitement des risques

Cette partie nécessite l'établissement d'un plan de traitement des risques qui permettra de distinguer
et de classer les risques selon leur impact et leur probabilité. Pour contrôler avec succès l'impact
des divers risques associés aux actifs, l'atténuation des risques doit être surveillée en acceptant, en
évitant, en transférant ou en réduisant les risques à un certain niveau d'acceptation.
2.2.2 Mise en œuvre du SMSI
21
Après avoir terminé le plan de traitement, des mesures de sécurité doivent être déployées selon ce
plan. Ensuite, une mesure d'efficacité doit être définie pour contrôler le bon fonctionnement du
SMSI.
2.2.3 Maintenance du SMSI

La maintenance consiste à s'assurer du bon fonctionnement de chacun des processus du SMSI et à
vérifier que leur documentation est à jour ce qui permet à l'auditeur externe de maîtriser la gestion
du SMSI.
2.3 Phase de contrôle PDCA

Cette phase consiste à évaluer les mesures de sécurité mises en place afin de s'assurer de «
l'efficacité » du SMSI et de sa « conformité » à la norme ISO 27001. Pour répondre à ces deux
exigences de la norme, les organisations utilisent des audits internes ainsi que des revues de
direction et rendent le SMSI Évaluation.
2.3.1 Évaluation du SMSI

Après avoir planifié et déployé les mesures de sécurité, il est nécessaire de vérifier les
performances de sécurité et d'évaluer l'efficacité du SMSI.
2.3.2 Audits internes

L'audit interne peut être organisé avec le personnel de l'organisation ou être sous-traité à un cabinet
de conseil.
Le but de l'audit est de vérifier la conformité et l'efficacité du SMSI en recherchant les différences
entre la documentation du système (enregistrement, procédures, etc.) et les activités de
l'organisation. La norme exige que la méthode utilisée pour l'audit soit documentée dans une
procédure et que les rapports soient enregistrés pour être utilisés dans les revues de direction.
2.3.3 revues de direction

L'examen est une réunion annuelle qui permet aux dirigeants de l'organisation d'analyser les
événements qui ont eu lieu au cours de l'année en cours. Et grâce à cela, la direction peut fixer de
nouveaux objectifs et allouer de nouvelles ressources (financières, humaines et matérielles).
2.4 Phase d'acte PDCA

22
Cette phase consiste à réduire les dysfonctionnements par des actions correctives et une
amélioration continue en cas de non-conformité à la norme ISO 27001 et aux objectifs et exigences
de la direction. Ces actions contribuent à rendre le SMSI plus efficient et efficace.
2.4.1 mesures correctives

Nous intervenons de manière « corrective » lorsqu'un dysfonctionnement ou un écart est constaté.
Nous intervenons d'abord sur les effets pour corriger ce dysfonctionnement, puis sur les causes
pour éviter qu'ils ne se reproduisent.
2.4.2 Actions d'amélioration

L'amélioration continue vise à améliorer les performances du SMSI, c'est pourquoi l'organisation
doit améliorer le SMSI de manière continue.
3 Normes ISO/CEI 27000

Les normes de la famille ISO / IEC 27000 sur la sécurité de l'information, également connues sous
le nom de série ISO 27000, ont été développées et publiées par l'ISO (Organisation internationale
de normalisation) et la CEI (Commission électrotechnique internationale) pour fournir un cadre
mondialement reconnu pour une meilleure gestion de la sécurité de l'information. s'entraîner. Ces
normes de sécurité aident les organisations à sécuriser leurs informations, la figure 7 ci-dessous
présente la famille d'ISO 27000.
Figure 7 : La famille d'ISO 27000
23
ISO/CEI 27000: Systèmes de management de la sécurité de l'information — Présentation et
vocabulaire.
ISO/CEI 27001: Exigences du système de gestion de la sécurité de l'information.
ISO/CEI 27002: Code de bonnes pratiques pour les contrôles de sécurité de l'information.
ISO/CEI 27003: Guide de mise en œuvre du système de gestion de la sécurité de l'information.
ISO/CEI 27004: Gestion de la sécurité de l'information.
ISO/CEI 27005 : Gestion des risques de sécurité de l'information
ISO/CEI 27006: Exigences pour les organismes assurant l'audit et la certification des systèmes de
management de la sécurité de l'information.
ISO/CEI 27007: Lignes directrices pour l'audit des systèmes de management de la sécurité de
l'information.
3.1 ISO/CEI 27001

La norme ISO/IEC 27001 est une norme internationale pour la sécurité des systèmes d'information
de l'ISO et de l'IEC. Il s'adresse à tous types d'organisations (sociétés commerciales,
administrations, etc.) et définit les exigences pour l'implantation d'un SMSI. Il a été publié en
octobre 2005 et révisé en 2013 succède à la norme BS 7799-2 de BSI (British Standards
Institution). Il fait partie de la suite ISO/IEC 27000 et est utilisé pour certifier les organisations.
ISO/IEC 27001:2013 comporte 10 chapitres, plus une longue annexe A, qui couvrent :
Chapitre 0 : Présentation
Chapitre 1 : Champ d'application de la norme
Chapitre 2 : Références normatives
24
Chapitre 3 : Termes et définitions
Chapitre 4 : Contexte de l'organisation
Chapitre 5 : Diriger
Chapitre 6 : Planification
Chapitre 7 : Assistance
Chapitre 8 : Fonctionnement
Chapitre 9 : Évaluation des performances
Chapitre 10 : Amélioration
Annexe A : Liste des contrôles et leurs objectifs [4]
3.2 ISO/CEI 27002

La norme ISO/IEC 27002 est une norme internationale qui définit les lignes directrices pour les
bonnes pratiques de gestion de la sécurité de l'information, publiée en 2005 par l'ISO et l'IEC,
révisée en 2013 succède à la norme BS 7799-1 de BSI (British Standards Institution). La norme se
compose de 114 mesures et la sécurité de l'information est définie en considérant la triade CIA
(confidentialité, intégrité, disponibilité). Cette norme comporte 19 chapitres :
Chapitre 0 : Présentation
Chapitre 1 : Portée
Chapitre 4 : Structure de cette norme
Chapitre 5 : Politiques de sécurité de l'information
Chapitre 6 : Organisation de la sécurité de l'information
25
Chapitre 7 : Sécurité des ressources humaines
Chapitre 8 : Gestion des actifs
Chapitre 9 : Contrôle d'accès
Chapitre 10 : Cryptographie
Chapitre 11 : Sécurité physique et environnementale
Chapitre 12 : Sécurité des opérations
Chapitre 13 : Sécurité des communications
Chapitre 14 : Acquisition, développement et maintenance du système
Chapitre 15 : Relations fournisseurs
Chapitre 16 : Incident de sécurité de l'information
Chapitre 17 : Continuité de la sécurité de l'information et redondances
Chapitre 18 : Conformité [5]
3.3 ISO/CEI 27003

ISO/IEC 27003 est une norme internationale qui fournit un guide de mise en œuvre d'un système
de management de la sécurité de l'information conforme aux exigences de la norme ISO 27001.
Cette norme comporte 10 chapitres et une annexe A :
Chapitre 4 : Contexte de l'organisation
Chapitre 5 : Diriger
Chapitre 6 : Planification
26
Chapitre 7 : Assistance
Chapitre 8 : Fonctionnement
Chapitre 9 : Évaluation des performances
Chapitre 10 : Amélioration
Annexe A : Cadre politique [6]
3.4 ISO/CEI 27005

ISO/IEC 27005 est une norme internationale qui décrit la gestion des risques pour la mise en œuvre
d'un système de management de la sécurité de l'information publiée en 2008 par l'ISO et l'IEC,
révisée en 2011 et révisée à nouveau en 2018.
Cette norme comporte 12 chapitres et 6 annexes :
Chapitre 4 : Structure de la norme
Chapitre 5 : Contexte
Chapitre 6 : Présentation générale du processus de gestion des risques de sécurité de

l'information
Chapitre 7 : Établir le contexte
Chapitre 8 : Évaluation des risques liés à la sécurité de l'information
Chapitre 9 : Traitement des risques liés à la sécurité de l'information
Chapitre 10 : Acceptation des risques liés à la sécurité de l'information
Chapitre 11 : Communication des risques liés à la sécurité de l'information
Chapitre 12 : Surveillance et examen des risques liés à la sécurité de l'information
27
Annexe A : Définition du périmètre et des limites du processus de gestion des risques liés
à la sécurité de l'information
Annexe B : Identification et évaluation des actifs et évaluation des impacts
Annexe C : Exemples de menaces de type
Annexe D : Vulnérabilités et méthodes d'évaluation des vulnérabilités
Annexe E : Approches d'évaluation des risques liés à la sécurité de l'information
Annexe F : Contraintes liées à la réduction des risques [7]
4 Processus de gestion des risques

Le processus de gestion des risques se compose de plusieurs étapes, les éléments clés du processus
de gestion des risques sont présentés dans la figure ci-dessous.
Figure 8 : Processus de gestion des risques
4.1 Établir le contexte

Lors de l'établissement du contexte de gestion des risques, il est nécessaire de prendre en
considération :
- Définir le périmètre
28
- Compréhension de l'environnement externe et interne
- Identifier les critères de base
- Identifier les objectifs et les besoins
- Identifier les parties prenantes (corporate)
4.2 L'évaluation des risques

L'évaluation des risques est un processus complet d'analyse et d'évaluation des risques, elle se
divise en trois sous-parties :
4.2.1 Identification des risques

Après avoir établi le contexte, la prochaine étape du processus de gestion des risques consiste à
identifier les risques potentiels, l'objectif de l'identification des risques est de déterminer les causes
des impacts et de comprendre comment, où et pourquoi les dommages peuvent survenir.
Elle se déroule selon les étapes suivantes :
- Identification des actifs
- Identification des menaces
- Identification des mesures de sécurité existantes
- Identification des vulnérabilités
- Identification des impacts
4.2.2 Analyse de risque

Dans cette partie, nous devons identifier les menaces et les vulnérabilités qui s'appliquent à chaque
actif. et une fois que nous connaissons les risques, nous devons considérer la probabilité et l'impact
pour nous permettre de faire la distinction entre une faible probabilité et un faible impact, par
rapport aux plus élevés.
L'analyse des risques comprend trois phases :
- Impacts estimés
29
- Probabilité d'occurrence estimée
- Niveau de risque estimé
4.2.3 Évaluation du risque

Une fois les risques identifiés, ils doivent ensuite être évalués en fonction de leur impact et de leur
probabilité d'occurrence. Dans cette étape, nous devons prendre en considération les informations
obtenues au cours de la phase d'analyse des risques. Les risques estimés sont classés selon leur
importance en fonction des décisions prises tout en établissant le contexte de l'analyse des risques.
Habituellement, nous utilisons une matrice d'évaluation des risques pour nous aider à identifier les
risques qui méritent d'être traités et à les hiérarchiser.
Figure 9 : Matrice d'évaluation des risques
La plupart des matrices d'évaluation des risques ressemblent à ceci, avec un axe présentant la
probabilité qu'un scénario de risque se produise et l'autre présentant les dommages qu'il causera.
Au milieu, nous avons des scores basés sur leurs totaux combinés.
4.3 Traitement des risques

Une fois les risques identifiés et évalués, le simple choix du traitement des risques le plus approprié
revient à équilibrer les coûts de mise en œuvre de chaque activité avec les avantages dérivés du
type et de la nature du risque. La figure 7 suivante montre les options de traitement des risques
disponibles :
30
Figure 10 : Options de traitement des risques
- Modifier le risque : Cette option est la plus courante et elle inclut la mise en place de mesures de
contrôle pour réduire la probabilité ou les conséquences du risque à un niveau acceptable.
- Conserver le risque : C'est l'option la moins souhaitable. C'est accepter le risque sans rien faire.
cette option ne doit être utilisée que si la probabilité d'occurrence du risque est trop faible ou si le
coût d'identification du risque est trop élevé pour justifier un traitement.
- Eviter le risque : arrêter d'effectuer certaines tâches ou processus s'ils comportent des risques trop
dangereux.
- Partager le risque : Cette option consiste à transférer le risque à un tiers (par exemple : assurance)
capable de le gérer.
4.4 Acceptation des risques

Une fois les risques traités, cette étape est dédiée à décider si le risque résiduel est devenu
acceptable ou à répéter le processus de traitement.
4.5 Communication des risques

Il s'agit d'un processus continu d'échange et de partage d'informations sur les risques entre les
décideurs et un autre collaborateur. La communication des risques vise à :
31
- Réduire les malentendus avec les décideurs
- Améliorer la coordination pour répondre aux incidents
- Partager les résultats de l'évaluation des risques et présenter le plan de traitement
- Acquérir de nouvelles connaissances en sécurité
- Améliorer la sensibilisation à la sécurité
4.6 Suivi et revue des risques

Ce processus consiste à surveiller et à réexaminer les éléments de risque :
- Valeur des actifs et catégories
- Impacts, menaces, vulnérabilités, probabilité d'occurrence
- Éléments externes (contexte juridique, environnemental)
- Modification de la démarche d'appréciation des risques (impact, évaluation, critères d'acceptation

des risques)
5 Méthodologies d'évaluation des risques

Une méthodologie est une approche rigoureuse et standardisée basée sur des outils tels que des
questionnaires, des logiciels spécialisés, permettant d'analyser la sécurité du système
d'information, tels que :
 La méthode EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité)

 La méthode MEHARI (Méthode Harmonisée d'Analyse des Risques)
 La méthode CRAMM (CCTA Risk Analysis and Management Method)
 La méthode OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)
5.1 EBIOS
La méthode EBIOS est une méthode d'analyse des risques, développée en 1995 par la DCSSI
(Direction Centrale de la Sécurité des Systèmes d'Information) et maintenue en 2009 par l'ANSSI
(Agence Nationale de la Sécurité des Systèmes d'Information).
32
La méthode EBIOS est conforme aux normes internationales suivantes :
 ISO/CEI 27001
 ISO/CEI 27005
 ISO/CEI 31000
5.2 MEHARI
La méthode MEHARI est une méthode d'analyse des risques en informatique, développée en 1996
par le CLUSIF (Club français de la sécurité de l'information) en France puis le CLUSIQ (Club
québécois de la sécurité de l'information) au Canada.
La méthode MEHARI est conforme aux normes internationales suivantes :
 ISO/CEI 27001
 ISO/CEI 27002
 ISO/CEI 27005
5.3 CRAMM
La méthode CRAMM est une méthode d'analyse des risques développée par l'organisme
gouvernemental britannique CCTA (Central Agency for Communication and
Telecommunications) en 1985.
La méthode CRAMM est conforme aux normes internationales suivantes :
 ISO/CEI 27001
 ISO/CEI 27002
5.4 OCTAVE
La méthode OCTAVE est une méthode d'analyse des risques développée par le SEI (Software
Engineering Institute) de la Carnegie Million University à Pittsburgh aux USA en 1999.
La méthode OCTAVE est conforme à la norme internationale ISO 31010.
33
5.5 Comparaison des méthodologies d'analyse des risques
Afin de choisir la méthode d'analyse de risque appropriée, nous nous basons sur les critères
suivants :
EBIOS MEHARI CRAMM OCTAVE

Langue français français Anglais Anglais
Popularité haute haute moyenne moyenne
Conformité ISO 27001, ISO 27001, ISO 27001, ISO 31010
27005, 31000 27002, 27005 27002
Pays La France La France Angleterre Etats-Unis
Coût de mise en moyenne moyenne moyenne moyenne
œuvre
Qualité de la moyenne moyenne moyenne moyenne
documentation
Tableau 2 : Comparaison des méthodes d'analyse des risques
Sur la base des critères de choix de la méthode d'analyse des risques cités dans le tableau 1., nous
avons choisi la méthode EBIOS pour sa compatibilité avec les normes ISO 27001, ISO 27005,
ISO 31000, très populaire, le pays d'origine est francophone, langue du méthode est française, coût
moyen de mise en œuvre et qualité moyenne de la documentation.
6 Mise en place du SMSI ISO 27001 dans Qweeby

Après avoir compris l'organisation de l'entreprise et son objectif. nous allons présenter dans cette
partie, ma participation à la mise en place d'ISO 27001 à Qweeby avec l'équipe de recherche.
6.1 Phase de planification
6.1.1 La portée de la mise en œuvre du SMSI
34
Il est nécessaire de déterminer le périmètre sur lequel la direction souhaite établir le système de
management de la sécurité de l'information.
Dans notre cas, le champ d'application du SMSI s'applique au sein de Qweeby comprend les
employés, les actifs, les informations et toutes les ressources de l'entité.
6.1.2 Politique de sécurité de l'information

La politique est le niveau de sécurité qui sera appliqué dans le périmètre du SMSI. Toutes les
informations traitées par Qweeby via ses applications sont considérées comme des informations
confidentielles. Le classement de ces informations est nécessaire sachant qu'elles doivent respecter
le périmètre défini par la direction de Qweeby.
Les informations confidentielles nécessitent une protection particulière, afin de permettre de

contrôler et de limiter leur diffusion, dans les conditions définies dans la politique. Nous avons
donc commencé par classer les informations confidentielles de Qweeby puis nous avons mis en
place une politique regroupant des règles qui seront la base du système de management de la
sécurité de l'information.
6.1.3 L'évaluation des risques

Le problème de l'évaluation des risques n'est pas quelque chose de nouveau et il est traité par de
nombreuses méthodes développées dans différents secteurs et la méthode utilisée par Qweeby est
EBIOS.
L'une des premières étapes de l'évaluation des risques consiste à identifier les actifs afin de passer
à l'étape suivante d'identification des vulnérabilités et des risques. Dans ce cadre nous avons
organisé une rencontre avec les responsables des cinq départements :
 Département commercial
 Service réussite client
 Département des opérations
 Département des ventes
 Département de gestion
35
Le but de ces réunions est de collecter et de faire l'inventaire des actifs informationnels de Qweeby
avec la précision du propriétaire ainsi que de donner le degré de confidentialité, d'intégrité et de
disponibilité de chacun des actifs cités par les gestionnaires.
6.1.4 Mesure de sécurité

La dernière étape de la phase Plan consiste à sélectionner les mesures de sécurité. La norme
ISO/CEI 27001 propose dans son annexe A, 133 mesures de sécurité réparties sur onze chapitres.
Toutes les politiques travaillées par l'équipe de recherche au cours de ce projet se trouvent à
l'annexe A de la norme ISO 27001.
Les politiques que j'ai développées au cours de ce projet sont :
• A.5.1.1 : Politique de sécurité de l'information
• A.6.2.2 : Télétravail
• A.6.2 : Politique relative aux terminaux mobiles et au télétravail
• A.8.2 : Politique de classification des informations
En plus de cette politique, nous mettrons en œuvre une solution technique comme mesure de
contrôle et de sécurité.
 Configurer une solution d'authentification unique

 Mettre en place une solution de gestion des identités et des accès
 Mettre en place une solution de centralisation et de gestion des logs.
6.2 Faire la phase
6.2.1 Formation et sensibilisation des employés

La norme ISO 27001 : 2013 exige dans la partie « sensibilisation » que tous les employés soient
formés et conscients des politiques du SMSI et soient responsables que leur participation est
importante pour l'efficacité et la traçabilité de l'activité de Qweeby.
Dans notre cas, l'équipe de recherche a fait une séance de sensibilisation avec l'employé et en
présence du superviseur professionnel concernant deux politiques; la politique d'un bureau propre
et d'un écran blanc ainsi que le processus disciplinaire.
Conclusion
36
Dans ce chapitre, nous avons présenté un aperçu du système de gestion de la sécurité de
l'information, de ses normes, de la gestion des risques et des processus de mise en œuvre.
37
Chapitre 3 : Premier Sprint « Mettre
en œuvre une solution
d'authentification unique »
introduction
Dans ce chapitre, nous allons présenter le premier sprint nommé "Implémenter une solution
d'authentification unique". Tout d'abord, nous allons présenter l'objectif du sprint et le backlog de
38
sprint. Ensuite, nous allons présenter la branche fonctionnelle et technique , le sprint design et
l'expliquer avec des schémas et enfin nous découvrirons la phase de mise en œuvre et de validation
1 Objectif de sprint
L'objectif de ce sprint est de mettre en place une solution de gestion des accès dans une
application cloud via Azure AD. Nous allons implémenter une solution d'authentification unique
dans une application développée en Symfony. L'objectif est de permettre à l'employé de Qweeby
de se connecter à l'application interne via une troisième partie de confiance (Azure). Cette
solution de gestion des accès d'identité éliminera les mots de passe faibles qui peuvent provoquer
des violations de données et garantira que l'utilisateur change fréquemment de mot de passe. En
outre, cela atténuera les menaces internes causées par des initiés malveillants, en veillant à ce
que l'utilisateur n'accède qu'au système avec lequel il permet de travailler et ne peut pas
augmenter ses privilèges et, bien sûr, cela améliorera la satisfaction des employés et augmentera
la productivité.
2 Carnet de commandes de sprint

Fonctionnalités Caractéristiques Identifiant Histoire de Tâche
d'identification User l'utilisateur
Story
1 Mettre en place 1.1 Enregistrer une 1.1.1 connectez-vous à
une solution nouvelle Azure AD et ajoutez un
SSO application sur nouvel enregistrement
Azure AD d'application.
1.1.2 entrez les
informations
d'enregistrement de
l'application.
39
1.1.3 configurer l'octroi
implicite de l'application, le
secret client et les
autorisations API.
1.2 En tant 1.2.1 installer
qu'utilisateur, je KnpU/OAuth2
souhaite me ClientBundle.
connecter à 1.2.2 télécharger la
l'application avec bibliothèque cliente Azure.
Azure AD et 1.2.3 Configurer le
autoriser l'accès. fournisseur.
1.2.4 Configurez
AzureController() pour
vous connecter au service
client.
1.3 En tant 1.3.1 installer et configurer
qu'utilisateur, je l'ensemble Fosuser.
souhaite être
1.3.2 créer un contrôleur
authentifié dans
AzureAuthenticator à l'aide
l'application.
de l'authentificateur de
garde et l'intégrer à
Gestionnaire d'utilisateurs
FriendsOfSymfony.
Tableau 3 : Backlog du premier sprint
3 Branche fonctionnelle
3.1 Identification des acteurs
40
Les acteurs sont des entités ou un composant de logiciel ou de matériel qui échangent avec le
système. Dans ce sprint nous n'avons qu'un seul acteur, nos solutions ne seront utilisées que par
les salariés de l'entreprise sur l'application interne.
 Utilisateurs:les employés qui ont besoin d'accéder à différents services.
3.2 Exigences fonctionnelles

La solution que nous avons développée dans ce sprint permet aux utilisateurs de se connecter avec
un seul identifiant à plusieurs applications. Il propose un ensemble de fonctionnalités répondant
au besoin de l'entreprise, qui sont dans notre cas :
 Authentification
 Autorisation
 Sécurité et cryptage
3.3 Prérogatives non fonctionnelles

Les exigences non fonctionnelles offrent toutes les fonctionnalités et capacités de performance qui
améliorent les performances de notre système et garantissent sa convivialité et son efficacité. Les
exigences non fonctionnelles de notre projet sont répertoriées ci-dessous :
 Performance: notre système doit répondre en temps réel et conserver un temps d'inactivité
minimum.
 Maintenabilité: Notre code est écrit de manière claire, bien commenté et testé, comme
cette erreur facile dans le système peut être trouvée et corrigée.
 Extensibilité: Notre système peut être amélioré avec plus de couches de sécurité ou
modifier celui qui existe déjà.
4 Concevoir
4.1 Diagramme de cas d'utilisation
41
Le cas d'utilisation ci-dessous présente ce que l'utilisateur est capable de faire après avoir terminé
ce sprint. L'utilisateur a la possibilité de s'authentifier dans l'application avec un compte local, mais
le plus important, il peut se connecter à l'application avec Azure AD sans avoir besoin de saisir ses
informations d'identification à chaque fois qu'il se connecte ou nous pouvons l'appeler via une
connexion unique .
Figure 11 : Diagramme de cas d'utilisation du premier sprint
4.2 Diagramme de classes

Au cours de ce sprint, nous allons créer une classe « Utilisateur ». nous pouvons voir ses attributs
dans la figure ci-dessous.
42
Figure 12 : Diagramme de classes du premier sprint
4.3 Diagramme de séquençage

Après avoir précisé les fonctions de notre projet, nous allons présenter un examen approfondi des
fonctionnalités du SSO en concevant des diagrammes de séquence que sont « Autorisation OAuth2
» et « Authentification ».
4.3.1 Autorisation OAuth2

L'objectif de ce schéma est de comprendre la phase d'autorisation à l'aide du protocole OAuth 2.0.
Cette norme permet en toute sécurité à un fournisseur d'accéder aux données d'un autre, elle utilise
une terminologie complexe qui la rend difficile à comprendre.
Dans le schéma ci-dessous, nous expliquerons le fonctionnement de cette norme de manière

simplifiée. Mais avant d'intervenir, comprenons cette terminologie OAuth :
 Propriétaire de la ressource: c'est l'utilisateur, le propriétaire de l'identité.

 Client: c'est l'application (l'application Symfony dans notre cas) qui souhaite accéder aux
données ou effectuer des actions au nom du propriétaire de la ressource.
 Serveur d'autorisation: l'application qui connaît le propriétaire de la ressource (point de
terminaison de la plateforme d'identité Microsoft dans notre cas), où le propriétaire de la
ressource a déjà un compte.
43
 Serveur de ressources : l'interface de programmation d'application (API) ou le service que
le client souhaite utiliser au nom du propriétaire de la ressource (parfois, le « serveur
d'autorisation » et le « serveur de ressource » sont le même serveur).
 URI de redirection: URL vers laquelle le serveur d'autorisation redirigera le propriétaire
de la ressource après avoir accordé l'autorisation au client. Ceci est parfois appelé "URL
de rappel". et c'est l'application de la page d'accueil dans notre cas.
 Type de réponse: Le type d'informations que le Client s'attend à recevoir. Le type de
réponse le plus courant est le code, où le client attend un code d'autorisation.
 Portée: cela présente les autorisations granulaires souhaitées par le client, telles que l'accès
aux données telles que la lecture du profil de l'utilisateur ou pour effectuer des actions.
 Consentement: Le serveur d'autorisation prend les portées demandées par le client et
vérifie auprès du propriétaire de la ressource s'il souhaite ou non donner l'autorisation au
client.
 identité du client: Cet ID est utilisé pour identifier le Client auprès du Serveur
d'Autorisation.
 Secret du client: Il s'agit d'un mot de passe secret que seuls le client et le serveur
d'autorisation connaissent. Cela leur permet de partager en toute sécurité des informations
en privé dans les coulisses.
 Code d'autorisation: Un code temporaire de courte durée que le client donne au serveur
d'autorisation en échange d'un jeton d'accès.
 Jeton d'accès: La clé que le client utilisera pour communiquer avec le serveur de
ressources.
Maintenant que nous comprenons le vocabulaire du protocole, le diagramme de séquence ci-

dessous présente un examen plus approfondi du fonctionnement du flux OAuth, où il existe des
étapes visibles où l'utilisateur accorde l'autorisation, et d'autres étapes invisibles où les deux
services conviennent d'un moyen sécurisé d'échanger des informations.
44
Figure 13 : Diagramme de séquence d'autorisation OAuth2
4.3.2 Authentification
Le diagramme de séquence ci-dessous présente le scénario d'authentification dans notre
application après autorisation d'accès du fournisseur d'identité. quelque chose que nous n'avons
pas mentionné auparavant donnait à l'application l'autorisation d'accéder aux données de
l'utilisateur. le serveur d'autorisation a généré un identifiant d'application (identifiant Azure dans
notre cas) et l'a fourni au client pour qu'il l'utilise pour tous les futurs échanges OAuth et nous
l'avons utilisé pour établir l'authentification dans notre cas.
45
Figure 14 : Diagramme de séquence d'authentification
5 Branche technique
5.1 Solutions d'authentification unique
Il existe de nombreuses solutions d'authentification unique, parmi lesquelles nous pouvons
trouver :
46
 Annuaire actif Microsoft Azure : Microsoft Azure Active Directory (Azure AD) est l'une
des applications d'authentification unique les plus utilisées, permettant aux utilisateurs de
se connecter à plusieurs comptes avec leurs informations d'utilisateur Office 365. La plate-
forme est un service de gestion des identités et des accès basé sur le cloud, qui permet aux
employés de se connecter à Office 365, au portail Azure (Azure étant les services
d'application cloud de Microsoft) et à des milliers d'autres applications SaaS.. [8]
Figure 15 : Logo Microsoft Azure
 Okta :Okta fournit une suite complète de solutions de gestion des identités basées sur le
cloud. Okta permet aux organisations de gérer les identités de leurs utilisateurs avec une
plate-forme d'authentification unique toujours active, qui fonctionne sur tous leurs
comptes d'entreprise. Okta propose également une authentification multifacteur, des
répertoires universels et une gestion des accès aux API dans le cadre d'un réseau
d'intégration complet qui permet aux organisations d'améliorer la gestion et la sécurité
de leurs identités, tout en facilitant l'accès des utilisateurs à tous leurs comptes.. [8]
Figure 16 : Logo Okta
 Connexion unique :L'authentification unique de OneLogin permet aux utilisateurs de

sécuriser la connexion à plusieurs applications avec un seul nom d'utilisateur et mot de
passe, en utilisant la plate-forme OneLogin pour authentifier l'identité sur tous vos
comptes. OneLogin fournit un portail d'authentification unique pour les utilisateurs, qui
affiche tous leurs comptes d'entreprise et personnels auxquels ils peuvent accéder à l'aide
47
de leurs informations d'identification OneLogin. Les administrateurs peuvent mettre en
œuvre une authentification multifacteur sur tous les comptes d'entreprise d'un utilisateur,
afin de garantir que seuls les utilisateurs autorisés ont accès aux bonnes données. [8]
Figure 17 : Logo OneLogin
5.1.1 Justification du choix :

Pour la solution d'authentification unique, nous avons utilisé la solution Microsoft Azure Active
Directory en raison de l'architecture de l'entreprise. En fait, les applications internes de Qweeby
sont intégrées et gérées par Azure AD.
5.2 Protocoles d'authentification unique utilisés

Afin de centraliser le système d'authentification dans QWEEBY pour une meilleure gestion et
sécurité. nous avons mis en place une solution d'authentification unique pour la centralisation des
sessions et l'authentification des utilisateurs.
L'authentification unique est conçue pour authentifier une seule information d'identification sur
divers systèmes au sein d'une même organisation. Les trois principaux protocoles
d'authentification unique sont : OAuth2, SAML et OpenID Connect.
 OAuth2 :OAuth 2 est un cadre d'autorisation qui permet aux applications d'avoir un accès
restreint aux comptes d'utilisateurs sur un service HTTP, tel que GitHub, Azure AD et les
médias sociaux.
Ce protocole présente un accès délégué sécurisé. ce qui signifie qu'une application peut
accéder aux ressources d'un serveur du côté de l'utilisateur, et sans avoir besoin de partager
son mot de passe ou ses informations d'identification. Il y parvient en permettant au
fournisseur d'identité de fournir des jetons avec l'autorisation de l'utilisateur à une
application tierce.
 SAML :SAML est une norme basée sur XML pour le partage d'informations
d'authentification et d'autorisation entre les fournisseurs d'identité et les fournisseurs de
48
services afin de valider l'identité et les autorisations de l'utilisateur, puis d'autoriser ou de
refuser l'accès aux services.
 Connexion OpenID :OpenID est une couche d'identité au-dessus du protocole OAuth 2.0
qui étend OAuth2. Il permet l'authentification des utilisateurs à l'aide d'un service tiers
nommé fournisseurs d'identité. Les utilisateurs peuvent ensuite choisir de se connecter à
des sites Web qui acceptent le schéma d'authentification OpenID en utilisant leurs
fournisseurs OpenID préférés.
5.2.1 Comparaison des protocoles d'authentification unique

SAML OAuth2 Connexion OpenID
Qu'est-ce que Norme ouverte pour Norme ouverte Norme ouverte pour
c'est? l'autorisation et pour l'autorisation l'authentification
l'authentification
Histoire Développé par Développé par Développé par la
OASIS en 2001 Twitter et Google Fondation OpenID en
en 2006 2014
Cas SSO pour les Autorisation API SSO pour les
d'utilisation applications applications grand
principal d'entreprise public
Format XML JSON JSON
Tableau 4 : Comparaison des protocoles d'authentification unique

Après avoir exploré les trois protocoles, nous avons choisi OAuth2 comme protocole pour
implémenter la solution SSO pour deux raisons. Premièrement, parce qu'il s'agit d'un protocole
très connu utilisé par de nombreuses entreprises telles que Facebook et Google, il fournit
également les exigences nécessaires de manière sécurisée et simple.
49
Deuxièmement, selon la documentation Microsoft intitulée « Options d'authentification unique
dans Azure AD », il nous fournit un organigramme très détaillé, qui nous aide à décider quelle
méthode d'authentification unique correspond le mieux à notre situation. et comme nous
développons un nouvelle application cloud dans Azure AD, le protocole OAuth2 est le meilleur
choix dans notre cas.
Figure 18 : organigramme des méthodes SSO dans Azure AD
50
5.3 Architecture logique
La figure ci-dessous présente l'architecture logique du premier sprint « solution d'authentification
unique ».
Figure 19 : Architecture logique du premier sprint
5.4 Architecture physique

La figure ci-dessous présente l'architecture physique du premier sprint.
51
Figure 20 : Architecture physique du premier Sprint
Notre application est basée sur une architecture à 3 couches. Il s'agit d'un environnement basé sur
l'architecture client-serveur.
• Couche de présentation : elle présente la couche frontale qui interagit avec les utilisateurs et est
disponible via un navigateur Web.
• Couche Application : cette couche contient la logique métier fonctionnelle de la mise en œuvre
de l'autorisation et de l'authentification.
• Couche d'accès aux données : cette couche présente le serveur de base de données. c'est le
système de base de données de stockage qui donne accès aux informations stockées.
5.5 Choix technologiques
5.5.1 Frameworks et technologies utilisés

 Symfony :
« Symfony est un framework d'application Web PHP et un ensemble de composants/bibliothèques

PHP réutilisables. Il a été publié en tant que logiciel libre le 18 octobre 2005 et sous licence MIT.
[9]
Figure 21 : Logo Symfony
52
 Annuaire actif Azure :
« Azure Active Directory (Azure AD) est le service de gestion des identités et des accès basé sur
le cloud de Microsoft, qui aide vos employés à se connecter et à accéder aux ressources dans :
Des ressources externes, telles que Microsoft 365, le portail Azure et des milliers d'autres
applications SaaS. Les ressources internes, telles que les applications sur votre réseau d'entreprise
et votre intranet, ainsi que toutes les applications cloud développées par votre propre
organisation »[11]
Figure 22 : Logo Azure AD
5.5.2 Outils d'occasion et serveurs

 Php Tempête :
« PhpStorm est un IDE multiplateforme pour PHP, conçu par la société JetBrains pour créer des
applications Web. »
Figure 23 : Logo Php Storm
 Serveur Wamp :
« WampServer est un environnement de développement Web Windows. Il permet de créer des

applications web avec Apache2, PHP et une base de données MySQL. Parallèlement,
PhpMyAdmin vous permet de gérer facilement vos bases de données.[12]
53
Figure 24 : Logo du serveur Wamp
 Équipes Microsoft :
« Microsoft Teams est une plateforme de communication développée par Microsoft, elle propose
de nombreux services et fonctionnalités tels que le chat, les appels, la visioconférence et la
collaboration.
Nous avons utilisé cet outil dans tous les sprints de ce projet, afin de communiquer avec le
superviseur.
Figure 25 : Logo Microsoft Teams
 Trello :
« Trello est un outil de gestion de projet en ligne, lancé en septembre 2011. Il repose sur une
organisation de projets en tableaux de fiches répertoriant chacune une tâche précise.
Nous avons utilisé cet outil dans tous les sprints de ce projet, comme outil de gestion de notre
projet.
Image 26 : Logo Trello
6 Mise en place et validation du First Sprint
54
Dans cette partie, nous allons décrire les différentes phases de mise en œuvre de la solution
d'authentification unique dans une application SaaS symphony, en commençant par enregistrer
l'application dans Azure AD, en passant par la mise en œuvre du client OAuth2 pour l'autorisation
et l'authentification et la présentation du résultats.
6.1 Enregistrer une nouvelle application sur Azure AD

1. Connectez-vous auPortail Azure.
2. Sélectionnez le service Azure Active Directory, puis sélectionnez Inscriptions
d'applications > Nouvelle inscription.
3. Lorsque la page S'inscrire s'affiche, saisissez les informations d'inscription de
l'application : telles que le nom de l'application et les types de compte pris en charge et
l'URI de redirection.
4. Lorsque vous avez terminé, sélectionnez Enregistrer. Azure AD attribuera un ID client et
un ID locataire d'application uniques, et nous pouvons ajouter d'autres fonctionnalités,
notamment des certificats, une API secrète, des autorisations, etc.
5. Subvention implicite: nous configurons l'octroi implicite pour permettre à l'application de
demander un jeton directement depuis le point de terminaison d'autorisation. Et choisissez
le jeton que nous aimerions utiliser, le jeton d'accès dans notre cas.
6. De plus, nous avons ajouté un secret client à l'application, afin qu'elle puisse prouver son
identité lors de la demande d'un jeton.
7. Autorisations API: la liste des autorisations configurées doit inclure toutes les
autorisations dont l'application a besoin. Nous avons donc ajouté des autorisations à
l'application, telles que la lecture du profil utilisateur.
55
Figure 27 : Inscription d'application dans Azure AD
6.2 Implémenter un client OAuth 2.0 dans notre application

Tout d'abord, nous devons implémenter un bundle client OAuth pour l'application Symfony. Il
existe deux offres groupées : HWI/OAuthBundle et KnpU/OAuth2ClientBundle.
La différence entre eux est que le bundle hwi/oauth offre plus de fonctionnalités mais c'est un peu
difficile à installer. Le bundle knpU oauth2client prend plus de travail à configurer, mais nous
donne plus de contrôle de bas niveau.
Nous avons d'abord installé le bundle HWO/OAuth mais après l'avoir testé avec Azure AD, il y a
eu quelques problèmes et le plugin n'était pas stable avec notre fournisseur d'identité. Nous avons
donc installé le bundle Knpuniversity via le Composer dans notre application Symfony (V 4.4 car
ce bundle supporte la version 4.4 ou supérieure).
Ensuite, nous devons configurer le client. donc d'abord, nous téléchargeons la bibliothèque cliente
Azure AD. Deuxièmement, nous avons configuré le fournisseur avec les informations
d'identification que nous obtenons de l'application d'enregistrement Azure, telles que l'ID client,
le secret client, la route de redirection.
Figure 28 : Configuration du fournisseur
56
Troisièmement, le client que nous avons configuré doit avoir son service pour communiquer avec
le serveur Oauth2. Ainsi, nous implémentons la route et le contrôleur qui redirigent vers Azure
AD, notre contrôleur doit avoir deux services, le premier pour démarrer le processus de connexion
et le second est l'URL où Azure redirigera l'utilisateur une fois qu'il s'est connecté. Dans notre cas,
le lien http://localhost:8000/connect/azure redirigera l'utilisateur vers Azure AD.
Après avoir terminé le flux OAuth2, nous sommes en mesure de récupérer l'utilisateur, le jeton
d'accès et d'autres éléments que nous utiliserons dans notre phase d'authentification du système.
6.3 Mettre en œuvre l'authentification

À ce stade, le code permet à l'utilisateur de s'authentifier via le serveur Azure OAuth2 et nous
permet d'obtenir ses informations et son jeton d'accès.
Mais maintenant, nous voulons authentifier l'utilisateur dans notre application, et pour ce faire,
nous utiliserons l'authentificateur Guard au lieu de mettre tout le travail dans le contrôleur de la
dernière partie, et nous l'intégrerons au gestionnaire d'utilisateurs de FriendsOfSymfony afin de
créer un nouvel utilisateur.
La raison pour laquelle nous avons implémenté le bundle FosUser dans notre application est
l'architecture et les exigences de l'entreprise.
6.4 Résultats des tests

Dans cette partie, nous allons présenter le résultat de la solution d'authentification unique. La figure
ci-dessous présente la page de connexion de l'application, où l'utilisateur peut se connecter via
Azure.
Figure 29 : Page de connexion à l'application
57
Après avoir cliqué sur le bouton Connexion avec Azure, l'application redirige vers la page de
connexion du fournisseur avec certaines informations d'application dans l'URL, telles que l'ID
client, l'URL de redirection, le type de réponse et la portée.
Figure 30 : Lien de redirection
Figure 31 : Page de connexion du fournisseur
58
Figure 32 : entrez les informations d'identification pour le fournisseur
Figure 33 : séjour signé en question
59
Après la connexion avec Azure, le serveur d'autorisation affichera à l'utilisateur un formulaire de
consentement, basé sur les étendues demandées par le client. où il accorde (ou refuse)
l'autorisation.
Figure 34 : Autorisation demandée
Et enfin, l'utilisateur sera authentifié dans l'application comme le montre la figure ci-dessous.
Figure 35 : Connexion de l'utilisateur avec Azure AD
L'utilisateur sera ajouté à la base de données de l'application.
60
Figure 36 : Utilisateur ajouté à la base de données
Toutes les activités de connexion seront affichées dans les journaux Azure, comme illustré dans
la figure ci-dessous.
Figure 37 : journaux de connexion Azure AD
Conclusion
A la fin de ce sprint, et après avoir expliqué les étapes de développement de cette solution.
Qweeby aura la possibilité d'intégrer cette solution d'authentification unique dans son application
interne et d'en augmenter la sécurité et la gestion des accès utilisateurs.
61
Chapitre 4 : Deuxième sprint « Mettre
en œuvre un système de point de
terminaison de gestion des identités
interdomaines »
62
introduction
Dans ce chapitre, nous allons présenter le deuxième sprint nommé « Implémenter un système de
point de terminaison de gestion des identités interdomaines ». Tout d'abord, nous allons présenter
l'objectif du sprint, le backlog de sprint, la branche fonctionnelle et technique, nous allons
également expliquer quelques cas d'utilisation à l'aide de diagrammes. Ensuite nous expliquerons
les étapes de développement suivies afin de développer notre solution et enfin nous découvrirons
quelques phases de test et de validation.
Pour les administrateurs informatiques, l'approvisionnement automatique des comptes sur
différents systèmes a toujours été une panacée.
En tant qu'administrateur d'application Cloud d'une application d'entreprise dans Azure AD, vous
pourrez gérer le provisionnement des utilisateurs de votre application après avoir implémenté notre
solution "SCIM endpoint".
L'administrateur pourra créer un seul compte principal et l'ajouter à d'autres systèmes en utilisant
les mêmes informations utilisateur, où SCIM synchronisera automatiquement la gestion des
utilisateurs entre le fournisseur d'identité (Azure AD) et le fournisseur de services (l'application).
Cette solution fournira une méthode standard pour relier vos systèmes entre eux et facilitera
grandement la gestion des identités dans les applications et les services basés sur le cloud. De plus,
cela libérera votre équipe informatique des demandes répétitives des utilisateurs qui peuvent
désormais être automatisées.
63
Fonctionnalités Caractéristiques Identifiant Histoire de Tâche
d'identification User l'utilisateur
Story
2 Mettre en 2.1 En tant 2.1.1 Créer une
œuvre un qu'administrateur, application hors galerie
système pour le je souhaite et configurer les
point de configurer SCIM informations
terminaison de dans Azure AD et d'identification de
gestion des activer le l'application (URL du
identités provisionnement locataire, mappage,
interdomaines SCIM. étendue)
2.1.2 créer une fonction
getUserByQuery().
2.1.3 tester la connexion

d'approvisionnement
2.2 En tant 2.2.1 créer la fonction

qu'administrateur, getUserbyId ().
je souhaite ajouter
2.2.2 créer la fonction
un utilisateur
addUser().
2.2.3 tester la création.
En tant 2.2.4 créer la fonction

qu'administrateur, updateUser().
je souhaite mettre
à jour l'utilisateur. 2.2.5 tester la mise à jour

qu'administrateur, updateUser().
je souhaite
2.2.7 tester la mise à
jour.
64
désactiver
l'utilisateur.
qu'administrateur, deleteUser().
je souhaite 2.2.9 tester la
supprimer suppression.
l'utilisateur.
2.3 En tant 2.3.1 Créez l'interface
qu'administrateur, qui contient le générateur
je souhaite de jetons.
obtenir 2.3.2 fonction create
l'autorisation index() pour le
d'accès. générateur de jetons.
2.3.2 créer la fonction

generateAuth()
autorisation.
2.3.3 Testez le jeton

Porteur.
Tableau 5 : Backlog du deuxième sprint
Cette solution ne sera utilisée que par l'administrateur cloud de l'entreprise sur l'application
interne.
 Utilisateurs:Administrateur Cloud qui doit gérer le provisionnement des utilisateurs de

différentes applications.
65
La Solution que nous apportons dans ce sprint offre un ensemble de fonctionnalités répondant au
besoin de l'entreprise, qui sont dans notre cas :
 Permet à une norme d'automatiser l'approvisionnement du compte utilisateur, y

compris la création, la mise à niveau, la désactivation et la suppression du compte
utilisateur de manière plus sécurisée, plus fluide et moins chère sur une ou plusieurs
applications.
 Améliorez la visibilité et la sécurité des accès.

minimum.
 Maintenabilité: Notre code est écrit de manière claire, bien commenté et testé, comme
cette erreur facile dans le système peut être trouvée et corrigée.
 Extensibilité: Notre système peut être amélioré avec plus de couches de sécurité ou
modifier celui qui existe déjà.
4 Concevoir
4.1 Diagramme de cas d'utilisation
Dans cette partie, nous allons présenter un ensemble de cas d'utilisation que notre application doit
exécuter à travers un diagramme de cas d'utilisation.
Après s'être authentifié en tant qu'administrateur d'application cloud, l'administrateur doit tester la
connexion d'approvisionnement afin d'avoir l'autorisation de gérer l'approvisionnement des
utilisateurs. Ensuite, il peut ajouter un utilisateur, modifier des rôles, désactiver un utilisateur, les
66
supprimer et le point de terminaison SCIM synchronisera automatiquement la gestion des
utilisateurs entre les deux systèmes.
Figure 37 : Diagramme de cas d'utilisation du deuxième sprint
Description du scénario :
 L'administrateur s'authentifie avec Azure AD.

 L'administrateur teste la connexion et l'autorisation d'approvisionnement afin d'avoir accès.
 Le système affiche une liste des utilisateurs existants et provisionnés.
 L'administrateur Ajouter un utilisateur à l'interface de l'application Cloud Enterprise.
 Le système démarre un cycle de provisionnement toutes les 40 min, où il vérifie les
informations puis synchronise l'utilisateur.
 L'administrateur Met à jour un rôle d'utilisateur ou désactive un utilisateur.
 Le système démarre un cycle de provisionnement toutes les 40 minutes, au cours duquel il
vérifie les informations puis met à jour ou désactive l'utilisateur.
 Si un utilisateur a été désactivé pendant 30 jours, le système supprime automatiquement
l'utilisateur.
67
Description textuelle :
Cas d'utilisation Tester la connexion d'approvisionnement

Acteurs Administrateur d'applications cloud
Condition préalable L'acteur doit être authentifié et avoir l'accès pour gérer cette
application.
État du poste L'administrateur doit être autorisé à accéder au système
d'approvisionnement.
Scénario nominal 1- L'Admin copie le token actif du système autorisé
2- L'administrateur entre les informations d'identification
(URL du locataire et jeton) dans l'interface d'identification de
l'administrateur.
3- Le système vérifie les informations d'identification.
4- Le système donnera un accès à l'administrateur.
Scénario alternatif Les informations d'identification ne sont pas correctes, le système ne
donnera pas l'accès à l'administrateur.
Tableau 6 : Description textuelle de « Test de la connexion d'approvisionnement »
Cas d'utilisation provisionnement des utilisateurs

Acteurs Administrateur d'applications cloud
Condition préalable L'administrateur doit être autorisé à accéder au système
État du poste L'administrateur ajoute/met à jour un utilisateur et l'utilisateur est
provisionné avec succès.
Scénario nominal 1- L'administrateur Ajouter un utilisateur à l'interface de
l'application Entreprise
2- Le système ajoute l'utilisateur à l'interface
3- Le système importe les informations de l'utilisateur
68
4- Le système vérifie si l'utilisateur est dans le périmètre
(la portée dans notre cas : sont tous les utilisateurs qui sont dans
les fonctionnalités Utilisateur et Groupes)
5- Le système vérifie si l'utilisateur existe dans l'application
cible afin qu'il puisse décider de l'action à entreprendre.
(Action : créer ou mettre à jour)
6- Le système démarre le provisionnement des utilisateurs
toutes les 40 min.
(Si l'utilisateur n'existe pas dans l'application cible, il créera
l'utilisateur, si l'utilisateur existe dans l'application cible, le
système met à jour l'utilisateur)
Scénario alternatif L'utilisateur n'est pas dans le périmètre, le système ne démarre pas le
provisioning.
Tableau 7 : Description textuelle de « Provisionnement utilisateur »
4.2 Diagramme de classes

Lors de ce sprint, nous allons utiliser deux classes « User » et « Auth ». nous pouvons voir leurs
attributs dans la figure ci-dessous.
69
Figure 38 : Diagramme de classes SCIM
4.3 Diagramme de séquençage

Après avoir présenté la modélisation statique des fonctions du projet, nous passons au modèle
dynamique et nous préciserons les fonctionnalités les plus importantes de notre système en
concevant des Diagrammes de séquence qui sont « Authorization System », « User Provisioning
» et « SCIM provisioning ».
70
4.3.1 Système d'autorisation
Afin d'obtenir une autorisation d'accès, l'administrateur doit saisir le jeton de support valide. Le
scénario de cette étape est affiché ci-dessous.
Figure 39 : Diagramme de séquence (système d'autorisation)
4.3.2 Provisionnement des utilisateurs

Après avoir obtenu l'accès, l'administrateur doit démarrer un provisionnement d'utilisateurs.
71
Figure 40 : Diagramme de séquence (approvisionnement utilisateur)
4.3.3 Approvisionnement SCIM

Ce diagramme de séquence présente le scénario de provisionnement Azure AD SCIM, qui se
répète toutes les 40 minutes.
72
Figure 41 : Diagramme de séquence (approvisionnement SCIM)
5 Branche technique
5.1 Solutions SCIM
73
Il existe de nombreuses solutions SCIM qui peuvent nous aider à gérer facilement les identités des
utilisateurs dans les applications et services basés sur le cloud. Parmi eux, nous pouvons trouver
cette solution déjà définie dans le sprint précédent :
 Azure AD
 Okta
 OneLogin
5.1.1 Comparatif des solutions SCIM

Approvisionnement Approvisionnement
SCIM Active Approvisionnement OneLogin
Directory Okta
Client Oui Oui Oui
Serveur Oui Non Non
Open source Non Non Non
Développeur Microsoft Okta OneLogin
Tableau 8 : Comparaison des solutions SCIM

Pour l'implémentation SCIM dans l'application interne de Qweeby, nous avons utilisé la solution
Azure Active Directory SCIM Provisioning en raison de l'architecture de l'entreprise. En fait, les
applications internes de Qweeby sont intégrées et gérées par Azure AD. De plus, SCIM est pris en
charge dans Azure AD depuis 2016 et est de plus en plus utilisé pour provisionner des comptes
sur plusieurs systèmes tels qu'AWS.
5.2 Architecture logique
74
La figure ci-dessous montre l'architecture logique de notre application basée sur une API REST
backend.
Figure 42 : Architecture logique Second Sprint
5.3 Architecture physique

Le choix de l'architecture physique est très important pour le développement de notre solution.
La figure ci-dessous présente l'architecture physique.
Figure 43 : Architecture physique Second Sprint
75
Notre application est basée sur une architecture à 3 couches. Il s'agit d'un environnement basé sur
l'architecture client-serveur.
• Couche de présentation : dans ce projet, elle présente l'interface qui interagit spécifiquement avec
les utilisateurs finaux et elle est disponible via un navigateur Web ou Azure AD.
• Application Layer : dans ce projet, il contient l'API REST pour garantir la communication entre
Azure AD et notre application sur le Web.
• Couche d'accès aux données : dans ce projet, cette couche présente le serveur de base de données
d'hébergement. c'est le système de base de données de stockage qui donne accès aux informations
stockées.
5.4.1 Frameworks et technologies utilisés

Identique au sprint précédent, nous avons utilisé le framework Symfony et le service Azure AD
déjà définis dans le sprint précédent.
 Symfony
 Annuaire actif Azure
5.4.2 Outils et serveurs d'occasion

 Serveur Web Apache :
"Apache Web Server est un logiciel de création, de déploiement et de gestion de serveur Web open
source. Initialement développé par un groupe de programmeurs de logiciels, il est maintenant
maintenu par l'Apache Software Foundation. Apache Web Server est conçu pour créer des
serveurs Web capables d'héberger un ou plusieurs sites Web basés sur HTTP. Les fonctionnalités
notables incluent la possibilité de prendre en charge plusieurs langages de programmation, des
scripts côté serveur, un mécanisme d'authentification et la prise en charge de la base de
données.[13]
76
Figure 44 : Logo du serveur Web Apache
 Heidi SQL :
"Heidi SQL est un outil d'administration de base de données avec un éditeur SQL et un
générateur de requêtes."
Figure 45 : Logo Heidi SQL
 WinSCP :
« WinSCP (Windows Secure Copy) est un client open source SFTP, FTP et WebDAV pour
Microsoft Windows. son rôle principal est d'envoyer des fichiers entre l'ordinateur local et distant
de manière sécurisée.
Figure 46 : Logo WinSCP
 Facteur:
« Postman est un logiciel conçu pour tester les API de manière simple et concise. »
77
Figure 47 : Logo du facteur
 Php Tempête :
Identique au sprint précédent, nous avons utilisé PHP storm comme IDE pour PHP.
6 Étapes de développement
Dans la figure ci-dessous, nous expliquerons le provisionnement SCIM entre Azure AD et d'autres
applications.
Figure 48 : Approvisionnement SCIM avec Azure AD [14]
Pour fournir un provisionnement automatique à une application, nous devons développer et

intégrer un point de terminaison SCIM (API REST) avec le client Azure AD SCIM.
nous devons suivre ces étapes afin de permettre aux utilisateurs de s'approvisionner dans notre
application.
78
2. Understand 4. Integrate 5. Publish the
1. Design user
the Azure AD 3. Build a SCIM SCIM endpoint application to
and group
SCIM endpoint. with the Azure the Azure AD
schema
implementation AD SCIM client. app gallery
Figure 49 : Étapes d'approvisionnement SCIM
6.1 Phase 1 : Concevoir un schéma d'utilisateur et de groupe.
La première étape du développement du point de terminaison SCIM consiste à identifier l'objet

(utilisateurs/groupes), les attributs dont l'application a besoin et un schéma afin que SCIM puisse
gérer les utilisateurs et les groupes.
 Ressources SCIM :
SCIM propose un ensemble de ressources partagées via un protocole HTTP. Les ressources
peuvent être Utilisateur et Groupe ou autres. nous pouvons personnaliser les attributs de
l'utilisateur sous Enterprise User.
La figure ci-dessous montre le modèle objet de SCIM 2.0. Comme présenté ci-dessous, Resource
est le dénominateur commun et tous les objets SCIM en sont extraits.
Figure 50 : Ressources SCIM
 Schéma SCIM :
Avec Azure AD, le schéma utilisateur principal ne nécessite que trois attributs : id (identifiant
défini par le fournisseur de services), externalId (identifiant défini par le client) et meta
(métadonnées en lecture seule gérées par le fournisseur de services), les autres attributs dépendent
79
des besoins de l'application . Pour concevoir notre schéma, nous devons suivre les étapes ci-
dessous :
1. Répertoriez les attributs requis par votre application.

2. Mapper les exigences de l'application sur la norme SCIM
3. Mappez les attributs SCIM aux attributs Azure AD
Le tableau ci-dessous montre un exemple qui explique les étapes mentionnées ci-dessus :
Étape 1 : Déterminez les Étape 2 : Mappez les Étape 3 : mapper les

attributs requis par votre exigences de l'application attributs SCIM aux
application sur la norme SCIM attributs Azure AD
identifiant Nom d'utilisateur userPrincipalName
prénom nom.nom donné prénom
nom de famille nom.nom nom de famille
travail Courrier E-mails[type eq Courrier

« travail »].valeur
statut actif isSoftDeleted
Tableau 9 : Décrivez les attributs nécessaires
Le schéma présenté ci-dessus serait défini dans la charge utile JSON comme indiqué ci-dessous.
le JSON qui fait que la magie opère.
80
Figure 51 : schéma Json
 CARTOGRAPHIE SCIM:
Les attributs dans Azure AD sont généralement mappés à leurs propriétés dans le protocole SCIM.
mais nous pouvons personnaliser la façon dont les attributs sont mappés entre Azure AD et le point
de terminaison SCIM avec les fonctionnalités de MAPPING fournies par Azure Active Directory
Provisioning.
 POINTS DE FINITION SCIM :
Il existe de nombreux points de terminaison fournis par SCIM. chacun d'eux a un rôle et une
performance spécifiques. Le tableau suivant décrit les différences entre eux.
POINT DE FIN LA DESCRIPTION

/Utilisateur Effectuez des opérations CRUD sur un objet utilisateur.
/Grouper Effectuez des opérations CRUD sur un objet de groupe.
/ServiceProviderConfig Fournit des détails sur les fonctionnalités de la norme SCIM qui
sont prises en charge,
/Types de ressources Spécifie les métadonnées sur chaque ressource
81
/Schémas L'ensemble d'attributs pris en charge par chaque client et
fournisseur de services peut varier.
/Masse Les opérations en bloc vous permettent d'effectuer des
opérations sur une grande collection d'objets de ressources en
une seule opération.
Tableau 10 : déterminer les critères d'évaluation à développer
6.2 Phase 2 : comprendre l'implémentation d'Azure AD SCIM
Dans cette section, nous allons décrire comment le client Azure AD SCIM est développé et
comprendre comment concevoir nos demandes et réponses de protocole SCIM.
Lors de la construction de notre application, nous devons respecter les exigences du protocole
SCIM, que l'on peut retrouver dans les documents RFC 7644 (System for Cross-domain Identity
Management : Protocol) [15]
Il existe de nombreuses exigences à respecter pour assurer la compatibilité avec Azure AD, nous
allons en présenter quelques-unes :
 Prend en charge la création d'utilisateurs et éventuellement de groupes, conformément à la

section 3.3 du protocole SCIM.
 Prend en charge la modification des utilisateurs ou des groupes avec des demandes
PATCH, conformément à la section 3.5.2 du protocole SCIM.
 Prend en charge les requêtes d'utilisateurs ou de groupes, conformément à la section 3.4.2
du protocole SCIM. Par défaut, les utilisateurs sont récupérés par leur identifiant et
interrogés par leur nom d'utilisateur et externalId, et les groupes sont interrogés par
displayName.
6.2.1 Requêtes et réponses du protocole SCIM :

Nous pouvons trouver dans le document RFC 7644, une ligne directrice sur la façon de modéliser
les requêtes et la requête de réponse attendue.
82
Il s'agit des opérations utilisateur que nous devons développer dans le point de terminaison SCIM
afin d'activer le provisionnement de l'utilisateur.
Opérations utilisateur
 Obtenir l'utilisateur (demande/réponse)

 Obtenir l'utilisateur par requête (Demande / Réponse)
 Obtenir l'utilisateur par requête - Aucun résultat (Requête/Réponse)
 Créer un utilisateur (demande/réponse)
 Mettre à jour l'utilisateur [Propriétés à plusieurs valeurs] (Demande / Réponse)
 Mettre à jour l'utilisateur [Propriétés à valeur unique] (Demande/Réponse)
 Désactiver l'utilisateur (demande/réponse)
 Supprimer l'utilisateur (demande/réponse)
6.3 Phase 3 : création d'un point de terminaison SCIM
Dans cette partie, nous allons commencer le développement du point de terminaison SCIM. Après
cela, nous avons conçu notre schéma et compris l'implémentation Azure AD SCIM dans les phases
précédentes.
6.3.1 Gestion de l'authentification des points de terminaison

Le point de terminaison SCIM doit être autorisé, ce qui signifie que chaque demande d'Azure AD
doit être autorisée avec un jeton de support.
Nous avons développé un système autorisé qui peut fournir au système SCIM un jeton porteur
valide et actif tous les 30 jours.
L'authentification du porteur (également appelée authentification par jeton) est un schéma

d'authentification HTTP qui implique des jetons de sécurité appelés jetons du porteur. Le nom
« Authentification du porteur » peut être compris comme « donner accès au porteur de ce jeton ».
Le jeton du porteur est une chaîne, généralement générée par le serveur en réponse à une demande
de connexion. Le client doit envoyer ce jeton dans l'en-tête d'autorisation lorsqu'il fait des
demandes aux ressources protégées. [17]
83
Figure 51 : Authentification du porteur
Mais dans notre cas, le jeton du porteur est généré par notre application et c'est à cause de
l'architecture SCIM dans Azure AD qui nous permet de créer notre propre jeton et aussi à cause
de l'exigence Qweeby. Le jeton du porteur ne doit être utilisé que sur HTTPS (SSL).
6.4 Phase 4 : Intégrer le point de terminaison SCIM avec le client

Azure AD SCIM
Chaque application prenant en charge le protocole SCIM peut être intégrée à Azure AD avec la
fonctionnalité « application sans galerie » dans Azure AD.
Après l'intégration, Azure AD démarre un processus de synchronisation toutes les 40 minutes, où

il interroge le point de terminaison SCIM de l'application pour les utilisateurs et groupes autorisés,
et les crée ou les modifie en fonction de la tâche.
Voici les étapes pour connecter une application qui prend en charge SCIM :
1. Connectez-vous au portail Azure Active Directory.

2. Sélectionnez Applications d'entreprise dans le volet de gauche.
3. Sélectionnez Nouvelle application > Tout > Application hors galerie.
4. Entrez le nom de votre application, puis Ajouter pour créer un objet d'application. nous
pouvons l'ouvrir plus tard dans l'écran de gestion de l'application.
5. Dans l'écran de gestion des applications, sélectionnez Provisioning.
6. Dans le menu Mode d'approvisionnement, sélectionnez Automatique.
7. Dans le champ URL du locataire, saisissez l'URL du point de terminaison SCIM de
l'application.
8. si le point de terminaison SCIM nécessite un jeton de support, ajoutez un jeton secret.
9. Sélectionnez Tester la connexion pour qu'Azure Active Directory tente de se connecter au
point de terminaison SCIM. Si la tentative échoue, des informations sur l'erreur s'affichent.
84
10. Si les tentatives de connexion à l'application réussissent, sélectionnez Enregistrer pour
enregistrer les informations d'identification de l'administrateur.
11. Dans la section Mappages, vous pouvez modifier les attributs, les attributs correspondent
aux propriétés utilisées pour faire correspondre les utilisateurs et les groupes de votre
application pour les opérations de mise à jour.
12. le champ Portée définit quels utilisateurs et groupes sont synchronisés.
13. Activez l'état d'approvisionnement.
14. Enregistrez pour démarrer le service de provisionnement Azure AD.
6.5 phase 5 : publier l'application dans la galerie d'applications Azure

AD
Au cas où l'application développée serait utilisée par plusieurs locataires, elle peut être ajoutée à
la galerie d'applications Azure AD.
7 Mise en place et validation du deuxième Sprint

7.1 Tester la connexion
En tant qu'administrateur, Scénario 1 Scénario 2

je souhaite tester la
connexion
Pas L'administrateur entre les L'administrateur entre les
informations d'identification informations d'identification
valides. incorrectes.
Comportement Les informations L'administrateur reçoit une
d'identification fournies sont notification avec un message
autorisées pour activer le d'accès non autorisé.
provisionnement.
85
Tableau 11 : scénarios de connexion du deuxième test de sprint
 Résultat du scénario 1 :
L'administrateur doit accéder à une interface d'application sécurisée pour obtenir le jeton de
support actif.
Figure 52 : Génération du jeton du porteur dans l'application Web
L'administrateur doit copier le jeton actif valide dans le champ du jeton secret. Et devez entrer le
lien URL du locataire valide. Le lien URL du locataire a un format spécifique qui doit être
respecté dans le processus de développement qui est : https:// <>/scim
86
Figure 53 : connexion de test valide au point de terminaison SCIM
 Résultat du scénario 2 :
L'administrateur entre une URL de locataire invalide qui ne respecte pas le bon format.
Figure 54 : Connexion de test non valide en raison d'une URL de locataire non valide
87
L'administrateur entre un jeton invalide.
Figure 55 : Connexion de test non valide en raison d'un jeton non valide
7.2 Provisionnement des utilisateurs :

Afin d'activer le provisionnement automatique des utilisateurs dans notre application, nous
devons d'abord démarrer le cycle de provisionnement. Deuxièmement, nous pouvons commencer
par ajouter un utilisateur au périmètre identifié (Utilisateurs et groupes dans notre cas). Ensuite,
nous devons attendre le cycle suivant (toutes les 40 minutes) pour que le système puisse capturer
le changement et synchroniser les utilisateurs entre le fournisseur d'identité (Azure AD) et le
fournisseur de services (notre application).
88
Figure 56 : Démarrer l'approvisionnement
7.2.1 Ajouter un utilisateur
Figure 57 : Ajouter un utilisateur à l'interface des utilisateurs et des groupes
89
Figure 58 : Ajouter une affectation
Comme nous l'avons mentionné ci-dessus, généralement après avoir ajouté un utilisateur à la
portée, nous attendons le provisionnement automatique pour synchroniser le changement toutes
les 40 minutes, mais à des fins de test et pour comprendre ce qui se passe à l'arrière du système,
Azure AD nous fournit une fonctionnalité très intéressante et utile appelée Provision on demand.
Cette fonctionnalité nous permet de provisionner un utilisateur à la demande et de créer ou
mettre à jour rapidement le compte de l'utilisateur dans l'application cible en fonction de la
configuration d'approvisionnement.
Figure 59 : Fourniture à la demande pour ajouter un utilisateur
90
La figure ci-dessous présente le résultat de la mise à disposition à la demande, comme nous
pouvons le voir, il y a 4 étapes principales que le client SCIM va lancer avant d'effectuer toute
action de mise à disposition.
 Importer l'utilisateur :Cette étape montre l'utilisateur récupéré du système source et les
propriétés de l'utilisateur dans le système source.
 Déterminer si l'utilisateur est dans la portée: cette étape affiche les conditions de
portée qui ont été évaluées et celles que l'utilisateur a réussi ou échoué.
 Faites correspondre l'utilisateur entre le système source et cible :Cette étape montre
si l'utilisateur a été trouvé dans le système cible ainsi que les propriétés de l'utilisateur
dans le système cible.
 Faire une action:Cette étape montre l'action qui a été effectuée dans l'application cible,
telle que la création d'un utilisateur ou la mise à jour d'un utilisateur.
Figure 60 : Provision on demand crée avec succès un utilisateur
91
Après l'approvisionnement SCIM, l'utilisateur est ajouté avec succès à la base de données de
notre application.
Figure 61 : Utilisateur ajouté à la base de données de notre application
La fonctionnalité de journaux d'approvisionnement Azure AD nous permet de consulter toutes

les actions appliquées par le système d'approvisionnement, de manière très détaillée et en cas de
problème, cela nous aide à découvrir la cause du problème. La figure ci-dessous présente le
résultat de l'action précédente.
Figure 62 : Journaux de provisionnement Azure AD (créer)
7.2.2 Mettre à jour le rôle de l'utilisateur
Figure 63 : Modifier l'utilisateur dans l'interface des utilisateurs et des groupes
Dans la figure ci-dessous, nous avons changé le rôle de l'utilisateur d'utilisateur en

administrateur.
92
Figure 64 : Modifier l'affectation
Le rôle de l'utilisateur est modifié avec succès dans notre application 'base de données.
Figure 65 : Edité par l'utilisateur dans la base de données de notre application
La figure ci-dessous présente les journaux de l'action précédente dans Azure AD.
Figure 66 : Journaux de provisionnement Azure Ad (mise à jour)
7.2.3 Désactiver l'utilisateur

Dans l'approvisionnement Azure AD, il existe deux types de suppression, la suppression
logicielle et la suppression définitive.
 Suppression douce: signifie désactiver l'utilisateur, dans ce cas l'utilisateur perd son
accès à l'application.
 Suppression définitive: signifie supprimer complètement l'utilisateur de l'application.
93
Figure 67 : Suppression logicielle de l'utilisateur dans l'interface Utilisateurs et groupes
Comme le montre la figure ci-dessous, une fois que nous avons supprimé un utilisateur, il est
supprimé de manière logicielle et son statut change pour désactiver l'utilisateur.
Figure 68 : Suppression logicielle de l'utilisateur dans la base de données de notre

application
L'utilisateur est correctement désactivé dans les journaux d'approvisionnement Azure AD.
Figure 69 : Journaux de provisionnement Azure AD (Désactiver)
7.2.4 Supprimer l'utilisateur

Comme nous l'avons mentionné dans la partie précédente, la suppression définitive signifie
supprimer complètement l'utilisateur de l'application. Dans l'approvisionnement Azure AD, la
suppression définitive prend des mesures 30 jours après la suppression définitive de l'utilisateur.
94
Malheureusement, nous ne pouvons pas tester cette étape avec Azure AD SCIM Client car cela
prend du temps.
Mais comme nous avons déjà développé la fonction hard delete, nous la testons avec postman.
Avec postman, nous avons d'abord créé un utilisateur de test, nous ne pouvons pas utiliser un
utilisateur réel car cela affectera la synchronisation entre le client SCIM et le point de
terminaison SCIM.
Figure 70 : créer un utilisateur de test à supprimer définitivement
Nous avons supprimé l'utilisateur avec facteur et reçu la réponse requise (204 Pas de contenu).
Et bien sûr, l'utilisateur a été supprimé dans la base de données.
Figure 71 : Suppression définitive d'un utilisateur du facteur
Conclusion
95
Dans ce chapitre, nous avons présenté un aperçu détaillé du deuxième sprint où nous avons
expliqué la phase fonctionnelle et technique du sprint. Aussi, nous avons évoqué les étapes de
développement du sprint et donné quelques cas d'utilisation à l'aide de diagrammes et enfin les
phases de test et de validation.
Désormais, Qweeby aura la possibilité d'intégrer la solution SCIM Endpoint dans son application
interne pour une meilleure gestion des identités.
96
Chapitre 5 : Troisième Sprint « Mettre
en place une solution de centralisation
des logs »
introduction
Dans ce chapitre, nous allons présenter le troisième sprint intitulé "Mettre en place une solution
de centralisation des logs". Tout d'abord, nous allons présenter l'objectif du sprint, le backlog du
sprint, la branche fonctionnelle et technique, la phase de conception, nous allons également
expliquer les composants des technologies utilisées. et enfin, nous présenterons les phases de
mise en œuvre et de validation.
L'objectif de ce sprint est de mettre en œuvre une solution de centralisation des journaux qui sera
capable de collecter des données à partir d'une source de sortie spécifique et de les transformer
sous la forme nécessaire, dans notre cas, l'entrée est un fichier journal qui contient les factures de
97
l'entreprise mises en non manière structurée. Notre objectif est donc de le transformer en quelque
chose de plus structuré et consultable. Après cela, nous pourrons explorer ces données de manière
simple et facile à l'aide de l'interface Web Kibana.

Fonctionnalité Identifiant
d'identification Caractéristique User Histoires Tâche
Story d'utilisateurs
Mettre en place 3.1 Installez 3.1.1 Installer Centos7
une solution de l'environnement. dans une VM
centralisation 3.1.2 Installer
des logs Elasticsearch
3.1.3 Installer Kibana
3.1.4 Installer Logstash
3.2 Configurez 3.2.1 Configurer
3 l'environnement. Elasticsearch
3.2.2 Configurer Kibana
3.2.3 Logstash de
configuration
3.3 Collecte des 3.3.1Collectez les
données. données du plugin
d'entrée.
3.4 Traitement des 3.4.1 Fusionnez les
données. messages multilignes en
un seul événement à
l'aide du plug-in de codec
multiligne et du script
d'expression régulière.
98
3.4.2 analyser les
données de journal non
structurées en quelque
chose de structuré et
interrogeable à l'aide du
plugin de filtre Grok et du
script d'expression
régulière.
3.5 Envoi des données. 3.5.1 Configurez la
destination dans la
section de sortie.
3.6 Visualisez les 3.6.1 rechercher,
données. analyser et visualiser les
données stockées dans
les index Elasticsearch.
Tableau 12 : backlog du troisième sprint
Cette solution ne sera utilisée que par les salariés de l'entreprise sur l'application interne.
 Utilisateurs:employé qui doit gérer les journaux d'une application.

La Solution que nous apportons dans ce sprint offre un ensemble de fonctionnalités répondant au
besoin de l'entreprise, qui sont dans notre cas :
99
 Mettre en œuvre une solution de centralisation des journaux pour faciliter les audits
et permettre à l'utilisateur de rechercher facilement dans les journaux de manière
structurée et simple.

minimum.
 Extensibilité: Notre système peut être amélioré avec plus de fonctionnalités ou modifier
celui qui existe déjà.
 Évolutivité : Notre système peut gérer une quantité croissante de travail en ajoutant des
ressources au système.
4 Branche technique
4.1 Gestion des journaux solutions
 Pile ELK :
« ELK est l'acronyme de trois projets open source : Elasticsearch, Logstash et Kibana.
Elasticsearch est un moteur de recherche et d'analyse. Logstash est un pipeline de traitement de
données côté serveur qui ingère les données de plusieurs sources simultanément, les transforme,
puis les envoie à une « cachette » comme Elasticsearch. Kibana permet aux utilisateurs de
visualiser les données avec des tableaux et des graphiques dans Elasticsearch »[dix]
Figure 72 : Logo ELK Stack
 Graylog :
100
« Graylog est un puissant outil open source pour centraliser et gérer de grandes quantités de
données de journaux provenant de différentes sources. cette solution de gestion centralisée des
logs composée de trois outils : Elasticsearch qui est le moteur d'indexation des documents,
Mongodb qui est une base de données NoSQL permettant de stocker la configuration et quelques
autres paramètres et Graylog-server et graylog-web-interface pour la collecte et la visualisation
des logs. "
Figure 73 : logo graylog
4.1.1 Comparatif des solutions de gestion de logs :

Pile ELK Graylog
Alerte Non (payant) Oui
Analyse Avancée Avancée
Représentation graphique Avancée De base
Plugins disponibles De nombreux Quelque
Courbe d'apprentissage Haute Meugler
Installer Long Rapide
Tableau 13 : Comparaison des solutions de gestion des logs

La pile ELK et Graylog sont deux solutions très populaires pour la gestion des journaux et offrent
toutes deux un nombre similaire de fonctionnalités communes. Le choix de la bonne solution
dépend des besoins de l'organisation. par conséquent, nous avons choisi la solution de pile ELK
car l'entreprise utilise déjà cette solution, et notre objectif est d'améliorer cette solution en utilisant
les mêmes technologies.
101
4.2 Architecture de vitesse
La figure ci-dessous présente une architecture globale de notre solution de centralisation des
journaux utilisant ELK Stack.
Figure 74 : Architecture du troisième sprint
L'architecture est composée de 4 objets principaux : Logs, Logstash, Elasticsearch et Kibana.
 Journaux: dans ce projet, il présente le fichier journal d'entrée qui contient les données à
analyser et c'est un fichier journal des factures de l'entreprise.
102
 Logstash: il collecte les journaux. puis il les analyse et les transforme sous la forme
nécessaire.
 Recherche élastique: où toutes les données transformées de Logstash sont stockées,
recherchées et indexées.
 Kibana: Kibana utilise la base de données Elasticsearch pour découvrir, visualiser et
gérer.
4.3.1 Technologies utilisées

 Logstash
« Logstash est un pipeline de traitement de données côté serveur qui ingère des données provenant
de plusieurs sources simultanément, les transforme, puis les envoie à une « cachette » comme
Elasticsearch. »
Figure 75 : Logo Logstash
 Recherche élastique
« Elasticsearch est un moteur de recherche et d'analyse. »
Figure 76 : Logo Elasticsearch
 Kibana
103
« Kibana permet aux utilisateurs de visualiser les données avec des tableaux et des graphiques
dans Elasticsearch. »
Figure 77 : Logo Kibana
4.3.2 Outils d'occasion

 Poste de travail VMware :
« VMware Workstation est un outil de virtualisation de poste de travail créé par la société
VMware, il peut être utilisé pour mettre en place un environnement de test pour développer de
nouveaux logiciels, ou pour tester l'architecture complexe d'un système d'exploitation avant de
l'installer réellement sur une machine physique.
Figure 78 : Logo VMware Workstation
5 Les composants de la pile ELK

5.1 Recherche élastique
5.1.1 Présentation d'Elasticsearch

Elasticsearch est un moteur de recherche et d'indexation open source de nouvelle génération. Basé
sur la bibliothèque Apache Lucene, ce moteur de recherche propose des fonctions avancées telles
que les recherches par coordonnées géographiques, l'analyse et la catégorisation par agrégations,
le filtrage des résultats ou encore la recherche sur plusieurs index et différents types de documents.
Conçu pour le Cloud, Elasticsearch a été spécialement conçu pour indexer de très gros volumes de
données tout en garantissant une mise à l'échelle efficace et une haute tolérance aux pannes.
5.1.2 Les fonctionnalités d'Elasticsearch

104
 Réplication des données :
Dans un cluster Elasticsearch, lorsque vous avez plusieurs nœuds, les données qui y sont stockées
sont répliquées entre eux. Cela permet entre autres de conserver toutes les données en cas de perte
d'un nœud. La réplication se fait automatiquement. L'ajout d'un nœud ou d'une partition déclenche
une réplication automatique.
 Recherche en temps réel et contextuelle :
La recherche dans Elasticsearch est l'une des plus performantes du marché. On parle de recherche
distribuée. Lorsque nous exécutons une recherche sur le nœud principal, le nœud principal renvoie
la recherche sur les autres nœuds et les résultats sont renvoyés au demandeur. Une des
particularités du moteur est qu'il regroupe les éléments indexés selon le contexte des données.
 Facettes :
Elasticsearch prend en charge les facettes, qui sont des regroupements de résultats de recherche.
Cela permet aux utilisateurs d'avoir une vue agrégée de leurs données. Il existe plusieurs types de
facettes disponibles dans Elasticsearch, notamment :
 Filtre : renvoie le nombre de hits correspondant à un filtre.

 Distance géographique : regroupe les données par intervalle de distance géographique.
 Requête : renvoie le nombre de hits correspondant à une requête.
 Termes : renvoie les termes les plus fréquents.
 Statistique : permet de calculer la somme, le minimum, la moyenne, le maximum, la
variance, etc. sur des données numériques.
5.2 Logstash
5.2.1 Présentation de Logstash

Cet outil est utilisé pour configurer l'analyse des journaux. Les points d'entrée utilisés pour
récupérer les informations sont définis via un fichier de configuration. Plusieurs types de point
105
d'entrée peuvent être choisis, dont les fichiers : dans ce cas, on indique à Logstash où lire les
fichiers journaux. Logstash lit ensuite ces fichiers ligne par ligne. Il est alors possible d'appliquer
des "filtres" sur ces lignes : il ne s'agit pas seulement de sélectionner certaines informations et d'en
écarter d'autres, mais aussi d'effectuer des opérations plus complexes, comme le mappage.
Par exemple, dans le cas d'un journal avec UID, il est possible de résoudre l'ID en « Nom, prénom
» en passant un appel externe. Vous pouvez également extraire des informations spécifiques et les
stocker dans des champs spécifiques, ou même exécuter du code Ruby. Autre exemple : le filtre
GROK permet d'extraire des informations à l'aide de RegEx (expressions régulières) pour
correspondre à certains modèles, comme un numéro de version.
Une fois les points d'entrée et les filtres définis, nous indiquons à Logstash où envoyer les
résultats : plusieurs points de sortie, ou adaptateurs, peuvent être définis.
Le plus utilisé est Elasticsearch, mais il peut s'agir d'une DB, ou d'un fichier... Logstash est bien
un ETL (Extract Transform Load, des entrées, des sorties, un processus entre les deux).
5.2.2 Le principe fonctionnel de Logstash

Logstash fonctionne sur un principe simple, un peu comme un routeur de messages. On peut parler
de chaînes de maillons entre ces différents composants.
Inputs Encoders / Filters Outputs

Decoders
•/var/log/*.log •multiline •data •elasticsearch

•database logs •json •grok •nagios
•apache logs •csv •geoip •zabbix
•nginx logs •plain •mongodb
Figure 79 : Principe de fonctionnement du Logstash
Tous les différents éléments que nous allons détailler sont implémentés sous forme de plugins, ce
qui facilite leur ajout à Logstash. La liste de ces plugins continue de s'allonger.
106
 Contributions: Logstash accepte tout ce qui peut être représenté sous forme de chaîne en
entrée ; texte, nombre, date et des plugins plus génériques sont bien sûr disponibles comme
Syslog.
 Encodeurs / Décodeurs: Les codecs permettent de standardiser et de conditionner un
ensemble de filtres. Il existe de nombreux codecs, notamment multiligne, qui fusionnent
les messages multilignes en un seul événement.
 Filtres: Les filtres vous permettent de formater tout message arrivant dans Logstash. Par
format, on entend découper un message en plusieurs parties et inversement, formater les
dates, standardiser le nom des champs, mais pas que ça. il existe des filtres pour créer des
sommes de contrôle, extraire des nombres, supprimer des messages avant stockage et bien
sûr Grok.
Grok est l'un des outils les plus puissants qui nous permet de structurer n'importe quel
message. Sa force réside dans sa capacité à construire des expressions complexes à partir
d'expressions régulières simples.
% {IP : client}
Dans l'exemple ci-dessus, IP est une expression Grok qui capture l'adresse IP
correspondant aux expressions régulières.
Mais parfois, Logstash n'a pas de modèle dont nous avons besoin. pour cela, nous pouvons
créer notre propre plugin personnalisé. nous pouvons utiliser la syntaxe Oniguruma qui
nous permettra de faire correspondre un morceau de texte et de l'enregistrer en tant que
champ :
(?<field_name>le modèle ici)
 Les sorties: Une fois que Logstash a terminé l'opération des messages, il peut maintenant
être routé vers les plugins de sortie qui permettent d'envoyer des messages à un outil tiers,
généralement c'est Elasticsearch.
5.3 Kibana
5.3.1 Présentation de Kibana

Kibana est le dernier outil de l'application d'analyse de logs : les données sont analysées dans
Logstash, stockées dans Elasticsearch, mais pas encore exploitables. Kibana, qui est une interface
107
homme-machine nous permettant de consulter des documents d'une base de données Elasticsearch
et de les sortir vers des tableaux de bord.
5.3.2 Le principe fonctionnel de Kibana

Kibana est une interface Web qui se connecte au cluster Elasticsearch, et permet de faire des
requêtes en mode texte pour générer des graphiques (histogrammes, barres, cartes, etc.), ou des
statistiques. De nombreux composants graphiques sont disponibles pour donner une dimension
visuelle aux données stockées dans Elasticsearch.
6 Mise en place et Validation du troisième sprint

6.1 Mise en place de l'environnement
La solution de centralisation des journaux ELK stack peut être installée à l'aide de différentes
méthodes et sur une variété de systèmes d'exploitation et d'environnements. Dans ce projet, nous
avons choisi d'installer la pile sur une machine virtuelle Centos 7, une distribution qui relève de la
fondation Linux. Nous avons choisi cette version car elle est stable et conviviale.
6.1.1 Installation de machine virtuelle

En utilisant la plate-forme de virtualisation VMware Workstation Pro 14. nous avons créé une
machine virtuelle contenant le système d'exploitation centos 7.
6.2 Installation de la pile ELK

Après avoir installé la machine virtuelle Centos 7, nous passerons en revue tous les composants
nécessaires pour créer une pile ELK fonctionnelle.
6.2.1 Installation de Java 8

Elasticsearch et Logstash nécessitent l'installation de Java, nous allons donc installer une version
récente d'OpenJDK 8 Java car c'est ce que recommande Elasticsearch.
6.2.2 Installation d'Elasticsearch

Tout d'abord, nous devons ajouter la clé de signature Elastic afin que le package téléchargé
puisse être vérifié.
108
Ensuite, nous devons créer et configurer le fichier de configuration du référentiel
elasticsearch.repo dans /etc/yum.repos.d/ et l'étape suivante consiste à installer Elasticsearch.
6.2.3 Installation de Kibana

Kibana utilise la même clé GPG qu'Elasticsearch, nous n'avons donc pas besoin de réimporter la
clé. De plus, le package Kibana se trouve dans le même référentiel de pile ELK qu'Elasticsearch.
il n'est donc pas nécessaire de recréer un autre fichier de configuration du référentiel. Ensuite,
nous installons Kibana.
6.2.4 Installation de Logstash

Identique aux autres parties de la pile ELK, Logstash utilise la même clé GPG et le même
référentiel. Il ne reste donc plus qu'à installer Logstash sur CentOS 7.
6.3 Configuration de la pile ELK

Après avoir installé les services ELK-stack, ils doivent maintenant être configurés pour qu'ils
puissent recevoir et analyser les journaux.
6.3.1 Configuration d'Elasticsearch

La configuration d'Elasticsearch utilise un fichier de configuration appelé "elasticsearch.yml" qui
nous permet de configurer des paramètres généraux tels que le nom du nœud et les paramètres
réseau (adresse IP de l'hôte et numéro de port)
Figure 80 : Configuration d'Elasticsearch
Comme le montre la figure ci-dessus, nous avons associé Elasticsearch à l'adresse IP localhost
local et avons également affecté le port 9200 en tant que port http.
109
6.3.2 Configuration Kibana
Il est maintenant temps d'appliquer les paramètres nécessaires de Kibana en modifiant son fichier
de configuration "Kibana.yml" qui existe sous le répertoire /etc/kibana/kibana.yml. Comme le
montre la figure ci-dessous, les paramètres spécifiques indiquent à Kibana quelle connexion
Elasticsearch se connectera et quel port sera-t-il utilisé. Cette adresse sera utilisée plus tard afin
que nous puissions nous connecter à l'interface graphique ELK-stack et visualiser les logs.
Figure 81 : Configuration de Kibana
6.3.3 Configuration de Logstash

Le fichier de configuration Logstash est au format JSON, il se trouve dans /etc/logstash/conf.d.
En fait, la configuration dépend largement du cas d'utilisation et des plugins utilisés. dans la partie
suivante, nous l'expliquerons plus en détail.
6.4 Analyse du journal
6.4.1 Configurations de script de journal

Pour cette étape, nous avons créé un fichier script appelé log.conf qui doit être exécuté lors du
démarrage du serveur ELK-stack, ce fichier contient les paramètres nécessaires pour recevoir,
indexer, filtrer et rechercher les logs envoyés par le fichier logs.
Entrée/Fichier: Un plugin d'entrée permet à une source spécifique d'événements d'être lue
par Logstash et dans notre projet, nous diffusons des événements à partir d'un fichier.
Sortir: Logstash, après avoir collecté les journaux, ils doivent être indexés dans une base
de données et un moteur de recherche Elasticsearch. Cette tâche est gérée par la section de
110
sortie, où nous avons indiqué le nom de l'index, l'adresse IP et le port du moteur de
recherche Elasticsearch.
Codec multiligne: Le premier problème que nous avons rencontré était que nos entrées
sont multi-lignes et pas de ligne de journal unique. pour résoudre ce problème, nous avons
utilisé le plugin Logstash codec Multiline pour réduire les messages multilignes et les
fusionner en un seul événement. pour ce faire, nous avons remarqué que chaque facture se
termine par la même ligne de fin et un format de date. ainsi, nous avons créé une expression
régulière pour cette ligne, et nous avons demandé au plugin de codec multiligne de créer
un événement chaque fois qu'il trouve une ligne de journal qui termine cette expression
régulière. comme ça, nous pouvons fusionner chaque facture en un seul événement.
Filtre Grok: le deuxième problème était de savoir comment filtrer un événement avec son
ID. notre fichier journal contient des données non structurées et pour résoudre ce problème,
nous avons utilisé le filtre Grok du plugin Logstash.
Grok est un excellent moyen d'analyser des données de journal non structurées en quelque
chose de structuré et de recherche. ainsi, de la même manière, nous avons créé une
expression régulière personnalisée pour filtrer la facture par son identifiant.
6.4.2 Test d'analyse de log

Arrivée à la phase finale de vérification et test des journaux d'événements envoyés au serveur
ELK-stack. Pour effectuer cette tâche, nous devons dans un premier temps exécuter le script
"log.conf" que nous avons créé précédemment. Après avoir exécuté le script, un index nommé «
mylogs » sera créé dans Elasticsearch DB, nous l'ajouterons donc à l'interface Kibana afin de
pouvoir le visualiser.
111
Figure 82 : Créer un modèle d'index dans Kibana
Ensuite, nous afficherons l'index dans le tableau de bord Discover de Kibana.
Figure 83 : Afficher l'index dans Kibana
Ensuite, nous allons faire une recherche sur chaque facture par son ID. le résultat renverra toutes
les informations sur cette facture, comme indiqué dans la figure ci-dessous.
112
Figure 84 : Test d'analyse du journal ELK-stack
Conclusion
Dans ce sprint, nous avons expliqué l'architecture et les composants de la solution et nous avons
détaillé les étapes d'installation avec les prérequis de l'ELK-Stack. Finir par le test de la solution
d'analyse de logs.
Après avoir mis en œuvre cette solution, nous sommes maintenant en mesure de gérer les
données de manière plus simple et automatisée.
113
Conclusion générale
Dans le cadre de mon projet de fin d'études, j'ai participé à la conception et à la mise en place
d'un système de management de la sécurité de l'information pour l'entreprise QWEEBY.
Dans un premier temps, nous avons commencé par comprendre le contexte de l'entreprise et nous
approprier les normes ISO 27001 et ISO 27002 et déterminer les politiques de sécurité de
l'information.
Deuxièmement, afin d'appliquer ces politiques et de confirmer l'annexe A de l'ISO 27001, nous
nous sommes engagés dans un processus de mise en œuvre de certaines mesures de sécurité et de
contrôle. nous avons mis en place trois solutions techniques afin de mieux contrôler et accéder au
système de gestion des identités de l'entreprise et de mieux centraliser et faciliter la gestion des
logs.
Ce stage a été une bonne opportunité pour moi de mettre en pratique toutes les connaissances que
j'ai acquises au cours de ma vie académique. Cela m'a non seulement permis d'intégrer une
approche de nouveaux standards et de maîtriser un nouveau framework et de nouvelles
technologies mais aussi cela m'a permis d'intégrer le monde professionnel.
114
Bibliographie
[1] Processus Scrum https://shadow-tech.fr/posts/mise-au-point-c-est-quoi-agile
[2] Système de gestionhttps://en.wikipedia.org/wiki/Management_system
[3] Modèle PDCA appliqué aux processus SMSIhttps://www.iso.org/obp/ui/#iso:std:iso-

iec:27001:ed-1:v1:en
[4] Structure de la norme ISO 27001https://en.wikipedia.org/wiki/ISO/IEC_27001
[7] Structure de la norme ISO 27005https://fr.wikipedia.org/wiki/ISO/CEI_27005
[8] chanter seul sur les solutionshttps://www.expertinsights.com/insights/top-10-single-sign-on-

solutions-for-business/
[9] Symfonyhttps://en.wikipedia.org/wiki/Symfony
[10] Pile ELKhttps://www.elastic.co/what-is/elk-stack
[11] Azure ADhttps://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-

directory-whatis
[12] Serveur Wamphttps://www.wampserver.com/en/
[13] Serveur Web Apachehttps://www.techopedia.com/definition/4851/apache-web-server
[14] Schéma SCIM : https://docs.microsoft.com/fr-fr/azure/active-directory/app-

provisioning/use-scim-to-provision-users-and-groups
[15] Document RFC 7644 :https://tools.ietf.org/html/rfc7644
[16]https://swagger.io/docs/specification/authentication/bearer-authentication/
[17] Termes Elasticsearchhttps://www.guru99.com/elk-stack-tutorial.html#6
115

Rapport Final - Amani

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Final - Amani

Transféré par

Droits d'auteur :

Formats disponibles

Traduit de Anglais vers Français - www.onlinedoctranslator.

Mise en place et déploiement du système de

 ESPRIT: Dr Aouini Imen

 QWEEBY : Monsieur Mersel Dalí

La Directrice Académique, Dr.Imen Aouini

Le superviseur professionnel, M.Dali Mersel

Mon humble effort que je consacre à

Mon père Fathi

Mes chers frères Mazen et Mohamed

pour leur soutien et leur amour.

A tous mes amis pour leur soutien et leur amitié.

A tous ceux que j'aime et à tous ceux qui m'aiment.

A tous ceux qui m'ont aidé et j'ai oublié de mentionner .

Je tiens à exprimer ma plus profonde gratitude à tous ceux qui ont

Loin du dénouement de ce travail en particulier :

Mon superviseur chez QWEEBY, M. Dali Mersel, pour

m'encourageant à faire un travail correct et efficace

environnement pour terminer mon travail.

Mon encadrant à l'Ecole Supérieure Privée d'Ingénieurs et de Technologie

Et je tiens à remercier tous ceux qui ont contribué d'une manière ou

Table des matières

CHAPITRE 1 : CONTEXTE GÉNÉRAL ................................................................................................3

CHAPITRE 2 : ÉTAT DE L'ART ....................................................................................................... 16

CHAPITRE 3 : PREMIER SPRINT « METTRE EN ŒUVRE UNE SOLUTION D'AUTHENTIFICATION

CHAPITRE 4 : DEUXIÈME SPRINT « METTRE EN ŒUVRE UN SYSTÈME DE POINT DE TERMINAISON

CHAPITRE 5 : TROISIÈME SPRINT « METTRE EN PLACE UNE SOLUTION DE CENTRALISATION DES

Conclusion ........................................................................................................................................................ 113

Conclusion générale.......................................................................................................................................... 114

Bibliographie .................................................................................................................................................... 115

FIGURE 2 : ORGANIGRAMME DE QWEEBY.....................................................................................6

FIGURE 3 : GESTION DES UTILISATEURS DANS L'APPROCHE TRADITIONNELLE ................................8

FIGURE 4 : GESTION DES UTILISATEURS AVEC SCIM..................................................................... 11

FIGURE 5 : PROCESSUS SCRUM [1] .............................................................................................. 15

FIGURE 6 : MODÈLE PDCA APPLIQUÉ AUX PROCESSUS SMSI [3] ................................................... 18

FIGURE 7 : LA FAMILLE D'ISO 27000............................................................................................ 23

FIGURE 8 : PROCESSUS DE GESTION DES RISQUES ....................................................................... 28

FIGURE 9 : MATRICE D'ÉVALUATION DES RISQUES ...................................................................... 30

FIGURE 10 : OPTIONS DE TRAITEMENT DES RISQUES ................................................................... 31

FIGURE 11 : DIAGRAMME DE CAS D'UTILISATION DU PREMIER SPRINT ........................................ 42

FIGURE 12 : DIAGRAMME DE CLASSES DU PREMIER SPRINT ........................................................ 43

FIGURE 13 : DIAGRAMME DE SÉQUENCE D'AUTORISATION OAUTH2 ........................................... 45

FIGURE 14 : DIAGRAMME DE SÉQUENCE D'AUTHENTIFICATION .................................................. 46

FIGURE 15 : LOGO MICROSOFT AZURE........................................................................................ 47

FIGURE 16 : LOGO OKTA ............................................................................................................. 47

FIGURE 18 : ORGANIGRAMME DES MÉTHODES SSO DANS AZURE AD .......................................... 50

FIGURE 19 : ARCHITECTURE LOGIQUE DU PREMIER SPRINT ......................................................... 51

FIGURE 20 : ARCHITECTURE PHYSIQUE DU PREMIER SPRINT........................................................ 52

FIGURE 21 : LOGO SYMFONY ...................................................................................................... 52

FIGURE 22 : LOGO AZURE AD...................................................................................................... 53

FIGURE 23 : LOGO PHP STORM ................................................................................................... 53

FIGURE 24 : LOGO DU SERVEUR WAMP ...................................................................................... 54

FIGURE 25 : LOGO MICROSOFT TEAMS ....................................................................................... 54

IMAGE 26 : LOGO TRELLO........................................................................................................... 54

FIGURE 27 : INSCRIPTION D'APPLICATION DANS AZURE AD ......................................................... 56

FIGURE 28 : CONFIGURATION DU FOURNISSEUR ......................................................................... 56

FIGURE 29 : PAGE DE CONNEXION À L'APPLICATION ................................................................... 57

FIGURE 30 : LIEN DE REDIRECTION.............................................................................................. 58

FIGURE 31 : PAGE DE CONNEXION DU FOURNISSEUR .................................................................. 58

FIGURE 32 : ENTREZ LES INFORMATIONS D'IDENTIFICATION POUR LE FOURNISSEUR ................... 59

FIGURE 33 : SÉJOUR SIGNÉ EN QUESTION ................................................................................... 59

FIGURE 34 : AUTORISATION DEMANDÉE ..................................................................................... 60

FIGURE 35 : CONNEXION DE L'UTILISATEUR AVEC AZURE AD ....................................................... 60

FIGURE 37 : JOURNAUX DE CONNEXION AZURE AD ..................................................................... 61