Cloud privé : 7 risques majeurs que vous ignorez peut-être

Créer un cloud privé dans votre centre de données sur site pourrait changer la donne. Un « cloud privé » implique la puissance de l'informatique à la demande, au gré de l'utilisateur, et une latitude totale pour l'élaboration d'une solution technique capable de satisfaire les besoins spécifiques de vos applications. Un cloud privé vous permet de ne plus être à la merci de fournisseurs tels qu'Amazon Web Services (AWS) ou Microsoft Azure, et de conserver votre liberté d'action, par exemple pour stocker les données localement et gérer facilement la conformité, ce qui entraîne généralement des économies considérables.

Les clouds privés présentent toutefois leurs propres défis à relever. L'adoption d'un cloud privé expose votre organisation à certains risques, parfois mal connus. Quels sont ces risques et peuvent-ils affecter votre choix entre cloud privé ou public ?

Nous présentons ici les sept risques susceptibles d'avoir un impact sur votre projet de cloud privé, de même que certaines des solutions envisageables pour les atténuer.

-ERR:REF-NOT-FOUND-

-ERR:REF-NOT-FOUND-En fin de compte, un cloud privé reste un cloud.

Dans la plupart des entreprises, les projets de cloud privé sont perçus comme un moyen de remédier aux problèmes associés à un cloud public. Il est néanmoins important de comprendre que les clouds privés utilisent la même infrastructure que les clouds publics, ou une infrastructure très similaire : du matériel de base à la gestion de l'infrastructure virtuelle (VIM) et la Gestion et orchestration (MANO), assurées par des logiciels tels que VMware vRealize® ou OpenStack, en passant par la virtualisation via des hyperviseurs comme VMware ESXi ou un commutateur écran-clavier-souris (KVM).

Les problèmes repérés dans les clouds publics, entre autres faible visibilité du trafic et de l'activité et failles de sécurité, sévissent également dans les clouds privés. Toutefois, si ces problèmes relèvent en grande partie de la responsabilité du fournisseur de cloud public lorsque vous optez pour cette formule, ils vous incombent lorsque vous choisissez un cloud privé.

Vous attendez généralement des fournisseurs de cloud public, pour qui le cloud est l'activité principale, qu'ils soient mieux pourvus en personnel compétent pour exploiter cette technologie et en gérer les problèmes. Votre propre personnel informatique dispose-t-il du même niveau de compétence ? Combien coûterait leur formation aux nouvelles technologies, par exemple à OpenStack, ou le recrutement de nouveaux experts du cloud ?

De la gestion des correctifs à la mise à jour des politiques et l'adoption d'une nouvelle technologie, toujours susceptible d'introduire des vulnérabilités et d'exposer votre infrastructure à de nouveaux vecteurs de menace, comment allez-vous gérer la sécurité dans votre cloud privé ?

Il est vrai qu'au sein de votre centre de données, vous serez mieux à même de résoudre les problèmes essentiels avec une plus grande latitude et davantage de contrôle. Mais, pour commencer, il vous faudra faire face aux mêmes difficultés.

-ERR:REF-NOT-FOUND-Risque n°1 : Violations de sécurité

La sécurité d'un cloud public incombe en partie au fournisseur du cloud et en partie à l'organisation qui en consomme les services. Tout ce qui se produit dans les machines virtuelles (VM) relève de votre responsabilité, tandis que la gestion et la protection du matériel lui-même, la virtualisation et les services cloud, incombent au fournisseur de cloud.

En réalité, un cloud privé peut être moins sécurisé qu'un cloud public. En matière de sécurité, les fournisseurs de cloud public ont une longue expérience et un savoir-faire maîtrisé. Ils disposent généralement de stratégies, de techniques et d'outils parfaitement au point pour protéger les diverses couches de la pile cloud. Bien évidemment, les clouds publics sont une cible bien plus importante pour les pirates, mais les fournisseurs de cloud comprennent parfaitement les problèmes de sécurité propres au cloud et savent y pallier. En tant qu'entreprise privée, il vous faudra apprendre tout cela.

