THÈSE
présentée devant
L’Institut National des Sciences Appliquées de Lyon pour obtenir
LE GRADE DE DOCTEUR
ÉCOLE DOCTORALE : Ecole Doctorale Informatique Information et So- ciété
Par
Loubna ALI Ingénieur Electronique
Titre :
Gestionnaire d’infrastructure distribuée
Soutenance 13 novembre 2008
Jury
Frédérique BIENNIER Professeur, Laboratoire LIESP – INSA de Lyon
Directeur de Thèse
Dominique RIEU Professeur, Laboratoire LIG – Grenoble Examinateur, Rappor- teur
Eric RONDEAU Professeur, CRAN - Faculté des Sciences et techniques de Nancy
Examinateur, Rappor- teur
Jacques MALENFANT Professeur, Laboratoire LIP6-Paris Examinateur Samir TATA Maître de Conférences, TELECOM & Mana-
gement SudParis
Examinateur
LABORATOIRE D'INFORMATIQUE POUR L'ENTREPRISE ET LES SYSTEMES DE PRODUCTION
LIESP - Lyon, France
RESUME
Gestionnaire d’infrastructure distribuée
Les contraintes de flexibilité et réactivité sur les entreprises conduisent celles- ci à de nouvelles formes organisationnelles : alliances, réseaux et autres organisations collaboratives. Le partage des systèmes d’information conduit à utiliser un processus commun interentreprises. Ce processus distribué utilise les technologies de l’information et de la communication qui sont à leur tour renforcent la diffusion de tels processus. Ainsi, ces nouvelles architectures organisationnelles utilisent largement des infrastructures distribuées ce qui impose de prendre en compte des contraintes de sécurisation, de contrôle d’accès et de gestion de la qualité de service. En outre, du fait de l’évolutivité de ces organisations, le système de management de l’infrastructure distribué doit permettre de réaliser un management pro-actif (pour s’adapter au mieux aux changements de contexte) et autonome (de manière à garantir l’agilité du système).
Pour répondre à ces besoins, nous proposons de coupler la modélisation des processus d’entreprise à la modélisation de l’infrastructure distribuée pour établir des prévisions d’usage de l’infrastructure (ce qui permet de réaliser une gestion proactive) et d’utiliser les données collectées via le système d’administration pour surveiller et gérer la qualité de service de bout en bout. Pour garantir l’agilité du système de management, nous avons choisi de l’implémenter dynamiquement grâce à une plate-forme d’agents mobiles (les aglets). Notre architecture de management est basée sur un système d’administration multi-niveaux (suivant l’organisation hiérarchique de l’infrastructure distribuée de l’organisation collaborative) décentralisé (respectant ainsi les zones de responsabilité). Cette plate-forme constitue un point d’interconnexion non seulement entre les différentes zones géographiques de l’organisation mais aussi entre les différents niveaux de décision dans le système de management. L’intégration d’un mécanisme de composition d’agents offre une grande flexibilité et permet de définir « à la demande » les outils nécessaires à l’administration. Enfin, notre plate-forme ne se limite pas à la gestion pro-active de l’infrastructure, elle permet également de supporter des mécanismes de sécurité en pouvant générer les agents capables de mettre en œuvre des fonctionnalités d’authentification ou d’autorisation.
Mots-clés : Systèmes de management, sécurité, Optimisation des entreprises virtuelles, réingénierie de processus de business, modélisation d'entreprise et agents mobiles.
ABSRACT
Distributed infrastructure management system
The diffusion of the TIC and the constraints of flexibility and reactivity on the companies lead those to new organizational forms: alliances, networks and another definition of BP inter enterprise in addition of an increased division of the information systems. These new organizational architectures largely use distributed infrastructures what forces to take into account: the security constraints, the access control and the quality of service management. Since of evolutionarily of these organizations, the distributed infrastructure management system must allow the realization of proactive management (to adapt as well as possible to the context changing) and autonomous (so as to guarantee the system agility).
To realize these needs, we propose to couple the processes modelling of company with the distributed infrastructure modelling to establish forecasts of the infrastructure utilization (which make the realization of a proactive management possible) and to use the collected data via the administration system to monitor and manage the quality of service from beginning to end. To guarantee the agility of the management system, we chose to implement it dynamically thanks to a mobile agents (aglets) platform. Our management architecture is based on a multilevel administration system (according to the hierarchical organization of the distributed infrastructure of the virtual enterprise) and it is decentralized (thus respecting the responsibility zones). This platform constitutes a point of interconnection not only between the various geographical organization areas but also between the various levels of decision in the management system. The integration of agent’s composition mechanism offers a great flexibility and makes it possible to define "in the request" the necessary administration tools. Lastly, our platform is not limited to the proactive infrastructure management; it makes the possibility also to support security mechanisms while generating the agents able to execute the functionalities of authentication or authorization.
Key-words: management systems, security, Optimization of the virtual enterprises, process of business reengineering, enterprises modelling and mobile agents.
REMERCIEMENT
Un immense Merci à Madame BIENNIER, pour son soutien, sa gentillesse, et son bienveillance.
Mes remerciements vont également à Madame Dominique Rieu, Professeur au département informatique de l’IUT 2 rattaché à l’Université Pierre Mendés-France de Grenoble, d’avoir accepté de rapporter mon mémoire de thèse et d’avoir accepté de participer au jury.
Monsieur Eric Rondeau, Professeur à l’Université Nancy 1, d’avoir accepté de rapporter mon mémoire de thèse et d’avoir accepté de participer au jury.
Monsieur Jacques MALENFANT, professeur en informatique à l’Université Pierre et Marie Curie, d’avoir accepté de participer au jury.
Monsieur Samir TATA, Maître de Conférences à Institut National des télécommunications de SudParis (TELECOM & Management SudParis), d’avoir accepté aussi de participer au jury.
Table des matières
CHAPITRE1 INTRODUCTION GENERALE... 17
PARTIE I SYSTEMES DISTRIBUES ET ADMINISTRATION: CONTEXTE, NOTIONS DE BASE, PROBLEMATIQUES ET SOLUTIONS ... 24
CHAPITRE2 CONTEXTE... 25
2.1 Introduction ... 25
2.2 Organisation d’un processus distribué ... 27
2.3 Interopérabilité et gestion de la performance globale ... 28
2.3.1 Gestion du processus commun ...30
2.3.2 Système de surveillance des activités de business...31
2.4 Prise en compte des contraintes de sécurité... 32
2.4.1 Organisation d’un projet de sécurité...33
2.4.1.1 Spécification des besoins de sécurité...34
2.4.1.2 Conception ...36
2.4.1.3 Réalisation ...38
2.4.1.4 Mise en œuvre ...39
2.5 Conclusion... 40
CHAPITRE3 DIFFERENTS FONCTIONS D’ADMINISTRATION... 41
3.1 Introduction ... 41
3.2 Architecture et protocoles traditionnels de management de réseau ... 42
3.2.1 Architecture OSI (Interconnexion de systèmes ouverts) ...43
3.2.2 Architecture et protocoles Internet ...45
3.2.3 Modèle de management MANDAS ...48
3.2.4 Convergence de ces approches et limites...49
3.3 Gestion des profils et identification de contexte en utilisant des approches liées aux systèmes de sécurité ... 50
3.3.1 Gestion des connaissances sur les profils ...51
3.3.1.1 Contrôle d’accès : principes et pratique...51
3.3.1.2 Gestion d’accès basée sur les rôles...53
3.3.1.3 Intégration de la protection RBAC sur les Workflows dans les processus de business..54
3.3.2 Le système de protection IDS ...57
3.3.2.1 Architectures de base du système de détection d’intrusion (IDS) ...58
3.3.2.2 Méthodes de détection ...60
3.3.2.3 Types de signatures dans le système administration...61
3.4 Analyse des indicateurs de management en utilisant Process-Mining :... 62
3.4.1 Détecter les anomalies en utilisant Process-Mining (α-Algorithm) ...62
3.4.1.1 Utilisation de l’algorithme α...64
3.4.2 Détection d’intrusions en utilisant Process-Mining (la méthode ADAM)...65
3.5 Conclusion... 68
CHAPITRE4 NOUVELLES TECHNOLOGIES D’ADMINISTRATION... 70
4.1 Introduction ... 70
4.2 Intégration des contraintes de qualité de service : Service Level Agreement (SLA) .... 70
4.2.1 Services de management de SLA ...71
4.2.2 Indicateurs et surveillance des services de business ...74
4.2.3 Indicateurs de qualité pour les applications de business ...76
4.3 Agents mobiles : définition, classification, enjeux d’utilisation et typologies... 79
4.3.1 Définition des agents et des agents mobiles...79
4.3.2 Classification des agents selon leurs propriétés ...80
4.3.3 Enjeux de l’utilisation d’agents mobiles...81
4.3.4 Typologie des agents mobiles ...83
4.4 Administration proactive ... 84
4.4.1 Gestion proactive des réseaux en utilisant l’intelligence artificielle ...84
4.4.2 Gestion proactive de sécurité en utilisant le trafic de MIB ...85
4.4.3 Administration proactive des systèmes distribués en utilisant les agents mobiles...89
4.4.3.1 Principe de système distribué et proactif de gestion ...89
4.4.3.2 Système de gestion en utilisant la plate-forme « Aglets » ...91
4.5 Administration autonome ... 94
4.5.1 Définition ...94
4.5.2 Différents aspects de l’administration autonome ...95
4.6 Conclusion... 95
PARTIE II ... 97
ADMINISTRATION DYNAMIQUE DES RESEAUX ET ARCHITECTURES DISTRIBUES . 97 CHAPITRE5 MODELE GENERIQUE D’ADMINISTRATION... 98
5.1 Problématique... 98
5.2 Cycle de vie de système d’administration... 99
5.3 Modèle générique d’administration ...100
5.3.1 Système d’administration de BP basé sur les rôles...100
5.3.2 Modèle global du système d’administration...103
5.3.3 Utilisation des équations SLA dans le modèle d’administration ...111
5.3.4 Modèle d’administration en utilisant les agents mobiles ...113
5.3.5 Organisation du système global d’administration...114
5.4 Conclusion...117
CHAPITRE6 ARCHITECTURE POUR UN SYSTEME D’ADMINISTRATION AGILE ET AUTONOME...119
6.1 Introduction ...119
6.2 Architecture globale du système de management ...120
6.2.1 Plate-forme à base d’agents mobiles ...121
6.2.2 Organisation de la base de données ...122
6.2.3 Implémentation de la plate-forme ...123
6.2.4 Moniteur global et rapports sur le contexte...124
6.3 Organisation du système d’administration...124
6.4 Implémentation des agents mobiles dans le système d’administration ...126
6.5 Organisation distribuée de la plate-forme de management...129
6.5.1 Algorithme de management des gestionnaires de zone ...132
6.5.2 Algorithme de management des sondes de surveillance ...134
6.5.3 Algorithme de management des serveurs...135
6.6 Conclusion...136
CHAPITRE7 GESTION DE LA SECURITE ET DE LA QUALITE DE SERVICE...137
7.1 Introduction ...137
7.2 Gestion de la sécurité...137
7.2.1 Besoins de sécurité ...137
7.2.2 Modèle de sécurité ...138
7.2.3 Architecture de sécurité ...140
7.2.4 Utilisation des agents mobiles pour assurer la sécurité (contrôle d’accès selon les contextes et authentification) ...143
7.2.5 Organisation de notre architecture de sécurité dans un réseau distribué...145
7.3 Qualité de service dynamique...147
7.3.1 Définition de la qualité de service dynamique ...148
7.3.2 Agents mobiles pour un monitoring proactif...151
7.4 Conclusion...152
CHAPITRE8 ETUDE DE CAS ET RESULTATS...154
8.1 Architecture du prototype...154
8.2 Cas d’usage retenu ...154
8.3 Partie informationnelle du prototype de management ...156
8.3.1 Base de données MySQL: ...156
8.3.2 Interface de gestion ...159
8.3.2.1 Interface principale de gestion ...159
8.3.2.2 Interface sur les aglets ...161
8.3.2.3 Sous-interface sur les utilisateurs ...162
8.3.2.4 Sous-interface PHPMyadmin ...163
8.3.2.5 Sous-interface d’envoi des messages...164
8.4 Partie fonctionnelle du prototype de management...164
8.4.1 Recherche des informations de management...165
8.5 Conclusion...170
CHAPITRE9 CONCLUSION GENERALE ET PERSPECTIVES...171
ANNEXE A ...175
ANNEXE A ...175
Table des figures
Figure (1.1) : Relation entre le système d’administration et les différents
composants de l’infrastructure distribuée....20
Figure (1.2) : Composants du modèle de processus présentés en plusieurs parties. 21 Figure (2.1) : Gestion SOA du référentiel d'entreprise. [Rivard,2005] p : 40....26
Figure (2.2) : Organisation hiérarchique d’une infrastructure distribuée. [Rivard,2005]. p : 27...29
Figure (2.3) : Modèle techno-fonctionnel de SOA [Rivard,2005] p : 54....30
Figure (2.4) : Cycle de vie du projet de sécurité avec la proposition des méthodes de sécurité. [Ali,2004]. P :18....34
Figure (2.5) : Démarche globale d’EBIOS. [Nationale,2004]. P : 6....34
Figure (2.6) : Différentes étapes de méthodes OCTAVE pour classifier les risques. [Alberts,2003]. P : 3...37
Figure (3.1) : Interaction de management avec les ressources en utilisant l’agent SNMP et la base MIB. [Hunt,1997], p :75....46
Figure (3.2) : Modèle de management MANDAS. ([Bauer,1997] P : 509)...48
Figure (3.3) : Architecture de WFMS basé sur la RBAC. ([Samarati,1994] P: 41). 51 Figure (3.4) : Différents niveaux de compositions du BP....55
Figure (3.5) : Relation entre : rôle, tâche et utilisateur....56
Figure (3.6) : Architecture de WFMS basé sur le RBAC. ([Liu,2004]. P: 383)....56
Figure (3.7) : Réseau protégé par NIDS. ([Daniels,1999] P : 5)....59
Figure (3.8) : Modèle conceptuel du NIDS. ([Gagnon,2004], P : 24)...59
Figure(3.9) : Exemple d’un tableau de journal de log [Aalst,2004b] P :5....63
Figure(3.10) : Modélisation de flow de processus en utilisant réseau de Petri [Aalst,2004b] p :6....64
Figure (3.11) : Exemple d’un processus d’achat sur un site Web [Aalst,2004b] P :14. ...65
Figure (3.12) : Phase d’entrainement de ADAM [Barbara,2001b] P :13...67
Figure (3.13) : Phase de test d’ADAM [Barbara,2001b] P :13...68
Figure (4.1) : Service de bout en bout et contrat de service. [Forum,2004] P: 10....72
Figure (4.2) : Composition hiérarchique de processus de business dans l’entreprise. [Forum,2004] P : 2...73
Figure (4.3): Relations entre KQI, KPI et SLA. [Forum,2004] P : 7...74
Figure (4.4) : Relations entre les ressources de services de business et les (KQIs, KPIs). [Forum,2004] P : 29....75
Figure (4.5) : Utilisation d’ARM pour mesurer la performance des applications. [Forum,2004] P : 49...78
Figure (4.6) : Utilisation des KQI et KPI avec le système de management et l’interface ARM....78
Figure (4.7) : Architecture de gestion proactive et le service de vérification. ([Franceschi,1997], P: 169)...85
Figure (4.8) : Attaques de type déni de service distribué (DDOS). ([Cabrera,2001] p : 612)...86
Figure (4.9) : Cycle de vie de l’attaque DDOS...87
Figure (4.10) : Utilisation de SNMP pour collecter les informations...88
Figure (4.11) : Système de surveillance. ([Hood,1997] P : 1149)...88
Figure (4.12) : Interactions entre les serveurs de système de gestion.
([Mathieu,2004] P :146)...90
Figure (4.13) : Cycle de vie d’un Aglet. ([Lange,1998b] P : 39)....91
Figure (5.1) : Cycle de vie de système de management....99
Figure (5.2) : Modèle du processus d’une organisation distribuée.... 101
Figure (5.3) : Intégration du contrôle d’accès dans le modèle.... 102
Figure (5.4) : Modèle global de processus avec les indicateurs... 105
Figure (5.5) : Différents types de ressources proposées par [Mathieu,2004]... 106
Figure (5.6) : Informations fournies par le contexte.... 106
Figure (5.7) : Différents types de données et des journaux de logs.... 107
Figure (5.8) : Base de données historique.... 109
Figure (5.9) : Journal de log de Workflow.... 110
Figure (5.10) : Utilisation des équations de SLA dans le modèle d’administration. ... 112
Figure (5.11) : Interaction de l’agent mobile avec l’environnement... 114
Figure (5.12) : Organisation du système global de management.... 115
Figure (6.1) : Architecture globale du système de management.... 121
Figure (6.2) : Système d’administration multi-niveaux.... 125
Figure (6.3) : Installation des agents codes... 127
Figure (6.4) : Utilisation de l’agent code pour surveiller les différents types des nœuds... 127
Figure (6.5) : Envoi des agents action vers les sites désirés.... 128
Figure (6.6) : Utilisation de l’agent action pour gérer le système et assurer la sécurité... 129
Figure (6.7) : Décomposition hiérarchique du système de management.... 130
Figure (6.8) : Organisation multi-niveaux du système de management.... 131
Figure (6.9) : Graphiques de LDS utilisés avec leurs significations.... 132
Figure (6.10) : Algorithme de management des gestionnaires de zone.... 133
Figure (6.11) : Algorithme de management des sondes de surveillance.... 134
Figure (6.12) : Algorithme de management des serveurs.... 135
Figure (7.1) : Composants du système de management de sécurité.... 139
Figure (7.2) : Architecture globale de sécurité dans un réseau distribué... 141
Figure (7.3) : Différentes parties de l’architecture de sécurité.... 143
Figure (7.4) : Exemple d’un scénario de management.... 144
Figure (7.5) : Différentes étapes pour accéder aux applications ou aux ressources. ... 146
Figure (7.6) : Composants qui décrivent le contexte.... 148
Figure (7.7) : Modèle de service du processus de business... 150
Figure (7.8) : Modèle de système de management basé sur le contexte.... 152
Figure (8.1) : Modèle de prototype.... 155
Figure (8.2) : Différentes parties de la base de données de gestionnaire.... 157
Figure (8.3) : Informations expliquant le fonctionnement des agents.... 158
Figure (8.4) : Interface d’identification.... 160
Figure (8.5) : Interface principale d’administration.... 161
Figure (8.6) : Interface d’administration concernant les aglets... 161
Figure (8.7) : Sous-interface de consultation de types et des informations des aglets.
... 162 Figure (8.8) : Interface d’administration concernant les informations générales sur
les utilisateurs... 162 Figure (8.9) : Sous-interface d’identification pour accéder à PHPMyadmin.... 163 Figure (8.10) : Sous-interface d’envoi principale d’administration des messages. 164 Figure (8.11) : Tableau des informations sur les utilisateurs.... 166 Figure (8.12) : Fichier de log de mail... 167 Figure (8.13) : Résultats obtenus de notre programme de calcule... 169 Figure (8.14) : Courbe montrant le nombre de paquets passant au serveur dans une tranche du temps.... 169
Chapitre1 Introduction générale
De récents changements économiques ont conduit les entreprises à opérer des recentrages métier. Cette focalisation s’accompagne d’une logique d’externalisation/collaboration entre entreprises conduisant à de nouvelles stratégies d’organisation qui intègrent une partie de l’environnement dans l’organisation propre de l’entreprise (alliances, entreprises virtuelles ou étendues, « supply chain »…) ainsi qu’à un partage accru des systèmes d’information afin de conserver la cohérence globale.
Ces stratégies de collaborations rendent les frontières des entreprises de plus en plus diffuses compte tenu de la nécessaire ouverture des systèmes d’information vers les partenaires. Faisant largement appel à l’infrastructure distribuée, ces organisations imposent d’offrir un système de gestion de la performance « de bout en bout », adaptatif et proactif de manière à optimiser l’infrastructure existante en s’adaptant au niveau de qualité de service demandé pour garantir le bon fonctionnement des activités de business, des équipements et des applications dans l’infrastructure distribuée. Cette optimisation doit aussi tenir compte des contraintes de sécurité inhérentes au contexte de relations interentreprises.
Ces besoins de management impliquent de mettre en place un système de surveillance qui, en utilisant les protocoles classique d’administration réseau, permet d’acquérir les informations sur le comportement de l’infrastructure. A partir de ces informations, il faut procéder au calcul des indicateurs de performance adéquats (en fonction des contraintes de qualité de service à prendre en compte) afin de contrôler le système distribué et d’entreprendre des actions de management adaptées.
Dans la littérature, plusieurs architectures et moyens de management ont été proposées pour résoudre le problème de gestion des réseaux, des systèmes d’information et des processus de business : l’architecture OSI, les protocoles de management de l’Internet, le modèle MANDAS, les systèmes de détection des intrusions, etc. Malheureusement, aucune de ces architectures de management ne peut répondre à l’ensemble des besoins : gestion distribuée « de bout en bout » (i.e. intégrant le réseau et le système d’information), adaptative et proactive.
En effet, pour répondre aux contraintes de flexibilité et réactivité des organisations collaboratives, il faut non seulement recourir à un système d’administration autonome et proactif mais aussi intégrer les contraintes de sécurisation.
En outre, le partage d’information entre partenaires suppose de mettre en place des mécanismes de sécurité, de contrôle d’accès et de gestion de la qualité de service. Pour cela, nous proposons d’intégrer les spécifications du système d’information pour fournir des indicateurs qui
permettent de calculer les paramètres de qualité de service de bout en bout et diagnostiquer la situation (ou le contexte actuel) de cette organisation distribuée afin de pouvoir adapter la configuration de l’infrastructure. Cette opération est réalisable à condition de disposer d’un système de surveillance qui doit être agile (le système d’administration doit pouvoir s’adapter aux changements structurels), s’adapter aux besoins et prendre en compte les contraintes « temps réel ». Différents travaux permettent de répondre (partiellement) à ces objectifs :
•
Les services de management de contrats de service (SLA) utilisent différents types d’indicateurs de performance pour évaluer le niveau de qualité de service.•
Les moyens d’analyse des indicateurs de performance comme ADAM et l’algorithme α, basés sur la notion de processus de « mining », permettent de tirer parti du contexte.•
L’utilisation des agents mobiles dans le domaine de management des réseaux distribués permet d’apporter agilité et comportement dynamique.Or aucune de ces approches ne permet à elle seule de bâtir une architecture de management distribuée, agile et proactive. Il faut en effet que le système puisse contrôler la qualité de service (gestion contractualisée éventuellement) mais aussi pouvoir s’adapter et définir des indicateurs (et donc des processus de collecte et de calcul) correspondant au contexte.
Pour répondre à ces problèmes, nous proposons de coupler la modélisation des processus d’entreprise à la modélisation de l’infrastructure distribuée pour :
•
Utiliser les spécifications des processus pour établir des prévisions d’usage de l’infrastructure et permettre une gestion proactive de celle-ci.•
Utiliser les données collectées via le système d’administration de l’infrastructure pour reconstruire les processus effectivement mis en œuvre et donc suivre leur évolution.Développé à la suite du projet « Service de communication de bout en bout », notre projet s’intéresse principalement à la mise en place d’un système de reporting couplé au système d’administration de l’infrastructure, la gestion des traces laissées dans les journaux de logs et autres systèmes de contrôle permet de reconstruire partiellement les workflows effectifs (en s’intéressant principalement aux parties de processus « interentreprises ») et d’évaluer s’il convient ou non d’amender les politiques de collaboration. Pour cela, nous nous intéressons à la modélisation de " signatures applicatives " (c.à.d. les informations repérant le comportement) et à leur intégration dans le système de modélisation.
Outre l’utilisation de ces signatures, il faut aussi intégrer leur mise à jour pour répondre aux besoins en fonction du contexte et prendre en compte les changements de qualité de service en fonction des contrats et des relations de collaboration interentreprises.
L’architecture de notre système (figure 1.1) est construite autour du système d’information distribué et de l’architecture de communication (intégrant les limites de responsabilité). Elle comporte différents modules : le système de surveillance, la plate-forme de management contenant les moyens et les méthodes de management et un orchestrateur supportant la mise en œuvre du système de management.
Figure (1.1) : Relation entre le système d’administration et les différents composants de l’infrastructure distribuée.
Ainsi, comme le montre la figure 1.2, pour supporter efficacement les processus métier, notre architecture est composée de différents composants :
•
Le composant « organisation » intègre la modélisation du système d’information (en incluant infrastructure, information et processus de business).•
Le composant « administration » contient les composants concernant les indicateurs de performance et de qualité de service qui sont utilisés par les systèmes de détection des fautes ou le système de management. Ces indicateurs sont les éléments clefs du processus de gestion.•
Le composant « implémentation » intègre l’outillage de la plate-forme de management (différentes procédures d’acquisition des informations, de calcul d’indicateurs, mais aussi moyens et méthodes de management) qui supportera la tâche de gestion de l’infrastructure distribuée. Ce composant repose sur une plate-forme d’agents mobiles (les aglets) et doit s’interfaceravec les composants techniques du système d’information de l’entreprise.
L’utilisation d’agents mobiles pouvant être créés à partir de patron permet de construire un système agile pouvant s’adapter dynamiquement au contexte.
Figure (1.2) : Composants du modèle de processus présentés en plusieurs parties.
Outre son rôle dans la tâche de management, notre plate-forme à base d’agents mobiles peut aussi contribuer à assurer des fonctions de sécurité en construisant dynamiquement des agents chargés de mettre en œuvre les procédure d’authentification, d’autorisation… et en identifiant et prédisant les fautes ou les attaques pour les éliminer avant que le réseau s’arrête.
Ce mémoire est organisé en deux parties : état de l’art puis présentation de notre contribution.
L’état de l’art débute par une présentation de contexte (chapitre 2) afin de préciser le cahier des charges et poser le problème de la définition du comportement en modélisant un processus distribué et en intégrant les contraintes de protection du système d’information. Nous baserons notre approche sur l’organisation des processus interentreprises et des moyens à mettre en œuvre pour les supporter. Dans un deuxième temps, nous prendrons en compte les contraintes de sécurité en nous intéressant aux
méthodes qui pourrons être mises en œuvre pour construire une politique de sécurité adaptée et pour la mettre en œuvre.
Après avoir précisé le contexte, les chapitres suivants porteront plus particulièrement sur les éléments à intégrer dans un système de gestion d’infrastructure distribuée agile afin de suivre les contraintes d’évolution d’une entreprise virtuelle. Dans un premier temps (chapitre 3), notre étude portera sur les approches classiques concernant la gestion de :
•
La qualité de service : Nous exposerons d’abord les méthodes traditionnelles permettant de collecter des données liées au monitoring du système (protocoles traditionnels de management) puis nous présenterons des méthodes permettant de réaliser les différentes tâches de gestion.•
La sécurité : dans un contexte de relations internetreprises, nous avons choisi de privilégier la gestion des profils et du contrôle d’accès (contrôle d’accès basé sur les rôles, détection d’intrusion)..Dans un deuxième temps (chapitre 4), nous prendrons en compte les contraintes de relation interentreprises et d’agilité. La gestion
« contractualisée » de la qualité de service passe par la mise en œuvre de contrats de type SLA. Ces contrats font appel à une large variété d’indicateurs de performance, éventuellement calculables à la demande à partir des informations de bas niveau collectées via les protocoles traditionnels, indicateurs qui peuvent aussi être utilisé pour évaluer le contexte. Les contraintes de distribution et d’agilité peuvent quant à elle être prises en compte mettant en œuvre une technologie distribuée (par exemple une plate-forme d’agents mobiles) et en intégrant les principes des systèmes de gestion autonomes (« autonomic computing »).
Cet état de l’art montre que des solutions ponctuelles existent mais qu’il faut définir une structure d’intégration afin d’avoir une architecture qui prenne en compte les besoins sur le fonctionnement et qui puisse être générée dynamiquement.
Dans un premier temps (chapitre 5), nous définirons l’architecture globale de management. Cette architecture permet d’intégrer les vues technologiques (liées à la description de l’infrastructure), organisationnelles (décrivant les processus de business et l’organisation de l’entreprise) et le système de management. Pour cela, nous définirons un modèle générique de processus de management qui permet d’orchestrer les composants qui sont associés soit aux moyens de collecte d’informations (en se basant sur les protocoles d’administration) soit aux méthodes d’administration comme ADAM.
Les contraintes d’agilité et de distribution du système liées au contexte de l’entreprise virtuelle imposent de construire un système de gestion qui soit adaptatif et organisé de manière décentralisée. Pour
répondre à ces contraintes, nous proposerons une solution de type système autonome (chapitre 6) qui met en œuvre des agents mobiles qui pourront être générés selon besoins. Basée sur une plate-forme d’aglets, notre solution permet de représenter et utiliser différents types d’agents qui, par des opérations de paramétrage et de composition, pourront permettre au système de management d’avoir une grande variété de comportements.
Enfin, cette solution est organisée de manière distribuée en respectant les contraintes issues des relations interentreprises (limites de responsabilité…).
Enfin, pour prendre en compte les contraintes propres à un environnement distribué interentreprises (sécurité et qualité de service de bout en bout) nous proposerons dans le chapitre sept d’intégrer les solutions de sécurité et la définition de modèles de contexte dans notre architecture globale.
Nous conclurons cette partie par la présentation de notre prototype de système de management.
Partie I
Systèmes distribués et
administration: contexte, notions de
base, problématiques et solutions
Chapitre2 Contexte
2.1 Introduction
Du fait des changements d’environnement et des contraintes du marché, les entreprises doivent s’adapter très vite et faire ainsi preuve d’agilité (pour prendre en compte les changements structurels) flexibilité et réactivité.
Ceci conduit souvent au développement de stratégies de collaboration et donc à la mise en place d’une organisation distribuée réunissant plusieurs entités (entreprises, sites d’une même entreprise, unités de gestion…). Ces stratégies imposent de partager processus et informations ce qui conduit de fait à décloisonner une organisation (dans le cas d’une collaboration interne) ou à ouvrir les frontières de l’entreprise (collaboration avec l’extérieur).
Selon les entités impliquées dans la collaboration, nous pouvons identifier plusieurs types d’organisations collaboratives. Le type le plus simple est associé à une stratégie de collaboration interne. Il s’agit de re- grouper plusieurs filiales ou unités de gestion d’une même entreprise. Ces entités sont reliées par le réseau d’entreprise et peuvent partager un sys- tème de décision. En revanche, dans le cas d’une collaboration entre entre- prises (nous parlerons alors d’entreprise virtuelle), chaque entreprise parte- naire constitue un nœud possédant son propre système d’information et de décision et il faudra définir une infrastructure capable de relier l’ensemble de ces nœuds (physiquement et logiquement) permettant à chacun de pou- voir communiquer et agir avec les autres partenaires [Tidd,1997].
Ce contexte impose que les partenaires doivent disposer de systè- mes d’information réactifs et agiles et que l’infrastructure d’administration mise en place soit elle-même flexible, réactive et agile car la performance liée au système d’information impacte la performance globale. Or les sys- tèmes d’information d’entreprise sont souvent constitués par un ensemble de logiciels « métier » (ERP (Enterprise Ressource Planning), PLM (Pro- duct Life Management), SCM (Supply Chain Management), CRM (Custo- mer Relationship Management)…) qui n’offrent que peu de possibilité d’interopérabilité ou d’agilité. Par exemple, bien que les ERP, aussi appelés Progiciels de Gestion Intégrés (PGI), soient des applications dont le but est de coordonner l'ensemble des activités d'une entreprise (activités dites ver- ticales telles que la production, l'approvisionnement ou bien horizontales comme le marketing, les forces de vente, la gestion des ressources humai- nes, etc.) [Marche,2008a], ils n’ont pas réelles liaisons avec les systèmes spécialisés dans la gestion des achats, l’ordonnancement d’atelier… De même, les systèmes de gestion de la relation client (CRM) automatisent les
différentes composantes de la relation client mais ne permettent pas une in- terconnexion avec le système d’approvisionnement du client [Marche,2008b].
Pour arriver au niveau d’agilité requis, une stratégie basée sur une architecture orientée services (SOA) peut être adoptée. Cette stratégie permet de définir un référentiel global et l’orchestrateur SOA permet de re- lier, grâce à un ensemble de connecteurs appropriés, les différentes compo- santes du système d’information [Footen,2008].
Figure (2.1) : Gestion SOA du référentiel d'entreprise. [Rivard,2005] p : 40.
Ce type d’architecture conduit donc à privilégier les organisations basées sur les processus métier. Des systèmes de gestion des processus (BPM) et de monitoring des activités (BAM) sont alors nécessaires pour contrôler la « qualité de service » de l’organisation mise en place [Footen,2008].
Dans la suite de ce chapitre, nous présenterons d’abord des modè- les de processus distribués (basés sur l’approche workflow) avant de nous intéresser plus précisément aux contraintes d’interopérabilité et aux possi- bilités apportées par les approches orientées services. Enfin, la collabora- tion entre entreprises pose le problème de la gestion des risques liés aux échanges et donc de la définition de politiques de sécurité adaptées. Nous conclurons ce chapitre en présentant des méthodes pouvant être utilisées pour définir globalement une politique de sécurité et conditionner ainsi l’organisation d’une infrastructure adaptée.
2.2 Organisation d’un processus distribué
La mise en place d’une organisation collaborative (comme c’est le cas d’une entreprise virtuelle) s’accompagne de la mise en place d’un système de décision distribué permettant de coordonner les différentes entités tout en respectant les limites de responsabilité et d’autonomie. L’efficacité d’un tel système de décision repose sur l’organisation d’une infrastructure tech- nologique permettant de partager efficacement les informations et suppor- ter l’exécution de processus distribués entre les partenaires [Malone,1997].
Modéliser les processus de business d’une organisation virtuelle permet de formaliser les échanges. Pour supporter l’exécution d’un tel pro- cessus, on peut recourir à une approche de type workflow. En effet, un Workflow permet de définir la succession de tâches à réaliser, les rôles as- sociés à ces tâches et les informations à échanger. Toutefois, la modélisa- tion et la gestion d’un processus de business d'une organisation virtuelle exige de prendre en compte les spécificités de cette organisation répartie entre différentes entreprises : en particulier, on s’intéressera au niveau d’intégration et au niveau de participation des partenaires.
Ces contraintes conduisent à mettre en évidence plusieurs straté- gies différentes pour organiser la mise en œuvre des processus partagés :
•
Chaque entreprise peut protéger son autonomie et donc ses propres Workflow. Dans ce cas, les interactions entre Workflows doivent être définies afin que chacun d’eux puisse servir de support à une activité identifiée dans l’organisation d’un processus interentreprises [Casati,2001]. Dans ce type d’architecture distribuée, les différents gestionnaires de tâches peuvent être coordonnés grâce aux relations de dépendance entre les tâches.•
Un Workflow commun est défini au préalable puis est transformé en graphe d’activité. Ceci permet de le mettre en œuvre (i.e. l’exécuter) de manière décentralisée en répartissant les activités entre les différents partenaires.Une telle approche est proposée par [Muth,1998] et suppose d’utiliser massivement des processus de gestion de transactions pour assurer la cohérence globale (contrainte due au partage d’information).
•
Les Workflow de type B2B (business à business) se rapprochent de la notion traditionnelle de l’Echange de Donnée Informatisé (EDI). Pour cela, [Aalst,2002] propose de combiner différentes descriptions pour le processus de business partagé : workflow publics et privés sont définis simultanément. La cohérence globale est garantie en définissant précisément les échanges d’information et les formats d’échange [Bussler,2002]). De cette manière, les processus de business collaboratifssont définis comme l’interconnexion d’un ensemble de processus privés (vus comme des boîtes noires pour laquelle seules les interfaces (entrées et sorties) sont connues) et de processus publics (vus comme des boites blanches incluant les descriptions précises de processus).
•
Le Web-EDI basé sur ebXML peut être employé pour fournir un cadre ouvert et réactif à la coopération inter-entreprise. Une telle infrastructure d'E-service peut mettre en place un Workflow dynamique [Su,2003].Néanmoins, cette approche intrinsèquement ouverte implique de prendre en compte les points suivants :
o Des contrats électroniques (E-contrats) doivent être mis en place entre les partenaires pour supporter les processus d’échanges entre les différentes partenaires de l’organisation collaborative [Chiu,2002].
o Les processus de business doivent être cohérents. Pour cela ces processus sont organisés sous forme de transactions, pour garantir la cohérence des informations partagées (en garantissant les propriétés
« ACID » (c.a.d. Atomicité, Consistence Isolation et Durabilité)) et des processus de reprise en cas d’erreur [Papazoglou,2003].
•
Les organisations basées sur les contrats mettent l’accent sur les relations légales et formelles entre les partenaires en s’intéressant aux obligations, contraintes de synchronisation… Ce type d’organisation impose de définir précisément le processus réel, ceci explique que le processus d’élaboration de ce processus commun doit inclure une phase de négociation contractuelle décrivant les engagements précis. En outre, l’exécution de ce type de processus doit être suivie de manière à pouvoir être rapprochée des contraintes contractuelles (qui fait quoi, avec quels moyens, quand et où) [Perrin,2003].Ces différentes stratégies imposent une infrastructure distribuée supportant l’échange entre les partenaires. Or les composants traditionnels d’un système d’information d’entreprises ne sont que peu ouverts et interopérables. Pour garantir un niveau d’agilité et d’interopérabilité suffisant, on peut recourir à une organisation de type architecture orientée services.
2.3 Interopérabilité et gestion de la performance globale
Dans une organisation distribuée, plusieurs types de système d’informations peuvent être impliqués. En effet, pour chaque « métier », un système dédié peut être utilisé (CRM pour la gestion de la relation client,
SCM pour la gestion de la chaîne logistique, ERP pour les fonctions de ges- tion…). Le système d’information global apparaît donc comme un ensem- ble de briques de différentes formes qu’il va falloir organiser pour former un tout cohérent. Pour cela, le processus de business interentreprises repré- sente une sorte de « ciment » permettant de lier ces briques.
Pour respecter les contraintes d’interopérabilité tant au niveau « business » qu’au niveau technologique, un processus peut être organisé avec une inter- face métier unique (partie publique) et autant d’implémentations privées que nécessaire. La sous-couche d’abstraction technique quant à elle doit permettre de définir l’interface permettant d’abstraire les différentes im- plémentations (figure2.2).
Figure (2.2) : Organisation hiérarchique d’une infrastructure distribuée.
[Rivard,2005]. p : 27.
L’agilité quant à elle peut être apportée par le déploiement d’une architecture orientée services (SOA) [Gold-Bernstein,2004]. Cette approche traite les notions d’orchestration, de contrôle et des supports techniques du processus de business. Une architecture orientée service repose sur le mo- dèle technico-fonctionnel présenté dans la figure suivante. Ce modèle inclut les composants suivants [Rivard,2005]:
•
Le référentiel de services et de méta-données sert de dictionnaire de référence ;•
L’infrastructure de transport et de connexion constitue la couche basse du modèle ;•
Les services d’orchestration sont associés à une couche intermédiaire de la plate-forme et prennent en compte l’enrichissement métier ;•
Les services de pilotage sont associés à la couche haute assurant le suivi et la supervision ;•
Les services transversaux (fonctions de sécurité, gestion de transaction, système d’administration) concernent l’ensemble des couches du modèle.Figure (2.3) : Modèle techno-fonctionnel de SOA [Rivard,2005] p : 54.
Pour garantir le bon fonctionnement des processus de business et pour offrir un niveau idéal de flexibilité et de connectivité des activités de business, l’architecture orientée services nous offre deux services très effi- caces et qui peuvent s’adapter aux contraintes de l’organisation de Work- flow [Rivard,2005]: le processus de management des processus de business (BPM) et le système de surveillance des activités de business (BAM). Ces systèmes permettent de contrôler l’exécution et la performance globale des processus.
2.3.1 Gestion du processus commun
Pour satisfaire les contraintes d’agilité des organisations collaboratives, il faut impérativement identifier, développer, modéliser, déployer et gérer les processus de business (incluant à la fois les activités manuelles et les activités automatisées) de manière efficace. Ceci est réalisé par la gestiont des processus de business (ou processus métier) : le BPM. Déployer un BPM offre les avantages suivants :
•
Réduire l’écart entre les exigences de business et les systèmes d’information en demandant d’abord aux responsables des différents secteurs métier de modéliser les processus de business puis en demandant aux responsables du système d’information de fournir une infrastructure capable d’exécuter et contrôler ces processus de business.•
Augmenter la productivité et réduire les coûts en optimisant les processus de business.•
Augmenter l’agilité et la flexibilité des entreprises en séparant la logique du processus de business des autres règles de business.•
Réduire les coûts de développement en utilisant des langages de programmation de haut niveau. Cette opération peut aider les gestionnaires et les développeurs de réaliser vite les mises à jour et les reconstructions de système d’informations.La mise en place d’un BPM efficace suppose de disposer d’indicateurs adaptés et de suivre en permanence les activités ce qui de- mande un système de monitoring adapté.
2.3.2 Système de surveillance des activités de business
Le système de surveillance des activités de business (Business Activity Monitoring ou BAM) donne une vue claire sur le processus de business [Rivard,2005]. Les services de base de ce monitoring doivent fournir les indicateurs de performance concernant les différentes entités dans l’organisation. Ces indicateurs peuvent porter sur différents points :
•
Modélisation des processus : il s’agit ici d’établir les spécifications nécessaires et de reprendre les détails des activités proposées par l’organisation. A chaque activité est associée la liste des ressources, des clients, des produits, etc. que l'acteur doit utiliser.•
Exécution des processus : il s’agit ici de contrôler la bonne exécution du processus de business, ou plus précisément, la bonne coordination et le bon fonctionnement des workflows dans un processus de business.•
Surveillance de processus : il s’agit d’appliquer les différentes démarches de surveillance sur les processus de business en collectant les indicateurs de performances et les analyser dans le but de détecter les fautes et éloigner les risques des dommages.Si on intègre le système de management de l’infrastructure distri- bué à ce cadre, on obtient alors un complément intéressant d’information permettant d’élaborer ou consolider de nouveaux indicateurs de perfor- mance pour enrichir le tableau de bord global.
Comme on le voit, le partage d’information et de l’infrastructure jouent des rôles clés dans l’organisation de la performance globale. Or ce partage représente un risque pour les partenaires à la fois en raison de la valeur stratégique de certaines information et en raison de risques spécifiques liés à l’organisation d’une infrastructure distribuées (système ouverts, risques spécifique au système de communication…). Pour garantir la sécurité d’échange des données entre les partenaires d’une entreprise virtuelle, une infrastructure distribuée sécurisée doit être installée. Cette infrastructure doit être capable d’assurer la sécurité de l’infrastructure en
respectant une politique globale de sécurité. Outre l’organisation d’un processus commun, la mise en place d’une architecture interopérable, il faut aussi intégrer la gestion d’un projet de sécurisation pour produire une infrastructure adaptée aux besoins des organisations collaboratives.
2.4 Prise en compte des contraintes de sécurité
Le recentrage « métier » et l'accroissement des relations partenariales (lo- gique d'externalisation) modifient la notion de frontière de l’entreprise, les partenaires économiques sont considérés comme des membres d'une même structure organisationnelle de l'entreprise étendue. Ces organisations utili- sent largement les techniques de l’informatique distribuées et sont rendues vulnérables vis à vis de l’insécurité informatique, piratage et sabotage vi- sant à détruire ou modifier les informations.
Pour y remédier, il faut définir une politique de sécurité et l’adapter aux différents modes de collaborations entre les entreprises partenaires.
En fonction des stratégies de collaboration (qui sont déclarés dans les contrats signés par les partenaires), les autorisations d’accès données par une entreprise à ses partenaires sont différentes ce qui impacte fortement les composants et l’architecture de sécurité que nous devons mettre en place. De cette façon, la construction de l’architecture de sécurité change selon les droits qu’une entreprise veut donner aux autres partenaires.
Pour construire une politique de sécurité pour une entreprise virtuelle, il faut tenir compte des points suivants [Ali,2004]:
•
la culture : définition du niveau de formation dans l'entreprise, des responsables informatique et de leur expérience. Ceci couvre aussi la possibilité d'adapter les contenus informatiques de l’entreprise aux besoins de l'entreprise virtuelle.•
la capacité : cet axe décrit l’infrastructure technologique (réseaux, serveurs, accès Internet), les possibilités d’accès à des équipements appropriés pour les usagers (cartes son, cartes vidéo, configuration des appareils, etc.), le support des services informatiques.•
les clients : c’est la définition du profil des clients visés par l'entreprise (client final ou une autre entreprise partenaire).•
Les aspects stratégiques : cet axe permet de définir les buts de la collaboration (nouveaux produits, contacts avec des partenaires…).2.4.1 Organisation d’un projet de sécurité
Pour intégrer un projet de sécurisation du système d’information distribué, il faut respecter différentes étapes :
•
identifier et évaluer les risques,•
proposer des méthodologies de gestion des risques,•
proposer des plans d'action de prévention et de protection,•
contrôler et rendre compte de la mise en œuvre de la politique de sécurité, ainsi que son impact sur les risques.Pour réaliser un projet de sécurité dans une entreprise virtuelle, différents étapes formant le cycle de vie de projet de sécurité doivent être respectées [Ali,2004]:
•
La spécification des besoins de sécurité : cette étape donne une vision globale sur l’organisation en totalité. Cette vision détaille les différents composants de l’organisation en mettant les points de vulnérabilité de chaque partie du système informatique.•
La conception : dans cette phase, nous identifions les différents types des risques en proposants des solutions convenables pour que l’organisation soit résistante contre ces risques.•
La réalisation : cette phase s’occupe de fournir les meilleurs moyens pour réaliser le projet de sécurité pour permettre d’éviter les risques présentés dans les phases précédentes.•
La mise en œuvre du projet de sécurité : cette dernière étape vise à prendre en charge l’installation, la gestion et la maintenance des composants de sécurité.Plusieurs méthodes existent pour contribuer à la définition d’une politique de sécurité : en effet, chacune d’elles ne couvre pas la totalité du cycle de vie mais se concentre plutôt sur un aspect spécifique (figure 2.4).
On peut alors recourir à différentes méthodes de manière coordonnée au cours d’un projet de sécurisation d’un système d’information.
Figure (2.4) : Cycle de vie du projet de sécurité avec la proposition des méthodes de sécurité. [Ali,2004]. P :18.
2.4.1.1 Spécification des besoins de sécurité
Tout d’abord, une politique de sécurité suppose de pouvoir exprimer objec- tivement les besoins en termes de sécurité. Pour réaliser cette étape, nous proposons d’utiliser la méthode EBIOS (Expression des Besoins et des Ob- jectifs de Sécurité) [Nationale,2004]. Cette méthode propose une démarche pour faire l'étude et le traitement des risques dans le domaine de la sécurité des systèmes d'information. Les démarches d’EBIOS se déroulent en sui- vant cinq phases (figure 2.5). A l’issue de ces cinq phases, l’étude est syn- thétisée dans le principal document en sortie de la méthode EBIOS : la fi- che d'expression rationnelle des objectifs de sécurité (appelée FEROS).
Figure (2.5) : Démarche globale d’EBIOS. [Nationale,2004]. P : 6.
La méthode EBIOS débute par une étude du contexte qui s’intéresse aux points suivant :
•
Présentation de l'organisme : Pour connaître les contraintes générales et définir une architecture adaptée au système d'information.•
Étude du système cible : Il est nécessaire de préciser le sous-ensemble du système d'information de l'organisme constituant le système cible et des enjeux.•
Détermination de la cible de l'étude de sécurité et des éléments sensibles : Cette activité consiste à recenser et décrire les différentes entités, qu'elles soient de type matériel, logiciel, réseau, personnel, site ou organisation.Une fois déterminé le contexte, la méthode EBIOS propose ensuite de passer à l’expression des besoins de sécurité. Dans cette phase, EBIOS réalise une fiche des besoins de sécurité associés aux différentes fonctions comme la disponibilité, l’intégrité et la confidentialité. L’expression des besoins produit une valeur finale de sensibilité qui aide à disposer une vision objective et cohérente des besoins de sécurité du système cible.
Parallèlement à l’expression des besoins, EBIOS prévoit une phase d’étude des risques. Pour cela, les étapes suivantes sont définies :
•
Étude des menaces génériques: Dans cette étape on sélectionne les méthodes d'attaque pertinentes pour le système cible. L'étude des menaces se compose de deux tâches : La sélection des menaces et l’étude de l'impact de la menace (accidentelle ou délibérée).•
Étude des vulnérabilités spécifiques : L'objectif de cette étape est de déterminer les vulnérabilités spécifiques du système cible et la caractérisation de celles-ci en terme de faisabilité (pour les menaces délibérées) ou de probabilité (pour les menaces accidentelles). Les objectifs de sécurité consisteront à diminuer ces vulnérabilités.Après ces deux phases d’étude, on doit procéder à l’identification des objectifs de sécurité. Pour cela, deux sous-tâches sont définies :
•
Formalisation des objectifs de sécurité : Cette partie vise la synthèse des résultats précédents pour déterminer les objectifs de sécurité permettant de couvrir les risques. Pour cela, il faut prendre en compte les hypothèses, les enjeux et les différentes règles de sécurité. Cette activité contribue au traitement des risques dans le processus de gestion des risques.•
Détermination des niveaux de sécurité : Cette activité a pour but de déterminer le niveau de résistance adéquat pour atteindre les objectifs de sécurité. Elle permet également de choisir le niveau d'assurance des exigences de sécurité.La cinquième phase d’EBIOS vise la détermination des exigences de sécurité. Cette dernière phase est également composée de deux parties :
•
Détermination des exigences de sécurité fonctionnelles : Pour assurer les exigences de sécurité fonctionnelles du système cible, chaque risque déjà identifié est traité, refusé, optimisé, transféré, ou pris en charge. Et le risque résiduel doit être clairement identifié et accepté. Ici il doit être possible de faire le traitement des risques en utilisant un processus de gestion des risques.•
Détermination des exigences d’assurance de sécurité : Le but de cette étape est de faire une expression complète des exigences de sécurité de la cible de l'étude de sécurité. Ces exigences sont sélectionnées selon le niveau d'assurance choisi (niveaux de sécurité). Elles constituent le fondement de la confiance dans le fait qu'un système cible satisfait à ses objectifs de sécurité.En conclusion, on peut dire que la méthode EBIOS propose une démarche complète. Toutefois, l'inconvénient de cette méthode est qu'elle reste orientée grandes entreprises et son utilisation nécessite l'intervention de consultants sécurité externes sachant conduire les évaluations des risques. En outre, il n'y a pas de remise en cause des choix de conception avec cette méthode car elle ne donne pas une solution claire pour
« soulever » les problèmes de sécurité, voire inventorier les risques d’attaque.
2.4.1.2 Conception
Une fois identifiés les besoins, on peut passer à la phase de conception.
Dans cette phase, deux méthodes sont utilisables. Tout d’abord, la méthode OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evalua- tion) [Alberts,2003] est une démarche visant l’organisation interne de l'en- treprise. A partir des biens et des grandes familles de risques identifiés avec EBIOS, cette méthode crée une vue large permettant l’organisation des ris- ques courants pour assurer la sécurité de l'information. L'analyse des ris- ques comporte les activités suivantes:
•
identifier les risques.•
analyser les risques pour déterminer des priorités.•
faire un plan d'amélioration en développant une stratégie de protection pour réduire les risques.•
projeter la mise en application de la stratégie de protection et limiter les risques en développant des plans d'action détaillés.•
mettre en application les plans d'action détaillés.•
surveiller les plans d'action pour contrôler l’efficacité.•
contrôler les variations de plan d'exécution en prenant en compte l'action la plus convenable.La méthode OCTAVE est autodirigée aussi, elle a proposé un cadre systématique pour faire une spécification détaillée de la hiérarchisation des risques réseau à traiter. Pour cela, OCTAVE groupe les risques en plusieurs classes en précisant: le type de bien à protéger (les mêmes bien qui sont bien identifiés par les méthodes EBIOS), le mode d'accès, l’acteur (interne /externe), la motivation (accidentel / délibéré) et les conséquences. Après avoir procédé à la classification des risques, on peut passer à l'étape suivante : c’est l'évaluation de ces risques. Il faut alors préciser les impacts (faible, moyen, fort), et donner ensuite des indications sur le nombre d’occurrence et la probabilité de l'événement « attaque » correspondant (figure 2.6).
Figure (2.6) : Différentes étapes de méthodes OCTAVE pour classifier les risques. [Alberts,2003]. P : 3.
La méthode OCTAVE offre une grille d’analyse des risques couplée à l'organisation interne de l'entreprise. Pour rendre cette approche compatible avec les besoins propres de l’entreprise virtuelle, il faut apporter un certain nombre d’adaptations concernant les impacts des risques. Est-ce que ces risques menacent seulement l’entreprise partenaire, quelques entreprises voisines aussi ou elles menacent l’entreprise virtuelle en totalité. De plus, cette méthode n’est pas complète au niveau de l’étude des risques de l’entreprise virtuelle, elle reste limitée au niveau de la gestion de reprise des problèmes causés par les attaques. Pour cela, nous proposons la méthode SNA qui prend en compte la notion de détection des attaques, limite les dommages causés par ces attaques et garantit la poursuite du travail du réseau et de système d’information.
Dans la méthode SNA [Moore,2001], il existe trois éléments de base pour étudier les attaques :
•
Résistance aux attaques : pour les empêcher ;•
Reconnaissance des attaques : pour les identifier et évaluer convenablement l'étendue des dommages;•
Recouvrement : c'est la capacité d'apporter les services et les biens nécessaires pour limiter les dommages.Cette méthode peut aussi être considérée comme une méthode complémentaire pour EBIOS. Elle reprend les différentes fonctions proposées par EBIOS et les profils des menaces proposés par OCTAVE en intégrant non seulement le réseau mais aussi le système d’information et les processus de business.
Les vulnérabilités prises en compte par la méthode SNA peuvent être issues de l’organisation des processus (Workflow), des applications et de leurs objectifs, des protocoles supportant l’interopérabilité. Pour garantir un niveau de protection suffisant, il faut à la fois s’intéresser au profil d’attaque qui menace le Workflow et mettre en place des composants convenables de sécurité.
En outre, cette méthode comporte des facettes permettant de la rattacher aux phases de conception d’une architecture de sécurité et d’implémentation de cette architecture.
En s’intéressant à la sécurité des entreprises, SNA propose une bonne solution. Elle divise l’étude des attaques en trois parties:
•
La prise en compte des attaques basées sur le réseau d’entreprise. Ces attaques proviennent de l’infrastructure de communication et des services qui supportent ces communications.•
La prise en compte des attaques basées sur les applications de l’entreprise.Ces attaques sont celles liées à l'architecture des applications comme le serveur Web, les services de courrier électronique ou les applications qui supportent l'infrastructure de décision
•
La prise en compte des attaques sur les données privées de l’entreprise. Ces attaques sont spécifiques à certaines transactions ou peuvent être organisées pour un dessein particulier.Pour créer le sous-système de sécurisation à l’aide de composants, nous proposons de recourir à la méthode MASS d’IBM présentée dans le paragraphe suivant.
2.4.1.3 Réalisation
Au niveau de la réalisation, on peut recourir à la méthode MASS proposée par IBM [Buecker,2005]. Cette méthode aide à réaliser un catalogue des besoins de sécurité et propose des cadres permettant de réaliser l'intégration de ces besoins de sécurité. Pour définir les besoins de sécurité, la méthode MASS identifie onze classes de fonctions et de besoins: audit de sécurité, communication, cryptographie, protection des
données, identification et authentification, gestion des fonctions de sécurité, protection des fonctions de sécurité, utilisation des ressources, accès aux composants, chemins de confiance et droits d'accès au domaine privé. Pour ce qui concerne la démarche d’intégration, MASS fournit ensuite des cadres de solutions pour le réseau et le système d'information (NIS) en utilisant cinq catégories ou sous-systèmes. Pour chaque sous- système fonctionnel, cette méthode identifie des objectifs et exprime les services de sécurité issus des Common Criteria que ce sous-système doit satisfaire.
•
Le sous système d'audit de sécurité•
Le sous système d'intégrité•
Le sous système de contrôle d'accès•
Le sous système de contrôle de flux•
Le sous système de gestion d'identité2.4.1.4 Mise en œuvre
Si on s’intéresse plus spécifiquement à la mise en œuvre au niveau de l’infrastructure de communication, la méthode SAFE/CISCO est conseillée pour réaliser cette étape. Cette méthode propose une infrastructure sécurisée orientée réseau. Reposant sur une organisation en différents sous-systèmes associés à des sous-réseaux, cette méthode propose l’interconnexion des différentes zones et permet d’installer un système de sécurité sur un site et d’en réaliser l'exploitation, la maintenance et le retrait. De plus, la méthode propose sept composants principaux de sécurité qui seront ensuite répartis en fonction des types d’attaques auxquelles ils peuvent permettre de faire face : logiciels antivirus, politiques de sécurité, contrôle d'accès, coupe-feu, mécanisme de cryptage, système de détection d'intrusion (IDS) et contrôle de réseau.
La méthode SAFE vise la construction d’une architecture de sécurité. Cette méthode, proposée par CISCO [Convery,2000],divise l’architecture de sécurité en trois parties: l'entreprise campus, l'interface de l'entreprise et les services des fournisseurs d’accès. Pour chaque partie SAFE propose de mettre en place des composants de sécurité qui ont la capacité d'éliminer les risques et d'éviter les attaques pouvant viser plus particulièrement telle ou telle partie. La démarche de construction proposée part du cœur de l’entreprise et va vers l’extérieur. Dans chaque zone, on regroupe les ressources nécessaires et les composants de sécurité à implanter.
