Modélisation conjointe de l infrastructure et des processus pour l administration pro-active de l entreprise distribuée

Transcription

1 04 ISAL 0085 Année 2004 Modélisation conjointe de l infrastructure et des processus pour l administration pro-active de l entreprise distribuée THÈSE présentée et soutenue publiquement le 10 décembre 2004 devant L Institut National des Sciences Appliquées de Lyon pour obtenir le Grade de Docteur (spécialité informatique) Ecole Doctorale Informatique et Information pour la Société par Hervé MATHIEU Jury Rapporteurs : Examinateurs : Pr. Dominique RIEU Pr. Hervé PINGAUD Pr. Eric RONDEAU Pr. Joël FAVREL Pr. Frédérique BIENNIER (Directeur de thèse) Laboratoire de Productique et d Informatique des Systèmes Manufacturiers

2

3 Remerciements Un immense Merci à Madame BIENNIER, pour son soutien, sa gentillesse, et son indulgence, et sans laquelle mes projets, qui j espère seront les projets de toute une vie, auraient été incroyablement plus difficiles à mettre en œuvre. Je tiens à remercier en particulier Monsieur Favrel pour m avoir accueilli au laboratoire PRISMa. 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, Monsieur Hervé Pingaud, Professeur à l Ecole des Mines d Albi Carmaux, Monsieur Eric Rondeau, Professeur à l Université Nancy 1, pour l intérêt qu ils ont porté à ce travail en acceptant de le rapporter. Un grand merci à Madame Matar, à l équipe chargée de l informatique au premier cycle de l INSA ainsi qu à ses responsables, et enfin à l équipe du CS Doua Aïkido, pour sa tolérance, sa formidable énergie et sa bonne humeur. Merci à toutes les personnes bienveillantes qui m ont soutenues et aidées, explicitement ou non, dans mes recherches souvent difficiles, mais toujours passionnantes. Les amateurs de musique ont ceci de pénible qu ils nous demandent toujours d être totalement muets au moment même où nous souhaiterions être absolument sourds. Oscar Wilde i

4 ii

5 A mes parents. iii

6 iv

7 Table des matières Introduction générale xv Partie I Introduction 1 Chapitre 1 La modélisation de l entreprise 1.1 Définitions et problématique Concepts et composants de la modélisation d entreprise Les méthodologies de modélisation d entreprise Un exemple de démarche orientée décisionnel : GRAI GIM Un exemple de démarche orientée ressources humaines : PERA Exemples de démarche orientée système informatique : IEM ou ARIS Vers un premier cadre intégrateur : CIMOSA Vers une architecture fédératrice : GERAM Bilan sur les architectures d intégration : Méthodes spécifiques adaptées à la conception et à l évolution des SI : IDEF0 / SADT : Merise Approches objet Méthodes orientées composants et patrons métiers RAD : Conclusion v

8 Table des matières 1.5 L importance du workflow et du BPR dans la modélisation d entreprise Le workflow : Les process de business et leur réingénierie Conclusion Chapitre 2 Administration des systèmes distribués 2.1 Administration de base Configuration Gestion des pannes Performance Comptabilité Sécurité Standards pour la sécurité des infrastructures La série arc-en-ciel du DoD Le standard ITSEC de l Union Européenne Les Common Criteria Le standard ISO Méthodes de haut-niveau pour la sécurité des infrastructures Expressions des besoins et des objectifs de sécurité : méthode EBIOS La méthode MEHARI L étude des attaques : la méthode OCTAVE SNA La méthode Mass La mise en œuvre d une architecture de sécurité et le suivi de son utilisation grâce à la méthode Safe Techniques de mise en œuvre de la sécurité au sein du système informatique La sécurité par le contrôle d accès La sécurité par le chiffrement Les logiciels et les protocoles de mise en œuvre des techniques de sécurité Conclusion Méthodes avancées de détection en matière de sécurité des infrastructures 77 vi

9 2.5.1 Propriétés attendues d un SDI Les approches actuelles en détection d intrusion Les approches empiriques La détection de l inconnu : immunologie Vers l administration proactive des systèmes distribués Chapitre 3 Administration proactive à l aide d agents mobiles 3.1 Pourquoi les agents mobiles? Application aux systèmes distribués Sécurité et agents mobiles : Problèmes courants Types d attaques possibles sur un serveur : Points techniques De la sécurité des codes mobiles et de l exécution de fonctions encryptées : Conclusion : Les principales plates-formes d agents mobiles Conclusion Partie II 99 Introduction 101 Chapitre 1 Démarche de conception du système de gestion de l infrastructure : 1.1 Introduction Etablissement des modèles statiques : concepts fondamentaux Définition du concept de ressource Définition du concept d acteur Définition du concept de règle Modèle d infrastructure et administration Modèle de données d administration Modèle de données global de l infrastructure vii

10 Table des matières 1.4 La conception du modèle organisationnel Description des concepts : Le modèle organisationnel global : Lien entre le modèle organisationnel et le modèle d infrastructure : Exploitation du modèle global et construction du modèle dynamique Vue générale : Phase descendante : Phase ascendante : Grille de description des échanges du système de gestion de qualité de service Organisation de la grille : Horizons stratégique, tactique et opérationnel : Utilisation de la signature de comportement Conclusion : Chapitre 2 Organisation générale du système de gestion croisée 2.1 Introduction Principe du système de gestion Un système de gestion multi-niveaux Des niveaux découpés en zones d administration Architecture détaillée du système de gestion Mise en œuvre du système de gestion de l infrastructure via la plateforme Aglets Des serveurs et des agents : Genèse du système de gestion de l infrastructure Délimitation des zones d administration Création des serveurs d administration Collecte d indicateurs à l aide des agents mobiles Le rôle des contrats dans l optimisation de critères Implantation du système de gestion Rôle des agents de collecte de données : Rôle des agents d administration : Sécurité du système de gestion de l infrastructure : Authentification des nœuds et accès au service aglets viii

11 2.8.2 Sécurisation de l administration et de la collecte de données Sécurisation de la gestion des données inter-zone Possibilité d itinéraire inter-zone pour un aglet Conclusion Chapitre 3 Mise en œuvre de la plate-forme et résultats 3.1 Introduction Validation du modèle de données du SI Rappel du contexte Démarche Etude de cas sur une entreprise virtuelle Mise en place des agents mobiles de collecte d information Aspects pratiques de la plate-forme et expérimentation Mécanismes de sécurité mis en œuvre Scénarios concernant les agents mobiles de la plate-forme Les agents mobiles : un système intrusif Simulation de pratiques collaboratives : injection de trafic Exemple : extraction des pratiques collaboratives Scénario de collecte adopté Résultats Conclusion et perspectives Conclusion générale 189 Annexes Annexe A code A.1 Aglet 1, première classe : EnvoiParallele A.2 Aglet 1, seconde classe : Travailleur A.3 Aglet 2, première classe : Lanceur A.4 Aglet 2, seconde classe : Travailleur ix

12 Table des matières Annexe B Mécanismes avancés de sécurité : Kerberos B.1 Kerberos et l authentification - introduction B.2 Principe du tiers de confiance - le KDC B.3 L authentification Kerberos B.3.1 Le service d authentification (AS) B.3.2 Le service de délivrement de ticket (TGS) B.4 Limitations B.5 Un point sur l authentification inter-domaine avec Kerberos : Annexe C Interopérabilité des principales implémentations de Kerberos C.1 Contexte C.1.1 Microsoft et les écarts par rapport aux standards C.1.2 Description des types d interopérabilité des implémentations C.2 Tests C.2.1 Configuration avec un seul KDC C.2.2 Configuration avec plusieurs KDC C.2.3 Authentification avec un KDC sous UNIX C.2.4 Le service de changement de mots de passe Liste des acronymes 213 Bibliographie 217 x

13 Table des figures 1 Vue d ensemble du système de gestion de la qualité de service dans le SI de l entreprise xvii 2 La qualité de service de bout-en-bout dans le SI de l entreprise xvii 1.1 Cadre de référence de modélisation des SI ([Lon04], page 36) Séquencement des étapes du cadre de référence pour la conception et la modélisation du SI en vue de son évolution ([Lon04], page 38) Tableau des architectures de référence GRAI La grille GRAI Un exemple complet de grille GRAI ([Lut96], page 45) L architecture ARIS Cadre de modélisation CIMOSA Cycle de vie GERAM pour une entreprise ou une entité GERAM : Architecture et méthodologie de référence pour l entreprise Les différents niveaux d intégration des systèmes Les méthodes classiques de modélisation d un SI L activité dans IDEF Hiérarchie de diagrammes IDEF Tableau récapitulatif des types de workflow et des caractéristiques associées Les différents types d administration des infrastructures Les concepts de la sécurité des systèmes d information Chronologie des standards Services de sécurité impliqués selon les différents niveaux de certification (N=Non, Y=Oui, O=Optionel) Analyse de vulnérabilité selon les différents niveaux de certification d après [EEC91] (O = Oui) Comparaison des niveaux de certification ITSEC et TCSEC d après [EEC91] Contexte d évaluation défini dans les Common Criteria d après [co98], p Modèle des concepts de sécurité d après [co98], p Niveaux de certifications des Common Criteria d après [co98] Méthode proposée dans le standard ISO Notation de la probabilité de l événement (P) Echelle de dommages (H) Evaluation des risques d après [Car01], p xi

14 Table des figures xii 2.14 Démarche EBIOS globale [DCS04] Les trois plans issus de la méthode Processus de gestion des risques avec OCTAVE [Ree03] Identification des risques et de leurs impacts [Ali04] Enchaînement des phases de SNA Risques et méthodes d atténuation associées Les technologies utilisées par SAFE [CT00] Organisation d une architecture sécurisée pour l entreprise (selon SAFE) ([CT00] p.4) Les grandes étapes de l authentification Kerberos Principe de base d un firewall Schéma de la configuration générale d un firewall Exemple de maillage Exemple de table de phéromones pour le nœud Comparaison des différentes plates-formes d agents mobiles Constitution d une Ressource Propriété d une Ressource Récursivité de la ressource d infrastructure Historisation des données propres à la ressource Interaction entre les processus issus d une même tâche Utilisation des règles par les processus Agencement des tâches, processus, acteurs et journaux Taux d accès hebdomadaire sur un serveur web Exemple de perte de paquets sur des flux gérés à l aide de DiffServ Exemple de profils et de politiques pour le domaine OSI concernant la sécurité Lien entre la ressource, ses profils et ses politiques Agencement et échange de consignes entre acteurs Instanciation partielle du modèle Modèle global d infrastructure Les acteurs et les rôles dans l organisation Description de la macro-ressource Description des droits d accès Description de la ressource organisationnelle La tâche dans un workflow traditionnel La tâche dans un workflow ad-hoc Les entités composant la partie workflow Modèle organisationnel global Corrélation du modèle d infrastructure et du modèle d organisation Vue globale du système de gestion de la qualité de service du SI Vue macroscopique de la grille de description des interactions du système de gestion de la qualité de service Grille de description des interactions du système de gestion de la qualité de service

15 1.27 Agencement et échange de consigne entre acteurs Illustration des échanges entre les acteurs à travers les différents niveaux de décision Détection de virus arrivant sur un serveur mail Moyenne des processus présents dans la file d exécution d un serveur de base de données sur les différents jours de la semaine Une architecture multi-niveaux pour le système de gestion de manière à gérer les trois niveaux du SI Une architecture multi-zone pour chaque niveau du système de gestion Architecture complète du système de gestion Interactions entre les serveurs du système de gestion Architecture interne des serveurs de gestion de zone d un niveau décisionnel Détail de la station d administration L infrastructure d un niveau décisionnel du SI comme un ensemble de nœuds L infrastructure d un niveau du SI segmenté en zones spécifiées par des contraintes Les zones du SI spécifiées en contraintes techniques Configuration initiale Collecte d indicateurs Collecte sur les équipements pouvant recevoir les agents mobiles et les équipements ne le pouvant pas Appel d offre Soumission des offres choix des offres Initialisation d un nouveau nœud : envoi des aglets en broadcast vers les autres nœuds Initialisation d un nouveau nœud : extraction des informations contenues par les aglets par les nœuds destinataires Initialisation d un nouveau nœud : envoi de nouveaux aglets contenant l adresse du serveur vers le nouveau nœud Authentification et accès au service aglets Le service aglet et les clés de sessions des nœuds administrables Administration sécurisée des nœuds Collecte de données sécurisée Echanges de données horizontaux Echanges de données verticaux Partage des clés de cryptage entre les différents niveaux pour l authentification inter-domaine Authentification d un serveur auprès d un autre serveur (cas le plus défavorable) (les flèches montrent le trajet de la demande d authentification) l infrastructure de management d une organisation virtuelle vue comme un ensemble de nœuds administrables (vue d un seul niveau décisionnel) xiii

16 Table des figures 3.2 Modèle global simplifié de l organisation articulée autour des ressources, des journaux de log, et des profils de comportement Infrastructure d entreprise virtuelle simplifiée Plate-forme de modélisation de l entreprise virtuelle Implantation du système de gestion de la qualité de service dans une entreprise virtuelle La sécurité de la plate-forme Exécution d une commande à distance sur une cible unique Exécution d une commande sur tout un itinéraire Agents résidents sur les nœuds cibles Scénario choisi pour évaluer l aspect intrusif du système de gestion de la qualité de service Réception agent et émission agent + message sur mathieu05 (échantillonnage à la minute) Réception agent + émission message sur mathieu06 (échantillonnage à la minute) Octets reçus par mathieu02 et mathieu03 (échantillonnage à la minute) Moyennes des octets en réception sur les différents nœuds du réseau (échantillonnage minute) Trafic erratique reçu sur mathieu02 échantillonné toute les une,cinq et 10 minutes Trafic en bloc reçu sur if04 échantillonné toute les une,cinq et 10 minutes Trafic en bloc reçu sur if04 échantillonné toute les 15 minutes (cas limite) Trafic en bloc reçu sur if04 échantillonné toute les 20 minutes Configuration physique de la plate-forme Séquence des opérations Flux de données Trafic erratique de type http sur mathieu02 (échantillonnage à la minute) Trafic de type transfert de fichiers sur if04 (échantillonnage à la minute) 188 B.1 Authentification Kerberos C.1 Les différentes configurations et les modes associés C.2 Relation de confiance bilatérale entre KDC UNIX C.3 Relation de confiance unilatérale C.4 Confiance bilatérale entre KDC xiv

17 Introduction générale Le contexte économique actuel est fortement évolutif, et pour répondre aux demandes du marché, il est nécessaire que les entreprises soient suffisamment performantes, en ce sens qu elles doivent être réactives et flexibles à un environnement évoluant rapidement. Pour cela, il est fondamental qu elles possèdent une organisation et une infrastructure de fonctionnement capable d être reparamétrable facilement pour prendre en compte ces évolutions de manière proactive, de telle manière qu elles soient en mesure de s adapter à l évolution du contexte économique. La qualité de l adaptation de l entreprise à un contexte évolutif est fortement liée à la qualité de service offerte par son infrastructure de fonctionnement. En effet, toute entreprise a besoin d une telle infrastructure pour être opérationnelle. Cette dernière prend en charge l ensemble des opérations de l entreprise, et on l appelle communément le système informatique (SI). On peut associer au SI des indicateurs pour refléter la qualité de son fonctionnement, c est la notion de qualité de service (QoS) de bout-en-bout. Dans ce cadre, l infrastructure joue un rôle important et doit correspondre aux besoins. Aussi, pour la dimensionner, il est nécessaire d avoir une idée des besoins et il faut donc les définir et les modéliser. Pour mener cette étude, nous recourons aux techniques de modélisation d entreprise qui permettent d obtenir des modèles donnant une vue statique complète de l entreprise et qui fournissent ainsi une base de prévisions permettant de réaliser le dimensionnement. L utilisation de l infrastructure du SI peut être considérée comme étant dynamique et évolutive, c est-à-dire qu elle va elle-même générer de nouveaux besoins qui vont l amener à évoluer. Pour bien gérer les évolutions, il est souhaitable d utiliser les prévisions fournies par les modèles d entreprise, et de les faire évoluer compte tenu du contexte dynamique dans lequel on se trouve. La notion de qualité de service est un outil permettant de fournir un feedback sur le bon fonctionnement de l infrastructure et permet d affiner les paramétrages et de prévoir les évolutions, ce qui aura un impact également sur les modèles d entreprise, qui devront être mis à jour à leur tour. Ce positionnement est évident dans une entreprise conventionnelle mais il est renforcé dans le cadre des entreprises virtuelles et/ou étendues car ces organisations nécessitent plus de flexibilité, de sécurité et de réactivité par rapport aux entreprises classiques, ce qui renforce les besoins en terme de bon fonctionnement de l infrastructure. En outre, leur durée de vie assez courte impose de concevoir une infrastructure adaptative qui ne soit pas un frein pour la collaboration inter-entreprise. Pour prendre en compte l évolution des organisations, un processus de réingénierie continu peut être envisagé. Ce type de processus nécessite un système qui donne des informations pertinentes et relativement complètes sur l utilisation réelle du SI. Ces données xv

18 Introduction générale d administration sont issues de différentes sources et ne sont pas structurées. Aussi, nous avons construit un modèle global permettant d intégrer les modèles de processus d entreprise, la description de l infrastructure et les données d administration reflétant les process réels de l entreprise, ce qui justifie une logique de reconstruction. Pour cela, nous proposons une démarche d intégration de ces différentes vues. Cette approche nous conduit à proposer un système de gestion de la QoS de bout-en-bout. En effet, la mise en place d une bonne QoS dépend d une collecte de données d administration représentatives et de l exploitation correcte de ces données. L administration des infrastructures permet de collecter les données concernant les différents processus théoriques et réels de l entreprise, ce qui permet de garantir l utilité du retour d usage et d adapter les modèles d entreprise aux processus réels en supprimant en partie le temps de latence de la réingénierie des processus. On peut considérer l optimisation de l entreprise suivant deux axes : une approche de haut-niveau qui a pour but d optimiser les processus à partir des modèles d entreprise une approche de bas niveau qui a pour but d optimiser l infrastructure de fonctionnement de l entreprise Les acteurs de ces approches n échangent traditionnellement pas d informations car les mondes de la modélisation d entreprise et de l administration d infrastructure sont cloisonnés. Ce cloisonnement constitue un frein au bon déroulement de l optimisation de l entreprise. Or, ces deux approches sont complémentaires et il serait judicieux de créer une synergie entre elles pour mettre en place des boucles de rétroaction et ainsi améliorer l optimisation de l entreprise (figure 1). Concrètement, l unification de l administration des infrastructures avec la modélisation d entreprise se traduit par le fait qu on doit structurer des sources de données différentes car le SI, qui constitue la mine d information concernant à la fois l infrastructure et l organisation, n est pas structuré du point de vue de l information qu il contient. Pour parvenir à cette structuration de l information, il est nécessaire d établir des modèles de données permettant de corréler les informations du SI entre elles. Pour obtenir un système intégré, ces modèles devront être regroupés au sein d un modèle de données global unique, ce qui permettra de fédérer la totalité des gisements d information provenant du SI. Le modèle de données global permet de fournir une vue intégratrice de l ensemble de l organisation, ce qui permet d interpréter au mieux les données provenant du SI. On peut distinguer deux grandes classes de données dans le SI : les données relatives à l exploitation du SI (données opérationnelles) et les données relatives au fonctionnement de l organisation (données organisationnelles). Un modèle de données pour chacune de ces classes sera établi. Par ailleurs, outre la corrélation, il faut être capable d exploiter les informations du SI, ce dernier étant un système fortement distribué, dynamique, hétérogène et avec des contraintes de connectivité instable. Dans ce cadre, une approche centralisée de l exploitation des informations ne convient pas, et une approche distribuée de traitement de l information, basée sur des agents mobiles par exemple, semblerait plus adaptée. La dimension organisationnelle du SI décrit comment le système informatique, qui n est autre qu un ensemble de ressources matérielles et logicielles, est amené à remplir un rôle fondamental au sein de l organisation (entreprise, université...). Cela suppose que xvi

19 Modèle d'entreprise orientations théoriques proaction GAP évolution permanente de l'entreprise explication Modèle réel entreprise orientations réelles Workflow ordonnancement, tâches, acteurs Workflow effectif Flux prévisionnels données traitements indices de recherche de corrélation détection administration mine de données brutes récupère profils d'utilisation de l'infrastructure profils d'utilisation de l'organisation Flux réels Fig. 1 Vue d ensemble du système de gestion de la qualité de service dans le SI de l entreprise Système d'information de l'entreprise infrastructure technique : équipements de communication infrastructure organisationnelle : processus de décision, échange entre services... indicateurs techniques indicateurs organisationnels proaction mise en correspondance QoS de bout en bout Fig. 2 La qualité de service de bout-en-bout dans le SI de l entreprise xvii

20 Introduction générale le système est conçu de telle manière qu il puisse prendre en compte la structure de l organisation pour laquelle il opère. La dimension organisationnelle concerne donc tous les mécanismes mis en place au sein du SI pour que ce dernier puisse gérer l entreprise. La dimension opérationnelle du SI décrit comment le SI fonctionne au sens technique du terme, c est-à-dire que cette dimension est chargée du contrôle du bon fonctionnement des infrastructures de communication. Dans notre démarche de mise en place d un système de gestion de la QoS de bout-en-bout, il sera fondamental de faire le lien entre la dimension infrastructurelle du SI et sa dimension organisationnelle. Ces concepts sont illustrés par la figure 2. Le but des modèles de données étant de structurer les informations provenant du SI de manière à faire le lien entre les différents niveaux stratégiques du SI, ce qui est en fait une mise en perspective des données du niveau opérationnel au niveau organisationnel, il sera nécessaire de faire une correspondance entre les modèles de données d infrastructure et d organisation. Une fois cette correspondance établie, les données issues du niveau opérationnel et celles provenant du niveau organisationnel s expliqueront mutuellement. Une fois que les modèles de données permettant la bonne exploitation des informations provenant des infrastructures sont établis et mis en correspondance, il est nécessaire de mettre en place un système de collecte et d exploitation des données adapté à la complexité des infrastructures des SI distribués. Pour cela, le paradigme des agents mobiles nous a paru particulièrement adapté par rapport aux approches centralisées classiques. La mise en perspective et l exploitation de données brutes dans un système distribué est un problème classique qu on retrouve très souvent dans la gestion d infrastructures informatiques. Il s agit d un problème distribué, et un contrôle centralisé de la résolution de tels problèmes est difficile, voire souvent impossible. La majorité des problèmes trouvant leur origine au cœur des réseaux d ordinateurs en font partie. Ces environnements sont très souvent des assemblages d équipements hétérogènes de taille et de complexité importante dont la connectivité entre les éléments est dynamique et incertaine. L entretien et le contrôle de telles infrastructures sont d autant plus difficiles, car une approche centralisée, incompatible avec la distribution intrinsèque d une telle infrastructure se révèle trop peu adaptative. Par ailleurs, la vulnérabilité aux pannes de telles approches peut, à l extrême, les rendre dangereuses. Beaucoup d efforts sont actuellement déployés pour proposer des approches physiquement distribuées dans le domaine de contrôle des réseaux, en particulier dans les domaines de routage et de la protection des systèmes. Ces approches pour la gestion de systèmes distribués offrent des perspectives tout à fait intéressantes, c est pourquoi nous nous proposons d utiliser un système de gestion de qualité de service intrinsèquement distribué, basé sur les technologies d agents mobiles. Cette approche appliquée dans le contexte du système informatique de l entreprise est à la fois novatrice et prometteuse. Cette thèse est composée de deux parties. La première partie décrit les concepts liés à la modélisation d entreprise pour être en mesure d établir un modèle global de l organisation permettant de recouper les indicateurs provenant des différents niveaux et de les mettre en perspective. Les concepts liés à l administration des infrastructures informatique sont ensuite détaillés de manière à fournir une connaissance de ce qui a été déjà fait dans le domaine de l administration des systèmes d information. L administration des infrastructures informatiques et la modélisation d entreprise sont des domaines vastes et très différents. Compte-tenu de la grande étendue des domaines que constituent la xviii

