Architecture de Sécurité - coopérer pour protéger efficacement son SI. Les Appliances dans les Infrastructures SOA

Transcription

1 IT LA RÉFÉRENCE TECHNIQUE ON-LINE DES PROFESSIONNELS DE L'INFORMATIQUE Architecture de Sécurité - coopérer pour protéger efficacement son SI Les Appliances dans les Infrastructures SOA TOP5 des anti-patterns appliqués à l ESB Les visions dynamiques de l Architecte d Entreprise La gouvernance du patrimoine applicatif - optimisation de la qualité applicative Bimestriel - novembre/décembre 2010 Le Cloud Computing privé au service des métiers n 88

2

3

4 édito Délit de Pattern-IT Avec le souci de bien faire et de faire gagner du temps, les grands cabinets de consulting industrialisent leurs activités. Eux aussi? Eh oui! Partant du principe que copier les meilleurs avec les règles qui les font gagner fera forcément d une entreprise un leader, ils vendent à prix d or des best-practices. Attention, pas n importe lesquelles : fidèles aux grandes théories, aux référentiels et patati et patata. Et le plus beau? Tous les cabinets proposent des approches sectorielles annoncées comme les plus fiables et pourtant différentes. À croire qu ils les ont analysées dans des contrées très éloignées! Autre danger de taille, l enferment dans un carcan ne risque-t-il pas de brider l initiative et l innovation? Réponse admirable : On a aussi prévu l innovation! Concept étonnant de «l encadrement de la créativité»! Faut-il pour autant jeter le bébé avec l eau du bain? Certes non. Mieux vaut une approche trop structurante que rien. Et si elle n est pas trop exotique, elle restera adaptable. Toutefois, restez souples dans l application. Les décideurs auraient tort de s en remettre corps et âme à une unique approche psychorigide. De toute façon, la confrontation avec les réalités du terrain calme les ardeurs des plus rigoristes. Dans le cas contraire, préparez donc les chèques et l échec! José Diz Rédacteur en Chef IT LA RÉFÉRENCE TECHNIQUE ON-LINE DES PROFESSIONNELS DE L'INFORMATIQUE Editeur Press & Communication France Une filiale du groupe CAST 3, rue Marcel Allégot Meudon - FRANCE Tél. : Fax. : redaction@it-expertise.com Rédacteur en chef José Diz j.diz@it-expertise.com Directeur de publication Aurélie Magniez a.magniez@it-expertise.com Abonnements/Publicité abonnement@it-expertise.com Conception Graphique Nicolas Herlem Parution IT-expert - (ISSN ) est un journal édité 6 fois par an, par P&C France, sarl de presse au capital de ,61. Avertissement Tous droits réservés. Toute reproduction intégrale ou partielle des pages publiées dans la présente publication sans l autorisation écrite de l éditeur est interdite, sauf dans les cas prévus par les articles 40 et 41 de la loi du 11 mars P&C France. Toutes les marques citées sont des marques déposées. Les vues et opinions présentées dans cette publication sont exprimées par les auteurs à titre personnel et sont sous leur entière et unique responsabilité. Toute opinion, conseil, autre renseignement ou contenu exprimés n engagent pas la responsabilité de Press & Communication. Abonnements Vous pouvez vous abonner gratuitement sur 4 IT-expert n 88 - novembre/décembre 2010

5 IT-expert n 88 - novembre/décembre 2010 Sommaire 6 Dossier Architecture de Sécurité - coopérer pour protéger efficacement son SI A travers une démarche de dialogue entre les différents services de la DSI et les utilisateurs métier, l auteur propose une évolution des pratiques de gestion du changement. Un cadre de coopération qui s élabore progressivement pour que chacun s implique dans une vision globale. Un article très concret! 14 Technique Les Appliances dans les Infrastructures SOA Des boîtes noires au cœur des applications? Les appliances SOA prennent surtout en main les fonctions techniques de l infrastructure. Paramétrables et alignées aux politiques de l entreprise, elles l emportent souvent sur une solution logicielle. Encore faut-il choisir en connaissance de cause. 19 Technique TOP5 des anti-patterns appliqués à l ESB À contre-courant des innombrables guides de bonnes pratiques, Claude-Emmanuel Drexler (responsable de l offre ESB chez Logica Business Consulting) distille avec humour et professionnalisme issus de son expérience de terrain. Instructif et éclairant! 24 Actualités Internationales Les informations marquantes d éditeurs, de marchés, d organisme de standardisation, de débats en cours et de tendances. 28 Comment ça marche? Les visions dynamiques de l Architecte d Entreprise En quoi l aspect «transformations» des SI et des organisations favorise-t-il une vision globale de l entreprise et comment cela contribue-t-il à une représentation compréhensible et utile des chaînes de valeur? Le point de vue éclairé d un spécialiste. 36 Quoi de neuf docteur? La gouvernance du patrimoine applicatif - optimisation de la qualité applicative Lætitia Bardoul, Senior Analyste pour le CXP, défriche concrètement le terrain de la gouvernance applicative. Une occasion d y voir plus clair dans ces concepts surutilisés, et de comprendre comment se positionnent les divers modules, ainsi que les éditeurs spécialisés. 41 Livres Expression des besoins pour le système d information d Yves Constantinidis et Moderniser son système d information de Sabine Bohnké. 42 Rubrique à brac Le Cloud Computing privé au service des métiers Les technologies et innovations du cloud computing peuvent aussi se décliner dans l infrastructure de l entreprise. Ainsi, la DSI passe du rôle de fournisseur de moyens à celui de fournisseur de services en proposant enfin le modèle «Self Service», aboutissant au catalogue de service personnalisé. IT-expert n 88 - novembre/décembre

6 Architecture de Sécurité Coopérer pour protéger efficacement son SI Pourquoi établir un mode de coopération plus mature entre la sécurité des SI, la DSI et les métiers? Tout simplement pour anticiper les besoins métiers, participer à l élaboration de propositions IT et concevoir une architecture de sécurité d entreprise efficace. L objectif ultime visant à préserver et à protéger ce patrimoine immatériel de l entreprise. Une démarche plutôt centrée sur la dynamique d évolution de l architecture de sécurité que sur un modèle générique utilisable pour toute entreprise. 6 IT-expert n 88 - novembre/décembre 2010