Les clouds hybrides, de plus en plus nombreux, posent d'autres problèmes. Sécuriser un cloud hybride se révèle encore plus complexe. Lorsque vous migrez des charges de travail du cloud privé vers le cloud public (ce qui est possible à la demande), comment étendre la protection de votre centre de données privé jusqu'au cloud public ? Une certaine transition entre vos systèmes de sécurité internes et ceux du cloud public sera alors inévitable. Lors d'une telle transition, alors que trafic et applis passent d'un système à l'autre, le risque de « défaut de sécurité » ouvrant la porte à des violations est majeur. Et ce problème n'est pas facile à résoudre.

-ERR:REF-NOT-FOUND-Risque n°2 : Problèmes de performances

Les performances sont un problème bien connu dans les environnements virtualisés. La nature hautement dynamique de l'environnement, qui complique grandement les prévisions d'évolution des charges au niveau de l'infrastructure, a une incidence sur les performances des applications et sur le confort d'utilisation.

Dans un cloud public, les utilisateurs connaissent le nombre d'instances de machine et les ressources informatiques à leur disposition, mais bien d'autres éléments sont susceptibles d'affecter les performances : bande passante du réseau, latence et gigue, voisinage gênant sur les ressources partagées, accès aux ressources et services clés et vitesse de cet accès, etc. Pour plus d'informations sur les risques de performances médiocres avec le cloud public, consultez notre page : « VPC : le jeu en vaut-il la chandelle ? ».

Votre latitude est bien plus importante dans l'élaboration d'un cloud privé. Vous pouvez choisir les composants matériels et logiciels, l'infrastructure réseau et la topologie susceptibles de garantir des performances optimales pour votre cas d'utilisation. Mais qui vous dit que vous bénéficierez réellement des performances promises en théorie ?

De même que les fournisseurs de cloud public ne sont pas toujours en mesure d'offrir les performances nécessaires à leurs utilisateurs du fait de la complexité des infrastructures virtualisées et à évolution dynamique, votre cloud privé n'atteindra pas toujours votre objectif théorique de performances.

Des goulots d'étranglement masqués peuvent se produire dans les systèmes virtualisés, et les performances risquent alors de dépendre de la combinaison actuelle de charges de travail, de mises à niveau logicielles pour VMware, OpenStack ou d'autres composants du système, et de bien d'autres facteurs. Comment être certain du bon fonctionnement de votre infrastructure dans tous les cas d'utilisation et toutes les situations de l'environnement, notamment lors des mises à niveau ?

Pour pouvoir atténuer ces risques, la mise en œuvre d'un processus ininterrompu, à même de valider les performances en permanence, est une étape essentielle. Lors de chaque déploiement, vous devez être en mesure de tester les performances de façon concrète et réaliste, de préférence de manière automatique, afin de détecter les problèmes le plus tôt possible. L'absence d'un tel processus expose votre organisation à d'éventuels problèmes de performance imprévisibles.

-ERR:REF-NOT-FOUND-Risque n°3 : Expertise et courbe d'apprentissage

Les clouds privés existent désormais depuis un certain temps, et la plupart reposent sur l'infrastructure logicielle bien connue de VMware, exploitée par une vaste base d'utilisateurs. De plus en plus de projets de cloud privé optent toutefois pour des plateformes Open Source, une option plus puissante et moins onéreuse. La technologie OpenStack devient peu à peu la nouvelle référence de facto pour les clouds privés, mais cette plateforme est encore mal connue.

Si votre équipe ne comprend pas d'experts chevronnés pour OpenStack (oiseaux plutôt rares), il leur sera extrêmement difficile de mettre un projet OpenStack sur les rails. Lors de l'étude menée en 2016 auprès d'utilisateurs d'OpenStack, ces derniers ont fait part de leurs difficultés et de la complexité inhérente à cette technologie, bien que la plateforme gagne progressivement en maturité. Lorsque tout n'est pas parfaitement réalisé dès le départ, un déploiement OpenStack risque de devenir problématique par la suite. Un tel déploiement peut alors affecter votre capacité à doter vos clouds privés des fonctionnalités nécessaires, voire retarder la réalisation du projet.

-ERR:REF-NOT-FOUND-Risque n°4 : Manque de visibilité