21 modélisation d entreprise et l administration des infrastructures informatiques, l état de l art qui en est fait est plus large que pointu. Il a pour rôle de donner les grandes lignes de ces domaines de telle manière qu il soit possible d envisager ensuite leur intégration dans le but d optimiser l organisation dans sa globalité. Par ailleurs, nous soulevons une manière d appréhender les méthodes de construction et de corrélation des indicateurs entre-eux. Enfin, nous présentons la technologie des codes mobiles, et les possibilités de sécurisation de tels codes. La seconde partie décrit tout d abord le modèle de données qui permettra de recouper les indicateurs provenant des différents niveaux de l organisation, puis nous présenterons l architecture du système de gestion de la qualité de service, avec une proposition de sécurisation de celui-ci, et enfin les résultats obtenus. xix

22 Introduction générale xx

23 Première partie xxi

24

25 Introduction Face à un contexte économique très évolutif, il est nécessaire que les entreprises possèdent une organisation optimale pour répondre à des besoins parfois complexes qui changent rapidement. Un tel contexte a poussé les organisations à former des alliances sous la forme d entreprises virtuelles ou étendues qui sont des organisations devant évoluer rapidement pour répondre à un besoin précis et volatile. Ces structures permettent d améliorer la flexibilité, l évolutivité et la réactivité de l organisation. Les groupements d entreprise se créent pour effectuer des projets spécifiques limités dans le temps. Dans ce cadre, l organisation de l entreprise et son infrastructure de fonctionnement doivent être optimisées au maximum. Dans un tel contexte, il y a nécessité d intégrer les différents services, de partager les informations, de rationaliser l organisation et d éviter les redondances, ce qui se résume à une optimisation de l organisation. Cette dernière peut être freinée, à cause notamment de la diversité des communautés d acteurs de l organisation souvent cloisonnées et qui possèdent différents points de vue de l entreprise et des améliorations à apporter. Par rapport au désir de faire évoluer l entreprise, l optimisation du système informatique (SI) pour mieux répondre aux besoins de l entreprise est une nécessité, ce qui conduit à une remise en question permanente du SI. Pour optimiser l organisation de l entreprise et la QoS de son système informatique, deux approches peuvent être envisagées : une approche de haut niveau qui consiste à améliorer les processus de l entreprise. C est une approche théorique dans laquelle il est nécessaire de modéliser l entreprise. Cette approche peut rencontrer le non-soutien des usagers car elle implique des changements abruptes de l infrastructure. Elle présente par ailleurs des délais d ingénierie important, ce qui peut créer des décalages entre les besoins exprimés à l instant t, pour lesquels les processus ont été repensés, et les besoins à l instant t+1, qui correspondent à leur mise en œuvre réelle. une approche plus pragmatique consiste à améliorer l existant, c est-à-dire en améliorant les infrastructures de fonctionnement de l entreprise. Or l administration du SI fournit toutes les clés pour cela, en terme d informations et de moyens. Pour ce même but d optimisation, on a deux approches, l une théorique et l autre pratique. Ces deux approches travaillent sur des informations différentes mais complémentaires pour l optimisation. Or, ces informations ne sont traditionnellement pas corrélées compte tenu du fait qu elles appartiennent à deux mondes complètement dissociés. La modélisation de l entreprise appartient plus à la cellule décisionnelle de l entreprise tandis que l administration est gérée par des équipes d exploitation informatique. Il est donc 1

26 Introduction nécessaire, par rapport à l intérêt de ces approches, de les explorer en détail. Nous nous intéresserons donc dans un premier temps aux principes de base de la modélisation d entreprise, puis à l administration des infrastructures de fonctionnement, qui sont le plus souvent distribuées. Enfin, nous explorons l intérêt de l utilisation des agents mobiles pour une administration efficace et flexible des architectures distribuées. L utilisation des technologies de pointe comme les agents mobiles pour effectuer l administration des infrastructures de fonctionnement renforce le besoin d avoir une sécurité optimale du système informatique, car ce type de technologie pousse à utiliser de manière extrême tout le potentiel des équipements du système d information, et peut introduire par là des failles de sécurité. Par ailleurs, le fait de travailler dans des environnements constitués d entreprises virtuelles ou étendues renforce les besoins de partage et d échange de données, ce qui peut également créer des problèmes de sécurité. Or, la sûreté des systèmes est capitale pour la survie de l entreprise, il est donc nécessaire d avoir à disposition tout un arsenal de méthodes et de techniques permettant de concevoir une architecture du système informatique la plus sûre possible. A cet effet, un panel de méthodes et de techniques permettant de répondre à des contraintes de sécurité sera étudié. 2

27 1 La modélisation de l entreprise 1.1 Définitions et problématique La notion d entreprise telle qu elle est comprise dans le contexte de la modélisation d entreprise peut se définir comme l ensemble organisé des activités mises en œuvre par des ressources techniques et / ou humaines dans le cadre d une finalité identifiée, qui est la raison d être de l organisation. L entreprise dans sa globalité est un domaine très vaste. Dans le cadre de la productique, la modélisation d entreprise concentre ses efforts sur le système de production, partie de l entreprise correspondant aux activités de création de valeur. La modélisation d entreprise a mis en évidence l importance d appréhender l entreprise à travers ses fonctionnalités. Ce point de vue permet d avoir une vision des services constituant l entreprise. Le contexte économique, favorisant l apparition d alliances d acteurs économiques au profit d un projet collectif (entreprises virtuelles ou entreprises étendues), met en avant la modélisation d entreprise qui a dans ce contexte un rôle majeur dans l analyse des réseaux complexes constitués par les entreprises virtuelles ou étendues. Aujourd hui, la quasi-totalité des activités de l entreprise, à tous les niveaux, est gérée par le système informatique de l organisation (SI). Dans un tel contexte, modéliser l organisation se limite souvent à modéliser son système informatique. La figure 1.1 représente un cadre de référence de modélisation et de conception des SI d entreprise. Selon le cadre de référence (figure 1.1), le SI peut se décomposer en 4 niveaux d architecture [Lon04] : niveau d architecture métier. Il s agit du niveau le plus abstrait et le plus proche de la stratégie de l organisation. Il doit répondre à la question Quels sont les métiers de l entreprise?. Une manière de répondre à cette question est de modéliser les processus de l entreprise. niveau d architecture fonctionnelle. Une fois que les métiers sont définis, il faut répondre à la question que va-t-on faire pour être capable de faire ces métiers?. C est le Quoi. Il s agit de l étape de spécification du système informatique en terme d applications. niveau d architecture applicative. Il a pour rôle de donner les clés permettant de réaliser les spécifications définies au niveau de l architecture fonctionnelle. C est le Comment. 3

28 Chapitre 1. La modélisation de l entreprise Les quatre niveaux stratégie de l'organisation du cadre de référence Architecture métier Quels métiers? Niveau d'abstraction Architecture fonctionnelle Architecture applicative Quoi? Comment? Acteurs et organisation Architecture technique Avec quoi? Fig. 1.1 Cadre de référence de modélisation des SI ([Lon04], page 36) niveau d architecture technique. Il s agit du niveau le moins abstrait dans la hiérarchie des niveaux d architecture du SI. Il doit répondre à la question Avec quels composants va-t-on réaliser les applications définies au niveau de l architecture applicative. C est le Avec Quoi. Le séquencement des étapes dans l élaboration de la politique de conception et d évolution du SI est représenté par la figure 1.2. D après ce cadre de référence, il est facile de comprendre l importance de la modélisation des métiers de l entreprise dans le but de modéliser le SI. En effet, ce sont les métiers de l entreprise qui décident du contenu du SI. Or les métiers se décrivent très bien à l aide des processus créateurs de valeur ajoutée de l entreprise. Dans ce cadre, on voit bien l intérêt d une modélisation orientée processus. Un processus, au sens métier, manipule à la fois des données statiques qui représentent le cœur du métier et des données dynamiques qui sont liées aux flux échangés par le processus. Les données statiques évoluent peu et peuvent donc être parfaitement décrites par un modèle de données. Les données dynamiques sont beaucoup plus volatiles, car elles sont liées aux flux, et les flux évoluent rapidement dans le contexte dynamique de l entreprise. C est ici où ce qu on appelle le workflow ( science de la gestion des flux ) prend toute son importance. Si le modèle des données métiers est établi, ce qui est envisageable avec une bonne expertise relative aux métiers de l entreprise, la modélisation des processus peut se ramener à la modélisation des flux (workflow). Il existe différentes formes de flux dans l entreprise. Les plus évidents sont les flux produits, et les flux financiers. Mais il existe un d autres types de flux prépondérants : les flux d informations et de décision. Ces derniers sont d autant plus complexes que l entreprise 4

29 1.1. Définitions et problématique Niveaux du cadre de référence Métier Stratégie métier Architecture métier existante Architecture métier cible Fonctionnel Architecture fonctionnelle cible Applicatif Architecture applicative existante Architecture applicative cible Technique Architecture technique existante Architecture technique cible Fig. 1.2 Séquencement des étapes du cadre de référence pour la conception et la modélisation du SI en vue de son évolution ([Lon04], page 38) modélisée l est. Les activités concernant l information (traitement, mémorisation, transport) doivent être cohérentes avec les autres activités de l entreprise. Cette cohérence est définie d un point de vue sémantique (la bonne information) et d un point de vue dynamique (au bon moment). Dans ce cadre, il est fondamental de maîtriser les flux (maîtrise du workflow) pour modéliser l entreprise. La conception, l évaluation, l exploitation et l évolution des systèmes d information font partie des thèmes majeurs de la productique, et, à ce titre, concernent la modélisation d entreprise. L évaluation des systèmes d information vise à connaître les performances de ce dernier. Elle est utilisée en général pour comparer les performances existantes à des performances attendues. La conception d un système informatique va utiliser la modélisation d entreprise comme outil de spécification. L évolution permanente du contexte économique conduit à envisager en permanence de nouvelles organisations. Il existe donc un besoin d adaptation permanent. On peut noter que même dans le cas d un système complètement nouveau, une action de conception ne partira jamais de rien. Il est beaucoup plus courant de faire évoluer les installations existantes que d en créer de nouvelles. Les entreprises actuelles sont beaucoup plus souvent demandeuses d actions de restructuration que d actions de conception. La liaison avec le niveau stratégique apparaît aujourd hui comme étant indispensable dans la course à la performance. Ainsi, le découplage entre la gestion des infrastructures et la gestion de l organisation doit être proscrit : les fonctionnalités et les performances du système de production doivent être définis en harmonie avec la stratégie de l entreprise. 5

30 Chapitre 1. La modélisation de l entreprise 1.2 Concepts et composants de la modélisation d entreprise Un modèle est une abstraction et une représentation simplifiée de la réalité. Elle agit comme un filtre sur la partie du monde réel qu elle représente, ne conservant que l information essentielle pour l étude et supprimant les détails inutiles. La démarche générale consiste à abstraire les relations entre les entités modélisées. Ce processus d abstraction est appelé modélisation. Nous faisons la distinction entre la modélisation et le formalisme utilisé pour effectuer le modèle. La modélisation est une représentation abstraite du monde réel, tandis que le formalisme de modélisation est utilisé pour décrire cette représentation. Les modèles d entreprise doivent permettre : la représentation du système, tant son état actuel que les différentes possibilités d évolution, l évaluation (du système existant ou à venir), l optimisation des performances du système. En plus de ces besoins techniques, les modèles doivent remplir un rôle de support aux acteurs humains du projet en favorisant : la communication à l intérieur du projet, la communication dans l espace (échanges entre les acteurs pouvant appartenir à des structures différentes de compétences différentes), la communication dans le temps (archivage et documentation), les décisions de conception ou de modification du système. La modélisation d entreprise doit donc proposer des formalismes conduisant à des modèles permettant la valorisation du système, et d autre part, les modèles obtenus doivent être facilement appréhendables par les acteurs de l entreprise. De plus, par rapport à la complexité de l entreprise, les modèles doivent pouvoir être déclinés suivant plusieurs points de vue (projection) et adopter différents niveaux de détail pour correspondre aux besoins de leurs utilisateurs se situant à tous les niveaux de l entreprise. Les outils proposés par la Modélisation d Entreprise sont constitués de modèles, de méthodes, et de démarches de raisonnement ainsi que de supports informatique assistant le concepteur dans sa tâche d amélioration. L ensemble des méthodes manipule les concepts principaux suivant : l activité, le processus, l événement, la ressource, le flux. Pour réaliser un modèle, il est nécessaire d adopter une démarche structurée, ceci afin d obtenir un résultat utilisable. C est l intérêt des méthodes. Une méthode peut avoir 6

31 1.3. Les méthodologies de modélisation d entreprise des bases théoriques formelles. En règle générale, une méthode évolue au cours de son élaboration et de son utilisation. Elle définit par ses règles un mode d emploi qui permet de résoudre un problème. La représentation d un problème peut être réalisée au travers d un modèle, construit dans un certain formalisme. On distingue la notion de méthode de la notion de méthodologie. Nous considérons une méthodologie comme un ensemble de méthodes utilisant des formalismes de modélisation et des outils de représentation associés (graphiques ou textuels), des modèles de référence et une approche structurée. Une méthode permet de résoudre un problème élémentaire isolé tandis qu une méthodologie organisant un ensemble de méthodes permet de résoudre un problème plus global. SADT, IDEFx, GRAI sont des méthodes, tandis que IDEF (l ensemble des IDEFx), GIM, CI- MOSA sont des méthodologies. Une méthodologie est en général développée en conjonction avec une architecture de référence. Une architecture de référence fournit un canevas décrivant les différents formalismes à utiliser pour mener à bien l étude tandis que la méthodologie décrit comment les utiliser. Une architecture de référence est donc un ensemble structuré de méta-modèles représentant les invariants du système à modéliser. CIMOSA, ARIS, PERA et GERAM ont proposé différentes architectures de référence. 1.3 Les méthodologies de modélisation d entreprise La modélisation d entreprise a pour but de développer et de promouvoir des méthodes, des techniques, des modèles et des outils permettant de maîtriser le comportement de l entreprise dans le temps. La modélisation d entreprise est une approche de type top/down, en ce sens qu on part des aspects généraux avant de les raffiner pour obtenir des modèles spécifiques pouvant être implémentés. Durant la modélisation, l accent peut être mis sur différentes facettes, ce qui a donné différentes démarches de modélisation possibles. Par exemple, on peut orienter la modélisation suivant le système décisionnel, ou bien suivant les ressources humaines, ou encore en partant du système informatique Un exemple de démarche orientée décisionnel : GRAI Le modèle GRAI [DBP83] [Rob91] donne une description générique d un système manufacturier en se focalisant sur les détails de la partie de contrôle du système. Dans sa méthodologie, l importance de l initialisation du programme basé sur le système courant est reconnu. Dans son framework de modélisation, les utilisateurs sont autorisés à proposer des impératifs pour le nouveau système. Un ensemble d outils de modélisation ont été développés et présentés pour promouvoir la facilité de compréhension pour des utilisateurs qui ne sont pas forcément des informaticiens. Le tableau 1.3 montre les différentes architectures de référence du modèle GRAI et à quels niveaux de décision ces architectures appartiennent. Le Système de Décision est décomposé en Niveaux de Décision et Centres de Décision. Chaque Niveau de Décision est caractérisé par un horizon et une période, critères de décomposition liés aux caractéristiques temporelles des décisions. L horizon correspond à la durée de la portée de la décision. La période correspond à l intervalle de temps au bout duquel il est nécessaire de remettre en cause les décisions élaborées sur l horizon 7

32 Chapitre 1. La modélisation de l entreprise Niveau Type de flux Données Process Opérations de décision Conceptuel Modèle conceptuel de données Modèle conceptuel de process Modèle conceptuel d'opérations Organisationnel Modèle de données d'organisation Modèle de process d'organisation Modèle opérationnel d'organisation Physique Modèle de données physique Modèle de process physique Modèle opérationnel physique Fig. 1.3 Tableau des architectures de référence GRAI considéré. Chaque Niveau de Décision est décomposé en activités. Les activités d un même niveau de décision sont regroupées selon leurs objectifs. On appelle Centre de Décision un ensemble d activités ayant même horizon et période, devant être exécutés suivant les mêmes objectifs donnés par un seul cadre de décision. Un Centre de Décision est composé : d activités de décision et d exécution, de relations d entrée (coordination, décomposition, synchronisation), de relations de sortie (résultat des décisions prises, cadre de décision, synchronisation, suivi), de relations internes au centre de décision entre les différentes activités qui le constituent. Les différents Centres de Décision sont reliés entre eux aux travers de liens de décision et d information. La notion de Cadre de Décision correspond à un lien de type décisionnel entre deux Centres de Décision. Les deux Centres de Décision considérés n appartiennent pas forcément au même niveau de décision. Le cadre de décision transmet les informations nécessaires à la prise de décision du centre de décision récepteur, à savoir les objectifs, les critères et les procédures à prendre en compte lors des prises de décision. Les liens de type informationnel modélisent les flux d information entre deux Centres de Décision, entre un Centre de Décision et l environnement extérieur de l entreprise considérée, ou encore entre un Centre de Décision et le système physique. Les relations entre les Centres de Décision sont modélisées au travers de la Grille GRAI. Cette dernière représente une vision globale et macroscopique de la structure du système étudié. Elle identifie et positionne les différents centres de décision les uns par rapport aux autres. Elle permet de mettre en évidence les principaux liens décisionnels ou cadres de décision de l organisation étudiée. La grille GRAI (figure 1.4) permet de décomposer le système modélisé selon les critères définis par la méthode GRAI : 8 les couples horizon-période relatifs à une prise de décision sont représentés sur l axe vertical,

33 1.3. Les méthodologies de modélisation d entreprise Fonctions H/P Informations Externes Gérer les produits Acheter Approv. Planifier la production Gérer les ressources Humaines Techno. Informations Internes H = P = H = P = Centre de décision H = P = H = P = Fig. 1.4 La grille GRAI les activités décisionnelles, groupées par fonctionnalités, sont représentées sur l axe horizontal. L intersection entre une fonction et un niveau de décision horizon/période (H/P) représente un centre de décision. Les liens de type informationnel sont représentés par une flèche à pointe simple, tandis que les Cadres de Décision sont représentés par une flèche à double-pointe allant du Centre de Décision émetteur vers le Centre de Décision récepteur. La colonne Informations Externes représente l interfaçage du Système de Gestion de Production avec le monde extérieur de l entreprise. La colonne Informations Internes correspond à l interfaçage du Système de Gestion de Production avec le Système Physique. Les informations représentées dans ces deux colonnes sont classées en fonction des horizons et périodes qui les caractérisent. Les colonnes entre Information Externes et Information Internes représentent les fonctions génériques du système analysé. L élaboration d une Grille GRAI est réalisée selon les étapes suivantes : identification des fonctions de gestion de production de l entreprise étudiée. Parmi toutes les fonctions possibles, ne sont représentées dans la grille que les fonctions présentes dans l entreprise, identification des couples horizon-période correspondant à chaque fonction. A la fin de cette opération, la structure de la Grille GRAI est constituée, positionnement des Centres de Décision aux intersections des fonctions et des couples (horizon, période), établissement des liens d information et de décision entre les Centres de Décision. 9

34 Chapitre 1. La modélisation de l entreprise Fonctions H/P Informations Externes Gérer les produits Acheter Approv. Planifier la production Gérer les ressources Informations Internes H = 2 ans P = 1 mois H = 8 mois P = 1 mois H = 6 mois P = 1 sem. Prévisions ventes Carnet commandes Recherche fournisseurs Définir politique appro. critiques Définir para. appro. Faire Envoyer plan commandes appro. Faire Plan long terme MRP Faire PDP Faire Ordo. moyen terme Définir politique d'embauche et S/T structurelle Définir S/T conjoncturelle Définir S/T conjoncturelle Niveau des stocks H = 3 mois P = 1 jour Relancer Faire Ordo. court terme Gérer le personnel H = 1 jour P = Temps réel Enregistrer commandes Enregistrer E/S Lancer Fabriquer Fig. 1.5 Un exemple complet de grille GRAI ([Lut96], page 45) La figure 1.5 représente une grille GRAI achevée. La méthode GRAI fournit des outils graphiques pour modéliser le système de décision d une entreprise, notamment la façon dont les décisions sont prises et les responsabilités réparties. Pour arriver à cela, la méthode GRAI fait intervenir les différents acteurs dans les grilles, notamment les flux d information, les ressources de l entreprise, les processus (activités). Toutefois la méthode GRAI ne supporte pas la modélisation des aspects fonctionnels, informationnels et physiques cités précédemment. Elle se contente d y faire référence pour appuyer la modélisation du système de décision. La méthode GRAI ne couvre qu un aspect restreint de l entreprise. Afin d élargir son champ d action, des travaux ont été entrepris au laboratoire GRAI afin de supporter les aspects de modélisation fonctionnelle et informationnelle en intégrant les méthodes IDEF0 et MERISE au processus de modélisation GRAI. Les résultats de ce travail ont donné naissance à la méthode GRAI-IDEF0-MERISE ou GIM GIM GIM [RZP89] est une méthodologie développée au laboratoire GRAI de l Université de Bordeaux en 1988 afin de remédier à certaines lacunes de la méthode GRAI et notamment étendre le champ de la modélisation au Système de Production et non plus seulement au Système de Décision. GIM modélise donc les trois sous-systèmes du Système de Production : sous-système décisionnel, informationnel et physique. GIM est l acronyme de GRAI-IDEF0-Merise. En effet, GIM résulte du constat de la complémentarité des méthodes GRAI, IDEF0 et Merise pour l analyse et la conception des systèmes de 10

35 1.3. Les méthodologies de modélisation d entreprise production et se veut une méthodologie intégrant ces trois méthodes. GIM distingue trois aspects différents : les traitements, les données et les opérations. Ces trois aspects sont modélisés à trois niveaux d abstraction différents : le niveau conceptuel, le niveau opérationnel, le niveau physique. Plus complète que la méthode GRAI, la méthodologie GIM présente toutefois un certain nombre de lacunes. Nous citerons notamment : la modélisation de système physique est incomplète. Il est fait de références aux ressources physiques utilisées au travers des mécanismes des boîtes IDEF0. Toutefois, il n existe pas de modèle physique, ou même logique, de ressources dans GIM. l intégration des modèles est faible. En effet, l intégration de GRAI, IDEF0 et Merise dans GIM est réalisée à travers des règles de cohérence entre les modèles : les différents modèles doivent être réalisés indépendamment les uns des autres. ll n y a pas unification des concepts de GRAI, IDEF0 et Merise utilisés pour modéliser chacun des aspects du Système de Production en un formalisme unique. Ceci pose notamment des problèmes lors de la validation des différents modèles deux à deux. Il n est pas prouvé que les règles de cohérence soient transitives. une fois les modèles organisationnels réalisés, GIM a recours à des techniques conventionnelles pour assurer le développement au niveau physique. La couverture réelle de GIM se limite donc actuellement aux niveaux conceptuels et opérationnels Un exemple de démarche orientée ressources humaines : PERA L architecture PERA [Wil94] est issue des travaux du Consortium Industrie-Université au Purdue Laboratory for Applied Industrial Control aux USA. Elle comprend une architecture de référence et une méthodologie associée. L architecture est composée de sept couches successives. Des phases méthodologiques couvrent le développement du système à travers les couches. La couche identification : sert à identifier l entité de l entreprise à modéliser (complexe industriel, atelier...). La couche concept : à ce niveau, l entité à modéliser permet la description des missions, des processus de gestion, des fournisseurs, etc... qui sont à la base de la définition des besoins. La couche définition : permet la définition de deux types de besoins, les besoins de gestion (gestion de la production, des informations...) et les besoins de production (opérations de fabrication). Ces besoins sont ensuite collectés dans des modules ou des fonctions, puis structurés en réseaux pour exprimer les flots d informations, de matières et d énergie. 11