7 Dossier Un environnement en mutation permanente Le besoin croissant d échanges d informations fiables au sein de l entreprise et au-delà de ses frontières, la création de nouveaux espaces stratégiques et de «business models» reposant sur la collaboration entre partenaires et compétiteurs internationaux, la mutation vers une économie numérique mondiale autant de préoccupations qui ont transformé la sécurité de l information en enjeu stratégique majeur. Le lien est désormais direct entre les évolutions permanentes des entreprises, les systèmes d informations et la sécurité de l information. En effet la plupart des projets de transformation d entreprise impactent directement le système d information. Deux cas se présentent : soit la transformation de l entreprise a un impact sur le système d information existant peu évolutif. Dans ce cas, le système d information est identifié comme un des freins aux évolutions (fusion d entreprise, acquisition, séparation, filialisation ) ; soit le système d information sert de moteur à la transformation de l entreprise (lancement d un site E-commerce, usage du multicanal, lancement de nouveaux services clients ). Dans les deux cas, l anticipation et l adaptabilité du système d information restent essentiels. Ces changements génèrent ainsi de nouveaux défis pour la sécurité des systèmes d information, tant technologiques et réglementaires, qu organisationnels. De nombreuses évolutions ou innovations technologiques impactant déjà la sécurité des SI, parmi lesquelles : Le Cloud Computing : l arrivée de nouveaux modèles de consommation de services et d infrastructures informatiques nécessite de gérer différemment la sécurité des systèmes d information. En effet, si les différentes formes du Cloud Computing privé, public, IaaS, PaaS, SaaS impactent différemment la sécurité des SI, il semble cependant que les différents modèles vont coexister dans l entreprise. Charge aux acteurs de la sécurité de définir les principes, les guides et les règles d usage des composants et des données, pour garantir l interopérabilité et la sécurité de l information. L ouverture des SI : l idée consiste à identifier les limites de l approche périmétrique qui ne permet plus de garantir la fluidité des échanges et l agilité requise au SI tout en donnant une fausse impression de sécurité. Il s agit plus de redéfinir les frontières que de les supprimer. Or, redéfinir régulièrement les frontières est une œuvre de plus en plus collective, qui repose sur une vision systémique et architecturale du système d information. Les systèmes industriels : les composants informatiques utilisés au sein des systèmes industriels sont désormais basés sur les standards du marché informatique, avec leurs avantages (coûts, pérennité, compétence), mais également leurs règles et contraintes (rythme des versions, anomalies, vulnérabilités, menaces). Il s agit d un nouveau champ d action pour la sécurité des SI, qui nécessite d appréhender une fois encore la sécurité, avec une approche coopérative et architecturale des systèmes industriels. Les objets communicants : il s agit d anticiper les nouveaux usages d Internet et des objets (des téléphones jusqu aux puces communicantes) et de positionner la sécurité comme un facilitateur, afin d anticiper la sécurisation des données réparties, les interactions avec l existant et les contraintes réglementaires. Le Challenge vise donc à positionner efficacement la sécurité des SI sur le chemin de la transformation, mais également de construire au sein de l entreprise cette capacité de transformation. En effet, plus que de transformer et de sécuriser le SI, les entreprises ont besoin de construire de façon durable une capacité collective à se transformer. C est pourquoi certaines grandes entreprises et administrations mettent en place un cadre de coopération, avec pour objectif d organiser la dynamique d évolution du Système d Information. L architecture de la sécurité d entreprise en fait partie. Formaliser un cadre de travail pour l architecture de sécurité Comment mobiliser les énergies pour créer la dynamique d évolution? Cette démarche vise à permettre un dialogue équilibré entre les acteurs différents (métiers, utilisateurs, architectes, réalisateurs, exploitants et sécurité), à faire émerger des propositions, à prendre des décisions et à les exécuter par consentement, à conduire les évolutions d architecture. Autant de défis qui nécessitent de changer les pratiques de management des transformations. La clé pour concrétiser et inscrire ces intentions dans la durée est de mettre progressivement en place un cadre de coopération permettant à chacun de contribuer dans une vision globale, de capitaliser et de diffuser les règles au sein des projets. Les pratiques de la sécurité des SI et l architecture de sécurité d entreprise Quand on parle de sécurité des systèmes d information, on évoque plusieurs aspects : Le management de la sécurité de l information (politique de sécurité, gestion du risque), L architecture et l expertise des composants contribuant à la sécurité (IAM, PKI, Firewalls ), La sécurité opérationnelle (gestion quotidienne de la sécurité, exploitation de la sécurité). La sécurité opérationnelle consiste à mettre en œuvre les processus définis pour assurer la sécurité de l information. Par exemple, l organisation d audits, l attribution de droits, la configuration des firewalls ou l analyse régulière d indicateurs. Cette activité est en lien direct avec le management de la sécurité qui s assure que la sécurité opérationnelle est correctement exécutée. L alignement de la sécurité opérationnelle sur la gestion des risques de l entreprise est alors fondamental. IT-expert n 88 - novembre/décembre

