Plus que jamais en informatique, il est compliqué de savoir où sont vos données, et quel est leur niveau de sécurisation. Grâce aux architectures géo-redondantes et aux nouveautés amenées par le Cloud, vos services peuvent très simplement se déplacer d’un pays à l’autre sans même que vous vous en rendiez compte. Arriver à suivre le cheminement d’un flux réseau, afin de comprendre les impacts en termes de performances et de sécurité devient un enjeu en soi.
Face à ce défi, je vous propose pour ce dernier chapitre quelques bonnes pratiques agrémentées d’exemples vécus :).
Les enjeux de performance et de réseaux
La répartition géographique des serveurs
Dans vos architectures, vous allez être amené à concevoir des systèmes distribués, par essence répartis dans des localisations différentes, en France et ailleurs. Plus que jamais, vous allez être amené à utiliser des services à différents endroits de la planète.
Exemple de problème de distribution des systèmes
J’ai eu le plaisir, dans une de mes expériences passées de travailler pour un grand groupe international, avec plusieurs de dizaines de milliers d’utilisateurs. Afin de faire évoluer leur système de messagerie, ils avaient décidé d’opter pour une solution Cloud, dont les serveurs étaient localisés aux Etats-Unis. Les premiers retours utilisateurs sur l’envoi et la réception de message étant probants, il a donc été décidé de déployer la solution dans le monde entier.
Quelques semaines plus tard, un écueil majeur est apparu : la filiale australienne mettait désormais 30 minutes à réserver la moindre salle de réunion, parfois plus. C’était tellement impactant pour eux qu’ils en ont fait une vidéo, envoyée à la DSI centrale (véridique !).
Après investigation, il est apparu que le module de réservation de salle, historiquement accolé à la solution de messagerie et de gestion du calendrier, était toujours hébergé dans les bureaux australiens après migration. Or ce module était très gourmand en échanges, ce qui ne posait pas de problèmes en local, mais devenait catastrophique à longue distance.
L'hybridation
Un autre aspect complexe créé par la généralisation du cloud est l’hybridation. Cela correspond à l’interconnexion de vos datacenters avec les fournisseurs de Cloud, afin de sécuriser vos accès et une partie du Cloud Public qui ne devient accessible que par vous.
En théorie, c’est très simple : vous définissez votre plan d’adressage et vous faites une extension de votre réseau.
En pratique, les choses se compliquent : d’un point de vue sécurité, le cloud est-il une zone de confiance ? Une DMZ ? Comment gérer l’exposition sur internet des données produites DANS le Cloud ? Comment réconcilier les besoins de maîtrise d’un plan d’adressage (avec un nombre d’adresses fini) et le dynamisme des environnements qu’il ne faut pas frustrer ?
Ma préconisation est de rester agile et de procéder par itération : zone par zone, usage par usage, on peut démarrer l’hybridation en restant maître de son interconnexion. Le pendant est un fort besoin de mesure : combien ai-je consommé d’adresses ? Quel est la charge de mon lien avec le fournisseur du Cloud ? Combien d’applications sont-elles en mode hybride ?
Vous serez surpris de constater comme ces éléments d’apparence simples sont rarement pris en compte, souvent au profit d’une stratégie centrée sur les infrastructures, avec un projet d’offre : « On va mettre en place la plate-forme, ça va générer des usages ». Cette approche, plus simple à mettre en place en apparence (« pas besoin de discuter avec les métiers ou les études! ») est risquée et nécessite de fréquentes itérations pour répondre aux besoins qui émergent, même si elle permet en apparence de pouvoir dire « c’est bon, on est dans le Cloud ! »
Les offres SaaS—Software as a Service
Pour finir sur l’aspect réseau et performances, je voudrais attirer votre attention sur les offres SaaS. Ce mode de consommation, très séduisant pour de nombreuses entreprises car porteur d’une promesse de facilité de gestion, implique en général un accès aux logiciels directement depuis internet.
Cela met une emphase particulière sur les problématiques d’accès, de débit et de latence, en particulier si vos utilisateurs sont dans des zones mal desservis (campagnes, étranger…) ou si vos liens sont sous-dimensionnés ou lents.
Exemple de problème d'accès avec une offre SaaS
J’ai l’exemple d’une société récemment passée à un service très populaire de suite bureautique à la fois disponible en ligne et en local sur son ordinateur. La promesse de l’éditeur était que les utilisateurs bénéficient ainsi des dernières mises à jour, en permanence.
Quelle ne fut pas la surprise des services informatiques, quand après une vague importante de mise à jour, tous les postes de travail ont dû télécharger complètement leur logiciel en local, sans que cela ne soit ni annoncé ni contrôlable ! Cela a bien entendu saturé toutes les liaisons internet de chacun des sites pendant plusieurs heures, impactant profondément le travail de chacun.
La sécurité dans un monde ouvert
Avançons maintenant sur l’aspect sécurité : de plus en plus de cas d’usage imposent d’ouvrir ses données et ses traitements (voir la démarche « open data »), et de plus en plus de services sont consommables directement depuis internet.
C’est l’analogie du robinet chez vous ou dans votre jardin : vos données sont soit « à l’abri » dans vos murs, soit « accessibles » dans votre jardin. Il est bien plus compliqué de vous assurer qui peut les consommer dans votre jardin que chez vous, et surtout de détecter une fuite (même si ça n'empêche pas quelqu’un de motivé de rentrer et se servir !). Les développeurs, souvent habitués à la protection de l’intérieur du datacenter, utilisent parfois des protocoles non sécurisés, des API sans authentification. Les administrateurs quant à eux peuvent avoir gardé leurs fichiers de mots de passe sur des machines ou des partages qu’ils pensent sécurisés.
Comment dans ce contexte garder un cap sans tomber dans le dogme (qu’il soit « tout chez moi » ou « tout dehors ») ?
Pour moi la première étape est bien entendu de classifier ses données : qu’est-ce qui est critique pour mon entreprise, et qui peut me faire perdre un avantage concurrentiel ? Quelles sont les contraintes légales ? Quels sont les impacts d’image ? etc.
Une fois les données sensibles identifiées, on peut leur associer un niveau de sécurisation cible :
Faut-il chiffrer les données sur disque ?
Uniquement en transit ?
Quelles données peut-on assumer héberger en dehors du datacenter ?
Parfois d’autres considérations, notamment politiques ou stratégiques, peuvent entrer en compte : vous ne verrez pas de grands acteurs de la distribution aller consommer des services chez AWS !
Ensuite, pour moi, il faut considérer aujourd’hui que tout est attaquable : qu’on soit dans le datacenter ou en dehors, la sécurisation des données, des flux et des accès doit être systématique. Cela permet d’insuffler des réflexes de conception, qui rendent les architectures plus évolutives : si la sécurisation d’une application est pensée dès le départ, on pourra facilement la migrer vers un cloud ou un autre.
Encore une fois, ces bonnes pratiques peuvent paraître évidentes, mais mon expérience m’a montré que c’était loin d’être le cas, et qu’il est toujours nécessaire de les rappeler en phase de conception.
Dernière histoire pour la route : récemment, en tant qu’architecte projet, j’ai été amené à travailler sur une application très sensible chez un client. La sécurité était au coeur du projet, tous les flux faisant l’objet de chiffrement et de contrôle, une authentification dans les règles de l’art, etc. Comme à mon habitude, je faisais le tour des interfaces avec mon client. Quelle a été ma surprise quand je me suis rendu compte que pour des raisons tactiques une API avait été développée sans authentification pour permettre certains imports de données ! Cet ajout de dernière minute, assez classique dans la vie d’un projet, n’a été possible que par l’absence de culture de la sécurité au sein de l’équipe projet.
En résumé
Dans ce chapitre, nous avons abordé la place des réseaux et de la sécurité dans les architectures d’aujourd’hui :
Les problématiques de latence, de débit et d’interconnexion d’un côté ;
La nécessité de classifier ses données et d’avoir une approche holistique de la sécurité de l’autre.
Voici qui conclut ce cours sur l’architecture en informatique ! En vous armant de la méthode proposée et aussi de votre bon sens, n’hésitez pas à vous lancer dans vos premières analyses.
La méthode est applicable tout le temps, et l’analyse peut être partout (comme la Force). Peu importe votre périmètre actuel d’intervention, vous pouvez déjà vous poser les bonnes questions et lister les caractéristiques fonctionnelles, applicatives, infrastructures et opérationnelles des systèmes sur lesquels vous travaillez. Allez voir vos architectes, qui se feront immanquablement un plaisir de vous montrer ce sur quoi ils travaillent et partagez avec eux votre vision.
Remerciements
Au tout début de ma carrière dans un grand cabinet de conseil en IT parisien, j’ai eu l’immense chance de côtoyer des architectes techniques. Ces personnages hauts en couleurs, grâce à leur expérience et de leur prestance, m’ont immédiatement inspiré à poursuivre cet objectif de carrière : « être architecte ». Merci à eux de m’avoir donné les bases nécessaires pour commencer à comprendre l’incroyable richesse des systèmes d’informations qui nous entourent.
Merci également à Mathilde Blanchat, Frédéric Chomette et Daniel Lefebvre pour leurs relectures assidues, ainsi qu’à Vincent Alessandrini-Fantin pour son aide et l’utilisation de ses représentations.