36 Chapitre 1. La modélisation de l entreprise La couche de spécification : spécifie les architectures d information et de fabrication et introduit le facteur humain, en précisant les compétences à attacher pour chaque tâche, ce qui définit l architecture humaine et organisationnelle. La couche de conception détaillée : les architectures fonctionnelles précédentes sont traduites en architectures d implantation en précisant les technologies à utiliser pour effectuer les tâches spécifiées. La couche d implantation : les équipements physiques, les équipes, etc... sont mis en place. La couche de mise en œuvre et de maintenance. PERA et la méthodologie associée sont des moyens informels qui conduisent les utilisateurs durant un projet d intégration d entreprise. Ceci à l avantage de faciliter la compréhension et l utilisation grâce à sa représentation graphique et sa méthodologie complète. Les aspects humains sont correctement pris en compte. De plus, PERA a montré son extensibilité afin de couvrir tout type d industrie. Les limites de cette approche informelle résident dans le manque de formalisme mathématique et de modèles implantables, ce qui oblige de tout remodéliser à chaque fois à l aide de méthodes plus spécifiques Exemples de démarche orientée système informatique : IEM ou ARIS L importance de la maîtrise des processus au sein du SI a été soulignée dans la section 1.1. En effet, comme les processus sont très corrélés aux objectifs stratégiques de l organisation, il existe une réelle nécessité de pouvoir les contrôler, et donc d être en mesure de traiter les données liées aux processus. IEM (Integrated Information Modelling for Computer Integrated Manufacturing (CIM)) [SMS90] [MSJ91] offre un cadre de modélisation orienté données en vue de créer un système de production intégré. IEM est une approche de modélisation du système intégré d information, qui permet de dériver différents modèles d entreprise à partir d un noyau. Le noyau est un ensemble d objets génériques issus de trois classes : produits, ordres et ressources. Chaque objet défini dans une entreprise manufacturière doit appartenir à l une de ces classes. Les classes produit et ressource peuvent contenir des matières, de l information ou de l énergie. La classe des ordres ne contient que des informations. Les activités du système de production considéré traitent et modifient les objets ainsi définis, ils représentent leurs méthodes. La structure objet initiale est enrichie au fur et à mesure en rajoutant au modèle de l entreprise (objets avec leurs méthodes) des couches pour représenter la solution technique, en adaptant le modèle générique à un environnement particulier (applications propres au système, stockage des données, réseaux...). D autres éléments relatifs à l organisation et aux responsabilités des différents membres du personnel peuvent être rajoutés aux objets de l entreprise. L inconvénient majeur de cette méthode est le défaut d encapsulation du système avec ses activités, principe important de l approche objet. ARIS (Architecture of Integrated Information Systems) [She93] [SGK95] est à la fois un cadre de modélisation générique et un outil de modélisation des processus d entreprise. Le cadre de modélisation ARIS (figure 1.6), est bâti sur une approche multi-niveaux et 12

37 1.3. Les méthodologies de modélisation d entreprise Organisation Diagramme de l'organisation Topologie Réseau Modèle conceptuel Modèle technique Implémentation physique du réseau Implémentation Modèle de données sémantique Processus, flux de données, événements Modèle fonctionnel Modèle conceptuel Schéma relationnel Topologie des systèmes distribués, déclencheurs Conception des modules Modèle technique Schéma physique de données Transactions, gestion réseau Flux de programme Implémentation Données Contrôle Fonctions Fig. 1.6 L architecture ARIS multi-vues. Il distingue quatre points de vues (fonctions, données, contrôle, organisation) et comporte trois niveaux (modèle conceptuel, modèle technique et implémentation). Les différentes démarches de modélisation ont toutes leurs avantages et leurs inconvénients. Par ailleurs, le fait qu une démarche soit plus adaptée qu une autre dépend du contexte et de l entité à modéliser. Il est donc apparu intéressant d intégrer ces différentes vues au sein d une même architecture de manière à être en mesure de proposer des modèles génériques adaptés quel que soit le contexte dans lequel on effectue la modélisation. C est le rôle de CIMOSA Vers un premier cadre intégrateur : CIMOSA CIMOSA (Computer Integrated Manufacturing for Open System Architecture) a fait l objet de plusieurs projets Esprit pour son développement (AMICE) et sa validation (CIMPRES, CODE, VOICE). Durant ces différentes phases, plusieurs entreprises industrielles et organisations de recherche ont été impliquées. L architecture CIMOSA [AMI93] [GQ90] [Vli93] [Ver93] est composée d un cadre de modélisation (Enterprise Modelling Framework), d un langage de modélisation (Modelling Language) et d une infrastructure intégrante (Integrating Infrastructure). L architecture CIMOSA fournit un cadre de modélisation s appuyant sur trois principes (Cube CIMOSA) : la génération, l instanciation et la dérivation. La génération consiste à modéliser suivant quatre vues (fonctionnelle, information, ressources et organisation) : Vue fonctionnelle : le but est de fournir des outils et des méthodes permettant de : 13

38 Chapitre 1. La modélisation de l entreprise Génération Organisation Constructions Génériques Vue Organisation Modèles Partiels Vue Organisation Modèles Particuliers Vue Organisation Dérivation Instanciation Ressources Information Vue Ressources Vue information Vue Ressources Vue information Vue Ressources Vue information Fonctions Vue fonctionnelle Vue fonctionnelle Vue fonctionnelle Niveau de modélisation des Spécifications de Conception Niveau de modélisation des spécifications de Conception Niveau de modélisation de la description de l'implantation Constructions Génériques Expression des besoins Constructions Génériques Spécifications de conception Constructions Génériques Description de l'implantation Modèles Partiels Expression des besoins Modèles Partiels Spécifications de conception Architecture de Référence Modèles Partiels Description de l'implantation Modèles Particuliers Expression des besoins Modèles Particuliers Spécifications de conception Modèles Particuliers Description de l'implantation Architecture Particulière Fig. 1.7 Cadre de modélisation CIMOSA Architecture de Référence Architecture Particulière décrire la fonctionnalité, la structure de contrôle et le comportement de l entreprise. effectuer une séparation entre fonctionnalité et comportement des fonctions de l entreprise. Vue information : le but est de permettre la spécification du système informatique de l entreprise, la création d une structure afin de stocker / mettre à jour / traiter les informations (données et connaissances) pour les besoins des utilisateurs et des applications (mémoire de l entreprise). Vue ressource : le but est la spécification et la description des composants requis et/ou implantés dans le système de production servant de réalisation des tâches de l entreprise. Il s agit aussi bien des composants de la technologie manufacturière que de ceux de la technologie informatique. Vue organisation : le but est la définition des responsabilités individuelles et l organisation de l entreprise. L organisation de l entreprise est exprimée en termes de cellules, d unités et de niveaux de prise de décision. L instanciation consiste à construire le modèle particulier de l entreprise à partir de modèles partiels exprimés en termes de constructions génériques de base. Ainsi, les modèles particuliers sont des modèles d entreprises particulières obtenus soit en particu- 14

39 1.3. Les méthodologies de modélisation d entreprise larisant des modèles partiels aux besoins précis d une entreprise, soit à partir de constructions génériques de base fournies par CIMOSA. Enfin, CIMOSA couvre tout le cycle de vie de la modélisation, grâce à la dérivation. Elle consiste à modéliser d abord les besoins de l entreprise, puis les spécifications de conception et enfin la description de l implémentation. Pour cela, CIMOSA retient les éléments suivant : Expression des besoins : c est la construction d un modèle utilisateur qui définit ce qui doit être réalisé dans l entreprise (le QUOI). Spécification de conception : c est la construction d un modèle de l entreprise non ambigu et cohérent. Différents modèles peuvent être développés pour étudier diverses alternatives par la biais de la simulation. Description de l implantation : c est la construction d un modèle exécutable de l entreprise (le COMMENT). Ainsi, une entreprise est divisée en domaines susceptibles d être étudiés par des équipes disjointes et à des moments différents. Chaque domaine est modélisé à l aide de constructions génériques communes aux différents points de vue. Ces constructions constituent les classes d objets de l entreprise. Un domaine est ainsi modélisé à l aide de processus, d événements et d activités d entreprise. Ces concepts décrivent les fonctionnalités et le comportement de l entreprise grâce aux règles de comportement qui relient les activités entre elles. Les entrées et les sorties des activités forment des objets d entreprise, les informations et les ressources nécessaires. Les activités se décomposent au niveau de la conception en opérations fonctionnelles. Chaque opération est exécutée par une entité fonctionnelle. Ces dernières sont des ressources de l entreprise telles que des humains, des machines ou des applications. Les aspects organisationnels sont définis en termes de responsabilités et d autorisations pour les fonctionnalités, les informations et les ressources. Ils sont structurés en unités organisationnelles. Ces constructions de base utilisent le concept orienté objet d héritage pour une structure hiérarchique des classes d objets. Pour l ingénierie et le contrôle d exécution des modèles d implantation de CIMOSA, l Infrastructure Intégrante (ISI) fournit un ensemble générique de services, pour des environnements hétérogènes caractérisant les environnements industriels. L ISI se comporte comme un système d exploitation contrôlant non plus uniquement le traitement traditionnel des données mais également tous les composants du système d entreprise, les personnes et les machines incluses. Elle est brièvement décrite ci-dessous [AMI93] [Que92]. L infrastructure se compose de cinq unités : L entité d Exécution (Business Entity) consiste à contrôler l exécution du modèle d implantation particulier en créant les occurrences des processus-maîtres et leur hiérarchie, puis à analyser le modèle et à affecter les ressources informatiques et manufacturières via ses fonctions génériques de gestion des processus, des activités et des ressources. L entité de Présentation (Presentation Entity) assure l interface entre les ressources (humains, machines et applications) et les autres entités. L entité d Information (Information Entity) assure la gestion des informations de l entreprise, des bases de données, des accès aux données, etc... 15

40 Chapitre 1. La modélisation de l entreprise L entité des Services Communs (Common Entity) fournit les services communs aux autres entités, essentiellement l échange de messages entre les services, la gestion des réseaux, les autorisations, la sécurité... L entité de Gestion du Système (System Management Entity) gère les outils informatiques de l entreprise, la distribution et l installation de mises à jour, les configurations, le lancement et l arrêt des systèmes, la gestion des erreurs, etc... Une particularité très intéressante est que CIMOSA fournit des modèles génériques permettant d instancier des processus génériques. Ces derniers sont un point de départ intéressant pour l implantation d installations physiques, toutefois, il peut être utile, voire nécessaire de faire la correspondance entre les processus génériques, qui restent théoriques, avec la réalité de l entité modélisée, de manière à ajuster au mieux les processus génériques. Le Business Process Reengineering (BPR) est particulièrement adapté pour cette mise en correspondance (voir section 1.5.2). Il existe donc différentes méthodes de modélisation qui sont plus ou moins adaptées suivant le contexte dans lequel on effectue la modélisation. Par rapport à cette diversité, il est nécessaire d intégrer ces différentes vues de la modélisation dans le but d obtenir des modèles génériques (rôle de CIMOSA). Dans l idéal, CIMOSA permet de modéliser n importe quelle entreprise, grâce à l intégration des différentes vues, avec une méthode unique décrite par CIMOSA. Néanmoins l application de CIMOSA sur une étude de cas dans [LGMF94] montre que CIMOSA est une architecture complète mais lourde à mettre en œuvre. De plus, le grand nombre des concepts utilisés constitue un frein supplémentaire à la mise en œuvre de la méthode et l absence de support logiciel accentue ce problème Vers une architecture fédératrice : GERAM Dans la modélisation d entreprise, nous sommes confrontés à une diversité des objectifs et à une diversité des méthodes. Beaucoup de méthodes ont été développées, et on ne peut pas dire que l une soit meilleure que l autre, car elles sont adaptées à des contextes différents. Cette caractéristique constitue la limite de chacune des méthodes vues précédemment, car aucune d elles ne donne une vue de l entreprise dans sa globalité, mais cible l organisation selon une vue partielle. Il est donc important de créer un cadre fédérateur à toutes ces méthodes ce qui permet d utiliser les points de vue de chacune des méthodes de manière à modéliser l entreprise selon les besoins mais en l appréhendant dans sa globalité. Pour obtenir un cadre de modélisation générique qui puisse répondre à la grande diversité des objectifs que l on peut rencontrer dans la modélisation d entreprise, l idéal serait de lier les méthodes de modélisation existantes à l intérieur d un cadre fédérateur. C est le rôle de GERAM. L architecture GERAM (Generic Entreprise Reference Architecture and Methodology) [BN94] est un ensemble de méthodes, de modèles et d outils nécessaires à la construction de l entreprise intégrée. Elle est en cours de développement en se fondant sur les concepts de trois principales architectures, CIMOSA, GRAI-GIM et PERA dans un but de généricité, c est-à-dire que GERAM devrait être applicable à n importe quel type d entreprise. Chaque entité de GERAM (y compris les entreprises) possède un cycle de vie. Les différentes phases du cycle de vie englobent toutes les activités intéressantes de la vie 16

41 1.3. Les méthodologies de modélisation d entreprise d une entité. Le cycle de vie est décomposé en sept phases (figure 1.8) : Identification du contenu : il s agit des activités identifiant le contenu d une entité particulière en considérant ses limites et ses relations avec son environnement interne et externe. Définition des concepts de l entité : il s agit de l ensemble des activités nécessaires pour développer les concepts de l entité traitée. Ces concepts incluent la mission de l entité, ses différentes vues, ses valeurs, ses stratégies, ses objectifs, ses concepts opérationnels, ses politiques... Définition des besoins : ce sont les activités nécessaires pour définir les besoins opérationnels de l entité d entreprise, ses process ainsi que tous ses besoins fonctionnels, comportementaux, informationnels. Cette description inclue à la fois le service et les éléments nécessaires de fabrication, ainsi que les éléments nécessaires de gestion et de contrôle de l entité. Conception : il s agit des activités définissant les spécifications de l entité ainsi que de ses composants. Ces activités incluent la conception de toutes les tâches humaines, de toutes les tâches machine, ainsi que les fonctions de contrôle et de gestion. Implémentation : il s agit des activités définissant toutes les tâches devant être accomplies pour construire ou reconstruire l entité. Fonctionnement de l entité : il s agit des activités nécessaires à l entité durant son fonctionnement lui permettant de produire des produits clients ou des services. Démantèlement et recyclage de l entité : il s agit des activités nécessaires pour réaffecter les composants de l entité en fin de vie à une autre mission, les recycler, les transférer... GERAM possède sept composants fonctionnels dont les interactions sont définies sur la figure 1.9 : EEMs : méthodologies d ingénierie d entreprise (figure 1.9). Elles décrivent le processus de l ingénierie d entreprise. Pour chaque type d activité du changement, elles décrivent des chemins de progression, identifient les tâches ainsi que les outils permettant ce changement. EMLs : langages de modélisation d entreprise (figure 1.9). Ils fournissent les éléments nécessaires pour modéliser les rôles humains, les processus et les technologies. GEMCs : cadres de modélisation de l entreprise générique. Ils définissent trois formes de concepts génériques : les glossaires (destinés aux utilisateurs) : toute la terminologie utilisée dans les modèles formels et non-formels doit y être définie. les Meta-Modèles (destinés aux développeurs d outils) : ils décrivent les concepts utilisés, leurs propriétés, et les relations entre eux. les théories ontologiques (destinées aux développeurs d outils) : ce sont des modèles formalisant les concepts utilisés pour la représentation de l entreprise. 17

42 Chapitre 1. La modélisation de l entreprise Identification Concept Besoins Phases du cycle de vie Conception préliminaire Conception détaillée Conception Implémentation Fonctionnement Démantèlement et recyclage Fig. 1.8 Cycle de vie GERAM pour une entreprise ou une entité PEMs : modèles partiels d entreprise. Ils fournissent des modèles de référence réutilisables pour les rôles humains, les processus et les technologies. Ce sont des modèles de grande qualité qui facilitent grandement la modélisation de l entreprise. EETs : outils d ingénierie d entreprise. Ils permettent l ingénierie de l entreprise, et plus particulièrement ils permettent la création, l utilisation et la gestion des modèles d entreprise. EMs : modèles d entreprise. Ils représentent l intégralité d une entreprise spécifique. Ils contiennent l intégralité des descriptions, des conceptions ainsi que les modèles formels de l entreprise qui sont nécessaires au cours du cycle de vie de l entreprise. EMOs : modules d entreprise. Ils sont implémentables sous forme de modules ou de produits (logiciels et matériels). Ils peuvent représenter les métiers, process opérationnels, technologies, etc... Les composants les plus importants de l entreprise ne peuvent être implémentés que s ils sont disponibles. Ceci inclue les ressources humaines disponibles sur le marché du travail, les équipements, les produits concernant le système informatique (logiciels...), et les services. GERAM constitue un cadre méthodologique de type Top/Down qui peut s appliquer au cycle de vie complet de l entreprise et de ses composants. GERAM permet de gérer simplement les processus standards, qui sont fournis au travers des PEMs. Ces processus standards peuvent s affiner grâce au BPR, qui reflète les exigences de la réalité de l entreprise. Pour être opérationnel assez rapidement, GERAM fournit par ailleurs une base de composants réutilisables au travers des EMOs. 18

43 1.3. Les méthodologies de modélisation d entreprise GERA : Architecture de référence d'entreprise généralisée identifie les concepts de l'intégration d'entreprise GEMCs : Concepts de modélisation générique de l'entreprise définit la signification des cadres de modélisation de l'entreprise EMOs : Modules d'entreprise fournit des modules implémentables des professions humaines et des technologies de process EEMs : Méthodologies d'ingénierie d'entreprise décrit le process d'ingénierie d'entreprise EMLs : Langages de modélisation de l'entreprise fournit des modèles pour la modélisation des rôles humains des process et des technologies emploie utilise réalisé dans supporte EETs : Outils d'ingénierie de l'entreprise aide à l'ingénierie d'entreprise PEMs : Modèles partiels de l'entreprise fournit des modèles références réutilisables des rôles humains, des process et des technologies EMs : Modèles d'entreprise représente le fonctionnement particulier de l'entreprise utilisé pour construire utilisé pour implémenter EOS : Systèmes opérationnels de l'entreprise aide au fonctionnement d'une entreprise particulière Fig. 1.9 GERAM : Architecture et méthodologie de référence pour l entreprise 19

44 Chapitre 1. La modélisation de l entreprise GRAI / GIM Systèmes indépendants Systèmes interfacés Systèmes intégrés GERAM 3. IEM / ARIS 4. Système universel CIMOSA Fig Les différents niveaux d intégration des systèmes Bilan sur les architectures d intégration : D une manière générale, on peut établir une taxonomie dans le niveau d intégration des systèmes (figure 1.10). Les systèmes peuvent être complètement indépendants les uns des autres, dans ce cas toute communication entre les systèmes est impossible. Ils peuvent être interfacés, intégrés ou se retrouver en symbiose totale, auquel cas on parlera de système universel (figure 1.10). Le but ultime des architectures d intégration est d obtenir une sorte de système universel, c est-à-dire un système où l indépendance des sous-systèmes qui le compose est complètement transparente pour les utilisateurs à tous les niveaux. C était le but que s était proposé CIMOSA, en intégrant les différentes vues de l organisation. Toutefois, une telle méthodologie est encore difficilement applicable compte tenu des problèmes de flexibilité que sa complexité peut poser. GERAM offre une une solution intermédiaire en donnant les grandes lignes d une architecture d intégration se proposant d intégrer les différents systèmes et de les interfacer. Toutefois, dans toutes ces architectures, il y a toujours un aspect concernant la gestion des flux de décision et d information. Si on adopte ce point de vue, il paraît intéressant d étudier comment ces éléments sont pris en compte dans la conception du système informatique supportant le fonctionnement de l entreprise. Après avoir décrit les méthodologies et les cadres de référence concernant la modélisation d entreprise, nous allons nous intéresser aux méthodes adaptées à la conception et à l évolution du SI de l entreprise. 20

45 1.4. Méthodes spécifiques adaptées à la conception et à l évolution des SI : Approches Méthodes Formalismes Fonctionnelle SA SADT / IDEF0 Diagrammes de flux de données Entité / Relation Merise Entité / Relation Objet RUP USDP Unified Modelling Language Fig Les méthodes classiques de modélisation d un SI 1.4 Méthodes spécifiques adaptées à la conception et à l évolution des SI : Des méthodes ont été très tôt nécessaires dans l élaboration des programmes informatiques, puis dans l élaboration des systèmes d information. Ces méthodes offrent des moyens de gérer la complexité de systèmes toujours croissante. On peut dénombrer trois grandes approches (figure 1.11) qui sont apparues progressivement : l approche fonctionnelle (la plus ancienne), l approche entité / relation, l approche objet IDEF0 / SADT : IDEF est l acronyme de ICAM (Integrated Computer Aided Manufacturing) Definition Method. IDEF est une méthode mixte qui prend en compte les contraintes liées aux données et aux flux de traitement, mais également les contraintes liées à la simulation et à l aspect dynamique du système étudié. En cela, IDEF est relativement proche des méthodes de modélisation en productique. IDEF couvre un ensemble de méthodes de modélisation complémentaires : IDEF 0 / SADT modélise les enchaînements de tâches sous la forme d actigrammes, IDEF 1 modélise les données sous la forme de modèles entité-association, IDEF 2 prend en compte la dynamique du système modélisé, IDEF 3 gère la notion de processus et d exécution concurrente, 21

46 Chapitre 1. La modélisation de l entreprise Contrôle C Entrée I Activité O Sortie M Mécanisme Fig L activité dans IDEF0 IDEF 4 introduit la modélisation orientée objet dans IDEF. Dans ce chapitre, nous ne décrirons parmi les composants d IDEF (notés IDEFx) que IDEF0 (ou SADT), illustrant l approche fonctionnelle de modélisation. La méthode SADT (Structured Analysis and Design Technique) a été développée dans les années 60 aux USA en même temps que les principes de la programmation structurée. SADT est une notation graphique pour décrire les systèmes structurés. Elle a été utilisée initialement pour modéliser les logiciels au cours des étapes d analyse et de conception. SADT distingue deux types de modèles : les actigrammes qui représentent les activités ou traitements du système modélisé, les datagrammes qui représentent les données du système modélisé. Le programme ICAM (Integrated Computer-Aided Manufacturing) du département de la défense américain a rendu public les actigrammes de la méthode SADT sous le nom d IDEF0. Les grandes lignes de SADT/IDEF0 sont développées dans [MM88]. Pour ce qui concerne les concepts de base, la méthode de modélisation IDEF0 est basée sur le principe de décomposition hiérarchique et structurée des fonctions de l entreprise, que l on nomme activité. Une activité, au sens IDEF0, peut être considérée comme une fonction de transformation d entrées (informations ou matières) en informations ou matières au moyens de mécanismes (hommes ou machines). L exécution de l activité proprement dite est déclenchée par une ou plusieurs données de contrôles (figure 1.12). Les relations d une activité avec les autres activités sont précisées au moyen de flèches. Les flèches qui entrent par le côté gauche du rectangle symbolisent les entrées de l activité, c est-à-dire les informations ou matières consommées par l activité et transformées en sorties. Les flèches qui sortent par le côté droit du rectangle symbolisent les sorties de l activité, c est-à-dire les informations ou matières produites par l activité suite à la consommation de ses entrées. Les flèches qui entrent par le bas du rectangle symbolisent les mécanismes utilisés par l activité, c est-à-dire les ressources (physiques ou humaines) 22

47 1.4. Méthodes spécifiques adaptées à la conception et à l évolution des SI : A A A Fig Hiérarchie de diagrammes IDEF0 nécessaires au déroulement de l activité. Enfin, les flèches qui entrent par le haut du rectangle symbolisent les contrôles de l activité, c est-à-dire les données qui influent sur le processus de transformation des entrées en sorties, et qui ne sont pas altérées par l activité elle-même. Une étude IDEF0 démarre avec la description la plus générale ou la plus abstraite du système à modéliser. Cette description est considérée comme une activité qui peut alors être décomposée en plusieurs sous-activités reliées entre elles par un diagramme. Ces sous-activités forment un niveau de décomposition. Des niveaux de décomposition supplémentaires peuvent être introduits en redécomposant les sous-activités obtenues précédemment. Ainsi, un modèle IDEF0 est composé d une hiérarchie de diagrammes. A chaque niveau de décomposition hiérarchique correspond un diagramme. Un diagramme est constitué d activités représentées sous forme de boîtes reliées entre elles (enchaînement des activités) (figure 1.13). La méthode IDEF0 est trop souvent restreinte à l utilisation de son formalisme graphique. En outre, IDEF0 est limité par la non prise en compte de la sémantique, c est-à-dire qu un modèle syntaxiquement correct peut être sémantiquement incorrect. IDEF0 permet de modéliser uniquement les aspects statiques d un système. La partie dynamique, c est-à-dire l évolution du système au cours du temps et l exécution concurrente de différentes activités, n est pas modélisée Merise Si on se place dans un contexte plutôt orienté processus de gestion, on peut se focaliser sur les aspects du système d information et de ses traitements sans intégrer de simulation. Née entre 1972 et 1975 lors des travaux des français Moulin, Tardieu, et Teboul 23