8 Le management de la sécurité met en œuvre la gestion des risques visant à assurer que le niveau de sécurité reste en ligne avec la stratégie de l entreprise, et à initier les projets nécessaires. Il revient aussi au management de la sécurité de l information d assurer le suivi régulier des actions, et d élaborer les évolutions nécessaires. Les apports de l architecture s évaluent au regard de la complexité, de l impact de l existant, et du nombre de chantiers de transformation de l entreprise. Il est en effet souhaitable que la sécurité soit prise en compte à tous les niveaux de l architecture de l entreprise. Le moyen de s en assurer est d intégrer la sécurité comme un des éléments de la vision, des phases de conception, mais également d accompagner les projets par des moyens adhoc (mise à disposition de composants, de modèles, d expertises). L Architecture de Sécurité d Entreprise (ASE) assure la cohérence entre ces trois activités de la sécurité des SI et les projets de transformation de l entreprise. En effet, il ne s agit pas de proposer et réinventer une nouvelle méthode ou un énième modèle révolutionnaire, mais bien de mettre en place ou de renforcer un cadre d architecture proposant un ensemble d éléments et méthodes pour construire, représenter et analyser les systèmes de l entreprise. Un cadre de coopération d architecture de sécurité d entreprise propose trois composantes : 1. un référentiel d Architecture de Sécurité d Entreprise 2. le processus de pilotage de la transformation 3. le cadre de capacité de transformation Le référentiel d AE et sa déclinaison ASE Le référentiel regroupe les prescriptions d architecture, les composants réutilisables... Il couvre aussi bien la définition des prescriptions elles-mêmes que leurs modalités d évolution ou encore la manière de les communiquer et de les publier. En complément de la modélisation descriptive du SI, le référentiel ajoute les règles, les principes et les composants fonctionnels et techniques qui organisent la modularité et favorisent l assemblage et l intégration des sous-systèmes. La construction collaborative du référentiel passe par un équilibre entre des initiatives «centralisées» et un enrichissement de ce référentiel au fil des projets et des usages locaux. En s appuyant sur un référentiel commun, les sous-systèmes ainsi représentés sont assemblés pour donner une vision instantanée, à jour, et cohérente, du système d information et de sa sécurité. Le référentiel d AE s impose ainsi comme un outil de capitalisation, de communication et d échange entre les parties prenantes. Il facilite la compréhension des différents points de vue, l analyse de scénarii et des dépendances, le partage d information ; il permet l émergence de solutions dans la coopération et non dans l opposition. Il appartient aux architectes d en expliquer et d en faciliter l usage. Principes, Vision, Exigences d Architecture Phases préliminaires Vision d architecture Stratégie Métier - Stratégie Technique Moteurs - Acteurs Exigences - Hypothèses - Ecarts Architecture Business Motivation Organisation Fonction S É C U R I T É Architecture des systèmes d informations Données Application S É C U R I T É Architecture Technique Services de Plateformes Composants Techniques S É C U R I T É Opportunité, Solution, Planification Réalisation de l architecture Gouvernance de la réalisation Figure 1 : le référentiel d ASE 8 IT-expert n 88 - novembre/décembre 2010

9 Le processus de pilotage de la transformation Si la transformation de l entreprise passe par l alignement des projets locaux sur les objectifs locaux, elle doit également garantir la cohérence des projets par rapport aux principes d entreprise, dont la sécurité. Il est donc essentiel d identifier et de différencier le processus d évolution de la politique et du référentiel d entreprise, et le processus d alignement des projets unitaires, sur leurs objectifs propres dans le respect des règles d entreprise. Réussir la transformation Parmi les éléments essentiels, on retrouve le référentiel, les principes de gouvernance, mais également les compétences à renforcer et l organisation à mettre en place. Bâtir une capacité d architecture : volet compétence Structurer l organisation Processus Référentiel Développer et entretenir les compétences individuelles et collectives Rôles et Responsabilités Grille de Compétences Formation Cursus Parcours Déployer la transformation cible Référentiel Architecturer la transformation Evaluation Coaching Monitorat Projets de la transformation existant Gouvernance Gouverner la transformation Les points de vue Instruire l architecture Cadrer la transformation Figure 3 : cadre de capacité (source Arismore) L Architecture de Sécurité d Entreprise, s articule autour de la gestion des exigences, afin de capturer les besoins métiers, de diffuser les principes de sécurité de l entreprise, et de gérer de façon cohérente l ensemble. Figure 2 : processus de transformation ASE (Source Arismore) Le schéma ci-dessus présente le processus permettant d identifier les besoins et de définir une cible, une trajectoire, un plan de route et des moyens associés, d une part, et le processus d ancrage des projets, d autre part. Le cadre de capacité de transformation Au-delà des éléments techniques et opérationnels décrits dans les deux items précédents, l apport réside également dans sa dimension managériale et humaine : le cadre et sa capacité à se transformer. Ce cadre recense les actifs à mettre en place et à maîtriser pour faire de l architecture un levier de transformation et de sécurisation de l entreprise. Une exigence exprime ce qu un système devra être ou faire et les propriétés qu il devra avoir. L ingénierie des exigences est une activité essentielle pour la fourniture d un système (vue du fournisseur) et son acquisition (vue de l utilisateur ou du client). Elle permet de réduire les coûts et délais de réalisation tout en améliorant la qualité et la sécurité. En effet, une exigence définit ce qu un système (ou un produit ou un service) devra être ou devra faire (vue fonctionnelle) et les propriétés qu il devra avoir (vue non fonctionnelle) pour répondre aux buts fixés par les acteurs. Une exigence exprimée ne sera pas nécessairement satisfaite. Mais cela permettra justement de tracer la nonsatisfaction, ce qui réduit l implicite à l origine de nombreux conflits et blocages. L ingénierie des exigences est une activité qui s applique tout au long du cycle de vie d un produit, d un service ou d un système. Elle ne se limite pas aux phases initiales d analyse et de conception, même si l essentiel de l effort peut être réalisé lors de ces phases. IT-expert n 88 - novembre/décembre