L'une des raisons justifiant la migration d'un cloud public vers un cloud privé est le gain de visibilité sur tout ce qui se passe dans le cloud. Il est courant de penser qu'en disposant d'une telle visibilité dans votre propre centre de données, il devient bien plus facile de discerner les charges de travail, l'utilisation, le trafic et les performances.

Dans le cas d'un cloud public, aucune solution simple ne vous permet de bénéficier d'une telle visibilité sur le trafic de votre réseau au niveau des paquets. Les outils de surveillance existants, comme Amazon CloudWatch et CloudTrail, ne vous permettent pas « d'inspecter l'intérieur des paquets » pour diagnostiquer avec précision les perturbations du réseau et éviter les problèmes de sécurité.

La situation n'est pas vraiment meilleure avec les clouds privés. Vous vous heurterez alors au problème du « trafic est-ouest » (données circulant entre les machines virtuelles), qui n'implique pas les câbles physiques et reste donc invisible pour les outils de surveillance traditionnels. Ce trafic est-ouest peut représenter 80 % (ou plus) du contenu circulant dans un centre de données virtualisé, donc un énorme angle mort pour les équipes informatiques.

Pour bénéficier d'une visibilité totale sur le trafic est-ouest circulant dans toute l'infrastructure du centre de données virtualisé, vous devez disposer d'une solution capable d'accéder au trafic destiné et provenant des différents utilisateurs et applications, et de l'acheminer vers les outils d'analyse chargés de l'inspecter et de signaler les problèmes.

-ERR:REF-NOT-FOUND-

-ERR:REF-NOT-FOUND-Risque n°5 : Limites d'échelle

Plutôt que de conserver un centre de données standard, de nombreuses entreprises construisent généralement un cloud privé pour bénéficier de la puissance de l'informatique à la demande et pouvoir développer plus rapidement des services et applications d'entreprise. Pour autant, et en définitive, les capacités de votre cloud privé dépendront de votre budget.

Que se passera-t-il alors si l'utilisation de vos applications dépasse largement le niveau prévu ? Par exemple, comment votre cloud se comportera-t-il si vous exécutez un service destiné aux clients et que l'utilisation « explose » ? Autre exemple, quelles modifications devrez-vous apporter à votre cloud privé si l'adoption d'un service d'entreprise va bien au-delà des prévisions ou encore si le volume de données augmente les attentes ?

Vous ne pouvez pas acheter sans fin des ressources informatiques supplémentaires pour prendre en charge les charges de travail du cloud privé, et en termes de rentabilité, acquérir un grand nombre de machines pour gérer la charge hors période de pointe n'a aucun sens.

La solution à ce problème passe généralement par un cloud hybride, qui autorise des « rafales » entre le cloud privé et le cloud public lorsque les charges de travail dépassent les capacités de vos ressources locales. Cependant, configurer un cloud hybride multiplie les coûts et la complexité de votre projet de cloud privé. Par ailleurs, le respect des réglementations externes ou des politiques internes est souvent ce qui justifie de commencer par la création d'un cloud privé. Par exemple, une politique interne peut obliger l'organisation à conserver les données hautement confidentielles sur site, sans aucune fuite vers le cloud public, ou encore une obligation légale peut imposer que ces données ne sortent jamais du pays. Dans un tel cas, utiliser un cloud hybride pour les pics de charge peut être problématique. Comment être sûr que seules les charges de travail non sensibles soient correctement réparties entre les clouds privé et public, tout en conservant sur site vos données confidentielles ou les informations soumises à réglementation ?

Si le cloud hybride n'est pas la bonne solution, vous risquez alors de dépasser votre capacité, donc de perdre les économies d'échelle et de budget qui ont motivé la création d'un cloud privé en premier lieu.

-ERR:REF-NOT-FOUND-Risque n°6 : Limites des services

Ce risque ne concerne pas le dimensionnement ni les capacités des services cloud. Un cloud public tel qu'Amazon EC2 ou Microsoft Azure permet d'accéder d'un simple clic à une multitude de services cloud, natifs et tiers, et d'obtenir toutes les fonctionnalités désirées : capacités de gestion avancée, dimensionnement automatique, haute disponibilité, services de stockage, provisionnement instantané des bases de données, clusters de Big Data, etc.