48 Chapitre 1. La modélisation de l entreprise [MRT + 76], la méthode Merise a été rendue célèbre dans le monde entier par l américain Peter CHEN [Che76]. A ce jour, de nombreuses entreprises utilisent ces modèles comme outil de communication pour les applications de Système de Gestion de Bases de Données Relationnelles (SGBDR). Merise est présente de manière transparente ou plus ou moins visible dans la plupart des logiciels de construction d applications de bases de données comme ACCESS, PARADOX, ORACLE, SQL Server, Informix, Ingres, Sybase... La première version de Merise, Merise 1, séparait les données des traitements. La notion de communication était limitée, ce qui pouvait suffire pour modéliser un système centralisé. Dans Merise, quatre niveaux d abstraction permettent de décomposer les préoccupations du concepteur. Le niveau conceptuel s appuie sur les invariants, répond à la question du Quoi et décrit la réalité du domaine dans sa rigueur et sa complexité. Le niveau organisationnel précise les aspects pratiques ( Qui fait Quoi ) et définit l organisation chargée de réaliser les fonctions décrites conceptuellement. Le niveau logique précise la vision informatique de la solution ( Comment ) et décrit les écrans, les enchaînements et les rapports. Le niveau physique décrit l outil informatique ( Avec Quoi ). Dans Merise, la description des données est primordiale. Le but recherché est la représentation de la mémoire du système et la définition d un serveur de données cohérent et fiable. Audelà de la description des données et des relations qui respectent les règles de dépendances fonctionnelles, c est la notion de contraintes qui évolue pour englober des traitements de plus en plus sophistiqués, notamment à cause de la généralisation des architectures clientserveur. Les contraintes sont des déclarations qui permettent de faire respecter l intégrité de l information conservée dans la base de données. Les contraintes classiques ont pour objet les clés, les cardinalités, les valeurs liées aux attributs. Le modèle Entité-Relation (étendu), les diagrammes de flux de données de Merise 2 et l orientation Objet de Merise 3 ont renforcé le champ d application de ces contraintes. Actuellement, Merise s articule autour de trois modèles : un modèle fonctionnel basé sur les diagrammes de flux, un modèle statique basé sur l Entité-Association enrichi de méthodes de traitements, un modèle dynamique des objets explicitant le contrôle et les interactions des objets. En conclusion, comme IDEF0, Merise est basé sur la systémique. Ces méthodes sont qualifiées de structurantes (descendantes ou Top-Down). Elles trouvent leurs limites économiques et techniques dans la modélisation d un monde en évolution rapide. Les méthodes sans méthode, qui adoptent une approche par les exigences (montantes ou Bottom- Up), conduisent généralement à la perte de cohérence systémique. RAD les associe pour le meilleur en essayant d éviter le pire. En outre, les méthodes vues précédemment différencient les traitements des données, ce qui pose des problèmes si l on souhaite réutiliser des composants du système d information existant pour le faire évoluer. Par rapport à ce problème de réutilisabilité, il est nécessaire d adopter des approches intégrant des concepts permettant la réutilisation aisée des composants développées. L approche objet a été particulièrement révolutionnaire en ce sens car elle a été la première méthode à intégrer ces aspects et à offrir des mécanismes permettant un réutilisation aisée des composants. 24

49 1.4. Méthodes spécifiques adaptées à la conception et à l évolution des SI : Approches objet Dans la conception des systèmes d information, les avantages évidents de l approche objet sont la stabilité de la modélisation par rapport au monde réel et à son évolution et la construction itérative facilitée par le couplage faible entre les composants et leur réutilisabilité d un développement à l autre. Cependant, pour Muller [Mul99], ces avantages ne sont que la conséquence de la grande capacité d intégration et d unification de l approche objet. Toute méthode de génie logiciel doit prendre en compte l organisation, la mise en relation et l articulation des structures pour en faire émerger un comportement macroscopique complexe qui n est autre que le système à réaliser. Il est donc nécessaire, lors de l étude du système, de considérer l agencement des parties, et d essayer d obtenir une vue globale des éléments qui le composent. Cette étude doit prendre en compte les différents niveaux d abstraction, depuis les détails jusqu à l agencement de l ensemble. La construction d un logiciel est par conséquent une suite d itérations à la fois de décomposition, et de réunion. Cette approche impose de décomposer pour comprendre, et de réunir pour construire. Classiquement, le processus de décomposition a été dirigé par le côté fonctionnel (typiquement IDEF0). Les fonctions du système sont identifiées, puis décomposées en sousfonctions, etc... jusqu à ce qu on obtienne des éléments simples pouvant être implémentés facilement. L approche fonctionnelle, dont les mécanismes intégrateurs sont la fonction et la hiérarchie, est satisfaisante lorsque les fonctions sont bien identifiées et lorsqu elles sont stables dans le temps. Cependant, dans l approche fonctionnelle, la fonction est très liée à la structure, et de ce fait les évolutions fonctionnelles peuvent impliquer des modifications structurellement lourdes. Pour éviter cela, l approche objet adopte un angle différent en considérant le système comme un tout organisé, dont les éléments sont solidaires et ne peuvent être définis que les uns par rapport aux autres. Elle ne propose pas de décomposer le système suivant ses fonctions, mais plutôt par rapport à ses fonctions et suivant ce que le système est. L approche objet a pour but une modélisation des propriétés statiques et dynamiques de l environnement dans lequel sont définis les besoins. Cet environnement constitue le domaine du problème. L approche objet a pour but de mettre en correspondance l espace du problème avec l espace de la solution (les composants réalisés du logiciel), en préservant la structure et le comportement du système analysé. Les fonctions sont alors représentées sous la forme de collaboration entre les objets composant le système. Le couplage entre les objets est alors dynamique, et les évolutions fonctionnelles ne remettent pas en cause la structure du logiciel. La force de l objet provient de sa double capacité à décomposer, et à recomposer. Cette force provient de la richesse des mécanismes d intégration du paradigme de la conception objet (héritage, polymorphisme...). USDP (Unified Software Development Process) de la société Rational Software Corporation est le résultat de plusieurs années de recherche dans les techniques d ingénierie logicielle. Les premiers concepts ont été établis entre 1987 et 1995 chez Ericsson. Entre 1996 et 1997, Rational a introduit UML (Unified Modelling Language) pour le formalisme. La méthode depuis 1998 est connue sous le nom de RUP (Rational Unified Process). Le but de l approche RUP / USDP est de proposer un processus pour développer des logiciels orientés objets importants, et de répondre aux questions clés : 25

50 Chapitre 1. La modélisation de l entreprise Qui fait quoi? Quand le faire? Comment atteindre un but qu on s est fixé? UML est un langage standard de modélisation logicielle. Il permet de visualiser, spécifier, construire et documenter un système logiciel. USDP conçoit l ingénierie logicielle à partir de cinq points de vues différents qui sont la capture des besoins, l analyse, la conception, l implémentation et le test. Des modèles et des diagrammes sont nécessaires pour expliquer et décrire le système à partir de ces cinq points de vues. USDP et UML fournissent un cadre de modélisation cohérent pour l ingénierie logicielle. UML fournit un ensemble de diagrammes utilisés pour développer les cinq points de vues d USDP. USDP est itératif et incrémental. Pour être efficace, un processus de développement logiciel a besoin d avoir une séquence de points clés ( milestones ) clairement définis qui fournissent aux membres du projet des critères qui doivent être remplis pour passer à la phase suivante. A l intérieur de chaque phase, on doit effectuer une série d itérations qui rapprochent le projet des critères à remplir. USDP propose quatre phases différentes, chacune avec un objectif précis : une phase de genèse qui a pour but de définir les limites du projet et de comprendre ce qu effectuera le futur système logiciel, une phase d élaboration qui a pour but de planifier le projet, de spécifier les aspects importants du système et de donner les lignes de bases de l architecture, une phase de construction qui a pour but de construire le système logiciel, une phase de transition qui a pour but de familiariser les utilisateurs au nouveau produit, et sa mise en route effective. USDP est orienté par les Cas d Utilisation. Un Cas d Utilisation spécifie une séquence d actions, incluant des variantes, que le système peut effectuer et qui donne un résultat observable du point de vue d un acteur du système. USDP est centré sur l architecture du logiciel à concevoir. Ce dont on a besoin, en plus des cas d utilisation, c est d une vision globale de l intégralité du système, nécessaire pour contrôler son développement. Le résultat de la phase d élaboration aboutit à une base de l architecture, qui est une sorte de squelette du système qu il reste alors à implémenter et à tester. L intérêt de RUP / USDP est de pouvoir créer assez rapidement une architecture du logiciel solide, avec tous les avantages de l objet (évolutivité, réutilisabilité, encapsulation...) Méthodes orientées composants et patrons métiers Par rapport au besoin d une meilleure productivité des équipes d ingénierie et d une meilleure qualité des produits, il est nécessaire de posséder des méthodes spécifiques couvrant tout le cycle de vie du produit. Ces méthodes doivent être adaptées au contexte, qui varie sans cesse d une situation à l autre, pour être efficaces et utilisables rapidement. Il est donc intéressant de construire des méthodes à partir d autres méthodes ou de composants provenant de méthodes existantes, pour obtenir des méthodes adaptées malgré la forte variabilité du contexte : c est l ingénierie des méthodes situationnelles ou SME (Situational Method Engineering) [RDR03]. Le but du SME est de développer des méthodes 26

51 1.4. Méthodes spécifiques adaptées à la conception et à l évolution des SI : adaptées au contexte à base de composants réutilisables. Ceci pose d énormes problèmes en ce qui concerne la sélection des composants à utiliser et la compatibilité entre ceux-ci pour obtenir une cohérence globale. Des concepts permettant de résoudre ces problèmes sont développés dans [Ral01] et un modèle d assemblage de composants provenant de méthodes existantes est décrit dans [RR01]. Le but de l approche par réutilisation de composants est d obtenir des méthodes adaptées au contexte qui sont rapidement exploitables. Plusieurs stratégies existent pour mettre en œuvre ces méthodes. Il y a tout d abord RAD (Rapid Application Development, qui sera vue plus tard dans ce chapitre), qui permet un développement rapide des applications du SI au risque qu elles soient incomplètes voire incohérentes, notamment si les développements des applications sont parcellaires. RAD présente toutefois des avantages indéniables si elle est correctement mise en œuvre, notamment en terme de rapidité et de réponse aux besoins. Une autre stratégie de mise en œuvre consiste à dire que les entreprises présentent un certain nombre de points communs, au niveau de leurs règles de gestion, de l organisation de leur production, de l organisation de leurs procédés... La capitalisation de ces connaissances communes peut déboucher sur la création de cadres génériques réutilisables permettant la création rapide de méthodes de conception et de modélisation adaptées au contexte. On retrouve ce concept de cadre générique au niveau de l instanciation des méthodes liées à la productique. Dans le cadre des SI, cette notion correspond au concept de pattern ([GRT03]). Ces patterns offrent des cadres génériques que l on va décliner et affiner en fonction du contexte. L utilisation des patterns pour le développement de méthodes spécifiques intervient plus dans le cadre de la conception des systèmes d information de production (SIP). Ce besoin est accru car les industries souhaitent fortement contrôler avec une grande rigueur le SIP pour améliorer sa réactivité aux différents changements impliqués par les process intervenant dans le cycle de vie du produit (développement, recyclage...). Ces patterns permettent de traiter toutes les facettes du SIP (organisationnelles et techniques). Les différents mécanismes empruntés à la modélisation objet (entre autre l héritage) permettent, à partir d une bibliothèque de patterns génériques, d établir des modèles précis permettant une ingénierie rapide des SIP. Un outil et un formalisme permettant de concevoir et d appliquer les patterns sont décrits dans [CFH + 02]. Les approches précédentes abordent le problème de la modélisation dans sa globalité. Toutefois, elles peuvent être lourdes à mettre en œuvre. Pour répondre de manière plus opérationnelle et plus rapide aux besoins des utilisateurs, et pour les impliquer fortement dans la conception et la mise en place des applications du SI, RAD est particulièrement adaptée, car elle permet de diminuer les risques d erreurs d appréciation des besoins et les problèmes d appréhension du changement, tout en permettant l obtention d un résultat rapide, donc facilement et rapidement validable pour le client RAD : Le RAD (Rapid Application Development) est une approche fonctionnelle et événementielle relativement légère permettant de concevoir et / ou de faire évoluer les processus du SI. C est une approche particulièrement adaptée à des projets qui ne sont pas trop importants. Les méthodes vues précédemment sont complètes, mais ne sont pas évidentes d approche et peuvent poser des problèmes de flexibilité, particulièrement dans un contexte 27

52 Chapitre 1. La modélisation de l entreprise très évolutif comme celui de l entreprise. Par ailleurs, toutes les méthodes vues jusqu à maintenant sont des démarches top / down, ce qui fait qu au cours du projet, on peut perdre de vue les besoins des utilisateurs. Pour parvenir à remplir ces différents buts, la méthode RAD possède les composants suivants : Un cycle de développement sécurisant et court fondé sur un phasage simple : Cadrage, Design, et Construction. Ces phases doivent s effectuer dans une fenêtre temporelle donnée (90 jours optimum et 120 jours maximum) ([Mar90]), afin de limiter les dérives. Une architecture de communication engageant des groupes de travail de structure et de composition variable selon les besoins des phases. Des méthodes, des techniques et des outils permettant de définir et d appliquer des choix potentiellement contradictoires portant sur le budget, les délais, la qualité technique, la qualité fonctionnelle et la visibilité. Une architecture de conception s appuyant sur les techniques de l objet et particulièrement sur celles qui permettent une conception en vue de modifications. Une architecture de réalisation qui impose, pour garantir la qualité technique, des normes minimales, des revues de projet, des jalons 0-défauts... L avantage de RAD par rapport aux méthodes plus classiques, et qu elle permet d envisager une approche bottom-up, tout en préservant une cohérence systémique, elle est légère à mettre en œuvre Conclusion Ce panorama sur les méthodologies n est pas bien sûr exhaustif. Certaines sont plutôt des dérivées d autres méthodologies. Le nombre de méthodes différentes montre qu il s agit d un besoin tout à fait réel. Les méthodes ont été vues en fonction de la genèse des approches, c est-à-dire que le modèle Entité / Relation (E-A) est apparu avec Merise, la décomposition fonctionnelle avec SADT, et l objet avec les méthodes précurseurs de USDP (OOD, OMT et OOSE). Cependant, des mises à jour ont été effectuées sur chacune des méthodes, qui sont maintenant relativement complètes et proposent le plus souvent l ensemble des paradigmes. Il en résulte que la modélisation d un système par ces méthodes va donner des modèles tout à fait similaires, seul le formalisme change. La plupart des méthodes de modélisation existantes, classiques ou objets, présentent certains aspects susceptibles d améliorations inhérentes : 28 Aux modèles supportés qui sont soit des modèles de données plats (E-A) soit des modèles de fonctionnels purs. Aux étapes du cycle de vie : les méthodologies présentées ne couvrent pas obligatoirement tout le cycle de développement, ce qui oblige leurs utilisateurs à recourir à plusieurs méthodologies durant le développement d un projet unique ce qui peut entraîner des trous et un manque de rigueur durant les passages d une méthodologie à une autre. Toutefois, les plus récentes qui résultent de l agrégation de méthodes déjà éprouvées, ont pour but de couvrir au mieux l ensemble du cycle.

53 1.5. L importance du workflow et du BPR dans la modélisation d entreprise Aux techniques utilisées : l absence de méthodologie conduisant à une déduction cohérente de solutions à la fois pour le matériel et pour le logiciel. La plupart des méthodologies supposent connue l architecture matérielle et de ce fait sont plutôt orientées purement génie logiciel. Aux domaines d application : certaines méthodes puissantes sont plutôt orientées gestion, d autres temps réel, etc... Rares sont celles qui recouvrent plusieurs domaines exigés par les systèmes de production. Au manque d outil logiciel permettant de faciliter et de guider le concepteur durant son cycle de développement à l aide d une méthode donnée. L approche objet constitue un apport considérable pour le génie logiciel, grâce à ses capacités de modularité et de réutilisabilité. Néanmoins, les utilisateurs des méthodes objets s accordent à en constater les erreurs de jeunesse. Le manque de cohérence des différents modèles utilisés, le manque d intégration du paradigme objet avec les autres paradigmes existants au sein d une même méthode et le manque de formalismes validables sont les principaux obstacles à leur totale adoption. La vue orientée purement informatique ou décisionnel peuvent suffire à modéliser un système informatique. Toutefois, cette vue peut être réductrice, particulièrement si on souhaite aller plus loin dans la modélisation, en modélisant les entreprises par exemple. Dans un tel cadre, il est nécessaire de faire appel aux méthodes et aux méthodologies adaptées vues dans la section L importance du workflow et du BPR dans la modélisation d entreprise D une manière générale, pour fonctionner, une organisation doit atteindre des objectifs. Chaque objectif est rempli par l accomplissement d un ensemble de tâches qui peuvent être regroupées sous forme de processus. On définit un workflow comme étant l entité regroupant et ordonnant ces tâches de telle manière qu elles soient exécutées séquentiellement et parallèlement pour atteindre les objectifs initiaux. Un workflow peut regrouper plusieurs processus et a pour rôle de gérer le partage des ressources, et donc les flux d information (contraintes de précédence...), pour que tout se déroule au mieux, ce qui n est pas trivial, car la juxtaposition de différents processus pose le problème complexe de partage des ressources. La description de chaque processus est réalisée sous forme d un ensemble de tâches, chacune d elles étant placée sous la responsabilité d un acteur. Des points de reprises semblables à ceux utilisés dans les systèmes transactionnels [ISO92] permettent de contrôler l avancement du processus d état stable en état stable [DDC97]. Or, toutes les architectures de modélisation d entreprise sont unifiées autour d un même concept fort, qui est le concept de flux d information, et donc de workflow Le workflow : La technologie workflow dérive en partie du domaine Office Information Systems (OIS) et du domaine Computer Supported Cooperative Work (CSCW). Le domaine du workflow a pour but d automatiser ou d aider à la réalisation des process de business 29

54 Chapitre 1. La modélisation de l entreprise (BP). La technologie de workflow peut être vue comme un type spécifique de groupware pour soutenir la collaboration qui est basée sur du travail plannifié et articulé en modèles de process de business [Ste97]. Caractéristiques du workflow : Une application workflow soutient essentiellement le séquencement des actions et des tâches, en allouant des sous-tâches à travers des rôles à des acteurs spécifiques. En outre, le logiciel de contrôle du workflow va monitorer les instances de process en cours d exécution. L application workflow va lier les tâches spécifiques (atomiques) aux outils informatiques requis pour supporter la tâche, et lier ces outils aux ressources d information de l organisation nécessaires pour l exécution de la tâche. Ainsi les applications workflow jouent un rôle crucial dans la logistique informative d une organisation : apporter la bonne information aux bonnes personnes au bon moment avec la bonne séquence. Selon Marshak [Mar94], les caractéristiques essentielles de workflow sont les tâches (ou activités) qui doivent être effectuées par des acteurs (qui jouent un rôle) et qui utilisent des outils qui donnent l accès à diverses sources d informations distribuées. Les modèles de process sont habituellement décomposés jusqu à atteindre les tâches atomiques qui seront exécutées par les acteurs identifiés avec des outils spécifiques et des ressources d information. Workflow ad-hoc vs workflow traditionnel : Il existe trois types de workflows [GHS95] : les workflows ad-hoc, les workflows administratifs, les workflows de production. On peut déterminer si un workflow appartient à l une ou l autre des catégories à l aide des critères suivant : répétitivité et prédictivité des workflows et des tâches, mode d initialisation et de contrôle du workflow, e.g., un contrôle par l être humain ou par une machine. Les workflows ad-hoc : les workflows ad-hoc réalisent des process bureautiques, tels que la documentation produit par exemple, où il n y a pas de schémas prédéfinis pour faire circuler l information entre les personnes. Les tâches de workflow ad-hoc impliquent la coordination humaine, la collaboration ou la co-décision. Ainsi, l ordonnancement et la coordination des tâches dans les workflows ad-hoc ne sont pas automatisés mais plutôt contrôlés par les humains. Par ailleurs, l ordonnancement de tâches et les décisions de coordination sont faites pendant que le workflow est exécuté. Les workflows ad-hoc impliquent typiquement de petites équipes de professionnels et sont destinés à supporter des activités à court terme qui nécessitent une solution workflow rapide. Les systèmes de management de workflow (WFMS) qui supportent les workflows ad-hoc doivent fournir les fonctionnalités pour faciliter la coordination humaine, la collaboration et la co-décision. 30

55 1.5. L importance du workflow et du BPR dans la modélisation d entreprise Les fonctionnalités pour contrôler l ordonnancement des tâches ne sont pas fournies dans de tels WFMS. Les utilisateurs d un workflow ad-hoc ont besoin d accéder au WFMS pour déterminer si le travail a été effectué. Par ailleurs, les workflows ad-hoc ne sont pas critiques, c est-à-dire que les échecs périodiques de tels worfklows n interfèrent pas de manière significative avec le process de business global. Les technologies utilisées par les WFMS ad-hoc vont du courrier électronique au calendrier partagé et aux systèmes de conférence. Les WFMS ad-hoc utilisent généralement une base de données propriétaire pour stocker l information partagée (documents...). Les WFMS qui supportent le workflow ad-hoc sont aussi appelés applications groupware. Les éléments importants relatifs à la sécurité des workflows ad-hoc concerne principalement l authentification des acteurs du workflow et la non-répudiation de messages, due à l utilisation importante des applications groupware (courrier électronique, partage de dossiers, de documents...). Les workflows administratifs : les workflows administratifs impliquent des process répétitifs que l on peut prédire avec de simples règles de coordination de tâche, comme par exemple le routage d une note de frais dans une organisation. L ordonnancement et la coordination des tâches dans les workflows administratifs peuvent être automatisés. Les WFMS qui supportent les workflows administratifs gèrent simplement le routage et les fonctions d acceptation ou de rejet des documents. Les workflows administratifs ne contiennent pas de process complexes (en particulier avec accès à des systèmes d information distribués). Les WFMS administratifs ne sont pas critiques. La technologie couramment employée est basée sur le courrier électronique. Comme pour les workflows ad-hoc, les éléments importants relatifs à la sécurité des workflows administratifs concerne principalement l authentification des acteurs du workflow et la non-répudiation de messages, due à l utilisation importante des applications de courrier électronique. Les workflows de production : les workflows de production impliquent des process de business répétitifs et prédictibles. Contrairement aux workflows administratifs, les workflows de production contiennent des process complexes impliquant l accès à des systèmes d information distribués. L ordonnancement et la coordination des tâches dans de tels workflows peuvent être automatisés. Cependant, l automatisation des workflows de production est compliquée à cause de : la complexité du process d information l accès à des systèmes d information distribués pour effectuer le travail et retrouver les données pour prendre des décisions. Les WFMS qui supportent les workflows de production doivent fournir des aides pour définir les dépendances entre les tâches, et contrôler l exécution des tâches avec peu ou pas d intervention humaine. Ces WFMS sont souvent critiques et doivent tenir compte de l intégration et de l interopérabilité des systèmes. Par ailleurs, les workflows de production posent de réels problèmes en ce qui concerne la synchronisation et le maintien d une certaine cohérence entre les processus lors de l exécution du workflow. Par la suite, on regroupera les workflows administratifs et de production sous l appellation workflows traditionnels, de manière à faire la distinction entre les workfows prédictibles et les workflows ad-hoc. Les workflows traditionnels correspondent à une structuration des process 31

