Ce document et ce qu’il décrit sont protégés par la loi du 11 mars 1957 sur la propriété littéraire et artistique, modifiée par la loi du 3 juillet 1985, de même que par les lois sur le copyright et par les conventions internationales

Toute reproduction ou distribution totale ou partielle de ce document ou de ce qu’il décrit, par quelque moyen que ce soit, doit indiquer explicitement l'auteur :

Patrick Gantet

Toute personne ne respectant pas ces dispositions se rendra coupable de contrefaçon et sera passible des peines pénales prévues par la loi.

Introduction

Les objectifs de ce document

Ce document a pour objet de proposer une démarche d’architecture du système d’information de l'Entreprise et de ses filiales, qui réponde aux besoins de simplification et de réactivité dans la réalisation et le déploiement d’applications. Et ceci à partir d’un noyau commun adaptable aux spécificités des différentes filiales en mettant en œuvre des technologies pérennes tout en maîtrisant les coûts.

L’objectif de ce document est donc de fournir à l'Entreprise un éclairage sur les divers scénarios d’architecture et leurs pertinences ainsi que sur la démarche à adopter pour les mettre en œuvre :

• • • • en concordance avec les choix, standards et méthodes actuelles pour le développement des nouvelles applications,

      • en fonction des types d’application existant au sein de l'Entreprise, de leur complexité, de leur durée de vie et des contraintes de réalisation qui sont imposées aux équipes de développement,

      • en adéquation avec la qualification et la formation des équipes de développement proposées par les SSII.

Les qualités attendues du système d’information

Concevoir un système adaptable

Noyau commun

Développer un ensemble de services métiers permettant la réalisation d’applications couvrant l’ensemble des activités de l'Entreprise par assemblage de ses services.

Applications multilingues

Isoler la partie présentation et reporting des applications afin d’en permettre la traduction dans les différentes langues utilisées au sein de l'Entreprise et de ses filiales et partenaires.

Applications adaptables aux contraintes locales

Isoler les règles métiers ou le traitement des spécificités dans des services qui pourront être remplacés pour répondre aux réglementations et législations des différents pays où est présente l'Entreprise et ses filiales.

Externaliser toutes les constantes métiers (taux, durées, devises, dates…) dans des tables accessibles par les services métiers afin de pouvoir faire évoluer ces paramètres (suivant les changements, les pays…) sans devoir modifier les services.

Concevoir un système ouvert

Intégration

Apporter une facilité de développement et de déploiement permettant la réalisation d’applications couvrant l’ensemble des activités de l'Entreprise avec des capacités de réutilisation de services.

Permettre l’incorporation de nouveaux services sans remettre en cause l’ensemble des applications.

Permettre l'intégration de progiciels acquis auprès de sociétés tierces pour informatiser certains domaines fonctionnels en s’intégrant à l’ensemble de manière cohérente.

Interopérabilité

Garantir l’interopérabilité des applications au sein de l'Entreprise, ainsi que potentiellement, avec les architectures de ses fournisseurs et partenaires.

Sécurité

Appliquer la politique de sécurité pour l'Entreprise, ses filiales et ses partenaires notamment :

• contrôler les accès aux applications en fonction des profils et droits des accédants,

• garantir, si nécessaire, la non altération et la confidentialité de l’information de sa saisie à son stockage final.

Pouvoir évoluer

Pérennité

Respecter les normes et standards du marché pour permettre l’évolution du système d’information sans être prisonnier de produits.

Choisir des produits conformes aux normes du marché et permettre, si besoin était, un changement de produit avec un minimum d’impact.

Évolutivité

Découper les applications en services pour permettre l’incorporation de nouvelles technologies ou nouveaux algorithmes dans ces services sans remettre en cause les applications.

Industrialiser le développement

Simplicité

Faire développer des applications à base de services sans se préoccuper des architectures matérielles et systèmes, ni de la localisation de ces services. Le développeur porte son effort sur métier et non sur la technologie.

Indépendance

Garantir la cohérence des interfaces d’appel et des versions entre les applications clientes et les services. Les différents composants doivent pouvoir évoluer indépendamment les uns des autres.

Qualité

Réaliser des applications de plus en plus fiables par la réutilisation de services – Service Oriented Architecture – et gagner en cohérence entre applications.