La plupart de ces capacités sont disponibles avec un cloud privé, mais il vous faudra alors les planifier, et consacrer suffisamment de temps et d'argent à leur intégration et leur déploiement. Dans certains cas, vous devrez parfois créer entièrement ces capacités. En particulier, il est difficile de recréer en interne les fonctionnalités de haute disponibilité et de résilience qu'offrent certains services cloud, par exemple Amazon AWS. Une fonction comme Multi-AZ, qui permet de conserver les réplicas des instances de machine dans un autre centre de données, se révélera impossible à mettre en œuvre dans la plupart des clouds privés.

En vérité, votre cloud privé ne disposera que des fonctions que vous aurez créées. Lorsqu'une fonction donnée n'est pas déjà incluse dans votre projet, votre capacité à innover est alors limitée dans votre cloud privé.

-ERR:REF-NOT-FOUND-Risque n°7 : Pertes de données

Selon les données obtenues par Veritas* sur 6 000 sources de risque pesant sur les données d'entreprise, la plupart des implémentations de cloud privé s'exposent à des risques majeurs de perte de données. Ces pertes de données peuvent se produire au sein de trois couches : la couche de l'hyperviseur, la couche des machines virtuelles et la couche du système de récupération d'urgence ou de sauvegarde. Du fait de la nature dynamique d'un cloud privé, les techniques classiques de protection des données peuvent se révéler insuffisantes, voire ne pas fonctionner comme prévu dans tous les cas. Il existe également un certain nombre de risques de configuration inadéquate dont les conséquences peuvent être désastreuses.

En voici quelques exemples courants, généralement mentionnés dans l'étude de Veritas :

  • L'exécution de plusieurs versions de VMware ESX, dont certaines utilisent des options du système de fichiers de machine virtuelle (VMFS) non prises en charge par les versions plus anciennes, peut générer des échecs de VM, des pertes de données et des interruptions de l'activité.
  • Lorsqu'une application sensible s'exécute sur deux machines virtuelles, l'une sous forme de copie en production et l'autre en tant que copie de sauvegarde, la défaillance de l'une de ces deux VM entraîne généralement un basculement automatique. Si ce basculement exécute la sauvegarde sur le même hôte physique que la copie en production, il existe un point unique de défaillance.
  • Lorsqu'un RAID 1 hautes performances est utilisé pour les données en production et un RAID 5 aux performances moindres pour l'archivage et la simulation, un décalage peut se produire et dégrader les performances ou provoquer des pertes de données, car certaines VM écrivent les données de production dans le stockage moins performant.

-ERR:REF-NOT-FOUND-Réduction des risques inhérents au cloud privé grâce à Ixia

Ixia est l'un des leaders en matière de solutions de test, de visibilité et de sécurité pour le cloud et le réseau, avec une solide expérience des tests et de la validation des périphériques réseau et des infrastructures virtualisées. La plupart des principaux fournisseurs de cloud et des grandes entreprises qui exécutent leurs charges de travail les plus importantes sur des clouds privés testent actuellement leurs implémentations avec des produits Ixia pour les valider.

Nous ignorons l'origine de certains des problèmes liés aux clouds privés et mentionnés ici. Les départements informatiques n'ont pas une grande expérience des clouds privés ; ils ignorent comment ils fonctionnent et à quoi s'attendre selon les différents scénarios.

Ixia offre une méthodologie exclusive pour simuler ces scénarios et les tester dans des conditions réalistes. Vous pouvez l'appliquer pendant que les systèmes sont encore en développement, puis également en continu pendant l'exploitation en production. Les tests en continu aideront les organisations à se familiariser avec les solutions techniques et les processus opérationnels qui identifieront les problèmes potentiels dans l'implémentation du cloud privé afin de les résoudre avant qu'ils ne causent des dégâts. Ixia fournit également une visibilité complète du trafic est-ouest circulant à l'intérieur des centres de données modernes et des clouds privés, ce qui permet aux équipes informatiques de diagnostiquer les problèmes de performance, d'identifier les failles de sécurité, etc.

Nous avons élaboré un guide rapide afin de vous aider à tester et surveiller en continu votre cloud privé, et ainsi réduire les risques et garantir que vous exploitez au mieux votre investissement à l'aide des solutions Ixia.