56 Chapitre 1. La modélisation de l entreprise Type Workflow administratif Workflow de production Workflow ad-hoc Prédictabilité oui oui non Structuration préalable du process de business oui oui non Eléments importants authentification et non-répudiation des messages cohérence et synchronisation des processus authentification et non-répudiation des messages Fig Tableau récapitulatif des types de workflow et des caractéristiques associées de l entreprise qui est déjà formalisée, tandis que les workflows ad-hoc vont au contraire aider à formaliser la structure du process auquel appartiennent les tâches ad-hoc. Les caractéristiques des différents workflows sont récapitulées sur le tableau Les process de business et leur réingénierie Les process de business, souvent décrits par les modèles d entreprise, peuvent être utilisés pour décrire à la fois l activité et l organisation de l entreprise. Les modèles d entreprise représentent la structure de l entreprise et de ses processus à l instant t. Néanmoins, le contexte changeant dans lequel les entreprises se trouvent provoque l évolution des process de business de l entreprise. Il peut donc exister un décalage entre les process de business modélisés et les process de business réels. C est dans ce cadre qu intervient ce qu on appelle la ré-ingénierie de business-process (ou Business Process Reengineering : BPR). Le BPR permet de reconstruire les process de business à partir de l activité réelle de l entreprise. Pour Hammer et Champy ([HC94]), la réingénierie des process de business est la repensée complète et la re-conception radicale des process de business pour parvenir à des améliorations très significatives concernant le coût, la qualité, le service et la vitesse [de l activité de l entreprise]. Les process de business sont gérés en grande partie par les WFMS. Ils sont fondamentaux dans la construction d un système de workflow. La mise en place d un tel système peut être effectué de deux manières : 32 une mise en place basée sur la modélisation : cette approche consiste à définir les modèles de process de business et les flux d information associés, et ensuite dériver les processus d activité orienté données [Age82]. Ces processus sont décrits principalement par des transitions, des graphes orientés [HY02] et des réseaux de Petri. une mise en place basée sur la reconstruction peut également être utilisée.

57 1.5. L importance du workflow et du BPR dans la modélisation d entreprise Ce procédé est particulièrement adapté à la mise en place des workflows ad-hoc, où une connaissance des activités réelles est importante. Pour la mise en place d un workflow basé sur la reconstruction des process de business, il est nécessaire de prendre en compte tous les niveaux de la reconstruction. En effet, le BPR doit intervenir à la fois au niveau organisationnel et au niveau opérationnel. Le but sous-jacent du BPR est de remodéliser les processus de manière à être en mesure de les faire évoluer. Ces évolutions sont nécessaires au bon fonctionnement du SI, mais elles peuvent générer des incohérences qui apparaissent entre les anciens et les nouveaux processus. Il est donc important d avoir à disposition des méthodes permettant de conduire le changement de manière efficace. Selmin Nurcan et Colette Rolland ([NR03]) proposent une méthode de réingénierie et de conduite du changement, EKD-CMM. C est une méthode permettant de faire évoluer l organisation en reconstruisant des process pour établir un modèle réel de l organisation. On modifie ensuite ce modèle suivant les souhaits et les besoins exprimés, ce qui permet de faire évoluer le système existant vers un nouveau système plus apte à répondre aux besoins. Toutefois, cette approche nécessite de disposer de la description des processus. Or cette description des process dans le cadre du BPR est une tâche très complexe, notamment car les processus sont très difficiles à formaliser compte tenu de la diversité des contextes et de leurs descriptions rarement formelles. Il y a donc une nécessité d avoir des approches permettant de guider les choix dans la mise en place de l évolution du modèle [NGS98], et par là conduire le changement. Une autre approche intéressante du BPR se rapproche du data mining : si on part de l hypothèse que chaque process, quel que soit sont niveau d action (organisationnel ou opérationnel) laisse des traces dans le SI, il doit être possible, si on exploite ces traces judicieusement, de reconstruire au moins partiellement les BP (Business Process). Maruster suggère pour cela une méthode de process mining [MWWA02]. Dans cette méthode, les activités des process sont enregistrées dans des journaux de log, ce qui permet la détermination des spécifications des process, qui reflètent leur comportement réel. Cette spécification détaillée permet de concevoir un réseau de Petri modélisant les tâches des process de business et leurs interactions. Cette méthode de process mining est basée sur l analyse des journaux de log des équipements stratégiques du système informatique. Cette approche donne des résultats intéressants, mais elle a toutefois ses inconvénients. Il se peut en effet que les journaux de log contiennent des informations intéressantes mais imprécises, car on ne peut pas tout enregistrer dans les journaux de log. A contrario, les journaux de log contiennent souvent des informations qui ne sont pas importantes, et qu on peut qualifier de bruit. Les journaux de trace d activité ne constituent pas une ressource suffisante pour reconstruire les process de business, même s ils fournissent des informations précieuses. Pour pallier à ce problème, il est souhaitable d utiliser d autres sources de connaissances au sein du système informatique de l entreprise. Une approche intéressante pour la construction d un système de workflow à partir des process de business passe donc par l exploitation judicieuse des informations provenant de l infrastructure de fonctionnement de l organisation. Cependant, le workflow doit pouvoir également s adapter rapidement aux changements de l infrastructure, aussi il apparaît intéressant de coupler l utilisation des informations issus de l infrastructure avec une méthode de conception adaptée à des évolutions rapides. Dans cette optique, l utilisation d une méthode de 33

58 Chapitre 1. La modélisation de l entreprise conception et de réalisation telle que RAD avec la mise en place d un WFMS semble particulièrement adaptée, mais pour cela, une bonne exploitation de l administration des infrastructures est fondamentale. Ce sera l objet du prochain chapitre qui détaillera les différents aspects liés à l administration des systèmes informatiques. 1.6 Conclusion Ce chapitre a détaillé un certain nombre de méthodes adaptées pour concevoir les SI d une part (SADT, Merise, RAD, USDP), et modéliser l entreprise d autre part (GRAI, GIM, PERA, IEM, ARIS, CIMOSA et GERAM). Dans les deux cas, il n existe pas de méthode parfaite, chacune ayant ses avantages et ses inconvénients. Cependant, en ce qui concerne la modélisation d entreprise, il y a la volonté d établir un cadre fédérateur (GERAM) permettant de répondre aux besoins des organisations dans leurs globalité. La modélisation d entreprise est fondamentale pour être en mesure de concevoir correctement les workflows responsables du bon déroulement des process de business à effectuer dans l entreprise. Toutefois, la reconstruction des process de business à partir des activités réelles est une méthode tout à fait intéressante pour garder les modèles d entreprise à jour. Pour cela, les informations contenues dans les journaux de trace d activité du système informatique ainsi que les données fournies par une bonne administration des infrastructures peuvent apporter des réponses complémentaires. 34

59 2 Administration des systèmes distribués Comme nous l avons vu dans le cadre de référence de la modélisation d entreprise (figure 1.1), les métiers de l entreprise peuvent être implémentés sous forme de processus qui reposent eux-mêmes sur une architecture technique. Les architectures les plus adaptées à un contexte dynamique de type entreprise virtuelle ou étendue..., sont les architectures distribuées. Ces architectures sont aujourd hui réalisables sans problème grâce à la maturité des environnements client / serveur. Par ailleurs, la grande flexibilité offerte par les architectures distribuées font qu elles sont omniprésentes dans le monde informatique d aujourd hui. Ces architectures distribuées supportant les processus de l entreprise sont néanmoins très complexes, de part leur étendue, souvent importante, et de part leur hétérogénéité. Face à ces contraintes, il est nécessaire et vital de les administrer quotidiennement mais aussi de les faire évoluer sur le long terme. Il existe plusieurs types d administration des infrastructures. L administration des infrastructures tel qu on l entend traditionnellement constitue une administration de base qui a pour rôle de gérer correctement les équipements et de résoudre les problèmes de tous les jours. Mais il existe par ailleurs une nécessité de faire évoluer les infrastructures sur le long terme et de remédier à des problèmes importants comme les problèmes de sécurité liés à l infrastructure. Cette tâche incombe à une administration qu on peut qualifier de haut-niveau. Elle a pour rôle de gérer correctement l évolution des infrastructures, à l aide de méthodes adaptées. La combinaison de ces deux types d administration permet d obtenir une administration dite proactive permettant à la fois de gérer les problèmes quotidiens et les évolutions des infrastructures pour satisfaire les besoins des utilisateurs et leur fournir une qualité de service (QoS) adaptée (figure 2.1). Globalement, le but de l administration de base est de gérer correctement la masse d information provenant de l infrastructure. Le problème ici est de collecter et d exploiter correctement les indicateurs de fonctionnement provenant de l infrastructure. La tâche de l administration de haut niveau est d élaborer et d exploiter des méthodes facilitant la mise en place d infrastructures permettant de répondre aux besoins d un contexte dynamique. 35

60 Chapitre 2. Administration des systèmes distribués méthodes besoins Administration pro-active Administration de haut-niveau : gérer l'évolution des infrastructures Administration de base : gérer l'information indicateurs de fonctionnement évolution de l'infrastructure exploitation de l'infrastructure réponse aux besoins = QoS Fig. 2.1 Les différents types d administration des infrastructures 2.1 Administration de base Pour collecter et exploiter correctement l information provenant de l infrastructure de l organisation, il est nécessaire d une part d être en mesure de détecter les données pertinentes qu il faut exploiter, et d autre part de classer les données compte tenu de leur signification. Pour aider à la classification des données pour l administration des infrastructures, l OSI a défini cinq domaines différents à l intérieur de l administration réseau dans chacun desquels il est possible de trouver et de mesurer des indicateurs intéressants. Le modèle d administration réseau de l OSI partitionne les fonctions de l administration réseau en cinq domaines conceptuels [KH00] : La gestion de la configuration La gestion des pannes La gestion des performances La gestion de la comptabilité La gestion de la sécurité Nous nous sommes focalisés sur ces domaines pour avoir un premier balayage des paramètres qui peuvent être intéressants pour l administrateur, pour répondre à ses besoins quotidiens. 36

61 2.1.1 Configuration 2.1. Administration de base Pour un administrateur, il est important de connaître précisément le réseau qu il doit gérer. Pour cela, on utilise différentes techniques permettant de prendre connaissance du parc informatique. Techniques passives de monitoring : les techniques passives de monitoring consistent à capturer l information là où se trouve l outil de mesure (sonde, sniffer...). Ces techniques ne donnent pas de moyen d être guidé dans le processus de découverte de l infrastructure, car on doit se contenter de regarder ce qui se passe sur le réseau. Il se peut que cela prenne un certain temps avant d avoir les informations nécessaires pour établir une carte de l infrastructure. Un autre problème avec les méthodes passives est que l on doit avoir un équipement de monitoring sur tous les sous-réseaux [SL93]. Le principal avantage du monitoring passif est que cette méthode n induit pas de charge supplémentaire sur le réseau (mesure non-intrusive). Techniques actives de monitoring : les techniques actives de monitoring consistent à aller chercher les informations là où elles se trouvent. Elles ont aussi leurs avantages et leurs inconvénients. Par exemple, en utilisant des sondes rapatriant les données vers un serveur central, il y aura une charge supplémentaire sur le réseau. D un autre côté, les techniques actives peuvent être plus facilement prises en main, et il est possible de minimiser le temps nécessaire pour avoir une carte complète du réseau. D une manière générale, le monitoring actif constitue une approche plus agressive mais elle permet d avoir une cartographie du réseau beaucoup plus rapidement qu avec le monitoring passif. Pour faire du monitoring, il est nécessaire de choisir les types d équipements ou de protocoles que l on va mettre en place. On peut soit utiliser un protocole de management du réseau (SNMP par exemple) pour réunir les informations concernant le réseau, ou on peut essayer d utiliser les caractéristiques des protocoles existant et d en extraire les données pertinentes pour l usage que l on souhaite en faire. Utiliser un protocole de management peut paraître attractif à première vue mais cela demande que la plupart des machines sur le réseau soient capables de répondre aux requêtes du protocole (problème d hétérogénéité). La seconde alternative a plus de chances de fonctionner sur un ensemble plus vaste, mais l analyse de données est plus complexe Gestion des pannes La gestion des pannes est un aspect fondamental de l administration de réseau, c est entre autre un des domaines qui apparaît souvent dans les problématiques de la qualité de service. Détection de pannes : il est possible de détecter certaines pannes réseau en utilisant les informations statistiques contenues dans les MIB [TJ98]. Thottan et Ji montrent qu on peut choisir un sous-ensemble approprié de MIB (Management Information Base) de telle manière que celui-ci décrive le fonctionnement du nœud. Les séries temporelles de données obtenues à partir de ces variables ont été analysées en utilisant le test GLR (Generalized 37

62 Chapitre 2. Administration des systèmes distribués Likelihood Ratio : ratio général de probabilité). Le test GLR a été utilisé pour détecter les points de changement dans le comportement des variables. Pour la plupart des fautes étudiées, la détection apparaît 5 minutes avant la panne réelle, et l algorithme est suffisamment simple pour fonctionner on-line. La gestion des pannes est l un des aspects les plus important de la gestion des réseaux. Les situations de pannes peuvent survenir à cause de composants défectueux, de leurs pannes transitoires, de pannes logicielles, ou d erreurs opérationnelles. Ces problèmes font que la gestion des pannes devient critique si l on souhaite avoir un réseau fiable. Les outils de management réseau du commerce ne peuvent que détecter les pannes sévères ou les problèmes de performance comme un lien coupé ou la perte de capacité sur un lien. Les méthodes utilisées ne capturent pas les changements subtils qui indiquent les problèmes courants qui peuvent survenir sur un réseau. Des systèmes à base de règles ont aussi été développés. Le problème de ces méthodes est qu elles demandent la présence d une base de données stockant des scénarios de pannes qui évoluent avec le temps. La plupart des schémas basés sur l intelligence artificielle souffrent d être dépendant de la connaissance acquise lors des pannes précédentes et les règles développées ne s adaptent pas bien à un environnement réseau qui change en permanence. Tri des alarmes : un autre problème lié à la détection de pannes est le tri des alarmes. Une simple erreur dans un réseau de télécommunications peut donner un grand nombre d indications d erreurs (alarmes) ce qui rend l identification de la source réelle d erreurs difficile [KS95]. Le problème s aggrave dans le cas d erreurs multiples. A cause de l évolution des réseaux (croissance en taille et en complexité), le besoin d avoir des systèmes avancés de gestion des pannes devient critique. Auparavant, le diagnostic des pannes était effectué par des experts consultant un pupitre. Cette méthode humaine est difficile à mettre en œuvre et à péréniser, pour des questions de transfert de connaissance notamment. Les applications distribuées ont besoin de temps de réponse très court en ce qui concerne les pannes. D autre part, la quantité d informations et la complexité des données générées par une panne et les capacités limitées de l être humain en terme de puissance de calcul rendent improbable le fait que la gestion des erreurs soit efficace sans automatisation. Dans ce contexte, les systèmes experts peuvent être très intéressants. Par ailleurs, Mika Klemettinen a développé des méthodes de data-mining permettant de trouver des informations intéressantes parmi le flot des alarmes générées par un réseau de télécommunication en cas de panne [Kle99]. On peut diviser le processus de gestion des pannes en trois étapes : corrélation d alarmes identification de la panne test (pour savoir si l hypothèse qu on émet concernant la panne est valable) Les deux premières étapes appartiennent au processus de localisation ou de diagnostic. Elles débouchent sur l établissement d hypothèses qui sont ensuite testées Performance Comme le nombre d utilisateurs de l Internet et le volume de trafic continuent de croître, il devient essentiel qu un ensemble de métriques de performances et de méthodes 38

63 2.1. Administration de base de mesures soient disponibles. De nombreuses recherches ont été faites sur les mesures de performance réseau et d analyse, comme le montre les paragraphes suivants. Efforts de standardisation à l IETF : l Internet Protocol Performance Metrics Working Group (IPPM WG) a pour rôle de définir un ensemble de métriques standards qui peuvent être appliquées à la mesure de la qualité, de la performance, et de la fiabilité des échanges sur Internet. Ces métriques seront conçues pour fournir des mesures de performance non biaisées. Les métriques développées doivent avoir les propriétés suivantes [HDZ98] : Elles doivent être concrètes et bien définies Elles ne doivent pas présenter de biais pour les réseaux IP implémentés avec les mêmes technologies. Elles doivent avoir un biais pour les nuages IP implémentés avec des technologies différentes. Ce biais doit être constant et connu. Elles doivent être utiles aux utilisateurs et aux fournisseurs d accès pour que ceux-ci comprennent le comportement de leur réseau au quotidien. Elles doivent éviter d induire des objectifs de performances superflus. Pour un ensemble donné de métriques, un nombre de méthodes de mesures distinctes peuvent exister. Ces méthodes concernent les métriques de base : Mesures directes d une métrique de performance en injectant du trafic de test sur le réseau. Projection d une métrique à partir de mesures d autres métriques pertinentes. Estimation d une métrique de base à partir d un ensemble de mesures de plus haut niveau (au niveau de l agrégation) Estimation d une métrique donnée à un temps t à partir d un ensemble de métriques apparentées à un temps t+i (i peut être positif ou négatif). Une méthodologie pour une métrique doit présenter la propriété de répétition. Si la méthodologie est utilisée plusieurs fois dans des conditions identiques, elle doivent donner des résultats cohérents. Ce qu on cherche est la propriété de continuité. Plus spécifiquement, une méthodologie pour une métrique donnée possède la propriété de continuité si pour une petite variation des conditions dans lesquelles la métrique est évaluée, l évaluation finale de cette dernière subit aussi (et seulement) de petites variations. En résumé, le travail fait par l IETF est l établissement d un concept et d une méthodologie, éléments fondamentaux pour la mesure des performances du réseau. Il existe des organismes connexes à l IETF dont le but est de mettre en place des outils de mesure de performance dans les infrastructures distribuées, et notamment Internet. C est le cas de la Cooperative Association for Internet Data Analysis (CAIDA), qui est une association coopérative ayant pour but de promouvoir une plus grande coopération dans l ingénierie et la maintenance d une infrastructure Internet globale. CAIDA a pour but de fournir un cadre conceptuel neutre pour soutenir ces efforts coopératifs. Un des buts de CAIDA est de créer un ensemble de métriques de performances pour Internet, en travaillant avec 39

64 Chapitre 2. Administration des systèmes distribués l industrie et d autres acteurs du marché pour assurer l utilité de ces métriques et leur acceptation universelle. Tous les outils listés dans CAIDA measurement tool taxonomy peuvent être catégorisés en deux ensembles : Outils de mesures non-intrusives Outils de mesures intrusives Les mesures non-intrusives mesurent le comportement du réseau en observant l allure d arrivée des paquets à un système d extrémité, puis en déduisant la performance du réseau sur la base de ces observations. En général, cette pratique requiert une connaissance intime de l application générant les flux de données qui sont observés de telle manière que l outil de mesure puisse distinguer le comportement de l application distante de ce qui est induit par le réseau dans ce comportement. Sans cette connaissance, le monitoring sur un seul site d extrémité des données échangées ne donnerait pas des indications de grande valeur, car il serait possible de proposer des interprétations très différentes des données. En pratique, l examen du comportement de la couche supérieure (e.g. TCP) et du timing des paquets à l intérieur du flux est habituellement employé par les outils de mesure nonintrusive. Les mesures intrusives se réfèrent à une injection contrôlée de paquets sur le réseau aux paquets résultant de cette injection. Par exemple Ping, la requête d echo ICMP et l échange de réponse d echo appartiennent à cette méthode. En envoyant des séquences de Ping à des intervalles réguliers, une station de mesure peut mesurer des paramètres comme le temps de traversée vers une machine, le temps d aller-retour vers un site distant, et la perte de paquets sur l aller-retour. Le problème des mesures intrusives est qu elles ajoutent elles-mêmes du trafic dans le réseau et qu elles modifient l état du réseau. Les problèmes généraux liés à la performance Quelles données collecter? Il est très utile tout d abord de définir la notion de mesure de performance par rapport à un flux. Car c est le flux qui fait le lien entre la partie physique du réseau et la partie applicative. Le concept de flux de trafic peut être défini ici comme quelque chose d équivalent à un appel ou à une connexion, délimitée par un top de départ et un top d arrêt, et généré par une entité particulière. Ce flux est associé à des attributs (adresse source, adresse destination, nombre des paquets, nombre d octets...). Un flux a les propriétés suivantes : il se produit entre deux points qui sont complètement identifiés par un ensemble d attributs propres aux points d extrémité, chaque flux peut avoir aussi des attributs calculés (e.g. classe de flux). Un nouveau flux peut être créé quand un paquet est compté est qu il ne correspond pas aux attributs d un flux existant. Comment les collecter? Il est intéressant que les mesures imposent un impact minimal sur l état de congestion du réseau et doivent consommer un minimum de ressources du réseau (bande passante et mémoire). Pour cela, il peut être utile d étudier des outils de détection non intrusifs comme tcpdump, tcptrace, fs2flows, NetraMet... Il y a des cas où les paramètres concernant l état du réseau qui ne peuvent pas être obtenus à partir de mesures non-intrusives, ou bien les estimations pour de telles mesures n offrent pas suffisamment de précision pour cet usage. Ceci justifie l emploi de sondes comme mping, pathchar, treno, ttcp... 40

65 2.1. Administration de base Interprétation des données liées à la collecte Les indicateurs suivants ont été analysés par l IPPM (Internet Protocol Performance Metrics). Ils peuvent être retenu comme des mesures fondamentales de la performance. Bande passante, débit et goodput : la bande passante est mesurée en octets ou en bits par seconde. La bande passante met en place une limite fondamentale. Cette limite est la vitesse à laquelle il est possible de transférer les données d un système d extrémité vers un autre système d extrémité. La bande passante réelle utilisée par un flux particulier peut être inférieure à la bande passante nominale. Le débit mesure le nombre d octets transférés par seconde, dans un intervalle de temps récent, expérimenté par un flux particulier. A cause de la congestion réseau, certains des paquets dans le flux de trafic peuvent être éliminés par les routeurs ou switchs traversés le long du chemin, ce qui oblige à effectuer une retransmission de certains paquets. Le Goodput mesure la capacité du réseau à transférer des quantités significatives de données avec une simple connexion transport qui prend en compte la congestion (e.g. TCP). La métrique de goodput est définie comme étant la moyenne de transferts de données utiles entre une source et une destination (le goodput ne doit pas être confondu avec le payload, qui correspond au pourcentage de données utiles présent dans un paquet). Quand il n y pas de retransmission de trames, le débit et le goodput sont équivalents. Perte de paquet : comprendre la perte de paquets de type P sur un aller-simple d une source vers une destination est utile pour plusieurs raisons. Premièrement, certaines applications ne fonctionnent pas correctement (ou pas du tout) si la perte de bout-en-bout est grande par rapport à certains seuils. Ensuite, la perte excessive de paquets est difficile à supporter pour certaines applications temps réels. Enfin, plus grande est la valeur de la perte de paquets, plus il est difficile pour TCP de soutenir une bande passante élevée. Temps de traversée : de la même manière que pour le cas des métriques de perte de paquets, définir un délai d aller-simple pour un type P de paquets d une source vers une destination est utile pour plusieurs raisons. Tout d abord, plus le retard est grand, plus il est difficile pour la couche transport de soutenir une grande bande passante. De plus, la variation trop importante de temps de traversée rend difficile le fonctionnement d applications temps réels. Gîte : la gîte est connue aussi sous le nom de variation du temps de traversée des paquets. Cette métrique est souhaitable car la plupart des applications IP sont sensibles à l acheminement régulier des paquets vers leur destination. En effet, les applications sont souvent sensibles à la variation brutale du temps de traversée tandis que généralement elles ne le sont pas par des variations lentes. Ce type de métrique a l avantage de pouvoir être utilisé mêmes si les horloges des deux hôtes d extrémités ne sont pas synchronisées. 41