Abaisser les coûts de maintenance des applications tout en améliorant leur qualité.

Réactivité

Répondre plus rapidement aux exigences de l'Entreprise et de ses filiales en réalisant des applications avec la réutilisation de services déjà existants et opérationnels.

Maîtriser l’administration

Flexibilité

Permettre de suivre les changements d’organisation et d’activité de l'Entreprise par une localisation des services des applications gérée de façon transparente pour le développeur.

Accueillir les nouveaux utilisateurs (Internet) sans dégrader les performances par des capacités de démultiplication des serveurs frontaux.

Continuité de service

Ne pas interrompre l’activité des utilisateurs lors de la mise en place de nouvelles applications ou versions de composants du système d'information, mais gérer ces changements de façon la plus transparente possible.

Réduire les fenêtres batch au minimum et permettre le 24h/24h et 7j/7j.

Synthèse

Le besoin d'être réactif et flexible pour suivre la croissance et les évolutions de l'Entreprise, notamment par l'ouverture de nouvelles filiales, conduit à privilégier une architecture qui permette d'incorporer rapidement dans le système d'information des produits du marché aussi bien que des développements spécifiques.

Architecture à base de services

La solution proposée pour bâtir les futures applications de l'Entreprise repose sur les architectures multi niveaux à base de composants mutualisés : les services. Une architecture multi-tiers est un modèle d’architecture d’applications dans lequel on sépare la présentation, les traitements et les données.

L’objectif poursuivi est de permettre :

• une évolution de l’un de ces tiers de façon "relativement" indépendante des autres,

• une adaptabilité en fonctions des particularités propres à chaque filiale en termes de linguistique et de réglementation.

Les communications entre services doivent être conformes aux standards du marché pour permettre l'interopérabilité avec les composants et les applications du marché.

è L'architecture multi-tiers à base de services est aujourd’hui le meilleur choix pour réaliser des applications de qualité car elles obligent à adopter une démarche de conception et séparent dans la réalisation les différents éléments IHM, logique et données.

Isolation des différentes couches

Les enjeux liés à cette séparation logique en couche sont considérables:

• améliorer la réactivité de mise à disposition des applications par la réutilisation de "briques" existantes,

• autoriser l’accès au système par le biais de canaux variés tels que l’Internet, les devices mobiles, le Poste de Travail, etc,

• capitaliser sur l’existant.

La séparation en couche intègre :

• Le besoin de construire des applications susceptibles d'être utilisées à partir de différents médias comme le Web, le Vocal, etc. conduit à isoler la couche cinématique et présentation du reste de l'application.

• La séparation entre la partie traitement qui représente les règles de gestion et la partie données sur lesquelles elles s'appliquent permet une meilleure modularité de l'application.

• Les composants d'accès aux données peuvent alors évoluer techniquement sans impact sur le reste de l'application. De plus la fréquence des évolutions des parties règles de gestion est toujours plus élevée que les changements de structure de données, et on gagne donc à isoler cette dernière pour avoir un minimum d'impact lors d'évolutions.

Une application sera donc découpée en :

• Une couche de présentation et de pilotage de l'application propre à chaque média d'accès.

• Une couche de logique métier où l'on trouvera les différents services décrivant les règles de gestion du métier.

• Une couche d'accès aux données encapsulant les données du métier et accessibles par les applications du métier et éventuellement par les applications d'autres métiers.

• Une couche de composants techniques comme des services d'impression, de sauvegardes, de transfert, dont certains pourraient être mutualisés pour l'ensemble de l'Entreprise.

Accès aux données entre domaines

Chaque domaine propriétaire de données doit gérer les accès à ces données :

• Bien que chaque domaine applicatif doit pouvoir être indépendant des autres, il participe d'une même Entreprise et doit offrir aux autres domaines des services d'accès à ses données.

• Une partie des fonctions d'accès aux données d'un domaine sera rendue publique pour en permettre un accès par les autres domaines.