10 Ainsi l ingénierie des exigences est l ensemble des activités consistant à : collecter et expliciter les besoins, attentes, contraintes et interfaces des parties prenantes pour toutes les phases du cycle de vie du système ; analyser et valider les exigences ; établir des scénarii pour satisfaire au mieux les exigences en fonction des contraintes ; gérer le suivi (changement, suppression, création) et la traçabilité (date de changement, auteur du changement ) des exigences ; assurer les arbitrages entre les exigences en fonction des contraintes ou pour résoudre des contradictions entre exigences ; valider la cohérence entre le système réalisé et les exigences. Une exigence ne contient pas d information concernant le design ou la conception du système. Elle exprime ce que le système devra être et non pas comment il devra être réalisé. Pour une même exigence, plusieurs solutions de design et conception sont possibles. Bien utilisée, cette démarche devient le moteur pour construire le cadre de l architecture de sécurité d entreprise. Comment mettre en place un cadre de coopération? La mise en place des pratiques d architecture de sécurité d entreprise s appuie sur une structuration des activités opérationnelles d architecture sous la forme de six thèmes. La trajectoire : contribution à la trajectoire de transformation d un Système d Informations ou d un domaine. Il s agit de construire une trajectoire d évolution basée sur une analyse des écarts entre une cible et un existant, suivie de la planification des projets alignés sur les exigences. Le référentiel d architecture et de sécurité : construire et capitaliser sur un cadre contenant les prescriptions d architecture, les principes de sécurité, la modélisation ou cartographie du SI. La gouvernance : enrichir les processus et les instances contributives permettant de gouverner la mise en œuvre de la trajectoire et l alignement des projets. Les projets : communiquer auprès des métiers et accompagner les projets au bon usage du référentiel avec une démarche de bout en bout depuis les phases avant-projet (opportunité, faisabilité) jusqu au déploiement. Le cadre de capacité : renforcer les capacités de l entreprise en agissant sur les pratiques, l organisation, les compétences, la conduite du changement et la communication. La Gestion des identités et des accès, un cas concret L un des blocs types de sécurité s inscrivant globalement dans une Architecture de Sécurité d Entreprise est la gestion des identités et des accès. En effet, une telle infrastructure permet de répondre à divers objectifs : réduire le niveau de risque récurrent dans les entreprises concernant la gestion des identités ; s inscrire dans les bonnes pratiques de la sécurité telles que définies dans la famille ISO 2700x ; concourir au respect des contraintes réglementaires métiers ou financières ; proposer un service transverse de sécurité concourant à une ouverture sécurisée du SI vers l extérieur ; prendre en compte les nouvelles architectures liées au Cloud Computing et à la mobilité ; offrir un catalogue de services permettant d offrir de nouveaux services métiers tout en répondant à la problématique du «Time to Market» ; apporter un plus grand confort aux utilisateurs finaux ; améliorer la qualité des processus supports ; bénéficier d un retour sur investissement au regard de la couverture du SI (applications et infrastructures) et des populations utilisatrices. Une infrastructure globale de gestion des identités fournit différents services à différentes populations : employés, partenaires, fournisseurs, clients (cf. figure 4 page suivante) L infrastructure de gestion d identité permet de rendre le SI plus performant, plus agile et plus sécurisé tout en répondant à des contraintes réglementaires (conformité). Toutefois un projet de gestion des identités et des accès réunit diverses parties prenantes (ressources humaines, services généraux, métiers, SI, sécurité ) avec différents points de vue et qui viseront chacun des bénéfices spécifiques. Répondre à ces usages et aux besoins de ces différentes populations passe par la mise en œuvre de processus optimisés et outillés : gestion du cycle de vie de l identité, gestion du cycle de vie des rôles, gestion des ressources, gestion du risque. La mise en œuvre de ces processus nécessite la définition de services transverses. 10 IT-expert n 88 - novembre/décembre 2010

11 Dossier gestion de l identité : réconciliation avec des sources autoritaires, processus d approbation, self-services provisioning : synchronisation avec les bases utilisateurs dans le SI ; gestion des rôles : lien entre l utilisateur et les ressources autorisées dans le SI. En effet, le rôle doit être géré au même titre que les autres objets ; en effet, le rôle peut être impacté par la vie propre des applications, la transformation du métier de l entreprise contrôle d accès : authentifier et autoriser l utilisateur pour une ressource ; fédération d identités : partager des données d identité entre des organisations indépendantes les unes des autres (cercles de confiance) ; audit : capacité à tracer les actions réalisées dans les services précédents et à présenter un reporting en fonction du profil de consultation. Pour que ces services soient fonctionnels, il est nécessaire de s appuyer sur différents référentiels (identités, habilitations, ressources ) et différents principes (architecture et sécurité). La réalisation d un tel projet ne peut se faire que dans le cadre d une démarche collaborative réunissant les différentes parties prenantes afin de définir : les exigences liées au projet ; les besoins auxquels il doit répondre en fonction des populations utilisatrices ; les modèles d architecture permettant de répondre à différents cas d usage afin de construire un catalogue de services ; la planification dans le temps de la mise en œuvre au regard des services envisagés et au regard de la gouvernance du SI (mise en œuvre parallèle de programmes métiers) ; la capitalisation des savoir-faire. Le cadre de collaboration et le projet de gestion des identités et des accès se complètent avantageusement. En effet, les services de gestion des identités et des accès enrichissent l architecture de sécurité d entreprise et, de ce fait, le référentiel. Quant au projet, il profite de la modélisation, du référentiel, du processus d évolution, et du processus d ancrage pour le raccordement des applications, l ingénierie des exigences ( ) proposé par le cadre de coopération. Les initiatives de l Open Group et du SABSA Institute L Open Group, a lancé plusieurs initiatives pour construire un cadre de coopération pour la sécurité, à travers plusieurs forums ; L architecture Forum Le Security Forum Le Jericho Forum TOGAF (The Open Group Architecture Framework) est un cadre d architecture d entreprise collaboratif permettant le partage de points de vue entre les parties prenantes de l entreprise, pour agir dans l intérêt collectif. Usage et parties prenantes Principes Acteurs du SI Utilisateur RH Métier RSSI Performance Conformité Sécurité Sécurité Référentiels Informations Processus Gérer le cycle de vie des utilisateurs et des rôles Gérer les ressources Gérer le risque SI Personnes Identités Processus Architecture Contrôle d accès Gestion des identités Fédération Audit Provisioning Gérer les rôles Figure 4 : la Gestion des Identités et des Accès (Source Arismore) IT-expert n 88 - novembre/décembre

