Liste de partage de Grorico
Un article récent publié sur InfoQ abordait la sécurité de HTML5 dans sa globalité, et notamment sur des attaques concernant les nouvelles fonctionnalités de navigation hors-ligne de HTML5.
Quelles sont donc ces fonctionnalités et qu’en est-il vraiment des risques associés?Rappel historique
La seule possibilité pour une application web HTML/JavaScript de stocker des données dans un navigateur était jusqu’à récemment de les stocker dans un cookie. Limités en taille (la spécification exige seulement des navigateurs qu’ils puissent gérer 4096 octets par cookie!), parfois refusés par les navigateurs et nettoyés régulièrement, et assimilés à des logiciels espions par les antivirus, leur fiabilité restait très limitée.
D’autres technologies à base de plugins, comme Adobe Flash, utilisaient des procédés propriétaires ne répondant pas aux normes du W3C (les « super cookies« ) et très critiquées pour leur opacité (manque de contrôle pour l’utilisateur pour savoir quelles informations sont stockées ou les supprimer). En 2007, Google a sorti Google Gears qui a permis de stocker des données dans le navigateur sous la forme d’une base de données relationnelle et de disposer en local d’un cache de ressources (cf. les articles publiés par Olivier Mallassi sur le blog OCTO).
Cette nouveauté a permis le développement de véritables applications web stockant un nombre conséquent de données en local, permettant un fonctionnement déconnecté de l’application et une meilleure réactivité en évitant d’inutiles aller-retours avec le serveur. L’exemple le plus marquant étant naturellement le client mail de Google, Gmail, qui innovait en plus avec le « flaky mode » où l’utilisateur naviguait en permance en local, utilisant les ressources stockées dans son navigateur, et où l’application mettait à jour ces données quand une connexion à Internet était disponible. Cependant, Google Gears restait un produit de Google, et son implémentation sur les navigateurs n’était pas garantie.
Le groupe de travail sur HTML5, auquel contribue fortement Google, a alors déclaré vouloir inclure dans la spécification HTML5 des normes de stockage local s’inspirant de Google Gears. En parallèle, début 2009, Google a d’ailleurs arrêté le développement de Google Gears, au profit de l’implémentation de la norme HTML5.
Cette normalisation contraint déjà les navigateurs web à implémenter ces mécanismes, entraînant à coup sûr une démocratisation de leur utilisation par les applications web.
Quels sont les risques liés au stockage local?
Parmi les sites précurseurs dans l’utilisation de stockage local se trouvent les webmails. Les données stockées dans le navigateur sont donc les courriers électroniques de l’utilisateur, qui sont des données très critiques par-rapport au respect de la vie privée, sans parler des cas où certains mails contiendraient des données plus sensibles, comme un numéro de compte bancaire…
Il convient donc impérativement de s’assurer qu’aucun tiers ne puisse accéder à ces données.
Quels sont les mécanismes de stockage local?
HTML5 prévoit deux systèmes de stockage de données en local :
- le Web Storage, comprenant local storage, toujours accessible à l’application et permettant par exemple à des onglets différents de partager des données, et le session storage, accessible uniquement à une fenêtre donnée. Les données sont stockées sous la forme de clés/valeurs,
- la Web SQL Database fournissant cette fois une base de données relationnelle, implémentée par les navigateurs avec SQLite. Signalons au passage que le choix de SQLite a été fait par les éditeurs de navigateurs au détriment de la proposition initiale de « Indexed DB » proposée par le W3C.
Un autre système de stockage local est fourni sous la forme de caches permettant cette fois-ci de stocker des ressources (images, fichiers JavaScript, etc.) et non plus des données.
Dans leurs spécifications respectives, le W3C aborde la sécurité, et décrit les mêmes problématiques pour les deux.
Quels risques et quelles protections?
La seule protection spécifiée par le W3C concerne l’origine des sites : des données stockées par un site A ne doivent pas être visibles pour un site B, en se basant sur l’hôte du site et le port. Cela empêche par exemple une iframe inclus dans un site, typiquement un encart publicitaire, d’avoir accès aux données stockées localement par ce site.Ce systèmes ne protège pas de certaines attaques, d’ailleurs décrites dans la spécification :
- les attaques par usurpation de DNS, qui consistent à usurper une adresse IP d’un serveur pour envoyer des paquets à sa place. Ce risque sera toutefois mitigé en utilisant SSL, et concerne le web dans sa globalité.
- le partage de nom d’hôte entre plusieurs sites : si le site d’adresse http://www.mon-site.com/site1 stocke des données, un autre site d’adresse http://www.mon-site.com/site2 y aura accès sans resctriction. Le risque étant faible de se faire attaquer par ce biais, car on a déjà fait confiance au premier site.
On remarquera que les attaques par XSS (cross site scripting) ne sont pas mentionnées et constituent pourtant un risque important, bien mis en valeur par l’OWASP. On pourra le mitiger avec notamment un contrôle du code côté serveur et une validation des données passées dans les formulaires.
La spécification ne prévoit pas d’autre mécanisme de sécurité.
Un point très important n’est pas abordé dans la spécification et pourrait pourtant s’avérer crucial : la spécification ne prévoit que les données stockées en base locale soient cryptées, elles sont toujours stockées en clair.
Ce point a été soulevé par Nicholas C. Zakas (un des référents mondiaux sur le langage JavaScript notamment, qui contribue à HTML5). Il a même proposé une proposition très détaillée d’évolution de la spécification vers un cryptage des données, décrite dans ce billet.
Dans ce système, un serveur d’application web aurait la responsabilité de chiffrer les données sur le client, avec une clé de cryptage gérée par l’application. Concrètement, une application web devrait exécuter la méthode Javascript suivante pour ouvrir la connexion en base de données :
window.openSecureStorage("mystorage", window.AES_128, key, function(storage){
//use storage object
});
L’application web choisirait donc l’algorithme de cryptage et la clef. Ainsi, même si un attaquant parvenait à récupérer des données, il ne pourrait les exploiter. On remarquera d’ailleurs que sans cryptage, toute personne ayant acccès physiquement au poste client pourra lire toutes ces données…
On peut tout de même se rassurer concernant les postes publiques (cyber cafés, etc.). En effet, les données sont stockées dans le navigateur dans un profil créé pour l’utilisateur, qui est normalement effacé lorsqu’il quitte le poste et que le compte est ré-initialisé, ce qui doit être l’usage pour ce type de poste. L’utilisateur devant tout de même s’en assurer, ce qui est loin d’être évident pour un utilisateur non initié. Il est ici plus question d’éducation des utilisateurs que de technologie.
Enfin, les caches peuvent quant à eux être attaqués par « Cache poisoning ». L’objectif de l’attaquant est alors d’injecter dans le cache du navigateur un fichier JavaScript en remplacement d’un fichier fourni par le serveur « sain », et dont le script malicieux serait exécuté par le client. Ce risque est à prendre en compte particulièrement dans les réseaux wifi ouverts comme on en trouve par exemple dans des restaurants, mais si ces attaques sont difficiles à détecter et à contrer, le risque s’avère relativement faible d’après les conditions requises pour permettre l’attaque, citées par l’OWASP.
Conclusion
Malgré cette énumération de risques, qui plus est incomplète, il convient d’insister sur le fait qu’ils ne sont pas spécifiques à HTML5 mais au contraire inhérents au web depuis ses débuts.
La nouveauté avec HTML5 est qu’il offre la possibilité de faire des application plus riches, stockant plus de données localement.
Cela doit simplement inciter les concepteurs et développeurs d’applications web à une certaine vigilance concernant la sécurité des données locales, mais ne vous y méprenez pas, HTML5 constitue bien dès aujourd’hui une formidable opportunité pour vos applications web!
Suggestion d'articles :
Virus informatiques, usurpations d’identité, hameçonnages, atteintes à la vie privée ou à la réputation, diffamations, vols de données, espionnage industriel ou politique, pédopornographie… le “piratage informatique“, improprement qualifié de “cybercriminalité” (la majeure partie du temps, il s’agit plutôt de délinquance) attise les peurs des gens. Mais une nouvelle menace, aux conséquences bien plus dommageables, a commencé cet été à faire du bruit dans le Landerneau de la sécurité informatique : qu’adviendrait-il, en effet, si des millions, voire des dizaines de millions de foyers, étaient privés d’électricité plusieurs jours, voire plusieurs semaines durant ?
“Du point de vue de l’attaquant -gouvernement hostile, organisation terroriste ou de protection de l’environnement-, le meilleur moyen de s’attaquer à un pays est de lui couper l’électricité. C’est l’équivalent, cyber, d’une attaque nucléaire : quand il n’y a plus d’électricité, tout s’arrête.”
Le scénario n’émane pas d’un roman de science-fiction, mais d’un professeur de Cambridge, Ross Anderson, l’un des experts les plus réputés en terme de sécurité informatique, et de Shailendra Fuloria, l’un de ses étudiants, spécialiste des systèmes SCADA (pour supervision, contrôle et acquisition des données).
Les systèmes de télégestion ne sont pas sûrs !
Créés pour permettre le contrôle à distance et la surveillance de processus industriels, la télégestion de systèmes d’approvisionnement, de transport et les canalisations de produits chimiques, de gaz, de pétrole, d’eau et d’électricité, les systèmes SCADA sont souvent perçus par les spécialistes de la sécurité informatique comme un maillon faible qu’auraient beau jeu d’exploiter des cyberterroristes, pirates informatiques ou hackers militaires.
En 2007, le projet Aurora avait ainsi démontré la possibilité de pirater le système SCADA d’un générateur électrique afin d’entraîner son autodestruction. Or, et comme le souligne l’un des experts interrogés dans ce documentaire de CBS, ces générateurs coûtent très cher, ils ne sont plus fabriqués aux Etats-Unis, et il faudrait des mois pour s’en procurer d’autres ou les réparer, ce qui aurait des conséquences non seulement économiques, mais également politiques :
En 2008, le Club de la Sécurité de l’Information Français (CLUSIF) évoquait, dans une étude sur les Enjeux de sécurité des infrastructures SCADA (.pdf), plusieurs explosions dans des usines chimiques, le fait que des sites nucléaires, guichets automatiques bancaires, systèmes de signalisation ferroviaire avaient été perturbés par des vers informatiques, entraînant, dans un cas, l’arrêt de 13 usines d’assemblage de véhicules, dans un autre l’arrêt d’une station nucléaire. La présentation évoquait également plusieurs actes de malveillance ayant perturbé des feux de signalisation, systèmes d’approvisionnement en eau, et même la prise de contrôle et le déraillement, par un adolescent, de 4 wagons.
Dans une intervention intitulée Electricity for Free ? (.pdf) présentée lors du dernier Black Hat (l’un des symposiums les plus réputés en matière de sécurité informatique), en juillet dernier, Jonathan Pollet, spécialiste de la sécurité SCADA chez Red Tiger Security, a expliqué avoir identifié 38 000 problèmes de sécurité, lors de 100 audits, effectués sur 10 ans.
Alors que la “durée de vie” (c’est-à-dire le temps avant qu’il ne soit infecté ou compromis) d’un ordinateur non protégé est estimée à 4 minutes, pour Jonathan Pollet, “les systèmes SCADA sont bien moins sécurisés que les systèmes informatiques“.
Au cours de ses audits, il a ainsi trouvé, sur des ordinateurs reliés à des systèmes SCADA, toute sorte de programmes qui n’avaient rien à y faire, mais qui pouvaient a contrario servir de vecteur ou de relais d’attaques : logiciels P2P ou de messagerie instantanée, scripts de téléchargement de vidéos pornographiques, et même des chevaux de Troie et autres “malwares“.
“Ce n’est qu’une question de temps : d’ici peu, nous assisterons à bien plus d’attaques ou d’incidents sur des réseaux SCADA du fait de l’absence de mesures de sécurité, ou de systèmes de défense mal configurés. Il faut nommer des responsables sécurité de ces systèmes. C’est une bombe à retardement.”
Découvert en juillet dernier, le vers Stuxnet serait le premier virus expressément créé pour infecter les systèmes SCADA. 60% des systèmes infectés auraient été situés en Iran. Pour Raphaël Marichez, de la société de sécurité HSC, Stuxnet constituerait “un tournant“, ouvrant la voie à “des virus exploitant des vulnérabilités “grand public”, avec la complicité de grandes firmes étrangères, pour cibler un système industriel précis“.
A défaut de connaître son auteur, et donc savoir s’il s’agit bel et bien d’une tentative d’espionnage industriel, voire d’espionnage tout court, on notera que, toujours cet été, un rapport du ministère de l’énergie américain constatait que les infrastructures énergétiques américaines étaient vulnérables à des attaques informatiques, faute d’effectuer correctement les mesures basiques de sécurité censées les protéger, ou encore parce qu’elles sont reliées à l’internet, utilisent des systèmes d’exploitation grands publics, et des ordinateurs improprement sécurisés.
Stuxnet exploitait ainsi une faille Windows, et se propageait via des clefs USB préalablement contaminées (via l’internet, ou sciemment), dès lors qu’elles étaient connectées au PC, même si celui était pourtant à jour en terme de correctifs de sécurité. En 2009, la Marine nationale française avait ainsi dû couper son réseau après avoir été contaminée par un virus, introduit via une clef USB dans son système Windows, pourtant déconnecté du Net.
L’invasion des compteurs électr(ON)iques
Ross Anderson et Shailendra Fuloria ne s’intéressent pas tant aux systèmes SCADA, mais à ces compteurs “intelligents“ (les guillemets sont de rigueur, lorsque l’on commence à doter d’”intelligence” des boîtiers électroniques), censés permettre d’effectuer des économies d’énergie et dont le développement est activement soutenu, outre-Atlantique, dans le cadre du plan de relance américain (qui y investit 3,4 milliards de dollars), et en Europe par une directive européenne de 2009, qui prévoit d’en équiper 80% des foyers à l’horizon 2020.
On dénombrerait ainsi, à ce jour, quelque 250 projets de compteurs “intelligents“, 49 millions d’ores et déjà installés, et 800 millions en préparation, d’après la carte des expérimentations (triangles) et projets (ronds) de compteurs “intelligents” électriques (en rouge), de gaz (en vert) et d’eau (en bleu) dressée par meterpedia.com :
Consultez la Smart Metering Projects Map sur une plus grande carte
Or, ces compteurs “intelligents” commencent aussi à défrayer la chronique. Début août, la CNIL s’inquiétait ainsi des risques qu’ils faisaient poser en terme de traçabilité des usagers :
“Les informations de consommation d’énergie transmises par les compteurs sont très détaillées et permettent de savoir beaucoup de choses sur les occupants d’une habitation, comme leur horaire de réveil, le moment où ils prennent une douche ou bien quand ils utilisent certains appareils (four, bouilloire, toaster…)
Les compteurs communicants peuvent également agir directement sur l’installation électrique. Ils permettent notamment de modifier la puissance de l’abonnement, voire même de couper l’alimentation électrique à distance, via une interface web. Ces fonctionnalités devront être parfaitement sécurisées pour éviter toute utilisation frauduleuse.”
Dans une étude (.pdf) sur la sécurisation du Smart Grid (ou “réseau intelligent“, le système auquel se connecteront ces compteurs “intelligents“), la société IO Active identifie ainsi 10 risques en terme d’atteintes à la vie privée, à commencer par la surveillance, en temps réel des appareils électriques, et donc des habitudes comportementales de leurs utilisateurs, mais également les risques d’usurpation d’identité, de surveillance, d’espionnage, de malveillance ou encore de bug informatique, et autres problèmes de sécurité inhérents à tout système informatique en réseau.
Début septembre, plusieurs associations de défense des consommateurs critiquaient de leur côté la précipitation, qualifiée de “passage en force (et de) fuite en avant“, avec laquelle le gouvernement avait décidé de généraliser le déploiement de Linky, le projet français, dont l’expérimentation devait durer jusqu’au 31 mars 2011, mais qui cumuleraient problèmes et erreurs, factures illisibles et parfois astronomiques (jusqu’à 3 voire 4000 euros, au lieu de 25 à 30, selon la Confédération Nationale du logement de Lyon, interrogée par le 7/9 de France Inter ce 10 septembre) :
“Le planning de pose dérape, les compteurs disjonctent un peu trop facilement et la transmission des données ne se fait pas. Comment réaliser un bilan complet au 31 décembre 2010, c’est-à-dire trois mois plus tôt que prévu, avant la pose de l’ensemble des compteurs expérimentaux et sans même les tester pendant la période hivernale ?”
Elles critiquent également le coût du compteur, estimé entre 120 et 240 euros, qui sera facturé aux usagers (à raison d’un ou deux euros par mois, sur 10 ans), et qui aurait été “pensé par et pour le distributeur ERDF et pas du tout au bénéfice du consommateur“, qui devra, en plus, acheter un second boîtier s’il veut pouvoir mesurer, voire contrôler, sa consommation électrique :
“Au final, les avantages du compteur sont avant tout pour le distributeur ERDF et pour les fournisseurs, qui vont ainsi pouvoir proposer des services payants au consommateur pour suivre sa consommation électrique et de nouvelles offres tarifaires.”
En réponse, ERDF, la filiale d’EDF en charge de Linky, rétorque que cela permettra d’identifier plus rapidement les problèmes, d’en régler une bonne partie à distance, et donc plus rapidement, que cela permettra aux clients de faire des économies en modulant le tarif, que 93% des clients s’en déclarent “satisfaits“, et que “toutes les informations clients sont strictement confidentielles et cryptées“.
Mais qui contrôlera le bouton OFF ?
Dans leur article, intitulé “Who controls the off switch ?” (.pdf) (qui contrôle le bouton off ?), Ross Anderson et Shailendra Fuloria s’alarment de la légèreté avec laquelle les fournisseurs d’électricité, avec l’aval des autorités, créent une “nouvelle cyber-vulnérabilité significative” faisant courir le risque de coupures massives d’électricité.
Les compteurs “intelligents” sont en effet dotés de composants matériels et logiciels, et donc potentiellement piratables, ou sujets à des bugs informatiques, d’autant qu’ils sont connectés aux fournisseurs d’électricité. L’objectif est de permettre à ces derniers de surveiller, en temps quasi réel, la consommation électrique, mais également de pouvoir modifier, à distance, l’intensité de l’électricité lors de pics de consommation, ou encore de couper le courant à ceux qui n’honorent pas leurs factures – ce qui, avec les compteurs manuels, réclamait jusque-là le déplacement d’un électricien.
A terme, le tarif sera ainsi modulé, plusieurs fois dans la journée, et les opérateurs proposeront aux abonnés la possibilité de gérer eux-mêmes leur consommation d’électricité, se réservant le droit de leur couper le courant, ou de le diminuer, en cas de pic de consommation.
Au Japon, où la variation des prix est d’ores et déjà envoyée aux consommateurs trois fois par jour, de plus en plus de gens investissent ainsi dans des batteries, qu’ils rechargent la nuit quand le prix de l’électricité est bas, et qu’ils utilisent en journée en lieu et place de leur abonnement à l’électricité. Les deux chercheurs estiment que ce type d’arbitrages ne pourra qu’inciter les clients à tricher, et pirater leurs compteurs “intelligents“…
De son côté, la Grande-Bretagne a décidé de centraliser la totalité des données renvoyées par les compteurs, avant de les renvoyer vers les opérateurs. Les autorités espèrent ainsi pouvoir être plus à même de contrôler, voire modifier, la consommation électrique britannique.
Pour Ross Anderson et Shailendra Fuloria, qui notent que les équipes techniques des vendeurs de compteurs, tout comme les experts de l’académie royale des ingénieurs, ont soigneusement été écartés des réunions de préparation de ce projet, cette centralisation des remontées des informations est un “scénario cauchemardesque“. L’existence même d’un système centralisé de contrôle de l’électricité ouvre en effet la possibilité d’une coupure généralisée de courant, dans tout le pays, en cas de bug ou de piratage informatique…:
“Le black-out s’étend sur des centaines de millions de foyers, certains pendant plusieurs jours, d’autres pendant plusieurs semaines; des gens meurent d’hypothermie, du fait de la panne des équipements médicaux électriques, ou d’électrocution en tentant de réparer eux-mêmes la panne électrique.
Le modèle économique de l’industrie énergétique est ruiné par la destruction de son “réseau intelligent“, et le remplacement des dizaines de millions de compteurs “intelligents” prendra des années. L’activité économique est perturbée, les responsables des opérateurs d’électricité sont renvoyés, des ministres doivent démissionner.”
Les deux chercheurs soulignent que plusieurs pays se sont dotés d’unités de guerre informatique offensive, et que l’armée américaine a déjà utilisé la coupure d’électricité, en Irak et en Serbie. Ils rappellent également qu’en 1996, l’IRA avait tenté de faire exploser les transformateurs de trois centrales électriques londoniennes, ce qui aurait eu pour effet de couper le courant à des millions de particuliers et d’entreprises pendant des mois. L’attentat avait pu être déjoué parce que la cellule de l’IRA avait été infiltrée par les services anti-terroristes britanniques. Si l’attentat avait eu lieu, il aurait entraîné des pertes estimées au tiers du produit intérieur brut du pays…
Des pirates informatiques, ou des employés mécontents, pourraient également profiter de ces vulnérabilités afin de faire chanter les opérateurs d’énergie, ou encore pour voler de l’électricité. Interrogé par CNet, Karsten Nohl, un autre chercheur connu pour avoir révéler plusieurs failles de sécurité en matière de RFiD et de téléphonie mobile, explique que “d’un point de vue matériel, les téléphones portables sont aujourd’hui bien plus sécurisés que la plupart des compteurs intelligents, (alors) qu’ils devraient bénéficier des meilleurs systèmes de protection disponibles“, ce qui semble loin d’être le cas dans celui qu’il a inspecté :
“Nous n’avons trouvé aucune des mesures de sécurité que nous serions en droit d’espérer dans un dispositif de ce type, relié à une telle infrastructure critique.”
Faute de signature électronique, de mesures de chiffrement ou d’authentification, les composants physiques étudiés n’étaient pas protégés, il était donc possible de les modifier, tout comme il était possible de modifier la consommation (pour la baisser de 25 kilowatts à 2,5 kW, par exemple), alors que le logiciel, lui, propriétaire, empêchait toute vérification de la qualité et de l’intégrité du code… ce qui n’a pas empêché Nohl de parvenir à faire planter, ou redémarrer, le “compteur intelligent“. Or, et dans la mesure où ils sont reliés en réseau, en cas de bug ou de piratage, ils pourraient entraîner des coupures en réseau, et le piratage d’un seul compteur pourrait entraîner la paralysie de tout ou partie du réseau.
Une série de vidéos présentées en 2009 par IOActive montre ainsi comment un virus informatique, couplé à une base de donnée d’adresses géolocalisées, pourrait, en 24h, couper l’électricité dans tout un quartier :
Or, la rapidité avec laquelle sont déployés ces “réseaux intelligents“, et les milliards de dollars qui y sont investis, font que les questions de sécurité passeraient souvent au second plan, d’autant qu’aucun standard international n’a encore été adopté, afin de les sécuriser.
Qualifiant la sécurité de cinquième roue du carrosse, Christophe Auffray, sur ZDNet, note également que si les technologies existent, elles ont un coût, qui attise les rivalités et tensions : “la sécurité de ces réseaux communicants représente un marché à fort potentiel pour les industriels, et chacun défend, notamment au niveau des autorités européennes, ses propositions et intérêts.”
Dans un autre article, “On the security economics of electricity metering” (.pdf), publié dans la foulée, Ross Anderson et Shailendra Fuloria émettent cinq recommandations afin d’éviter les conflits d’intérêts entre les opérateurs, d’éviter de voir s’affronter les Etats (qui cherchent à économiser l’électricité) et les entreprises privées (qui cherchent à maximiser leurs profits), d’éviter également que des détenteurs de brevets ne se servent sur la bête, et, in fine, de réguler le “complexe système sociotechnique” qui voit le jour et qui associe, dans un “réseau intelligent“, producteurs, fournisseurs et distributeurs d’électricité, régulateurs, vendeurs, sous-traitants, et leurs clients :
- les données devraient appartenir aux clients qui, seraient tenus de partager avec les opérateurs celles qui leur permettront d’effectuer leurs missions de régulation de la consommation, et de facturation, dans les limites du respect de la vie privée des utilisateurs;
- plutôt qu’un système centralisé de collecte des données, il faudrait privilégier un cadre d’échange et d’interopérabilité des données basés sur des standards “ouverts“, et non-propriétaires;
- les distributeurs devraient être tenus de nettoyer les données;
- l’audit de la consommation énergétique d’un client ne devrait pouvoir être effectué que par le distributeur d’électricité -et ledit client;
- plutôt que d’espérer pouvoir couper le courant à tels ou tels foyers, et afin d’éviter les risques posés par la centralisation des données, seules les compagnies énergétiques devraient être habilitées à moduler la consommation de leurs clients;
- au vu de sa complexité, et des enjeux politiques et économiques associés, le “réseau intelligent” devrait être placé sous la férule d’une autorité indépendante à même de défendre les intérêts des consommateurs et d’assurer l’intégrité et la sécurité du système.
Ces questions sont d’autant plus d’actualité que l’on commence aussi à voir apparaître de véritables mouvements d’opposition à ces compteurs “intelligents“, qui dénoncent tout à trac leur impact environnemental et sanitaire, les effets en terme d’ondes électromagnétiques et de radiofréquence, l’augmentation du prix de l’électricité, le gaspillage d’argent public, la façon non-démocratique avec laquelle ils sont déployés, cette intrusion de technologies de contrôle et de surveillance dans nos logis… En attendant de savoir comment les autorités, ainsi que les opérateurs, répondront à toutes ces questions, le compte à rebours a commencé.
Jean-Marc Manach
apprenti sorcier, confiance numérique, domotique, hacker, internet des objets, politiques publiques, surveillance
Les entreprises qui ont fait le pari de l’externalisation ont de plus en plus d’applications sur Internet. S’ajoutant à cela la nécessité stratégique de pouvoir s’interfacer toujours plus vite avec d’autres partenaires, de nouveaux besoins d’intégration sont apparus:
- la continuité de l’information entre SI interne et Cloud (scénarios SI2Cloud et Cloud2SI)
- la continuité de l’information entre applications sur le Cloud (scénarios Cloud2Cloud)
Le besoin de continuité entre SI interne et Cloud ravive d’anciennes problématiques. Les principaux freins ont été jusque là:
- la réticence au changement (manque de confiance dans le Cloud, crainte de perdre le contrôle des données)
- le risque encouru en exposant davantage le réseau de l’entreprise (ouvertures de ports supplémentaires sur le firewall)
- le manque de visibilité des adresses IP internes depuis le Cloud (contrainte du NAT, mécanisme IPV4 de passage du réseau public au réseau privé)
Face à ces défis nouveaux et anciens, l’intégration d’applications sur le Cloud est en pleine émergence. Tâchons dans cet article d’appréhender les différentes technologies d’intégration disponibles et leurs écueils, et d’identifier les tendances pour les années à venir.
SI2Cloud & Cloud2Cloud
Les éditeurs de SaaS proposent un interfaçage plus ou moins riche avec leurs solutions. Cela va de la simple exposition de services web pour les petits éditeurs, à la couche d’intégration complète de SAP (SAP Information Interchange), en passant par le moteur de workflow de Salesforce.com. Dans de nombreux cas, ces modules d’intégration se suffisent à eux-mêmes, mais sont indissociables de la solution SaaS en question. Ils sont particulièrement appropriés pour des échanges SI2Cloud (à l’initiative du SI interne) où les contraintes de sécurité sont négligeables, puisqu’il n’est pas nécessaire d’exposer davantage l’entreprise sur le réseau public.
Des spécialistes comme RunMyProcess et Cast Iron poussent leur offre d’intégration Cloud2Cloud. L’achat d’une solution standalone et propriétaire pour couvrir ce seul scénario ne semble pas pertinente, dans la mesure où les solutions SaaS exposent et consomment déjà des services web, voire embarquent un moteur de workflow. C’est la simplicité d’utilisation de ces solutions que l’on appréciera ici, ainsi que l’outillage pour le design et le monitoring des échanges. Leur côté très démocratique et l’implémentation complète des flux par paramétrage en font plutôt des solutions SaaS.
Aucune de ces solutions SaaS ne permet de passer outre les contraintes de sécurité du SI, ni d’accéder directement aux ressources internes de l’entreprise. La problématique des échanges Cloud2SI (à l’initiative du Cloud) reste entière.
Internet Service Bus
Le concept embryonnaire d’Internet Service Bus (ISB) ne ressemble pas à un serveur d’échange classique tel qu’un EAI, un ESB ou tout autre middleware. L’ISB se situe au niveau PaaS et à pour vocation de relayer des messages sur Internet au travers de protocoles rudimentaires comme TCP et HTTP; que les échanges soient à l’initiative du Cloud ou du SI interne. C’est tout du moins la définition que je vous en propose.
La motivation première qui a conduit aux solutions Linxter ISB, Microsoft Azure AppFabric, ou encore Amazon Simple Queue Service, est la difficulté et la réticence des entreprises à ouvrir leur réseau interne, empêchant les échanges Cloud2SI. En initiant lui-même la connexion, le service lève ici les problématiques de NAT et de firewall:
Les ISB de Linxter et Microsoft sont très proches, puisque tous deux reposent sur Windows Communication Foundation. Ils permettent la négociation automatique du protocole approprié (HTTP ou TCP) et, sur le modèle des réseaux Peer2Peer, d’établir une connexion directe entre client et service. La plupart des ISB proposent également le queuing de messages.
Pour assurer la continuité entre SI et Cloud, l’ISB peut aussi être employé comme une extension du serveur d’échange interne. C’est typiquement la stratégie Software + Services de Microsoft.
Dans ce cas, c’est l’intégration native entre l’ESB et l’ISB qui permet de passer au travers du firewall et du NAT. Une seule liaison permanente et bidirectionnelle relie les deux serveurs d’échanges, permettant ainsi aux applications internes et aux applications sur le Cloud de communiquer librement.
Les ISB sont bâtis sur un modèle d’architecture distribuée à base d’API propriétaires, couplant très fortement les systèmes. En outre, là où les serveurs d’échange actuels ont atteint de très bons niveaux de maturité, les ISB sont pauvres en terme de fonctionnalités d’intégration, ce qui ne permet pas de couvrir les scénarios Cloud2Cloud:
- Pas de mécanisme de transformation
- Connectivité réduite au strict minimum
- Pas de couplage lâche producteur/consommateur
Integration as usual
Les fonctionnalités nécessaires à l’intégration d’applications Cloud2Cloud sont peu ou prou les mêmes qu’à l’intérieur de l’entreprise: la connectivité technique, le mapping de données, les différents patterns d’échange, etc. Pourquoi alors ne pas héberger son ESB de prédilection directement sur une plateforme d’IaaS comme Amazon Virtual Private Cloud ?
Par ailleurs l’arrivée progressive de l’IPV6 ne bouleversera pas la manière de gérer la sécurité dans les DSI. Celles-ci seront toujours aussi réticentes à s’exposer sur le réseau public. Quelle que soit la technologie retenue, un pont logiciel prenant la forme d’un flux technique générique s’avère nécessaire entre plateforme d’intégration interne et externe. L’approche ESB prend tout son sens au travers d’une architecture hybride de ce type:
Il faut interfacer un nombre critique d’applications sur le Cloud pour justifier d’une telle architecture. La charge de travail sur un ESB et le traffic réseau étant relativement constants – au moins étalés – l’approche IaaS pourrait être économiquement peu avantageuse. C’est pourtant à mon sens la seule solution qui couvre aujourd’hui tous les scénarios Cloud2SI, SI2Cloud et Cloud2Cloud. Cette approche présente un autre avantage de taille: offrir une bonne évolutivité en cas d’externalisation et de rapatriement de services applicatifs.
Et pour demain
La notion d’ISB reste à préciser. Fort est à parier que les éditeurs ne tarderont pas à se positionner davantage sur ce segment; mais probablement pas sur ce modèle de connecteurs propriétaires qui va à l’encontre de l’esprit même du Cloud Computing. L’ISB a un rôle essentiel dans l’Internet des Objets, où l’un des enjeux est de structurer un très grand nombre d’échanges de données, depuis et vers le Cloud. Au lieu d’API propriétaires les ISB devraient reposer uniquement sur des standards, qui restent à définir. Pour convaincre les entreprises et toucher l’informatique de gestion, les ISB devront s’enrichir de nouvelles fonctionnalités. L’approche IaaS semble pour l’instant plus pérenne. Faut-il alors attendre plusieurs années pour que les éditeurs d’ISB fournissent les mêmes fonctionnalités que les ESB conventionnels ? Il convient de choisir sa solution d’intégration en prenant en compte les scénarios d’intégration SI2Cloud, Cloud2SI ou Cloud2Cloud présents et à venir, la nature des applications à interfacer (SaaS, PaaS ou IaaS), et la maturité de l’entreprise en termes d’architecture d’échange.
Suggestion d'articles :
Pas facile de faire le portrait musical d’une entité aussi complexe que Homer Simpson, mais faut dire que vous vous en êtes pas si mal tiré que ça. Des classiques tout à fait appropriés, et quelques belles surprises : The Archies et Ohio Express pour la (très) vieille école, ODB, les Autrichiens de Vodka Lennon, une reprise hallucinante de Ca Plane pour Moi par Sonic Youth et le Common People de Pulp, dont je vous conseille le live en 95 à Glastonbury. La folie totale, on oublie à quel point Pulp était immense dans les nineties. Merci d’avoir participé & enjoy the music.
Sons Perdus - Homer Simpson
(Cliquez sur le titre de la compil’ pour l’écouter avec Spotify – Si vous n’avez pas Spotify allez ici pour vous enregistrer gratuitement. Sinon, cliquez sur les chansons pour les écouter individuellement).
Sonic Youth - Ca Plane Pour Moi
Vodka Lennon - Homer Simpson
The Archies - Sugar Sugar
Renaud - Mon Beauf
Lynyrd Skynyrd - Simple Man
Didier Super - A Bas Les Gens Qui Bossent
Joan Jett & The Blackhearts - I love rock ‘n ‘roll
Pulp - Common People
Ohio Express - Yummy Yummy Yummy
Styx - Come Sail Away
Beck - Loser
Noir Désir - Lazy
Herbie Hancock - Rockit
Daft Punk - Television Rules the Nation
David Bowie - The Man Who Sold The World
U2 - Pride (In the Name of Love)
Turbonegro - Don’t Say Motherfucker, Motherfucker
Brigitte Fontaine - Y’a des Zazous
Ol’ Dirty Bastard - Shimmy Shimmy Ya
Grandaddy - He’s Simple, He’s Dumb, He’s The Pilot
Voici une histoire qui a tout pour plaire : un réseau mobile open source et low-cost alimenté par énergie solaire qui révolutionne la couverture des zones défavorisées et hors de portée des antennes. Il utilise la VOIP et fonctionne avec des portables existants. Ses créateurs sont des pointures. Et le meilleur dans tout ça c’est qu’il participe de l’initiative mêlant sexe, drogue et art, connu sous le nom de Burning Man. Par où on commence ?