• Si les données changent de propriétaire (d'un domaine à un autre) il convient de créer un service référentiel qui devient le propriétaire permanent des données et qui offre aux différents domaines des fonctions de mise à jour et qui contrôle les accès par les autres domaines.

Mutualisation de services

La mise en commun de services techniques permet d'alléger le développement des applications. Elle dégage les équipes de développement des applications de migrations techniques dues à des évolutions des technologies mise en œuvre.

Par contre, cette mutualisation demande une équipe de support et de maintenance des services mutualisés pour les faire évoluer ainsi que pour assister les équipes les utilisant.

Portabilité des applications

Face à la compétition entre éditeurs et à la rapidité d'évolution des normes, il convient de se protéger du manque de pérennité et de stabilité des offres du marché.

Trois grandes orientations permettent aujourd'hui d'obtenir cette garantie :

• Développement des services en Java car utilisable sur toute machine disposant d'une Java Virtual Machine.

• Généralisation des interfaces en HTML/Ajax car utilisable sur toute machine disposant d'un navigateur et offrant la puissance d'un poste graphique.

• Utilisation de XML pour tous les échanges entre composants au sein du SI et XML pour tout échange avec les partenaires en utilisant des WebServices ou des messages.

Réutilisation de l’existant

Aujourd’hui, le cœur du système d’information métier de l'Entreprise est écrit dans des langages traditionnels Cobol ou autres et il doit s’intégrer dans l’architecture des services métiers. De plus, la maîtrise et les compétences du l'Entreprise sont encore, à ce jour, en majorité sur le Cobol et les outils associés.

Il ne paraît donc pas souhaitable, compte tenu de la maturité des nouvelles technologies de vouloir y migrer en totalité trop rapidement. Par contre, il semble important de traiter la partie présentation et de faire évoluer les programmes Cobol vers des services métiers.

Urbanisme du système d'information

Systèmes d’Information

L’ensemble des activités de l'Entreprise est constitué de domaines fonctionnels (tel que le contentieux).

Chaque domaine supporte de manière indépendante et autonome, les activités d’un et d’un seul domaine de l'Entreprise. Afin de répondre à ces critères d’indépendance et d’autonomie, chaque domaine gère exclusivement les composants métiers qui sont de son ressort.

Le découpage en domaines

L'Entreprise pratique un certain nombre de métiers qui sont coordonnés par une organisation qui régit les règles de fonctionnement de l'Entreprise et qui définissent un domaine fonctionnel.

On distingue généralement des domaines :

• Verticaux comme ceux tournés vers les clients de l'Entreprise.

• Transverses qui sont les métiers communs à l'Entreprise comme la Comptabilité, la facturation.

• Mais aussi les domaines communs comme la gestion des clients, la gestion des nomenclatures.

Tous ces domaines s'appuyant sur des domaines techniques comme l'accès aux systèmes externes à l'Entreprise.

Urbanisation du système d’information

Chaque domaine doit pouvoir évoluer avec un minimum d’impact sur les autres.

Chaque domaine doit pouvoir fonctionner indépendamment des cycles de fonctionnement des autres domaines.

Pour atteindre les objectifs d’évolutivité et d’autonomie, les différents domaines communiquent entre eux.

è exclusivement à l’aide d'un mécanisme d'échange de messages, de manière synchrone ou asynchrone. Ce dispositif normalise les échanges entre domaines et permet d’urbaniser le système d’information, c’est à dire, de réguler les flux d’échanges entre les différents domaines fonctionnels.

Chaque domaine peut être décomposé en plusieurs composants contribuant à la réalisation du métier. Ces composants communiquent entre eux suivant différents modes de communication :

• Entre domaines

  • Question/réponse vers un service de consultation d’information d’un autre domaine.

  • Message asynchrone d’information à destination d’un autre domaine.

• Au sein d’un domaine

  • Question/réponse entre composants du domaine.

  • Message asynchrone si on n’a pas besoin de réponse ou pour paralléliser des taches.

• D’un domaine commun vers les autres domaines

  • Publication par événements.

  • Abonnement des domaines souhaitant une information.

Services publics et services privés

Un domaine offre en général un certain nombre d'applications (clientes) permettant de gérer les objets du domaine. Ces applications comprennent la partie présentation et le pilotage de l'application. Ce pilotage définit l'enchaînement des différentes phases du dialogue avec l'utilisateur et des traitements à exécuter. Elle décrit les appels de services du domaine pour mener à son terme l'application.

Les services du domaine peuvent accéder aux autres services de son domaine et ceux d'autres domaines.

Chaque domaine publie un certain nombre de services publics d'accès qu'il offre aux autres domaines.

è Ainsi les domaines ont accès aux informations des autres domaines uniquement via des services publics. Ceci permet à chaque domaine de contrôler ou d'interdire l'accès à ses informations en fonction du profil de l'appelant.

Isolation des données

Les apports de l’isolation des données sont :

• • • • Garantie de la portabilité des applications d’un système de gestion de base de données à un autre.

      • Garantie de non impact de l’évolution de la structure des données.

      • Amélioration de la flexibilité et de la réactivité du système d’information (modulaire et générique).

      • Garantie d’intégration vers des architectures extérieures.

      • Libération de la technologie pour le développeur pouvant ainsi porter son effort sur le métier.

Indépendance des applications vis à vis du système de gestion de base de données

L’isolation des données autorise sans modification des applications, le changement de technologie des bases de données.

On comprend bien qu’un changement de technologie de support des données s’il n’y a pas d’isolation de ces dernières, a un impact sur toutes les applications. Avec un isolement des données par un service d’accès, seul ce service est touché par le changement de technologie. Le service conservant la même interface d’accès, les applications sont inchangées.

Indépendance des applications vis à vis de l’implémentation physique des données

L’isolation des données autorise sans modification des applications, le changement de l’organisation physique des données (éclatement de tables sur plusieurs bases, modification de schéma et de tables).

On comprend bien qu’un changement de structuration des données s’il n’y a pas d’isolation de ces dernières, a un impact sur toutes les applications. Avec un isolement des données par un service d’accès, seul ce service est touché par le changement d’organisation des données.

è Le service conservant la même interface d’accès, les applications sont inchangées et surtout aucune n’est oubliée.

è Le service d’accès aux données masque les disparités d’accès aux données et permet d’utiliser les particularités d’une base sans préjuger d’un changement de fournisseur.

è L’accès à toutes les données se réalise d’une manière unique quelle que soit l’organisation qui les supporte (bases de données, fichiers, etc.). C’est le service qui en masque les mécanismes d’accès : ce service peut accéder aux données en appelant des procédures stockées.

è Le DBA peut réorganiser les tables sans aucune répercussion sur les applications.

Amélioration de la flexibilité et réactivité du système d’information

L’isolation des données autorise sans modification des applications, les modifications de répartition des données pour obtenir les performances souhaitées (réplication de données en local) ou un fonctionnement en autonome.

Le principe de base est le découpage en présentation, application (pilotage des contrôles et cinématique de l'application), composants métiers et accès aux données.

L'application est pilotée par un moteur d’enchaînement permettant de garantir la cinématique de l’application. La présentation générée peut être complètement HTML et fonctionner avec toute station cliente équipée d’un quelconque navigateur. Elle peut être plus complexe et utiliser des applets Java mais devient limitée à des stations intelligentes, réservées aux utilisateurs del'Entreprise.

L'accès des partenaires se fait par des échanges des flux XML (ou spécifiques aux partenaires) qui sont reçus par un contrôleur qui convertira les flux non XML et transmettra les messages sous forme XML à l’application concernée. Ces applications utiliseront les mêmes contrôles et règles métier que les applications utilisées par les utilisateurs finaux.

La présentation

L'isolation de la présentation permet de fournir plusieurs versions d'une même application pour différents médias en développant uniquement la partie présentation.

Suivant le niveau de complexité des saisies, la réalisation peut se faire en HTML seul ou en incluant des contrôles sous formes d'applets Java.

Ce flux est converti vers un message XML et la mise en forme est réalisée par un feuille de style XSL qui peut être personnalisée en fonction du partenaire (logos, charte …), et de la langue de l'utilisateur.

Les composants métiers

Un composant métier doit gérer un et un seul objet (par exemple le client ou le contrat). Il offre des fonctions qui permettent d'agir sur l'objet géré.

Le nombre de fonctions disponibles sur un composant ne doit pas excéder une trentaine. Au delà, cela signifie que l'objet est trop complexe et qu'il doit être découpé en objet plus élémentaire.

Les composants techniques

Un composant technique est construit pour gérer une et une seule ressource. Il dispose comme le composant métier de fonctions pour manipuler la ressource.

Par exemple ce peut être la gestion des communications avec l'extérieur, la gestion des impressions, etc. Il ne se distingue du précédent que par le type d'élément géré (la ressource).

En général, il n'appelle pas d'autres composants non techniques (un composant métier lui, utilisera si besoin des composants d'accès aux données ou techniques).

Les composants d’accès aux données

Chaque domaine est propriétaire de ses données. Il doit les isoler dans un composant d'accès pour permettre :

• l'indépendance avec les autres composants (règles de gestion du métier) qui le met en œuvre;

• l'indépendance de la base de données support des informations ainsi que de son organisation;

• le contrôle des accès qui sont fait par les autres domaines.

Ce composant peut avoir des fonctions privées (réservées aux seules applications du domaine) et offrir des fonctions publiques pour les besoins des autres domaines.

Le composant doit offrir des fonctions publiques d'accès de niveau fonctionnel et non programmatique. Ces fonctions étant publiques, leurs interfaces doivent toujours évoluer de manière compatible ascendante, pour ne pas obliger les autres domaines à des migrations à des fréquences ou des périodes non souhaitées.

Les référentiels

La vision précédente des données n'est pas toujours suffisante, en effet il y a des cas où la propriété de l'information passe d'un domaine à un autre ou des cas où les données sont réellement partagées entre domaines et qu'elles n'appartiennent pas plus à un domaine qu'à un autre (ex : cas des nomenclatures).

Le changement de propriétaire en passant les données d'un domaine à l'autre n'est pas simple à résoudre et ne résout pas le second cas (le partage).

è La solution est de créer un domaine référentiel qui sera le propriétaire et le garant permanent des données à partager.

Ce domaine offre un ensemble de fonctions d'accès aux données qu'il gère :

• Ces accès sont des accès en lecture et mise à jour.

• Il permet de contrôler les demandes qu'il reçoit des autres domaines et d'en vérifier le bien fondé.

• Par les règles de gestion qu'il aura implémentées, il réalisera le changement de propriétaire des données en acceptant ou refusant telle demande en provenance de tel ou tel domaine.

Ce domaine peut également offrir un service de publication abonnement aux autres domaines pour les informer de l'évolution d'une donnée.

è Le référentiel ne doit contenir que des informations réellement communes à plusieurs domaines. Les compléments d'informations ne relevant que d'un domaine, restent dans le domaine concerné et disposent d'une identification permettant le lien avec le référentiel.

è Les contraintes des différentes applications des divers domaines sur l'accès aux données conduit en général à bâtir les référentiels sur des plates-formes à haute disponibilité.

Les types d’applications

Ce chapitre n’a pas la prétention de vouloir traiter l’exhaustivité des types d’applications que l’on peut rencontrer, mais de donner pour chaque grande catégorie des modèles de découpage. Probablement les applications réelles seront un mixte de ces différents modèles car certaines parties seront complexes et d’autres plus simples.

De plus il faut penser à découper les projets en applications élémentaires et à ne pas hésiter à mettre en œuvre un outil de workflow qui garantira l’enchaînement de ces différentes applications élémentaires.

Les applications interactives

Les applications

Ces applications respectent le découpage multi-tiers et comportent des composants métiers, des composants techniques et des composants d’accès aux données.

Ces applications sont les applications qui réalisent :

• des mises à jour de l’information du système d’information et exigent donc des contrôles et l’application de règles de gestion.

• des consultations de l’information du système d’information qui ne nécessitent pas d’application de règles de gestion.

Transformation de messages en fichier pour traitement batch

Cette technique permet de faire évoluer un traitement batch en traitement au fil de l'eau tout en conservant pour certaines applications (batchs, partenaires …) la constitution d'un fichier.

La sécurité

Ce chapitre ne traite que la partie sécurité du système d'information, il ne porte pas sur les mécanismes de "disaster recovery" qui doivent être mis en place. Dans ce cadre, six domaines principaux sont à traiter :

• le contrôle d’accès physique,

• l’authentification,

• les habilitations,

• l’intégrité et la confidentialité,

• la non répudiation.

Le contrôle d’accès physique

Contrôler l’accès aux ressources du système d’information est la première barrière à mettre en œuvre dans la conception d’une architecture de sécurité.

Le principe de ce contrôle consiste à mettre en œuvre des filtres aussi bien physiques (procédures de sécurité, badge, salle machine …) que des filtres logiciels (seul les flux autorisés dans une table "Qui/Quoi" transitent effectivement).

Pour appliquer ce contrôle, on peut utilisera trois types d'outils :

• Filtrage protocolaire : surveillance des ports de communication et ouverture des ports selon le protocole,

• Détection de virus, surveillance des flux susceptibles de véhiculer des virus,

• Audit proactif, détection des attaques et des comportements anormaux.

La prise en compte conjointe de ces trois aspects constitue la politique de sécurité à mettre en œuvre. La conception de la politique de sécurité est l’étape qui va déterminer le périmètre fonctionnel de l’architecture de sécurité. Pour cela, il va falloir réaliser une cartographie de l’ensemble des flux entrants et sortants ainsi que les protocoles et les ports qu’ils utilisent.

Les offres de solution de contrôle d’accès système intégré aux infrastructures réseaux sont matures : Cisco, ISS, Network Associates ou CheckPoint proposent des offres très complètes intégrant l’antivirus, l’audit proactif, le contrôle des accès distants et les réseaux privés virtuels, à la fois en implémentation matérielle et logicielle.

L'authentification

Le service d’authentification comprend, deux fonctions complémentaires :

• L’identification, fonction qui associé un identifiant unique pour se connecter à un système.

• L’authentification, fonction qui consiste à vérifier que l’identifiant qui s’est connecté est bien celui qu'il prétend être.

Ces deux fonctions sont remplies par d'une part l’ "id" de signature et d'autre part le mot de passe.

Pour des besoins de sécurité plus forts (avec les partenaires), un système de certificats pourra être mis en place.

Les Certificats

Un certificat constitue une carte d’identité numérique. Il permet de justifier de l’identité d’un individu ou d’une entreprise sur présentation de ce certificat. Il repose sur la certification de cette identité par une entité de certification reconnue.

L'habilitation

La gestion des habilitations consiste à accorder des droits à des utilisateurs identifiés. Les habilitations s’appuient donc sur l’identification et l’authentification. Celles-ci consistent à offrir un accès personnalisé ou restreint aux ressources du système d’information. On distingue :

• l'accès à des applications,

• l'accès à des services d’une application : cela est généralement géré au niveau de l’application,

• l'accès restreint selon les données : il est possible de considérer des restrictions sur les valeurs des variables (ex : contrôle des montants).

La définition des habilitations fait généralement appel à la notion de groupe d’utilisateurs. Les habilitations étant définies au niveau de chaque groupe et non directement au niveau des utilisateurs (il est plus aisé de définir un groupe "client" et d’y affecter les clients que de redéfinir les droits pour chaque client).

Du point de vue technique, deux types d’approches prédominent, il s’agit des habilitations déclaratives et programmatiques :

• Habilitations déclaratives : l’idée est de protéger l’accès à des ressources à travers un outil complètement externe à la ressource (fichiers, applications, site Web). Il s'agit d’habilitations déclaratives par paramétrage de l’outil et non de programmation dans une application.

• Habilitations programmatiques : l’idée est ici de restreindre l’accès par du code intégré aux applications à protéger. Il s’agit d’habilitations qui concernent des fonctionnalités non visibles hors de l’application. Cette approche est adaptée à des habilitations fines et généralement complexes qui vont concerner par exemple les valeurs des paramètres des applications.

è Les habilitations déclaratives de part leur caractère externalisable seront mutualisées. L’idée étant de pouvoir administrer dans un composant unique l’accès aux différentes applications d’un système d’information.

Intégrité et Confidentialité

Les garanties d’intégrité et de confidentialité sont généralement regroupées car elles font appels à des techniques similaires de chiffrement :

• La confidentialité consiste à s’assurer que les messages transmis ne peuvent être lus que par l’émetteur et le destinataire. C’est ce que font deux personnes qui s’échangent un message chiffré en utilisant une clé que seuls eux connaissent.

• L’intégrité consiste à s’assurer que le message n’a pas été modifié durant sa transmission et qu'il arrive bien au destinataire.

Pour ces deux services de sécurité, deux approches existent :

• L'utilisation d'un canal sécurisé et l'envoi des messages en clair sur ce canal. On fait confiance à une infrastructure de transport et à sa sécurisation pour acheminer le message (sessions SSL sur HTTPS). Cette approche correspond à ce que l’on fait en utilisant une ligne spécialisée : un canal opaque et résistant aux attaques est créé et les messages peuvent transiter en toute sécurité. Les inconvénients en sont le coût nécessaire à la construction du canal, et le manque de flexibilité.

• Le chiffrement des messages sur un canal non sécurisé. Dans une optique de communication sur Internet, les canaux TCP/IP seuls ne procurent pas en standard d’infrastructure autorisant la confidentialité et l’intégrité de messages qu'il faut rendre par de la cryptographie. C’est cette approche qui offre la plus grande souplesse, car elle permet d’utiliser tout canal de communication, en particulier Internet.

La confidentialité et l’intégrité reposent sur la cryptographie symétrique et asymétrique.

La non répudiation

La non répudiation consiste, lors d’un échange, à certifier au destinataire d’un message que l’émetteur est bien qui il dit être et à certifier à l’émetteur que le destinataire a bien reçu le message.

Il s’agit donc de rendre deux services :

• Un service de signature de l’émetteur du message : signature électronique.

• Les certificats X.509 offrent un mécanisme de signature certifiée par un tiers de confiance qui permet le chiffrement et la signature.

• Un service de garantie de livraison : accusé de réception.

• Il s’agit du recours à un tiers faisant office de notaire qui a pour charge d’archiver la transaction. Les protocoles notariaux de la PKI proposent ce genre de service.

Architecture PKI (Public Key Infrastructure)

La mise en place d’une architecture PKI est une décision :

• Coûteuse du point de vue des applications à mettre en œuvre, des certificats et éventuellement des supports, et également des compétences à acquérir que ce soit sous forme de services ou de compétences en interne.

• Complexe, car les mécanismes de gestion de certificats sont nombreux et nécessitent une grande rigueur.

Cloisonnement des environnements extranet et internet

Pour rendre étanche les systèmes d’information de l'Entreprise vis à vis de l’extérieur, l’architecture suivante est recommandée :

• Un premier firewall contrôle les accès de l’extérieur vers une DMZ (DeMilitarized Zone) contenant les serveurs Web frontaux des applications.

• La DMZ entre les pare-feu qui permet l’authentification des utilisateurs externe en interrogeant un serveur d’annuaire LDAP externe au contenu limité (ex : serveur RADIUS).

• Un deuxième firewall sépare la DMZ du système d’information de l'Entreprise,

• Les serveurs d’application sont placés derrière le deuxième pare-feu et peuvent donc accéder de manière sécurisée aux différents serveurs du SI ainsi qu’aux référentiels.

• La connexion entre les serveurs Web et les serveurs d'application est assurée par le Servlet Redirector sur port fixe avec le protocole IIOP. Un contrôle sur les adresses IP des serveurs est à prévoir.

• Le serveur d'application se charge de l’authentification utilisateur en interrogeant le serveur d’annuaire LDAP externe contenant les listes des clients déclarés pour les applications concernées. A noter que ce principe est identique pour les applications destinées aux collaborateurs de l'Entreprise par l’appel depuis l'intranet à un annuaire interne.

Pour des raisons de sécurité, le module d’administration des serveurs d'application, "normalement " placé sur les serveurs HTTP est repositionné sur un serveur HTTP placé dans le système d’informations de l'Entreprise. Les fichiers de configuration du plug-in et du servlet invoker sont mis à jour par l’administration sur les serveurs HTTP. Cette solution permet :

• De ne pas placer le Référentiel dans la DMZ (cette base est en effet critique car elle contient toute la configuration des ressources du serveur d'application).

• De ne pas ouvrir un flux SQL d'accès aux données sur le firewall protégeant le SI de l'Entreprise pour permettre un accès du serveur d’administration vers le Référentiel laissé en interne.

• Une communication entre les serveurs Web et les serveurs d'application s’appuyant sur IIOP ou SIIOP (tunneling de IIOP sur SSL). L’utilisation de SIIOP devra être validée par des tests approfondis étant donné les risques de chute des performances.

Il faut mettre en place des automatismes pour déposer les fichiers de configuration vers les serveurs HTTP pour garantir les mises à jour de ces fichiers.

L'annuaire LDAP

L’authentification d’utilisateurs internes (ou externes) d’un système d’information impose la gestion et le stockage d’un ensemble plus ou moins conséquent et complexe de données selon le mode faible ou fort d’authentification utilisé.

La meilleure solution de stockage est la technologie LDAP. La majorité des actions sur ce type de référentiel consiste à des accès en lecture, et LDAP est un standard de fait pour ce type d’accès.

Compte tenu du nombre élevé de partenaires et d'utilisateurs potentiels, il est impératif de mettre en place un contrôle des accès au Système d'information de l'Entreprise par un annuaire LDAP.

Une étude doit définir d'une part des profils d'utilisateurs (droits d'accès à certaines applications/transactions) et d'autre part des groupes d'utilisateurs auxquels sont associés des profils.

Pour des raisons de performance et de sécurité, il y aura un annuaire pour le personnel interne (l'Entreprise et partenaires) et un annuaire pour les utilisateurs Internet.

Les applications ayant besoin d'accéder à l'annuaire LDAP, devront le faire par le standard JNDI (Java Naming and Directory Interface).

Figure 10 L'accès à l'annuaire LDAP

Le composant annuaire des applications sera un EJB Session. Il est conseillé de standardiser ce composant annuaire afin d’être réutilisé par toutes les applications le nécessitant.

Par ailleurs, il est possible de configurer la sécurité interne avec :

• La sécurisation au niveau des utilisateurs pour l’accès aux pages Web et aux servlets,

• La définition de groupes d’utilisateurs partageant des droits d’accès communs,

• L’utilisation d’ACL (Acces Control List) pour la définition des droits aux groupes et aux utilisateurs,

• Enfin, la possibilité de définir des droits d’accès spécifiques à des fichiers ou des répertoires.

Ces informations sont stockées dans un annuaire LDAP (recommandé). La configuration de ces options de personnalisation est réalisée depuis la console d’administration de l'annuaire.

Infrastructure préconisée

Le schéma ci-dessous représente l'infrastructure matérielle et système préconisée.

Figure 11 L'infrastructure matérielle

Cette infrastructure permet de réaliser des montées en charge dues soit à des augmentations de fréquentations des sites (surtout Internet) soit à une croissance des partenariats et des filiales.

Architecture de déploiement

Le déploiement de l'architecture préconisée peut varier en fonction des impératifs de l'Entreprise et de ses filiales (localisation, réseau, performance, législation).

La figure ci-dessus, présente toutes les possibilités de déploiement offertes par l’architecture physique préconisée.

Elle s’articule autour d’un serveur central (mainframe) localisé, pour diverses raisons de coût, d’organisation, de réglementation ou techniques dans un pays. Un pays qui héberge un serveur central est appelé pays de type 1.

Un pays de type 1 héberge les serveurs frontaux UNIX qui gèrent les clients et partenaires du pays.

Un pays de type 1 peut également gérer plusieurs pays « satellites » qui peuvent être :

• de type 2, s'ls hébergent, pour diverses raisons de coût, d’organisation, de réglementation ou techniques, les serveurs frontaux ; ou

• de type, 3 s'ils n’hébergent pas de serveurs frontaux.

Eléments de l’infrastructure

Les divers éléments de l’infrastructure sont :

• les serveurs centraux avec leurs dispositifs de stockage et de communication ;

• les serveurs frontaux avec leurs dispositifs de stockage et de communication ;

• les postes de travail ;

• les différents dispositifs d’accès : terminaux points de vente, distributeurs de billets, guichets automatiques ;

• les terminaux 3270 réutilisés, le cas échéant ;

• l’infrastructure de communication, lignes, routeurs, utilisation d’opérateurs de télécommunications, incluant :

• les communications Intranet autour des serveurs centraux (en rouge dans la figure) ;

• les communications entre les systèmes centraux et les serveurs frontaux déportés (en bleu dans la figure) ;

• les communications entre les serveurs frontaux et les partenaires (en brun dans la figure) ;

• les communications entre les serveurs frontaux et les postes de travail ou les autres dispositifs d’accès (en vert dans la figure).