12 COA (Collaboration Oriented Architecture) du Jericho Forum apporte un cadre de travail pour l ouverture des Systèmes d Information, avec une vision besoin des entreprises. Le SABSA (Sherwood Applied Business Security Architecture) du SABSA Institute est un cadre d architecture de sécurité d entreprise qui, au-delà des modèles et de la gestion du risque, introduit une méthode intéressante pour capturer les exigences (Business Attribute Profile). A la demande des partenaires de l Open Group, un groupe composé de membre de l Open Group (Security Forum et Architecture forum) et du SABSA Institute, travaille sur des initiatives de rapprochement comme l utilisation de pratiques communes pour la gestion des exigences et la mise à disposition de composants d architecture (vues, building blocks, artefacts). Pour les entreprises françaises, il est possible d enrichir progressivement leurs propres cadres des bonnes pratiques présentées en cohérence avec le système de gestion de la sécurité de l information proposé en se référant aux normes ISO 2700x. En effet, l accompagnement des projets de transformation de l entreprise et la contribution aux initiatives nationales et internationales sont d excellents moyens de valoriser et professionnaliser les métiers de la sécurité des SI. n A noter L Open Group a également créé un nouveau forum Trusted Technology Forum pour travailler sur la gestion de la chaîne d approvisionnement afin de garantir la sécurité des matériels et des logiciels achetés par les gouvernements et les grandes entreprises commerciales. Le cadre (Technology Provider Framework) ainsi initié fédère les bonnes pratiques à destination des fournisseurs afin de les aider à garantir la sécurité de leurs produits. Gilles Castéran, Directeur Associé d Arismore Arismore est une société innovante en conseil et intégration qui accompagne la transformation et la sécurisation des systèmes d information des grandes entreprises et des administrations. Avec un chiffre d affaires de 11 millions, Arismore est devenu le spécialiste en France de l Architecture d Entreprise et de la Gestion des accès et des identités. Site web : 12 IT-expert n 88 - novembre/décembre 2010

13 IDC vous donne rendez-vous mercredi 19 janvier 2011 (9h 14h) CONFERENCE IDC : OPTIMISER SA STRATEGIE DE SOURCING Insourcing, outsourcing, nearshore, offshore, Cloud Computing : comment tirer le maximum des différents modèles? Le DSI doit prendre en considération les objectifs stratégiques de l entreprise mais aussi les objectifs tactiques des différentes entités métiers. La réactivité de la DSI, couplée à la qualité de services rendus aux directions métiers sont deux critères essentiels aujourd hui. La question qui se pose alors est bien : Quelle stratégie de sourcing est la mieux adaptée à mon entreprise? La question est complexe et n appelle pas une réponse unique, d autant plus que les modèles à disposition des DSI sont toujours plus nombreux : tout réaliser en interne?, insourcing? outsourcing?, onshore? nearshore?, offshore?, Cloud Computing? Tous ces modèles sont ou seront présents dans les entreprises et il devient très important de faire les bons choix de modèles de delivery pour les bonnes «briques» du système d information. De plus, il faut être en mesure de d optimiser l ensemble sans créer de silo ou de point de friction. La politique de Sourcing Au programme : Mesurer les enjeux et la création de valeur pour l entreprise : réduire les coûts, gagner en flexibilité et libérer des ressources pour investir dans de nouveaux projets ou de nouveaux modèle économiques Conférence organisée par IDC Différents modèles et solutions de global sourcing Définir une politique de sourcing adaptée et adaptable à la transformation de l entreprise et garante de l optimisation de l infrastructure et des applications Le Cloud Computing Gagner une longueur d avance vers l étape ultime de l externalisation? IDC, cabinet leader de conseil, et d études dans les technologies de l information en partenariat avec Avec le retour d expérience de : Bertrand ETENEAU DSI Faurecia Yann BEYNoN DSI RoCHE Gael DoMINIQUE Direction des achats Groupe ToTAL Stéphane CoRDIER DSI Alliance Healthcare France Participez à la conférence IDC Stratégies de Sourcing le 19 janvier 2011, à Paris pour : dresser le bilan et faire le point sur les différents projets mis en place à ce jour. analyser ensemble quelles sont les bonnes pratiques, quels sont les leviers opérationnels et technologiques à votre disposition. faire les bons choix de modèles de delivery pour les bonnes «briques» du système d information. PROGRAMME DETAILLE ET INSCRIPTION GRATUITE : code invitation «ITX» ou contacter Edith Tricheux etricheux@idc.com - tel. :

14 Les Appliances dans les Infrastructures SOA 14 IT-expert n 88 - novembre/décembre 2010