66 Chapitre 2. Administration des systèmes distribués Comptabilité Depuis quelques années, un intérêt croissant s est manifesté pour la comptabilité (ou accounting) basée sur l utilisation de l Internet. Ce qui a suscité cet engouement est principalement l apparition de la gestion de la QoS pour la transmission des paquets IP. On peut s intéresser à l accounting au niveau de l infrastructure réseau (ex. nombre de paquets transmis...) mais aussi au niveau applicatif, auquel cas on s intéressera plus à des paramètres de haut-niveau comme la complexité des requêtes SQL... On s intéressera dans cette partie à l accounting au niveau de l infrastructure réseau. Un des processus clé dans un système d accounting est le métrage. Le métrage consiste à réunir toutes les informations concernant l utilisation du réseau sur lesquelles l accounting est ou peut être basé. Un des problèmes majeurs de l accounting [PB00] est de déterminer l ensemble des paramètres sur lesquels on peut baser l accounting. Une première classification des paramètres, qui peut être utile est : l accounting sur le service ou le contenu : les paramètres sont issus du ou des services fournis et du contenu des paquets. l accounting sur le transport : les services sont offerts et les paquets sont acheminés grâce au réseau. L utilisation des ressources du réseau pour le transport des paquets est une autre catégorie de paramètres sur lesquels l accounting peut être basé. Le point de départ pour l accounting est la collecte de données brutes d accounting. Ce processus est appelé habituellement le métrage. Il y a différentes méthodes, techniques et produits pour le métrage. Techniques de métrage d accounting : plusieurs fabricants ont développé et réalisé des outils de métrage propriétaires qui sont incorporés en général dans les routeurs. Cisco a mis au point Netflow. Cabletron a développé le LightWeight Flow Admission Control Protocol (LFAP) qui fournit de l accounting de flux au niveau des couches 3 et 4. NetFlow et LFAP basent leurs flux sur l adresse IP de source et de destination. Une MIB publique de métrage a été développée : il s agit de NetraMet. Modèles d établissement des prix : structurés en deux parties [HC99] : les prix de l Internet comme la téléphonie sont prix d abonnement. prix par session. Il existe deux types de pricing : Le pricing statique : le prix est défini par le client et le provider par un contrat de type SLA (Service Level Agreement). Les SLA sont des contrats qui définissent les contraintes et les engagements liés aux services offerts par un fournisseur d accès à un client. Ces contrats sont établis en général par les deux parties. 42

67 2.2. Standards pour la sécurité des infrastructures Le pricing dynamique : le prix dépend de la demande des ressources réseaux et de la congestion du réseau. L ajustement du prix peut être effectué par feedback ou par enchères. Les utilisateurs donnent une information d enchère sur les paquets, en cas de congestion à un nœud, les paquets avec une enchère faible sont supprimés. Avec le feedback pricing, les prix sont calculés par le provider de manière dynamique en fonction de la charge sur le réseau. Par exemple, le prix peut être calculé en fonction du remplissage des buffers aux nœuds du réseau. Le prix est renvoyé au client. Le client décide alors s il va oui ou non envoyer les paquets Sécurité Une définition relativement large de la sécurité d un système informatique est donnée par Garfinkel et Spafford [GS03] : Un système informatique peut être considéré comme sûr par le fait qu il se comporte comme on s y attend. La dépendance entre un comportement attendu du système et son comportement réel définit la notion de confiance. Le comportement attendu est formalisé en une politique de sécurité du système informatique et gouverne les buts qu il doit atteindre. Une définition plus réductrice de la sécurité informatique est basée sur la réalisation de la confidentialité, de l intégrité, et de la disponibilité dans les systèmes informatiques (définition plus classique). La confidentialité exige que l information soit accessible seulement par ceux qui sont autorisés à la consulter. L intégrité exige que l information ne soit pas altérée par les accidents ou par des manipulations délibérées. La disponibilité signifie que le système informatique doit fonctionner sans dégradation de son accès et qu il doit fournir les bonnes ressources aux utilisateurs autorisés quand ceux-ci en ont besoin. Un système informatique sécurisé protège ses données et ses ressources des accès non-autorisés, des dégradations, et de déni d utilisation (un utilisateur autorisé se voit refusé l accès et l utilisation de ses ressources). Il y a une relation forte entre le bon fonctionnement d un système informatique et sa sécurité. La sécurité des systèmes d information est un domaine très complexe et fera l objet d une section complète. La sécurité regroupe un ensemble de techniques qui sont : les politiques de contrôle d accès au système les méthodes de chiffrement et de signature les méthodes de détection d intrusion Ces techniques peuvent être mises en œuvre au travers de méthodes permettant de structurer la démarche de conception d une architecture de sécurité (figure 2.2). 2.2 Standards pour la sécurité des infrastructures La définition d une politique de sécurité est souvent réduite à la mise en œuvre d une infrastructure sécurisée. Cette approche a d abord conduit à l émergence d un standard de sécurisation au niveau ordinateur (années 80) puis aux standards portant sur les systèmes d information en garantissant des niveaux de certification au niveau de l infrastructure (années 90). Ce point de vue réduit n apporte qu une réponse technique aux 43

68 Chapitre 2. Administration des systèmes distribués Contrôle d'accès Chiffrement et signature Détection d'intrusion Logiciels et protocoles de sécurité Méthodologies de haut niveau : EBIOS, SNA, Octave... Architecture de Sécurité des systèmes informatiques Fig. 2.2 Les concepts de la sécurité des systèmes d information menaces et aux vulnérabilités liées à la technologie. Toutefois, une part importante des vulnérabilités peut être imputée à l organisation elle même. Ainsi, la définition plus précise des risques et de leurs impacts a-t-elle été plus récemment prise en compte pour permettre l organisation d une réelle politique de sécurité (figure 2.3) La série arc-en-ciel du DoD Publié en 1985, l orange book [DoD85] propose un cadre global pour mettre en œuvre et certifier des politiques de sécurité pour des systèmes informatiques distribués. Ce standard appelé TCSEC (Trusted Computer System Evaluation Criteria) vise la certification sécurité de briques composant le système informatique global (Trusted Computer Base ou TCB). L organisation de ce standard défini concurremment au projet CALS 1 (Computer Aided Acquisition and Logistics Support) peut le rendre bien adapté dans le cadre d une chaîne logistique en construisant de manière incrémentale un système commun sécurisé comme un ensemble de composants certifiés (qu il s agisse d éléments relatifs aux systèmes d information ou aux réseaux). Le processus de certification est basé sur la spécification d une politique de sécurité pour le système informatique. Cette politique est définie grâce à des objets étiquetés (les informations), la description des droits d accès accordés aux utilisateurs et les droits d accès aux informations (spécifiés grâce aux étiquettes associées aux objets). Les fichiers de log sont utilisés pour enregistrer précisément les actions sur le système (garantie de non répudiation) ce qui permet de mettre en œuvre des processus de restauration (undo processes). De plus, des processus d audit sécurité (incluant la spécification de tests) sont utilisés pour certifier en continu le niveau de sécurité atteint (figure 2.4). Ce standard de sécurité générique quant à l objet certifié a été ensuite précisé pour les architectures de communication [DoD87] ou les systèmes d informations [DoD91]. Pour 44

69 2.2. Standards pour la sécurité des infrastructures Canadian criteria Federal criteria TCSEC ITSEC BS779 Draft BS779 Common criteria V1 V2 ISO /2000 Fig. 2.3 Chronologie des standards ce qui concerne l instanciation de ce standard pour le domaine des réseaux, quelques services de sécurité de plus haut niveau ont été ajoutés : intégrité des communications (ce qui inclut les systèmes de cryptage), les services d authentification (systèmes basés sur les PKI), les services de non répudiation utilisant les services d authentification et les fichiers de log) ainsi que la prévention des dénis de services (systèmes de gestion, analyse de données basée sur le respect des protocoles, systèmes de restauration...) Le standard ITSEC de l Union Européenne Proposé en 1991, le standard Information Technology Security Evaluation Criteria [EEC91] de l Union Européenne a été développé pour réaliser une synthèse entre les travaux de certification sécurité des différents états partenaires [Col97]. De même que dans l Orange Book du DoD, sept classes de sécurité sont proposées pour caractériser le niveau de sécurité du système (incluant une classe de non certification E0). A la différence du TCSEC, l ITSEC met l accent sur les informations et les technologies mises en œuvre pour supporter un système informatique au lieu de se focaliser sur la certification de systèmes informatiques de confiance. Les besoins en terme de cible de sécurité (i.e. le niveau de certification visé) sont décrits selon 8 groupes de critères : identification et authentification, contrôle d accès, imputabilité, réutilisation d objets, fidélité, continuité de service, échange de données (incluant l authentification, le contrôle d accès, la confidentialité des données, l intégrité des données et la non répudiation). Ces critères sont également regroupés en neuf familles selon le cycle de vie du projet permettant d aboutir à un système informatique 45

70 Chapitre 2. Administration des systèmes distribués C1 C2 B1 B2 B3 A1 Contrôle d'accès discrétionnaire Réutilisation des objets Etiquettes Intégrité de l'étiquetage Exportation d'informations étiquetées Contrôle d'accès obligatoire Exportation vers des équipements multiniveaux Sortie lisible des étiquettes Etiquetage des sujets Etiquetage des appareils Identification et authentification Audit Chemin de confiance Architecture système Intégrité du système Test de la sécurité Spécification et vérification de la conception Analyse des canaux cachés Gestion de confiance de facilités Gestion de la configuration Recouvrement de confiance Distribution de confiance Guides des usagers des mesures de sécurité Manuel des facilités de confiance Documentation des tests Documentation de la conception O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O N N N N N N N N N N N N N N N N N N N N Y Y Y Y Y N N N N N N N N N N N N N N N N N N N N Y Y N Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Fig. 2.4 Services de sécurité impliqués selon les différents niveaux de certification (N=Non, Y=Oui, O=Optionel) 46

71 2.2. Standards pour la sécurité des infrastructures sécurisé : étude des besoins, conception de l architecture, conception détaillée, mise en œuvre, configuration et contrôle, langages de programmation et compilateurs, sécurité pour les développeurs, documentation opérationnelle, environnement opérationnel. Une analyse de vulnérabilité est ensuite mise en œuvre pour définir le niveau de sécurité atteint par le système. On notera que selon la précision et le niveau de formalisation atteint pour chaque critère, une classe de sécurité est attribuée au système (figure 2.5). De fait, ces critères conduisent à l évaluation de niveau de certification assez similaires à ceux introduits dans l Orange Book (figure 2.6). Toutefois, si l ITSEC vise une analyse globale du système support du système informatique, ce standard ne prend pas réellement en compte les aspects organisationnels. De la sorte, l accent est placé sur les aspects conception, développement et contraintes de mise en œuvre et non sur l adaptation de l organisation pour répondre aux contraintes de la politique de sécurité. De même, ce standard oublie les composants sécurité d un réseau ou d un système informatique réduit à sa dimension technique. Néanmoins, les carences liées à l aspect organisationnel sont souvent compensées dans les méthodes guidant la définition de politiques de sécurité basées sur un objectif de certification ITSEC, telle la méthode EBIOS qui sera présentée section Les Common Criteria Pour répondre aux besoins de sécurisation dans un contexte d entreprise étendue, il peut être souhaitable d utiliser des critères communs d évaluation pour certifier le niveau de sécurité atteint par les systèmes des différents partenaires. En dépit des similarités des classements réalisés en fonction des standards américain et européen TCSEC ou ITSEC (cf figure 2.6), quelques différences subsistent. Aussi, pour répondre aux contraintes d internationalisation un système d évaluation international, les Common Criteria (CC) [co98] est mis en place de manière complémentaire au standard ISO Le cadre de standardisation fixé dans les Common Criteria consiste à la fois en une définition des critères d évaluation ET en une méthode d évaluation (à la différence des standards ITSEC et TCSEC qui ne comportaient pas de facette méthode). De manière à apporter un bon niveau de réactivité et d ouverture, nécessaires dans le collaborative business, les certificats accordés peuvent être enregistrés dans une base commune (figure 2.7). La contribution principale de ce standard réside dans la définition d un modèle définissant les concepts et leurs relations impliqués dans la problématique sécurité, modèle intégrant à la fois les menaces et les responsabilités liées au système ou composant informationnel à protéger (figure 2.8). Par ce biais, les contraintes organisationnelles peuvent être prises en compte dans la définition des besoins en terme de sécurité, spécification qui peut aussi être guidée grâce à des structures cadres appelées profils. Le standard des Common Criteria repose sur deux concepts principaux ([co00] p. 6) : Profil de Protection (PP) : ensemble de besoins et d objectifs en terme de sécurité indépendant de l implémentation pour une catégorie de produits ou systèmes qui peuvent répondre à un ensemble de besoins similaires de différents consommateurs en terme de sécurité relative aux technologies de l information. Pour garantir la compatibilité ascendante avec les classes B1 et C2 du TCSEC, des profils de 47

72 Chapitre 2. Administration des systèmes distribués E1 E2 E3 E4 E5 E6 Cible de sécurité (menaces, objectifs, fonction, niveau d'évaluation) Modèles formels de sécurité Fonctions (informel) O O O O O O O O O O O O O O O Fonctions (semi-formel) O O Fonctions (formel) O Conception de l'architecture (informel) O O O Conception de l'architecture (semi-formel) O O Conception de l'architecture (formel) O Conception détaillée (informel) O Conception détaillée (semi-formel) Implémentation (hardware et code source) Implémentation (Code Objet) Opération (Documentation User/administrateur, recette et mise en oeuvre, démarrage et mise en oeuvre) Niveau de rigueur O O O O O O O O O O O O O Défini Décrit Expliqué Fig. 2.5 Analyse de vulnérabilité selon les différents niveaux de certification d après [EEC91] (O = Oui) 48

73 2.2. Standards pour la sécurité des infrastructures Classe TCSEC D C1 C2 B1 B2 B3 A1 Classe ITSEC E0 E1 E2 E3 E4 E5 E6 Fig. 2.6 Comparaison des niveaux de certification ITSEC et TCSEC d après [EEC91] Critères d'évaluation (les CC) Méthodologie d'évaluation Procédé d'évaluation Evaluer Résultats finaux d'évaluation Approbation / Certification Liste des certificats / Enregistrement Fig. 2.7 Contexte d évaluation défini dans les Common Criteria d après [co98], p

74 Chapitre 2. Administration des systèmes distribués Propriétaires souhaite minimiser impose peut être conscient de Agent menace veut abuser et / ou endommager apporte Contre-mesures peuvent être réduites par exploite Menaces peut posséder Vulnérabilités accroît sur pour réduire conduisant à Risque sur Biens Valeur Fig. 2.8 Modèle des concepts de sécurité d après [co98], p. 14 protection sont développés pour les pare-feux, les systèmes de gestion de bases de données relationnelles... Cible de sécurité (security target : ST) : décrit les objectifs de sécurité et les besoins associés à une cible d évaluation (Target Of Evaluation : TOE), i.e. le produit ou système devant être évalué et certifié. La TOE comporte également la définition des mesures fonctionnelles et assurances offertes dans la TOE pour faire face aux besoins exprimés. L évaluation est menée pour contrôler la conformité de la TOE vis-à-vis d un ou plusieurs PP. La protection du système informatique est réalisée grâce à différents composants sécurité mettant en œuvre des fonctions particulières (par exemple un composant RSA implémente une fonction de cryptage). Ces composants sont regroupés en familles (i.e. des groupes de composants ayant des objectifs de sécurité communs) elles mêmes regroupées en classes (des groupes de familles partageant un même but). Onze classes sont définies et permettent de classer les fonctionnalités de sécurité : 50 Audit (FAU) : reconnaissance, enregistrement, stockage et analyse des informations relatives aux activités de sécurité Support pour la cryptographie (FCS) : cryptographie et gestion des clefs Communication (FCO) : contrôles d identité de non répudiation Protection des données des utilisateurs (FDP) : contrôle de l import et de l export de données personnelles en fonction des règles sur la protection des données personnelles et de la vie privée

75 2.2. Standards pour la sécurité des infrastructures Identification et Authentification (FIA) : vérification de l identité des utilisateurs, gestion des attributs de sécurité des usagers, processus d autorisations Gestion de la sécurité (FMT) : administration des attributs de sécurité, données et fonctions utilisées pour assurer les fonctions d administration des autres classes fonctionnelles Gestion du respect de la vie privée (privacy) (FPR) : utilisé pour protéger les utilisateurs contre la découverte et les utilisations frauduleuses de leur identité par d autres utilisateurs. Protection des fonctions de sécurité des cibles d évaluation (TOE) (FPT) : contrôle d intégrité et administration des mécanismes et des données des fonctions de sécurité de la TOE. Utilisation de ressources (FRU) : supporte la disponibilité des ressources (capacité de stockage, capacité de traitement, mécanismes de tolérance aux fautes...) Accès à la TOE (FTA) : complémentaire à la classe relative à l identification, cette classe vise le contrôle des sessions des utilisateurs (nombre de sessions, historique des accès, modification des paramètres d accès...) Chemins (ou canaux) de confiance (FTP) : construction de canaux de communication et de chemins entre les utilisateurs et la TSF (Fonction de sécurité de la TOE) La certification des systèmes est réalisée selon sept niveaux pouvant être comparés facilement aux classes introduites dans le standard américain TCSEC et le standard européen ITSEC comme le montre la figure Le standard ISO Ce standard a été développé plus récemment (2000) [ISO00]. Il est basé sur le standard britannique BS 7799 et sur l organisation de l architecture de sécurité réseau de l OSI. Ce standard diffère des précédents dans la mesure où il est réellement centré autour du système informatique cœur d un système de décision et non autour d un système informatique. Pour ce faire, ce standard propose une méthode pour définir, mettre en œuvre et gérer une politique de sécurité cohérente. Ce standard prend également en compte les besoins en terme de communication et de sécurité physique (contrôle de sécurité des bâtiments, contrôles physiques d accès...). Enfin, ce standard englobe à la fois les aspects techniques et organisationnels d une politique de sécurité ainsi que la spécification des besoins en terme d évaluation. Pour ce qui concerne l aspect organisationnel, trois besoins principaux sont définis : Chaque membre de l entreprise DOIT être informé de la politique de sécurité en vigueur. La mise en place d un forum peut permettre de répondre à ce besoin de diffusion d une information à jour. Un responsable sécurité (Information System Security Officer ou ISSO) maîtrisant les Business Processes de l entreprise [Kov97] doit être nommé et les responsabilités individuelles en terme de sécurité doivent être clairement définies. 51

76 Chapitre 2. Administration des systèmes distribués Classes des CC Classes TCSEC Classes ITSEC D : Protection minimale E0 EAL1 : testé fonctionnellement C2 : Protection et contrôle d'accès EAL2 : testé structurellement EAL3 : méthodiquement testé et vérifié EAL4 : méthodiquement conçu, testé et audité EAL5 : conçu et testé semiformellement EAL6 : conception vérifiée semiformellement EAL7 : conception vérifiée formellement et testée C1 : Protection discrétionnaire C2 : Protection et contrôle d'accès B1 : Protection de sécurité avec des étiquettes B2 : Protection structurée B3 : Domaines de sécurité A1 : Conception vérifiée E1 E2 E3 E4 E5 E6 Fig. 2.9 Niveaux de certifications des Common Criteria d après [co98] Les processus de contrôle d accès DOIVENT être définis précisément ainsi que les processus d autorisation. Pour ce qui est du niveau technique, l organisation de l infrastructure, sa configuration et son système de gestion doivent : Offrir des accès dédiés pour les experts extérieurs (i.e. les experts n appartenant pas directement à l entreprise). Supporter les coopérations avec des entités extérieures (autres entreprises, partenaires institutionnels...). Offrir un système de contrôle d accès dévolu au contrôle d accès de tiers en fonction des contraintes des Business Processes de l entreprise Accorder une attention particulière au traitement des contraintes de sécurité dans le cas de contrats d externalisation. Pour assurer la maintenance de la politique de sécurité, des revues indépendantes doivent être menées régulièrement pour contrôler et évaluer la mise en œuvre de la politique de sécurité et sa pertinence. En effet, la politique de sécurité doit garantir les services de base, à savoir la confidentialité, l intégrité et la disponibilité des informations. Le responsable sécurité (l ISSO) doit mettre en œuvre un contrôle continu pour pallier aux brèches de sécurité. En cas de défaut, l incident doit être identifié, contenu et éradiqué avant de mettre en œuvre un processus de restauration. Bien entendu, la capitalisation de l incident et de son traitement doivent permettre de faire évoluer la politique de sécurité pour éviter de nouvelles brèches. 52

77 2.2. Standards pour la sécurité des infrastructures Les principaux composants d une infrastructure de sécurisation peuvent être répartis en différentes familles : Composants orientés données (classification des informations, étiquetage, besoins en terme de cryptage, processus de contrôle d accès et de recouvrement) Composants liés à la communication (VPN, acheminement sûr des informations) Composants réseau (firewall, contrôle de logging sur les applications...) Contrôles physiques (protection des serveurs physiques, contrôle d accès...) Gestion des alarmes (processus de gestion, reporting...). Pour garantir la sécurité du système, des contrôles répartis selon les zones de contrôle sécurité sont mis en place. Ils visent l évaluation de la politique de sécurité et de la sécurité organisationnelle, du contrôle et de la classification des biens (tangibles et intangibles), de la sécurité du personnel, de la sécurité physique et environnementale, de la gestion des communications, des contrôles d accès, de la bonne conception et de la mise en œuvre du système et de sa maintenance, de la gestion de la continuité de service et de la conformité vis-à-vis des business processes. Pour définir une politique de sécurité adaptée aux besoins, une méthode en 8 étapes est intégrée au standard (figure 2.10) : Comme la sécurité du système informatique doit impliquer totalement l entreprise, il est indispensable d obtenir le soutien de la direction de l entreprise. Comme la sécurité du système informatique doit être totalement sous le contrôle de l entreprise, il faut que le périmètre concerné par la politique de sécurité soit complètement inclus dans le périmètre soumis à l autorité de l entreprise. Même si la politique de sécurité doit être déclinée en différents documents adaptés à l audience visée, un document de référence UNIQUE, indépendant de la mise en œuvre, doit définir les concepts clefs ainsi que les buts poursuivis. Néanmoins, pour cette étape, le standard n offre pas de méthode pour analyser et réorganiser les business process. Pour contrôler continuellement la mise en œuvre de la politique de sécurité, un système d administration de la sécurité des informations doit être mis en place. Ce système doit permettre de définir le périmètre de sécurité et d offrir des feuilles de route détaillant les stratégies de sécurité mises en œuvre pour les zones de contrôles définies dans le standard. Pour définir des protections adaptées, une évaluation des risques prenant en compte les menaces, les vulnérabilités, les probabilités d occurrence des menaces et le degré de gravité associé aux dommages potentiels est proposée (figure 2.13) Selon les différents niveaux de risque identifiés, des contrôles doivent être définis et mis en œuvre. L atténuation des risques mise en œuvre par différents contrôles est décrite dans la déclaration d applicabilité qui constitue une partie du document de référence de l IMS (Information Security Management System). Des audits réalisés soit par des membres de l entreprise, des partenaires ou des auditeurs indépendant sont utilisés pour évaluer continuellement la pertinence et l efficacité de la politique de sécurité. 53

78 Chapitre 2. Administration des systèmes distribués Obtenir le soutien de la direction Définir un périmètre de sécurité Créer une politique de sécurité des informations Créer un système d'administration de la sécurité des informations Réaliser une évaluation des risques Sélectionner et mettre en oeuvre des contrôles Document formulant les responsabilités Audit Fig Méthode proposée dans le standard ISO Probabilité de l'événement Fréquence Note Négligeable Très bas Bas Médium Elevé Très élevé Extrême Ne devrait pas apparaître 2-3 fois sur une période de 5 ans <= 1 fois par an <= une fois par semestre <= une fois par mois => une fois par mois => une fois par jour Fig Notation de la probabilité de l événement (P) 54

79 2.2. Standards pour la sécurité des infrastructures Dommage de l'événement Insignifiant Mineur Significatif Degré de gravité Impact minime voire aucune incidence Ne nécessite pas d'efforts supplémentaires pour réparer Dégâts tangibles. Impose un effort supplémentaire pour réparer Note Dommageable Sérieux Grave Coût significatif lié aux ressources - Dommage sur la réputation et la confiance Dommage étendu et / ou perte de connectivité - Compromission d'une grande quantité d'informations et de services Arrêt permanent - Système totalement compromis Fig Echelle de dommages (H) Risque R (R = P * H) Evaluation Aucun Bas Medium Elevé Critique Extrême Fig Evaluation des risques d après [Car01], p

80 Chapitre 2. Administration des systèmes distribués 2.3 Méthodes de haut-niveau pour la sécurité des infrastructures Le système informatique constitue en quelque sorte le système nerveux de l organisation. Par ailleurs, dans un contexte économique de plus en plus tendu et ouvert à la compétition, l interconnexion du système informatique avec d autres systèmes extérieurs devient fondamentale, pour effectuer des alliances, pour avoir accès à la bonne information... Cette interconnexion des systèmes ouvre le système informatique de l organisation vers l extérieur, et dans ce cadre, un certain nombre de failles sécurité potentielles apparaissent et il est nécessaire de protéger le système contre les attaques le visant. Il devient donc vital de construire une infrastructure informatique solide, notamment du point de vue de la sécurité. Pour cela, un certain nombre de méthodes existe. Ces méthodes s articulent toujours autour des trois points suivants : la spécification des besoins de sécurité la conception de l architecture de sécurité du SI la réalisation de l architecture de sécurité La suite du chapitre détaille ces méthodes et la manière dont elles peuvent être utilisées pour obtenir une complémentarité intéressante Expressions des besoins et des objectifs de sécurité : méthode EBIOS La méthode EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) 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. Cette démarche est liée à la mise en œuvre d ITSEC. Elle s applique lors de la conception de systèmes mais aussi sur les systèmes existants, sur un périmètre défini du SI et elle comporte cinq étapes (figure 2.14). C est pourquoi la définition d un cahier des charges global peut être effectuée à l aide de la méthode EBIOS. Des analyses plus précises des risques et des moyens de recouvrement peuvent être menées de manière complémentaire avec des méthodes comme Octave ou SNA. La méthode EBIOS commence par une étude du contexte qui comporte les points suivants : 56 présentation de l organisation : pour connaître les contraintes générales et définir une architecture de sécurité adaptée au système informatique, il est nécessaire de définir les informations générales sur l organisation concernée par le projet de sécurité et d obtenir une vision globale du système informatique de l organisation. Ces éléments permettront dans les activités suivantes de préciser les enjeux du système cible pour cette organisation et de veiller à la cohérence des objectifs et des exigences de sécurité concernant ses missions. étude du système cible : il est nécessaire de préciser le sous-ensemble du système informatique de l organisation constituant le système cible de l étude et ses enjeux. Pour cela, il faut effectuer une description fonctionnelle du système cible en terme de :

