Cloud Public et réseau interne : ennemis ou amis ? (par Devoteam)
Au-delà de l’association intuitive “Cloud = Internet”, la mise en place d’une interconnexion entre le réseau interne de l’entreprise et les fournisseurs “cloud public” est souvent plus complexe que prévu, et peut entraîner des retards dans les projets, faute d’anticipation.
Intégrer le cloud public dans les différents modèles de déploiement des services du SI, avec le cloud privé ou privatif et le legacy : voilà qui est maintenant devenu un classique, dans une logique de modèle “hybride”. Mais le côté “prêt à l’usage” du cloud public laisse généralement complètement de côté la problématique de la connexion réseau : une carte bancaire, un accès Internet, le portail du fournisseur, et il est facile de provisionner et d’avoir accès à une VM, à du stockage, etc.. , en quelques minutes. Mais ceci ne couvre qu’une toute petite partie des besoins : accès à un service isolé, ne pouvant communiquer avec rien !
L’interconnexion avec le cloud public vient généralement “percuter” deux approches structurantes menées sur les dernières années : la centralisation des accès Internet et la segmentation réseau renforcée, et généralement complexifiée, au niveau des datacenters et des infrastructures centrales principalement pour des questions de sécurité.
Concernant les accès Internet, le déploiement de services à destination de l’ensemble des utilisateurs, comme la messagerie ou les outils bureautiques collaboratifs (Gmail, Drive, Office 365, …) entraîne une utilisation accrue d’Internet. Et ce nouvel usage peut amener à remettre en cause les centralisations réalisées précédemment. Au minimum, une revue des bandes passantes disponibles et une projection des consommations s’avèrent nécessaires pour éviter des déconvenues, au moment de la mise en service. Et quand l’entreprise compte plusieurs milliers de sites, l’opération peut prendre facilement plusieurs semaines, voire plusieurs mois…
Mais le point le plus structurant concerne les interconnexions entre le réseau des datacenters et le (ou les) fournisseur(s) Cloud retenu(s). Ceux-ci offrent de nombreuses possibilités en matière de réseaux virtuels, de VLAN, de contrôles de flux entre zones, etc.. , construites sur des mécanismes virtuels. Par conséquent, les mécanismes et les architectures réseau et sécurité internes à l’entreprise, construits avec la mise en oeuvre d’équipements physiques en coupure de flux, ne peuvent pas être reproduits et “propagés” tels quels dans le Cloud. Et c’est pourquoi les discussions peuvent être longues et complexes avec les RSSI !
S’appuyer sur les mêmes principes que le cloud
Ceci met en évidence la nécessité d’inverser l’approche : au lieu de chercher désespérément à “pousser” dans le cloud ses propres règles, il faut au contraire faire en sorte que son réseau interne s’appuie sur les mêmes principes que le cloud… pour aboutir à une architecture cohérente, rendant possible le fonctionnement hybride et son exploitabilité. Le cloud étant synonyme d’une accélération du “time-to-market”, il ne serait pas concevable que la moindre demande de changement, comme des ouvertures de flux, entraîne des délais, voire des dysfonctionnements.
Les règles de segmentation doivent être abordées dès le début dans une vision globale (public / privé) et bâties sur des critères simples, propres à l’entreprise, comme la classification des données, le réseau d’accès (Internet ou réseau interne), les environnements, ... . Et s’assurer que le provisionning des services dans ces zones pourra se faire de manière fluide.
Au-delà des problématiques d’architecture, il ne faut pas oublier le “support” pour cette interconnexion : VPN sur Internet ? Une offre de son opérateur WAN qui peut disposer de connecteurs avec les fournisseurs Cloud principaux ? Un accès fibre directement disponible entre l’hébergeur et le DC du fournisseur Cloud ? Un recours à des opérateurs spécialisés (InterCloud…) ? Toutes ces solutions doivent être pesées, en tenant compte du profil de consommation, de l’exigence d’engagement (SLA), des coûts, des engagements… en n’oubliant pas que le trafic descendant du cloud peut être aussi payant.
Tous ces sujets se cachent derrière le trait qui relie “simplement” le cloud public au réseau interne, sur le premier schéma de design réalisé en début de projet ! Et ne pas suffisamment anticiper le sujet peut entraîner des retards importants.
Après avoir commencé sa carrière dans le service en ingénierie informatique puis dans une première expérience de conseil en infrastructures, François Juillot a exercé pendant près de 10 ans les responsabilités de Directeur Infrastructures & Production au sein d’une grande PME. C’est armé de cette double compétence, capacité à délivrer des prestations de conseil au bon niveau et connaissance des problématiques concrètes des DSI, que François rejoint Devoteam Management Consulting. Depuis, il s’appuie sur son expertise en transformation d’infrastructures pour accompagner ses clients (Safran, Lafarge, Air Liquide, ENGIE…) sur des sujets de Stratégie IT et Datacenter, de migration vers des modèles Cloud.