15 Technique Infrastructures SOA et trafic XML La consommation grandissante des flux XML dans les infrastructures informatiques ne permet plus d envisager la solution logicielle comme étant l unique possibilité offerte pour traiter ce type de flux. En effet, les traitements sur les flux XML sont de plus en plus complexes et nombreux. Ils nécessitent des capacités de mémoire et de traitements importants, pour réaliser des fonctionnalités purement techniques et qui n apportent aucune valeur ajoutée aux applications métiers des entreprises. Des traitements variés liés aux contenus XML Il s agit principalement des traitements tels que : Transformation, adaptation de contenu Extraction, filtrage de données Validation des messages XML Chiffrement et déchiffrement de données XML Signature digitale et vérification de signature dans des documents XML Cette consommation de flux XML est liée en partie à l adoption désormais constatée des services Web au sein de l informatique de nombreuses entreprises. Concernant les flux de type services Web SOAP (Simple Object Access Protocol), les traitements XML concernent également l utilisation des standards Web-Services aboutis, quels qu ils soient : WS-Reliable Messaging WS-Addressing WS-Trust WS-Security WS-Policy Les applicatifs doivent réaliser des traitements visant à garantir la sécurité des applications et programmes qui consomment les contenus XML. En effet, les menaces XML sont relativement simples à créer et pénalisent lourdement les victimes de telles attaques. Parmi les plus classiques, on notera par exemple : Les dénis de service XML ou «XDoS» (XML Denial of Service) L accès non autorisé à des services La compromission de systèmes informatiques (XML Virus) Les attaques visant la confidentialité et l intégrité des données Outre ces contrôles sur les contenus, les applicatifs doivent réaliser d autres traitements techniques, distincts de toute logique métier. On notera par exemple : La gestion des habilitations pour l accès aux services de l infrastructure SOA, Les ruptures protocolaires parfois nécessaires, Le routage technique ou fonctionnel de l information, L exposition et le management des services, permettant par exemple de lisser le trafic ou le rejeter si le seuil d accès vers un service est dépassé (de manière générale ou pour un utilisateur en particulier). Le besoin de performance et de sécurité Les appliances (SOA Service Oriented Architecture) ont pour principal objectif de supporter des fonctions techniques clés de l infrastructure SOA de manière à garantir la pérennité des applications et des fournisseurs de services. Parce que les contrôles et traitements précités doivent être effectués en minimisant l impact sur les performances de l infrastructure SOA et en garantissant sa sécurité, une solution logicielle ne peut pas être envisagée à la différence d une approche par «appliance». Les appliances consistent en des équipements de type «réseau», dédiés à des traitements applicatifs plus ou moins étoffés selon les gammes proposées par les principaux éditeurs du marché. Les appliances SOA incarnent une déclinaison particulière de cette offre dans le sens où elles sont capables d effectuer des traitements et contrôles spécifiques aux services Web sur des trafics tels que SOAP, XML/RPC ou REST (Representational State Transfer). Des appliances à caractère technique Une appliance SOA est constituée d un équipement matériel qui embarque un microcode (ou «firmware»), élément indispensable et optimisé, qui porte l ensemble des possibilités de traitement offert par l appliance SOA considéré. Cette approche simplifie considérablement l installation, le déploiement et l évolution de l infrastructure SOA basée sur ce type de composant. En outre, elle opère une séparation claire entre les fonctions techniques et métiers, étant précisé que les appliances SOA n ont pas pour vocation de supporter quelque logique métier que ce soit, mais de prendre en charge des fonctionnalités exclusivement techniques. De plus, une appliance est un système configurable et non pas programmable ; il offre dans la plupart des cas des interfaces multiples (commande en ligne et interface graphique par exemple) permettant d implémenter les configurations requises. Ce mode d implémentation masque la complexité des spécifications et protocoles, en synthétisant les informations requises. La fourniture d interfaces de configuration diverses permet d adresser un large public : opérateurs réseau : installation physique et paramétrage réseau de l appliance, responsables sécurité : configuration des politiques de sécurité (contrôle d accès, menaces XML, protection des serveurs d arrière-plan ), architectes et développeurs : définition et implémentation des services. Par rapport aux menaces XML, il existe deux approches concernant les appliances SOA : 1. l approche positive consiste à rejeter, par défaut, toutes les attaques existantes. Il est cependant possible de diminuer le niveau des contrôles effectués. IT-expert n 88 - novembre/décembre

16 2. l approche négative consiste à n effectuer aucun contrôle de sécurité. Ces contrôles sont configurés au cas par cas, selon les besoins de sécurité. Un retour sur investissement très avantageux Une autre caractéristique intéressante des appliances SOA, leur excellent retour sur investissement. Les différents coûts à envisager pour effectuer une comparaison entre une appliance et une solution logicielle équivalente sont les suivants : coûts de l infrastructure opérationnelle complète ; coûts des développements d applications et de maintenance de la solution ; coûts d acquisition des produits ; charges de maintenance des produits ; coûts d installation et de déploiement. L ensemble de ces coûts est bien plus important avec une solution logicielle, car celle-ci nécessite plus de ressources (humaines, logicielles et matériels) dans l ensemble des phases de réalisation d un projet SOA. Où positionner ces appliances? Les appliances SOA se positionnent principalement en frontal des fournisseurs de services et des applicatifs de manière plus générale. Ils sont alors capables de : garantir la sécurité interne ; s intégrer avec des applicatifs de type legacy, via des connecteurs dédiés : dans ce cas, l appliance SOA doit pouvoir effectuer des transformations sur des contenus autres que XML. Autre positionnement possible : au sein de la DMZ (zone démilitarisée). Dans la mesure où ils sont capables de satisfaire à des niveaux de certification ou des critères de sécurité permettant leur utilisation dans cette zone particulière de l infrastructure d une entreprise. La rupture protocolaire opérée en DMZ par l appliance SOA est une garantie nécessaire de sécurité. Le fait d embarquer un microcode dans l appliance renforce également la sécurité dans la mesure où cette approche empêche tout développement de script ou ajout de modules supplémentaires à la solution qui pourrait impliquer de potentielles failles de sécurité. Ainsi, une appliance SOA embarque un microcode offrant au final une solution configurable complète, à la différence d une solution logicielle basée sur un serveur, sur laquelle un développement spécifique doit être implémenté et maintenu. DMZ Appliance SOA Web-Services Consommateurs Internes D une manière générale, une appliance SOA est gérée comme un équipement réseau traditionnel à l inverse d une solution basée sur plusieurs serveurs dont les coûts de gestion et de maintenance sont sans commune mesure. Web-Services Consommateurs Externes SOAP/HTTP(S) IP Firewall Appliance SOA IP Firewall SOAP/HTTP(S) Web-Services Fournisseurs Une intégration simplifiée à l infrastructure SOA L intégration des appliances dans l infrastructure SOA est facilitée, car elle se base sur des standards et spécifications. En effet, si les composants logiciels avec lesquels doit s intégrer l appliance utilisent des APIs ouvertes (basées par exemple sur SOAP ou REST), ou des protocoles d échange standardisés, alors l intégration est facilitée et s en trouve considérablement accélérée. Voici quelques exemples : les principaux registres et référentiels de services offrent, en plus d UDDI, des interfaces SOAP/REST permettant la récupération de métadonnées relatives aux services, à partir d une appliance SOA ; les scanners antivirus offrent une intégration possible via ICAP (Internet Content Adaptation Protocol), permettant à une appliance SOA de transmettre les attachements des messages SOAP et de rejeter tout contenu infecté par un virus. Un tel positionnement en DMZ est envisagé lorsqu une appliance SOA est utilisée pour exposer des services (on parle également de «virtualisation» des services) à des partenaires externes à l entreprise. Dans ce cas, elle est utilisée pour détecter et contrer les éventuelles attaques XML, mais également pour contrôler les accès aux différents services via des politiques de sécurité spécifiques. Ces politiques se basent sur des composants externes à l appliance (tels que des annuaires LDAP par exemple) afin de renforcer des contrôles d authentification et d autorisation vis-à-vis des services fournis. On parle alors de passerelle de sécurité externe (ou interne) ou encore de point de passage unique du trafic des services Web. En fonction des appliances SOA, il est possible de les interfacer avec une solution de gouvernance et de gestion du cycle de vie des services (registre de services) afin d alimenter les services de virtualisation à l aide des contrats d interface des fournisseurs de services. 16 IT-expert n 88 - novembre/décembre 2010