81 2.3. Méthodes de haut-niveau pour la sécurité des infrastructures Etude du contexte Expression des besoins de sécurité Etude des menaces Identification des objectifs de sécurité Détermination des exigences de sécurité Fig Démarche EBIOS globale [DCS04] flux d information : identifier les types d information liés au problème posé. nœuds d information : le système cible peut faire appel à différentes ressources communes aux différents domaines du système informatique. applications informatiques détermination de la cible qui fera l objet d une étude de sécurité : 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 qui feront l objet d une étude de sécurité. Une fois déterminé le contexte, la méthode EBIOS propose ensuite de passer à l expression des besoins de sécurité. Dans cette phase, les étapes suivantes sont nécessaires : réalisation des fiches de besoins : les besoins de sécurité associés à des informations et des fonctions sont exprimés selon les critères ITSEC (Information Technology Security Evaluation Criteria : critères de sécurité européens) : Disponibilité (D) : prévention d un déni d accès à l information ou à des ressources. Intégrité (I) : prévention d une modification non autorisée de l information. Confidentialité (C) : prévention d une divulgation non autorisée de l information. Pour cela, on crée des tableaux nécessaires à l expression des besoins de sécurité qui permettront aux utilisateurs d exprimer les besoins de sécurité des éléments qu ils 57

82 Chapitre 2. Administration des systèmes distribués manipulent habituellement dans le cadre de leur activité, d une manière objective et cohérente. Synthèse des besoins de sécurité : cette activité a pour but d affecter, pour chaque information et / ou sous-fonction, une valeur finale de criticité qui résulte de la synthèse des valeurs attribuées par les utilisateurs. A l issue de cette activité, il sera possible de disposer d une vision objective et cohérente des besoins de sécurité du système cible. Parallèlement à l étude des besoins, EBIOS prévoit une phase d étude des risques. Pour cela, les étapes suivantes sont définies : Etude 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 : les éléments menaçants sont caractérisés par leur type (naturel, humain, environnemental) l étude de l impact de la menace (accidentelle ou délibérée) : chaque menace est affectée d une valeur définissant sa gravité. Cette valeur caractérise l impact intrinsèque de la menace sur le système. Etude des vulnérabilités spécifiques : la vulnérabilité est une caractéristique du système pouvant être exploitée par une attaque. Cette caractéristique peut causer une faille dans le système au regard de la sécurité. L objectif de cette étape est de déterminer les vulnérabilités spécifiques du système cible et de les caractériser en terme de faisabilité (menaces délibérées) ou de probabilité (menaces accidentelles). Les objectifs consisteront à diminuer ces vulnérabilités. L identification des objectifs de sécurité suit ces deux études. Pour cela, deux soustâches sont définies : Formalisation des objectifs de sécurité : cette partie a pour but de faire la synthèse des résultats précédents pour déterminer les objectifs de sécurité. Il est nécessaire pour cela de prendre en compte les hypothèses, les enjeux et les différentes règles de sécurité. Détermination des objectifs de sécurité : elle a pour but de déterminer les niveaux de sécurité à mettre en place. La dernière phase d EBIOS a pour but de définir les exigences de sécurité. Cette dernière phase est composée de deux parties : 58 Détermination des exigences de sécurité fonctionnelles : pour assurer les exigences de sécurité fonctionnelles du système cible, chaque risque devra être traité. Les risques pourront être refusés, optimisés, transférés ou pris en charge et le risque résiduel devra clairement être identifié et accepté. Détermination des exigences d assurance de sécurité : le but ici est d exprimer complètement les exigences de sécurité de la cible de l étude de sécurité. Les exigences sont sélectionnées selon le niveau d assurance choisi lors de la détermination des niveaux de sécurité.

83 2.3. Méthodes de haut-niveau pour la sécurité des infrastructures A l issue de ces cinq phases, l étude est résumée dans un document de synthèse : la fiche d expression rationnelle des objectifs de sécurité (FEROS). La méthode EBIOS propose une démarche complète de détermination des objectifs de sécurité d un système informatique. L inconvénient de cette méthode est qu elle est conçue pour les grandes entreprises, et son utilisation nécessite l expertise de consultants sachant conduire l évaluation des risques. Par ailleurs, il n existe pas de remise en cause des choix de conception du SI avec cette méthode car elle ne donne pas de solutions claires pour pointer les problèmes de sécurité, ou pour inventorier les risques d attaque La méthode MEHARI En tant que méthode, MEHARI est un guide dont l objectif est d aider une entreprise, ou le responsable d une activité, utilisant l informatique comme support du système informatique, à élaborer un plan de sécurité de ce système [CLU00]. Universelle, indépendante des organisations et des outils informatiques, matériels et logiciels installés, MEHARI répond aux besoins d organisations complexes reposant sur des structures de management et informatiques décentralisées, largement distribuées. MEHARI peut s appliquer également efficacement à des activités simples, très centralisées. La démarche proposée répond à trois objectifs fondamentaux : Bâtir la sécurité de l entreprise sur une base unique d appréciation de ses valeurs et de ses risques, conformément à une politique de sécurité répondant aux objectifs qu elle poursuit. Déléguer aux unités opérationnelles autonomes les décisions nécessaires pour assurer la sécurité informatique afin de les responsabiliser et de s assurer de la prise en compte de leurs spécificités tout en leur imposant l application de la stratégie d ensemble. Assurer, au sein de l entreprise et pour l ensemble de ses unités, l équilibre des moyens et la cohérence des contrôles en matière de réalisation et de suivi de la politique de sécurité. La méthode MEHARI est conçue pour prendre en compte les différentes contraintes suivantes : avoir une approche globale de la sécurité des structures décentralisées, c est-à-dire proposer un cadre et une méthode qui garantissent la cohérence des décisions prises. manager la sécurité des systèmes d information dans leur complexité, due particulièrement aux systèmes distribués. permettre une approche analytique dans l évaluation des risques et la recherche de solutions, c est-à-dire répondre à la question Quelles solutions sont envisageables face à tels types de risques?. La démarche satisfait à un certain nombre de préoccupations. Elle cherche tout d abord à maintenir une certaine cohérence entre les choix et les décisions prises à tous les niveaux de l organisation. Elle essaie par ailleurs de répondre au plus près aux besoins et aux spécificités des unités opérationnelles, et de répartir les ressources entre les unités 59

84 Chapitre 2. Administration des systèmes distribués opérationnelles de manière équitable. Elle a pour but de rester réaliste, c est-à-dire qu elle laisse libre l entreprise dans ses choix stratégiques par rapport à la perception qu ont ses membres des risques et de leur gravité. Elle cherche à hiérarchiser les problèmes, et à prendre en compte en priorité les risques les plus critiques. Enfin, elle cherche avant tout à être efficace en proposant une automatisation de l appréciation des éléments liés à la sécurité du SI comme les processus de décision. Pour répondre aux objectifs fixés, la méthode propose trois niveaux de construction de plans associés à différentes phases qui s enchaînent logiquement les uns aux autres (figure 2.15) : en réponse à bâtir la sécurité de l entreprise sur une base unique d appréciation et pour satisfaire le besoin de cohérence, on construira un plan stratégique de sécurité. Le plan stratégique répond à la double nécessité de définir une stratégie de sécurité et donc des objectifs de sécurité conformes aux enjeux de l entreprise et de garantir la cohérence des actions et comportements. L efficacité du plan stratégique repose sur la qualité de l engagement des responsables de l entreprise et sur l adhésion des opérationnels qui, au minimum, doivent être consultés avant sa mise en application. Une part importante du plan stratégique consiste à mettre en place des métriques de mesures des risques. Ces métriques permettent une appréciation cohérente des risques dans toute l entreprise, ce qui définit les objectifs de sécurité. Par ailleurs, le plan stratégique doit comporter une classification des ressources du système informatique en fonction de leur valeur pour l entreprise, de manière à être en mesure d évaluer les impacts des scénarios des sinistres. Cet aspect est important pour l élaboration d une politique de sécurité, car il permet d envisager les techniques de recouvrement du système en cas d attaque ou de problème. en réponse à déléguer aux unités opérationnelles autonomes les décisions et pour satisfaire le besoin d adéquation aux spécificités de ces unités, un plan opérationnel de sécurité sera bâti pour chacune d entre elles, selon leurs besoins. Le plan opérationnel peut être élaboré soit à partir d une approche analytique basée sur un audit de services de sécurité, soit à partir d une évaluation des facteurs de risque, c est à dire d une appréciation de leur incidence sur la gravité du risque. Le nombre de paramètres intervenant dans la conduite d une analyse de risques est tel que le choix pour une approche ou l autre exige une réflexion préalable approfondie qui prenne en compte ces différentes caractéristiques ainsi que le nombre et la qualité des ressources que l on peut mettre en œuvre. enfin, le plan opérationnel d entreprise permettra d assurer l équilibre des moyens et la cohérence des contrôles. La conduite d un projet sécurité MEHARI est assurée par un chef de projet. En fonction de l importance de l étude, il lui sera adjoint une équipe constituant le noyau dur, composé de personnes connaissant bien le domaine étudié et les applications du système informatique. On peut également faire appel à une société de services extérieure. Dans ce cas, l élaboration du contrat, le contrôle de son exécution et le suivi du bon déroulement en même temps que la coordination des actions requérant une activité de la part de membres du personnel de l entreprise seront confiés à un responsable qui dépendra d un cadre dirigeant, et, si possible, du responsable de l entreprise lui-même, pour les mêmes 60

85 2.3. Méthodes de haut-niveau pour la sécurité des infrastructures Métriques des risques et objectifs de sécurité Valeurs de l'entreprise : classification des ressources Politiques de sécurité Charte de management Plan Stratégique de sécurité Etape préparatoire : domaine couvert, base de scénarios, reprise de classification Phase 1 Phase 2 - Unité Z Phase 2 - Unité Y Phase 2 - Unité X Audit de l'existant Evaluation de la gravité des scénarios Expression des besoins de sécurité Plan Opérationnel de sécurité Phase 2 Choix d'indicateurs représentatifs Elaboration d'un tableau de bord de la sécurité de l'entreprise Rééquilibrage et arbitrages entre unités Plan Opérationnel d'entreprise Phase 3 Fig Les trois plans issus de la méthode raisons que celles exposées ci-dessus. Dans tous les cas, différents acteurs doivent être impliqués : la direction pour ce qui est du domaine stratégique, de la fixation de la politique générale, de la définition des objectifs prioritaires, des natures de solutions à retenir ou à éviter absolument. les experts et techniciens de l informatique et de la sécurité informatique : qui ont la connaissance des systèmes existants et de leur caractéristiques. les utilisateurs à tous les niveaux de la hiérarchie : seuls à même d évaluer les conséquences des sinistres sur leur activité propre et les contraintes des solutions de sécurité proposées L étude des attaques : la méthode OCTAVE Le domaine de la sécurité des systèmes d information doit permettre de répondre aux attaques ciblant le SI. D un point de vue pratique, il est nécessaire d inventorier les attaques pour être en mesure d identifier les risques qui y sont liés ce qui permet d élaborer une réponse adaptée. La méthode OCTAVE est une démarche concernant l organisation interne de l entreprise. Cette méthode donne une vue globale de l organisation et elle permet d évaluer les risques courants de manière à assurer la sécurité de l information. L analyse des risques comporte les étapes suivantes : identifier les risques analyser les risques pour déterminer les priorités 61

86 Chapitre 2. Administration des systèmes distribués Surveillance Profiles de menace construits à partir des biens critiques Identification des vulnérabilités des infrastructures Implémentation Développement des stratégies et des plans de sécurité Formation des équipes Développement des politiques de sécurité Documentation formelle Fig Processus de gestion des risques avec OCTAVE [Ree03] 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 action les plans d action détaillés surveiller le déroulement des plans d action pour en contrôler l efficacité. contrôler les dérives par rapport au plan d action. Octave comporte trois facettes : vue organisationnelle : cette vue a pour but de construire des profils de menace, d identifier les vulnérabilités organisationnelles ainsi que les exigences de sécurité et les règles existantes. vue technologique : cette vue a pour but d identifier les vulnérabilités de l infrastructure. stratégie de sécurité et planification : une fois les facteurs de risque pris en compte, cette phase doit permettre de diminuer les menaces. OCTAVE permet de classer les risques en plusieurs classes. La classification des risques permet ensuite d évaluer les risques selon leurs impacts (faible, moyen ou fort) (figure 2.17). Il faut ensuite quantifier les risques en terme de probabilité. Après l identification des risques, OCTAVE propose une deuxième phase ayant pour but la construction d un plan de diminution des risques. La construction de ce plan passe 62

87 2.3. Méthodes de haut-niveau pour la sécurité des infrastructures Savoir Accès Acteur Motivation Conséquences Impacts Contrat Client Réseau LAN Physique Système Autre Interne Externe Délibéré Accidentel Délibéré Accidentel Divulgation Modification Perte/Destruction Interruption Divulgation Modification Perte/Destruction Interruption Faible Moyen Fort Faible Moyen Fort Faible Moyen Fort Faible Moyen Fort Fig Identification des risques et de leurs impacts [Ali04] par l analyse globale des vulnérabilités dans le système informatique pour déterminer les composants à évaluer plus précisément. Cette étude peut être concentrée sur le mode d accès et plus particulièrement sur les chemins d accès au réseau. Après avoir identifié les vulnérabilités, il est nécessaire de développer une stratégie de sécurité. Pour cela, une analyse des risques est nécessaire pour déterminer les impacts de ces risques sur l entreprise, de manière à être en mesure d établir un plan de protection. La méthode OCTAVE offre les bases pour une analyse systématique des risques et elle a pour but de réduire ces facteurs de risques (comme EBIOS). En cas d attaque réussie, l ensemble du système peut devenir inutilisable. Pour remédier à ce problème, la méthode SNA (Survivable Network Architecture) proposée par le CERT (Computer Emergency Response Team) est basée sur la prise en compte des attaques et non des risques SNA SNA propose de mettre en place des moyens de sécurisation pour assurer la continuité de service au niveau du réseau et du système informatique, ce qui donne des moyens de survie au système concerné. Dans la méthode SNA, il existe trois éléments de base pour étudier les attaques : étude des moyens de résistance aux attaques. étude des moyens de reconnaissance des attaques. étude des moyens de recouvrement (capacité de fournir des services pour limiter les dommages) 63

88 Chapitre 2. Administration des systèmes distribués Etape 2 : définition des capacités essentielles : -Sélection des Services / Biens essentiels et scénarios d'utilisation -Identification des composants essentiels Etape 1 : Définition du système -Missions, besoins, environnement, risques... -définition de l'architecture Etape 4 : Analyse des capacités de survie -Identification des composants (essentiels et / ou compromis) -Analyse des résistances, reconnaissances et recouvrements -Développement d'un plan de "survie" Etape 3 : Définition des compromissions -Sélection des intrusions, scénarios -Identification des compromissions sur les composants Fig Enchaînement des phases de SNA Cette méthode peut aussi être considérée comme une méthode complémentaire à EBIOS, car elle comporte des facettes permettant de faire le lien avec la conception et la réalisation du système de sécurité. Il existe des méthodes permettant de concevoir une solution de sécurité. Cette phase du cycle de vie est couverte par la méthode SNA proposée par le CERT. Pour doter l architecture de sécurité d un système informatique de capacités de survie, SNA propose une démarche en spirale permettant d élaborer un système de sécurité qui possède des capacités de recouvrement en cas d attaque. La méthode SNA se découpe en quatre phases qu il faut effectuer continuellement (figure 2.18). Les vulnérabilités prises en compte par la méthode SNA peuvent être issues de l organisation des processus (workflows), des applications, des protocoles utilisés, ou encore le système informatique. Pour garantir un niveau de protection suffisant, il faut s intéresser au profil des attaques potentielles et implanter les composants de sécurité adaptés. SNA souligne l importance d être en mesure de détecter des profils d attaque, ce qui nécessite de faire appel à des méthodes avancées de détection de d intrusion. Le but de SNA est de rendre le système informatique capable de survivre en cas d attaque. Pour cela, il est nécessaire de disposer de moyens permettant cette survie, c est-à-dire qu il faut être en mesure d identifier les ressources dont on a besoin et les personnes impliquées en cas d attaque pour construire des processus de secours permettant au système informatique de fonctionner en mode dégradé. Si on se place du point de vue de la gestion des flux, on peut dire que le but de SNA est de reconstruire les deux workflows suivants : 64 un premier workflow représentant les process de business et les ressources de l orga-

89 nisation 2.3. Méthodes de haut-niveau pour la sécurité des infrastructures un second workflow représentant les ressources touchées par les attaques. L idée globale de SNA est de coupler ces deux workflows de manière à être en mesure d identifier un workflow de secours permettant au système informatique de fonctionner en mode dégradé La méthode Mass La méthode MASS d IBM [BC03] est différente de la méthode EBIOS en cela qu elle est focalisée sur l aspect technique de la sécurité du système informatique plutôt que sur les aspects organisationnels. MASS aide à la réalisation d un catalogue des besoins de sécurité et propose des cadres permettant de réaliser l intégration de ces besoins à partir des common criteria. Pour les définir, la méthode MASS identifie onze classes ou catégories 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, chaînes de confiance, et droit d accès au domaine privé. En ce qui concerne la démarche d intégration, MASS fournit des solutions-cadres pour le réseau et le système informatique en utilisant cinq catégories ou sous-systèmes : Le sous-système d audit de sécurité : ce sous-système est responsable de l archivage des événements. Il doit aussi analyser de façon exhaustive et globale le fonctionnement d un centre ou d un service informatique afin de mesurer l adéquation entre les ressources matérielles et humaines mises en œuvre, les besoins de l entreprise, les objectifs recherchés et les résultats attendus. Ceci couvre les activités et les besoins suivants : l audit de sécurité pour les données, l estampillage de l information avec sa signature et son contrôle d intégrité, l analyse de l audit de sécurité. le sous-système de contrôle d intégrité : il a pour rôle de protéger le système informatique de tout dysfonctionnement lié aux transactions illicites, aux programmes piratés, aux fichiers altérés... Pour cela, les classes de besoins concernées sont : l intégrité des ressources, la protection physique du système, la tolérance aux pannes comprenant la reprise sur incident et le test automatique, le stockage des données et le contrôle du temps. le sous-système de contrôle d accès : il a pour rôle l authentification des personnes ou de toute autre entité accédant aux ressources du système informatique. Ce soussystème suppose la mise en œuvre d un dispositif de contrôle d accès, de mécanismes de surveillance de contrôle d accès, d identification et d authentification, de gestion des autorisations, de régulation du contrôle d accès. le sous-système de contrôle de flux : il a pour rôle de contrôler le flux de données entre deux équipements pour éviter la perte de données. Ce sous-système peut dépendre des mécanismes de contrôle d accès ou d authentification. Les besoins de ce soussystème sont : la gestion d autorisation sur les flux, la surveillance des flux, la mise en place de canaux sécurisés, la cryptographie, le stockage de données. 65

90 Chapitre 2. Administration des systèmes distribués le sous-système d authentification : il a pour rôle d identifier et authentifier toutes les entités accédant au système informatique. Pour cela, les besoins et les services suivants doivent être pris en compte : la gestion d un utilisateur ou d un groupe d utilisateurs, la sécurisation et le contrôle d intégrité des flux de données concernant les process de business, la gestion du cycle de vie des certificats électroniques La mise en œuvre d une architecture de sécurité et le suivi de son utilisation grâce à la méthode Safe Il a été vu précédemment que des composants fonctionnels de sécurité pouvaient être définis pour construire une architecture répondant aux critères d évaluation. Pour guider la mise en œuvre d une architecture sécurisée, il est possible d utiliser les méthodes MASS d IBM et Safe de Cisco [CT00]. D un point de vue opérationnel, il est nécessaire de définir des composants implémentables pour répondre aux contraintes de sécurité. Pour cela, nous proposons sept composants principaux qui seront ensuite répartis en fonction des types d attaques auxquelles ils peuvent permettre de faire face (classification proposée par SAFE). les logiciels antivirus : ils aident l utilisateur à détecter et à supprimer les virus dans la partie du système informatique le concernant. Pour que ces logiciels puissent faire efficacement leur travail, les ordinateurs de l entreprise doivent être mis à jour en permanence pour intégrer les nouvelles versions de ces logiciels antivirus. les politiques de sécurité : elles permettent le contrôle des accès au système informatique via le réseau. Ces politiques de sécurité doivent être gérées par un groupe de personnes autorisées disposant des compétences techniques nécessaires. le contrôle d accès : il a pour rôle de vérifier l identité de chaque utilisateur et de déterminer son périmètre d activité (les actions qu il a le droit de faire...). le pare-feu ou firewall : il s agit d un dispositif hardware ou software (ou les deux) sur le réseau permettant de filtrer les échanges. la cryptographie : elle a pour rôle de protéger les données qui vont être transportées sur le réseau public en les cryptant. Le cryptage permet de garantir la confidentialité des données transportées. le système de détection d intrusion (IDS) : il a pour rôle d identifier les activités non autorisées. Lors de la détection d intrusion, ce logiciel envoie un message au responsable de l administration de l infrastructure (administrateur système ou réseau) qui peut ainsi stopper la connexion de cette session non-autorisée. le contrôle du réseau : c est le travail des administrateurs réseau. Cette tâche a pour rôle l identification des faiblesses du réseau et de les éliminer. Pour chaque type de risque, SAFE propose un ou plusieurs moyens d atténuation reposant sur ces composants comme le résume le tableau Traditionnellement, on conçoit l infrastructure d un système distribué en partant de la périphérie du système pour remonter jusqu au cœur. C est la démarche la plus naturelle : on protège avant tout les abords du système les plus exposés aux attaques provenant de 66