17 Technique La possibilité d intégration avec les registres et référentiels de service est un point déterminant dans le choix d une appliance SOA. Un cadre normalisé et standardisé en zone SOA L un des principaux intérêts des appliances SOA est qu elles fournissent un cadre normalisé pour le traitement des flux de type Web-Services. Le point de passage unique qu elles constituent rend impossible le transit de flux qui ne respectent pas strictement les politiques de contrôle configurées sur ces solutions. Des échanges B2B fluides et sous haute sécurité Le RSSI d une société décide que tous les flux Web- Services en provenance de partenaires externes doivent : 1. utiliser le protocole HTTPS en authentification mutuelle, ce qui permet d identifier l application consommatrice du service, 2. utiliser un jeton de sécurité de type «UserName Token», permettant l identification des utilisateurs et le contrôle d accès aux services, et respectant la version 1.1 de la spécification WS-Security, 3. transmettre un flux valide, c est-à-dire qui respecte strictement le contrat d interface établi lors de la conception du service. Un partenaire externe à l entreprise et souhaitant consommer un service devra donc satisfaire à l ensemble des exigences, traduites sous forme de configuration au niveau de l appliance. Si une seule des conditions précitées n est pas respectée, alors l appliance SOA rejettera la requête du consommateur sans que cela n ait d impact sur le fournisseur du service qui n a à aucun moment été sollicité. Cette normalisation permet également aux entreprises d exposer de nouveaux services internes de manière optimisée. En effet, les responsables de l infrastructure SOA sont en mesure d exprimer des règles simples aux fournisseurs de services internes (équipes de développement) et d établir en quelque sorte les prérequis indispensables pour l exposition d un nouveau service sécurisé. Par exemple, l équipe d infrastructure SOA peut exiger que le contrat d interface (fichier WSDL du service) soit conforme avec la spécification «WS-Interoperability Basic Profile 1.0/1.1». Vis-à-vis des consommateurs du service, elle peut imposer une limite d utilisation du service par utilisateur, par consommateur ou commune à l ensemble des consommateurs du service. Les appliances SOA permettent évidemment d effectuer les contrôles de sécurité internes à l instar de ceux effectués pour les partenaires externes (détection et rejet des menaces, contrôle d accès, filtrage de données entrantes ou sortantes ) sachant que les attaques XML sont encore principalement exécutées par des utilisateurs internes aux entreprises. Monitoring de l infrastructure et des appliances SOA Les possibilités de monitoring offertes par SNMP permettent la supervision des appliances SOA et la récupération de métriques techniques diverses : usage CPU, consommation mémoire, nombre de connexions Le monitoring des services (Web- Services, services REST et XML) est également possible en utilisant des standards tels que WS-Management ou WS- Distributed Management, l idéal étant de pouvoir influer sur le registre des services à partir de la solution de monitoring, en fonction des données supervisées sur les appliances SOA. Ainsi, un consommateur peut être autorisé à consommer un service n fois par semaine. Si ce seuil est dépassé, il peut être nécessaire de fournir un service équivalent à ce consommateur, mais en mode «dégradé» (les informations retournées par le service pourraient dans ce cas être moins pertinentes). Si on considère les différentes briques de l infrastructure SOA que sont : l appliance SOA, le registre de gouvernance des services, la solution de monitoring des services ; Il est alors possible de mettre en place une solution à partir de laquelle la brique de monitoring sera alertée par l appliance d un dépassement de seuil, ce qui lui permettra de modifier la destination du service - pour le consommateur spécifique - au niveau du référentiel des services. L appliance SOA sera alors en mesure de router le consommateur vers le service «dégradé», sans intervention d un opérateur sur la solution de registre et sans modification ni du consommateur ni de la configuration de l appliance SOA. Web-Services Consommateurs Registre SOA SOAP/HTTP(S) Appliance SOA Monitoring Web-Services SOAP/HTTP(S) Web-Services Fournisseurs Au niveau de la solution de monitoring, l idéal est de pouvoir superviser l ensemble des intervenants : appliances et services, de manière à bénéficier d une vision globale de l infrastructure SOA au run-time. IT-expert n 88 - novembre/décembre

18 Appliance SOA et Bus de Services d Entreprise (ESB) Transformation, sécurité, routage dynamique de l information, management des services, rupture de protocoles, traçabilité des échanges : les principales fonctionnalités des ESB sont supportées par les appliances SOA. Le positionnement d une appliance SOA comme ESB peut être envisagé : si l appliance satisfait totalement aux besoins de connectivité exprimés ; si l appliance satisfait en partie aux besoins de connectivité exprimés, mais aussi si des interfaces standardisées de type Web-Services, XML/RPC, REST peuvent être implémentés sur les applications cibles, pour lesquels la connectivité n est pas assurée par l appliance ; si les besoins d orchestration au niveau des médiations du bus sont inexistants ou «légers» ; si les besoins en termes de performance et de sécurité sont importants : nombre de transactions élevé, nécessité de contrôler les flux, opérations cryptographiques Médiations exposées Appliance SOA Consommateurs Réseau Services Appliance SOA Le bus de service peut être accessible en externe à travers une appliance positionnée en DMZ, qui expose les services aux utilisateurs externes et assure les contrôles de sécurité nécessaires. Autre utilisation possible pour les appliances SOA : les interfacer en frontal d un ESB logiciel existant. Toutes les requêtes à destination de l ESB transitent alors par l appliance qui assure la sécurité de l infrastructure : à minima cela concerne la détection des attaques et la validation des messages. Il est également possible de déléguer à l appliance SOA le traitement des médiations qui ne nécessitent pas d orchestration (ou une orchestration légère) de manière à «soulager» l ESB logiciel de ces traitements. L appliance SOA assure également la protection de l ESB en limitant, si besoin, le nombre de transactions sur le bus. IP Firewall DMZ Appliance SOA IP Firewall Internet Consommateurs SOAP/XML/REST Appliance SOA SOAP/XML/REST SOAP/XML/REST Monitoring Services ESB Vers le «tout-appliance»? Les solutions à base d appliance se développent chez de nombreux éditeurs et intègrent de plus en plus de fonctionnalités techniques. L idée consiste à promouvoir des solutions permettant de centraliser les fonctions clés des infrastructures informatiques. Parmi les solutions les plus récentes, notons les appliances assurant la sécurisation des échanges B2B (Business to Business), celles assurant la connectivité entre des applications d une entreprise (dites «on-premise») et les applications présentes sur un Cloud, dans des domaines comme le CRM (Customer Relationship Management) ou encore celles permettant de gérer du cache applicatif. Le dénominateur commun de toutes ces appliances est qu elles n embarquent pas de logique métier et sont conçues pour effectuer des traitements spécifiques de manière optimisée et sécurisée. Il paraît cependant évident que les fonctions et applications métiers d une infrastructure informatique ne sont pas candidates pour être portées par une offre de type appliance, à une époque où l évolution de l informatique est de proposer une virtualisation de ces dernières intégrables et provisionnées dans un Cloud. n Joel Gauci, Certified IT Specialist Client Technical Professional chez IBM Software Group Services 18 IT-expert n 88 - novembre/décembre 2010

19 Technique TOP5 des anti-patterns appliqués à l ESB Appréhender de nouveaux concepts et s assurer de la bonne direction des projets informatiques nécessitent au préalable un arrêt sur ce qu on désigne couramment comme les «bonnes pratiques». Celles-ci sont généralement issues de la longue tradition des prédicateurs de nos temps, les «leads architects», respectables par leurs contributions à la discipline d ingénierie du logiciel. Aussi est-il commun de vérifier auprès de nos équipes, si celle-ci ont été bercées par des patterns du «GoF», de Martin Fowler, Jacobson ou plus récemment de Thomas Erl. IT-expert n 88 - novembre/décembre

20 Aujourd hui, ne pas disposer de connaissance des grands principes, et ne pas l exiger de ces équipes d architectes constitue une véritable prise de risque. Il est salutaire de prendre le temps de considérer, à la lumière des précédentes expériences, ce qui a été mal interprété des différents enseignements, ce qui n a pas fonctionné, puis de constater sans fard «tout le mal que l on ne souhaitait pas faire». Sous le vocable ESB se cachent 2 concepts différents : Le produit, offre logicielle évolution des EAI avec un outillage Web services et MOM. Le pattern d architecture, établissant une couche d intermédiation au sein du SI et endossant le rôle de fournisseur de service. L ESB expose alors des services sur la base d applications existantes via l utilisation de connecteurs («enablement»). Dans une démarche SOA, les concepts de «Médiation» et d «Exposition» font corps afin de fournir au reste du SI les services gages de stabilité et d évolutivité. Cause Tentative de rationalisation des services exposés au sein du SI sans prendre en compte les cas d usages métiers. Peur de l anti-pattern «Tout est Service». Démarche SOA portée isolément par l IT. Effet Les effets négatifs concernent la complexité fonctionnelle portée par ces services, qui répondent à de nombreux cas fonctionnels (tous les langages d implémentation ne sont pas aussi élégants que les prédicats Prolog pour adresser les clauses multiples ) ou bien une signature de service à tiroir, permettant la saisie de paramètres d entrée à géométrie variable. La gouvernance d un tel service s avère des plus délicates, puisqu il adresse de nombreuses problématiques, et donc en servant un dessein aussi large, est susceptible de subir de nombreuses évolutions. Nous risquons alors de produire de multiples versions, qui n intéressent qu un nombre limité de consommateurs, voire de multiplier les interfaces pour un même service, faisant alors porter l adaptation fonctionnelle par l ESB. Puisque l on aborde très souvent les bonnes pratiques, pourquoi ne pas se pencher sur quelques mauvaises pratiques communément recensées autour de la mise en place d un ESB? Anti-Pattern #1 Le Macro Service Description Suite à la mise en place d une méthodologie d identification de service, il peut arriver que le message initial de «rationalisation des services du SI» soit mal interprété, aboutissant à une situation opposée à celle recherchée ; une tentative de rationalisation du nombre d interfaces exposées pour un domaine fonctionnel, en fournissant des services de forte granularité. Nous tombons alors dans l excès inverse, à savoir : la fourniture d un nombre limité de services, qui répondent à un périmètre fonctionnel trop large. Exposition de Service Application Source Interfaces exposées Interfaces consommées Figure 2 : mauvais rôle fonctionnel endossé par l ESB Adaptation Fonctionnelle (filtrage, transformation ) Un corollaire, qui va généralement de pair avec les éléments décrits précédemment concerne les performances d un tel service. Il n est en effet pas rare de le voir remonter une grappe d objet d une profondeur importante afin de fournir à ces nombreux consommateurs toute l étendue des informations qu ils sollicitent. Applications Composites Portail Externe Interactions Utilisateurs et B2B Applications Composites Portail Interne & Applications Partenaires B2B Integration Référentiel de Sécurité Infrastructures transverses Registre et Référentiel SOA Médiation de Services Fournisseur/ Consommateur Business Process Management Moteur d exécution Exposition de Service (Enablement) Exposition de Service Moteur d exécution Business Database Domaine Métier 1 Application ERP Legacy Domaine Métier 2 Business Database Fonctions portées par un ESB Figure 1 : architecture logique simplifiée d un socle SOA 20 IT-expert n 88 - novembre/décembre 2010