91 2.3. Méthodes de haut-niveau pour la sécurité des infrastructures Accès non-autorisé Risques Attaques sur la couche application Attaque par virus ou par cheval de Troie Attaque sur les mots de passe Déni de service Usurpation d'adresse Internet Sniffers de paquets Reconnaissance de réseau (scan) Exploitation des relations de confiance Redirection des ports Méthodes d'atténuation Filtrage au niveau du coupe-feu Système de détection d'intrusion (IDS) sur les serveurs publics les logiciels antivirus sur les stations de travail IDS, contrôle sur les processus Contrôle des configurations TCP au niveau du coupe-feu pour limiter les risques Filtrage RFC 2827 et 1918 sur le coupe-feu local, contrôle d'accès et authentification Infrastructure commutée, cryptographie et IDS l'ids détecte les tentatives de reconnaissance; les protocoles sont filtrés pour limiter l'efficacité de l'attaque Modèle de confiance restrictif et formation de VLAN privés pour limiter les risques d'attaque par exploitation de confiance Filtrage restrictif et IDS pour limiter les risques d'attaque Fig Risques et méthodes d atténuation associées l extérieur. SAFE propose au contraire de protéger d abord le cœur du système avant de remonter vers sa périphérie. Cette démarche permet de minimiser les coûts, car une erreur de conception peut être détectée plus rapidement et corrigée sans qu il soit nécessaire de modifier la configuration de tous les postes clients. La méthode SAFE a pour but la construction d une architecture de sécurité pour l entreprise. Cette méthode, proposée par Cisco [CT00], 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 une partie du système. La démarche de construction proposée part du cœur de l entreprise pour aller vers sa périphérie. Dans chaque zone du système informatique, on regroupe les ressources nécessaires et les composants de sécurité à implanter. Le figure 2.20 présente les éléments d infrastructure réseau, les équipements de sécurité et les éléments de l infrastructure informatique pris en compte par SAFE. Les éléments nécessaires à prendre en compte entre le cœur de l entreprise et son environnement extérieur sont donc à la fois des équipements réseau (pare-feu, commutateur, routeur...) et des serveurs externes, c est-à-dire visibles depuis l extérieur comme : Serveur SMTP (serveurs mails) visibles depuis l extérieur. Serveur DNS pour relayer les requêtes internes vers l internet. Serveur FTP/HTTP pour contenir les informations à fournir aux clients et aux partenaires. 67

92 Chapitre 2. Administration des systèmes distribués Fig Les technologies utilisées par SAFE [CT00] Dans ce type d organisation, il faut impérativement traverser un ensemble de mécanismes de protection pour accéder aux informations de l entreprise : 68 le firewall permet de faire un premier filtrage (RFC 1918 et 2827). Ce filtrage permet de compléter le filtrage effectué par le fournisseur d accès. En outre, le firewall rejette les paquets fragmentés. sur les serveurs accessibles, un logiciel de détection d intrusion (Intrusion Detection System) permet de contrôler l apparition d activités suspectes au niveau du système d exploitation, ou dans les applications partagées (ftp, http, smtp...) le serveur doit être configuré pour ne répondre qu aux commandes autorisées et éliminer toutes les réponses inutiles qui pourraient faciliter la reconnaissance du réseau par les pirates. les commutateurs servent à fournir une connectivité entre les différentes parties de l architecture. Ils permettent d effectuer une séparation logique (réseau local virtuel) permettant d isoler les différents segments : segment extérieur (non-protégé), segment vers les services rendus publics, segment VPN et segment allant vers le cœur de l infrastructure informatique de l entreprise. Au sein du réseau interne de l entreprise (module entreprise campus ) implanté dans un site, les commutateurs et routeurs internes offrent un ensemble de services d acheminement du trafic (commutation et routage). Les équipements réseaux intègrent également des services dits de distribution intégrant la gestion de la qualité de service et le contrôle d accès. Pour inter-connecter les différents sous-réseaux physiques, des commutateurs de bâtiment permettent de relier l ensemble des postes clients, les serveurs et systèmes d administration tout en assurant des fonctions de filtrage entre les sous-réseaux (construction de réseaux locaux virtuels ou VLAN).

93 2.3. Méthodes de haut-niveau pour la sécurité des infrastructures Fig Organisation d une architecture sécurisée pour l entreprise (selon SAFE) ([CT00] p.4) Les autres modules de l architecture propres à l entreprise désignés par la zone enterprise edge dans la figure 2.21 sont destinés à assurer la connectivité avec d autres sites. Outre les aspects de construction et de mise en œuvre d une architecture sécurisée, il est important de garantir les possibilités de continuité de service. Dans ce cadre, cette architecture doit être remise en cause en permanence et il faut toujours chercher les faiblesses ou les vulnérabilités dans le réseau ou le système informatique et trouver la ou les solutions convenables pour remédier aux trous de sécurité et éviter les attaques pouvant en résulter. Le système de sécurité mis en place doit donc être flexible et évolutif pour être capable de changer au fur et à mesure de l apparition des besoins et des changements du système informatique ou du système d administration. Dans ce cadre de maintenance, la méthode SAFE donne quelques bonnes pratiques pour atteindre ces objectifs : encourager les utilisateurs à choisir un mot de passe difficile à trouver changer régulièrement les mots de passes s assurer que les logiciels antivirus fonctionnent en permanence assurer une formation des utilisateurs concernant les risques liés aux documents attachés aux s procéder régulièrement à des audits de sécurité gérer correctement les droits d accès aux ressources, les annuler systématiquement lorsqu un utilisateur quitte l entreprise 69

94 Chapitre 2. Administration des systèmes distribués effectuer des mises à jour régulière des logiciels se trouvant sur les serveurs exposés (web, mail...) ne pas faire fonctionner les services non nécessaires En conclusion, on peut dire que SAFE est une méthode globale permettant la construction et la maintenance d une architecture sécurisée. Cette méthode offre une solution complète en terme d intégration et de mise en œuvre de composants de sécurité dans une architecture distribuée. 2.4 Techniques de mise en œuvre de la sécurité au sein du système informatique Pour assurer la sécurité des systèmes informatiques, il a été mis au point différentes techniques permettant de répondre aux besoins des systèmes informatiques modernes en matière de sécurité. Ainsi, il existe des technologies permettant de réguler les accès au système (technologies de contrôle d accès), de crypter les échanges de données entre les entités du système ou communicant avec le système, et enfin des techniques permettant d authentifier les entités désireuses d effectuer certaines opérations sur le système La sécurité par le contrôle d accès Il est important de faire la distinction entre l authentification et le contrôle d accès. Etablir l identité d un utilisateur est le rôle de l authentification. Le contrôle d accès suppose que l authentification ait été accomplie avec succès. Dans le contrôle d accès, on distingue généralement les politiques des mécanismes. Les politiques sont les directives de haut niveau qui déterminent comment les accès sont contrôlés et les décisions d accès déterminées. Les mécanismes sont des fonctions hardware ou software de bas niveau qui peuvent être configurées pour appliquer les politiques. Le but de cela est de réutiliser les mécanismes pour différents usages de la sécurité. Il existe trois politiques qui peuvent apparaître communément dans une système informatique [SS96] : politiques classiques discrètes politiques classiques par mandatement politiques émergentes basées sur les rôles Politiques d accès discrètes classiques : les politiques discrètes régissent les accès des utilisateurs à l information sur la base de l identité des utilisateurs et des autorisations qui précisent, pour chaque utilisateur et pour chaque objet du système, les modes d accès (read, write, execute) que l utilisateur peut faire sur l objet. Chaque requête est contrôlée avant que les droits d accès ne soient accordés (ou rejetés). Les politiques d accès discrètes sont très flexibles, elles sont donc relativement populaires, mais il est cependant simple de contourner ces règles. Un utilisateur peut donner un fichier à autre un utilisateur qui en théorie n a pas le droit de le lire. La raison est que les politiques d accès discrètes n imposent plus de restrictions une fois que l utilisateur est en possession de l information. 70

95 2.4. Techniques de mise en œuvre de la sécurité au sein du système informatique Au contraire, la diffusion de l information est contrôlée dans les systèmes par mandatement qui évitent que l information contenue dans les objets avec un haut niveau hiérarchique se retrouve dans des objets de plus bas niveau. Politiques par mandatement classiques : les politiques par mandatement gèrent les accès grâce à la classification des sujets et des objets dans le système. Le niveau de sécurité associé à chaque objet reflète la sensibilité de l information contenue dans l objet. On a communément les classements suivant : TS, S, C, U (Top Secret, Secret, Confidential, Unclassified). Il y a par ailleurs deux règles fondamentales dans les systèmes par mandatement : read down : un utilisateur ne peut lire que les objets qui sont en dessous de sa classe write up : un utilisateur ne peut écrire que les objets qui sont au dessus de sa classe. (sans écraser les informations déjà présente à niveau plus élevé) La deuxième règle est un peu curieuse (pour éviter la fuite de l information dans des objets de plus bas niveau.) Elle est souvent interdite dans certains OS. Politiques basées sur des rôles : pour les chercheurs en sécurité et les exploitants, beaucoup d exigences de ces politiques classiques n ont pas été couvertes. Les politiques par mandatement proviennent d environnements rigides, les politiques d accès discrètes proviennent d exigences coopératives et autonomes. D une manière générale, on pourrait dire que les politiques par mandatement sont trop rigides et celles qui sont discrètes sont trop permissives. Il y a donc une nécessité d avoir une alternative. C est à partir de ce constat que sont apparus des systèmes basés sur les rôles. Les politiques basées sur les rôles régulent les accès aux informations sur la base du rôle de l utilisateur dans le système. Un rôle peut être défini comme un ensemble de tâches et de responsabilités associées à une activité particulière. Les autorisations d accès ne sont plus attribuées pour les utilisateurs mais pour les rôles. L approche par rôle a plusieurs avantages : (liste non exhaustive) gestion des autorisations : indépendance logique des autorisations d accès aux objets et des utilisateurs (association utilisateurs-rôles, et rôles-droits). Cette indépendance facilite la gestion du système notamment. rôles hiérarchiques : il y a souvent une hiérarchie des rôles dans l organisation. le moindre privilège : les rôles permettent à l utilisateur de se connecter au système avec les privilèges minimaux qui lui permettent d effectuer sa tâche. Cela lui permet de ne pas mettre en péril le système par une fausse manipulation par exemple. C est cette approche qui domine dans les systèmes qui sont édités actuellement La sécurité par le chiffrement Pour assurer la confidentialité des données dans un système informatique, on fait souvent appel aux technologies de chiffrement des données. Le chiffrement des données a été inventé pour assurer la confidentialité des données. Il est assuré par un système de clé (algorithme) appliqué sur le message. Ce dernier est décryptable par une clé unique 71

96 Chapitre 2. Administration des systèmes distribués correspondant au cryptage. Il existe à l heure actuelle deux grands principes de cryptage : le cryptage symétrique basé sur l utilisation d une clé privée et le cryptage asymétrique qui, repose sur un codage à deux clés, une privée et l autre publique. Le cryptage symétrique : le cryptage à clé privée ou symétrique est basé sur une clé (ou algorithme) partagée entre les deux parties communicantes. Cette même clé sert à crypter et décrypter les messages. Les algorithmes de chiffrement le plus connus sont : Kerberos, DES (Data Encryption Standard) et RSA. Le principal problème est le partage de la clé : comment une clé utilisée pour sécuriser peut être transmise sur un réseau insécurisé?[al02] La difficulté engendrée par la génération, le stockage et la transmission des clés sont des contraintes souvent rédhibitoires pour exploiter ce système sur l Internet. Pour résoudre ces problèmes de transmission de clés, on fait appel au cryptage asymétrique qui utilise une clé privée et une clé public. Le cryptage asymétrique : ce système de cryptage utilise deux clés différentes pour chaque utilisateur : une est privée et n est connue que de l utilisateur ; l autre est publique et donc accessible par tout le monde. Les clés publique et privée sont mathématiquement liées par l algorithme de cryptage de telle manière qu un message crypté avec une clé publique ne puisse être décrypté qu avec la clé privée correspondante. Une clé est donc utilisée pour le cryptage et l autre pour le décryptage. Ce cryptage présente l avantage de permettre le placement de signatures numériques dans le message et ainsi permettre l authentification de l émetteur. Le principal avantage du cryptage à clé publique est de résoudre le problème de l envoi de clé privée sur un réseau non sécurisé. Bien que plus lent que la plupart des cryptage à clé privée il reste préférable pour trois raisons : Plus évolutif pour les systèmes possédant un grand nombre d utilisateurs Authentification plus flexible Supporte les signatures numériques La signature numérique : dans toute transaction professionnelle, les deux parties doivent offrir une garantie de leur identité. La signature numérique et le certificat sont des moyens d identification de l émetteur du message. Le principe de la signature numérique consiste à appliquer une fonction mathématique sur une portion du message. Cette fonction mathématique s appelle fonction de hachage et le résultat de cette fonction est appelé code de hachage. Ce code fait usage d empreinte digitale du message. Il faut noter que la fonction est choisie de telle manière qu il soit impossible de changer le contenu du message sans altérer le code de hachage. Ce code de hachage est ensuite crypté avec la clé privée de l émetteur et rajouté au message. Lorsque le destinataire reçoit le message, il décrypte ce code grâce à la clé publique de la source puis il compare ce code à un autre code qu il calcule grâce au message reçu. Si les deux correspondent, le destinataire sait que le message n a pas été altéré et que son intégrité n a pas été compromise. Le destinataire sait aussi que le message provient de l émetteur puisque seul ce dernier possède la clé privée qui a crypté le code. Ce principe de signature a été amélioré avec la mise en place de certificats permettant de garantir la validité de la clé public fourni par l émetteur. 72

97 2.4. Techniques de mise en œuvre de la sécurité au sein du système informatique Les certificats : pour assurer l intégrité des clés publiques, ces dernières sont publiées avec un certificat. Un certificat est une structure de données qui est numériquement signée par une autorité certifiée (CA : Certification Authority). Il s agit une autorité en qui les utilisateurs peuvent faire confiance. Il contient une série de valeurs, comme le nom du certificat et son utilisation, des informations identifiant le propriétaire et la clé publique, la clé publique elle même, la date d expiration et le nom de l organisme délivrant les certificats. Le CA utilise sa clé privée pour signer le certificat et assure ainsi une sécurité supplémentaire. Si le récepteur connaît la clé publique du CA, il peut vérifier que le certificat provient vraiment de l autorité concernée et est assuré que le certificat contient donc des informations correctes et une clé publique valide Les logiciels et les protocoles de mise en œuvre des techniques de sécurité Les techniques explorées précédemment sont mises en œuvre à travers des logiciels et des protocoles spécifiques. Parmi les principaux protocoles permettant l authentification au sein des systèmes informatiques, on peut citer RADIUS, CHAP, SecureID (cartes à puce), IPSec et pour les logiciels : Kerberos et Personal CAT. Il existe par ailleurs des dispositifs de filtrage des communications, qui permettent d éliminer les communications illicites et pouvant être nuisibles. Ce sont les pare-feux ( firewalls ). RADIUS (Remote Authentication Dial-In User Service) [RRSW97] est un protocole client/serveur destiné à permettre à des serveurs d accès de communiquer avec une base de données centralisée regroupant en un point l ensemble des utilisateurs distants. Ce serveur central (appelé serveur RADIUS) va authentifier ces utilisateurs, et leur autoriser l accès aux ressources. Toutes les transactions RADIUS entre le client et le serveur sont authentifiées par l utilisation d un secret qui n est jamais transmis sur le réseau. De plus les mots de passe sont encryptés en utilisant cette même clé secrète. CHAP (Challenge-Handshake Authentication Protocol) [Sim96] est une procédure relativement sécurisée pour se connecter à un système. Les étapes pour se connecter à un système à l aide de CHAP sont les suivantes : Après l établissement de la connexion entre le serveur et un client, le serveur envoie un message au client. Ce dernier répond avec une valeur obtenue en utilisant une fonction surjective. Le serveur contrôle la réponse en la comparant à son propre calcul. Si les valeurs correspondent, l authentification est reconnue, sinon la connexion est terminée. A tout moment, le serveur peut envoyer un nouveau challenge au client connecté. SecureID [KS] permet, en une seule étape, d identifier avec certitude les utilisateurs du système et du réseau afin d interdire tout accès illicite. Utilisé avec des modules de contrôle d accès (ACM) logiciels ou matériels dédiés, SecureID génère un nouveau code d accès imprévisible toutes les soixante secondes. SecureID est une procédure aisée en une seule étape, garantissant l authentification certaine des utilisateurs. SecureID permet : 73

98 Chapitre 2. Administration des systèmes distribués d effectuer la prévention des accès non-autorisés aux ressources d information de l organisation, d authentifier des utilisateurs au niveau du réseau, du système, des applications ou des transactions. de générer des codes d accès à usage unique, imprévisibles et renouvelés automatiquement toutes les soixante secondes. d assurer un fonctionnement multi plate-forme à l aide de modules de contrôle d accès. Authentification Header dans IPSec : un des gros problèmes au niveau de la sécurité dans les réseaux TCP/IP est que les paquets IP (adresse + contenu) sont falsifiables sans trop de difficultés. Le rôle du protocole IPSec [KA98] est d éviter cela. Il est possible en effet, grâce à IPSec, de rajouter une entête d authentification cryptographique (Authentication Header - AH) ce qui permet d obtenir : l authentification de la source du paquet (adresse IP authentique) la vérification de l intégrité du contenu une authentification de bout-en-bout (même si la présence de nœuds intermédiaires est possible) une authentification portant sur l ensemble du paquet IP (entête + données) excepté sur les enregistrements modifiés en cours de route ( hop count, time to live, etc.) Par ailleurs, un paquet contenant un AH peut être traité par tous les intervenants d un réseau IP même s ils ne le comprennent pas (compatibilité vers l arrière) et pour générer un AH valide il faut que chaque système soit muni d une (ou plusieurs) clés et qu il soit en mesure de valider les AH générés par les autres intervenants. Kerberos [Gar03] est un service distribué d authentification qui permet à un client de prouver son identité à un serveur d application sans envoyer de données sensibles à travers le réseau qui pourraient permettre à un agresseur de corrompre le système ultérieurement. Une description détaillée de Kerberos fait l objet de l annexe B. Le problème de l interopérabilité des implémentations de Kerberos est traité dans l annexe C. Au départ, le client souhaite envoyer un message au serveur. Le serveur, pour être sûr de l identité du client, lui demande de s authentifier. Le serveur d authentification et le serveur vérificateur interviennent alors. Le client et le serveur d authentification possède la même clé d authentification, qui est la clé du client. Pour le client, cette clé équivaut à un mot de passe. Celui-ci envoie ensuite un message d authentification crypté avec cette clé au serveur d authentification. Celui-ci utilise alors sa clé pour vérifier l identification du client. Si le message est décrypté, le client est authentifié. Le service d authentification envoie alors au client un certificat crypté (contenant une clé unique permettant d identifier le client (clé de session), et une date d expiration au delà de laquelle il ne pourra plus s identifier) par une clé connue seulement de lui et du vérificateur (clé serveur ) (le client ne peut donc pas modifier le certificat puisqu il ne connaît pas cette clé). Le certificat est alors envoyé au vérificateur qui le décrypte en utilisant la clé serveur et utilise la clé de session obtenue pour authentifier le client. 74

99 2.4. Techniques de mise en œuvre de la sécurité au sein du système informatique Serveur d'authentification Client 4 Vérificateur Fig Les grandes étapes de l authentification Kerberos 1 : Envoi du message d authentification crypté avec la clé client. 2 : Si le client est authentifié, le serveur d authentification utilise sa clé serveur pour envoyer le certificat crypté contenant la clé de session (clé unique) identifiant le client. 3 : Envoi de ce certificat crypté au vérificateur. 4 : Le vérificateur, après avoir décrypté le certificat avec sa clé serveur, obtient la clé de session qui permet d authentifier le client. Personal CAT [Sil] permet une authentification forte des utilisateurs par carte à puce. Personal CAT permet d authentifier précisément les utilisateurs. Il se base sur les principes suivants : les informations échangées pour l authentification ne sont jamais deux fois identiques et ne présentent aucun élément exploitable par les observateurs externes. la conservation des clés secrètes sur carte à microprocesseur offre une grande garantie d inviolabilité. chaque carte utilisateur contient une clé différente, et son utilisation est protégée par la frappe d un code personnel qui bloque la carte après trois tentatives erronées. une session de sécurité permet un contrôle permanent de l origine des connexions applicatives, et des ré-authentifications régulières et automatiques en cours de dialogue (transparente pour l utilisateur) permet de prévenir toute tentatives d usurpation d identité. Les Firewalls : sont des composants du réseau permettant de concentrer l administration des nombreux points d accès entre un réseau privé et le réseau Internet [CZ96]. 75

100 Chapitre 2. Administration des systèmes distribués Fig Principe de base d un firewall La connexion d un réseau privé avec l Internet peut être rendue nécessaire pour certains services tels : Le courrier électronique, Les news, Le web, Les accès distants (ssh, sftp...). Il s agit en fait d une machine qui est reliée à l extérieur (Internet dans la plupart des cas) ainsi qu au réseau local et qui analyse le trafic réseau qui la traverse pour savoir si oui ou non elle laisse passer ce trafic dans un sens ou dans l autre (figure 2.23). Mais un firewall doit avant tout refléter la politique de sécurité et les méthodes d accès au système informatique de l entreprise. C est-à-dire que rien ne sert de déployer un tel système si l on n a pas déterminé les connexions que l on souhaite bloquer ou que l on souhaite laisser passer. Il est important de définir les services qui seront accessibles de l extérieur et les services auxquels auront accès les utilisateurs internes. Par exemple, il semble logique d interdire un accès via telnet à toute personne extérieure au réseau local. Cela permettra d éviter de pirater le système de l extérieur. De même, une entreprise peut interdire à ses utilisateurs d utiliser le service ftp pour envoyer des documents à l extérieur de l entreprise. Ce n est donc qu une fois cette politique définie que l on peut enfin mettre en place un système de firewall. Globalement, les pare-feux sont utilisés soit pour empêcher les connexions au réseau interne depuis l extérieur soit pour empêcher les connexions à partir du réseau interne vers l extérieur. Le schéma général d un système firewall peut être représenté par la figure L infrastructure présente une zone démilitarisée (brin de réseau physique compris entre le routeur d accès et le Firewall), dans laquelle on retrouve ce qu on appelle des bastions. Les bastions sont des ordinateurs qui fournissent des services publics à l extérieur. Il n y a pas besoin de les sécuriser de manière importante car ils ne contiennent aucune information vitale Conclusion La sécurité des infrastructures informatiques constitue un enjeu crucial pour le bon fonctionnement de l entreprise, qu elle soit classique, virtuelle ou étendue. Il existe un certain nombre de concepts et de techniques permettant de répondre aux besoins de 76

101 2.5. Méthodes avancées de détection en matière de sécurité des infrastructures Fig Schéma de la configuration générale d un firewall sécurité d un système informatique. Toutefois, par rapport à la diversité des techniques et à la complexité du problème, il est nécessaire d avoir un cadre fédérateur de manière à mettre en œuvre et à exploiter efficacement les techniques de sécurité existantes. Ce cadre est fourni par les différentes méthodes vues précédemment. Les techniques ont pour but de garantir une certaine sécurité, on peut considérer de ce fait qu elles ont un rôle préventif. Il existe par ailleurs des techniques évoluées de détection d intrusion intervenant lorsque la sécurité du système est en train d être compromise. Il s agit des techniques qui ont pour rôle de détecter les intrusions en train d être perpétrées sur le système. Ces techniques constituent un enjeu majeur pour la sécurité des systèmes informatiques d aujourd hui et de demain. 2.5 Méthodes avancées de détection en matière de sécurité des infrastructures On peut définir le concept d intrusion comme étant l action de s introduire quelque part sans y être autorisé. La détection d intrusion fait référence dans un contexte informatique à l action de détecter une intrusion (un accès non-autorisé) sur une machine ou un réseau donné. Un système de détection d intrusion (SDI) est l équivalent d un système d alarme. Le rôle d un SDI est de surveiller les points d accès, les activités illicites, et les intrus qui sont déjà connus. En pratique, les SDI classiques sont des outils permettant d interpréter le contenu de fichiers d audit (ou fichiers de log), les séquences d appels systèmes, ou encore les échanges protocolaires provenant des équipements stratégiques du réseau, comme les routeurs, serveurs, firewalls... Quand une attaque est détectée, un SDI peut émettre des alarmes, déclencher des actions automatiques comme couper par exemple les liens internet ou des serveurs spécifiques, ou tenter d identifier les attaquants et collecter des preuves de leurs méfaits. 77