Pourquoi l'informatique dématérialisée hybride n'est pas synonyme de sécurité hybride ?

Les réseaux hybrides en nuage permettent de résoudre de nombreux problèmes qui se posent aujourd'hui aux réseaux d'entreprise. Ils permettent la création d'une architecture de réseau unique, qui s'affranchit des environnements de centres de données sous-jacents. Ils permettent également la tolérance aux pannes, la résilience, des services "élastiques" dans les centres de données et une topologie de réseau qui ne dépend pas d'un seul fournisseur de réseau sous-jacent. Une entreprise peut gérer plusieurs environnements réseau physiques, mais peut-elle créer une structure réseau unique pour l'ensemble de ces environnements ? 

Par exemple, une entreprise peut maintenir deux centres de données (un principal et un autre pour la reprise après sinistre), en plus de plusieurs déploiements de nuages publics sur AWS, Azure, et/ou GCP. Chacun de ces environnements d'hébergement déploie ses propres architectures de réseau physique sous-jacentes avec ses propres technologies spécifiques, souvent avec différents fournisseurs de routage et de commutation.

Mais avec l'avènement du Software-Defined Networking (SDN) dans l'industrie des réseaux, la majorité des fournisseurs de réseaux peuvent aujourd'hui créer leur propre "nuage". Dans la terminologie des réseaux, un nuage est essentiellement un réseau virtuel, où la topologie du réseau est abstraite au-dessus de la topologie physique, souvent appelé "réseau superposé". Et un réseau superposé est essentiellement une collection de tunnels, tous gérés par un contrôleur SDN central. Ce nuage peut créer un réseau unique et unifié dans tous les environnements d'hébergement gérés. 

Un protocole de tunnelisation, tel que VXLAN, est utilisé pour créer la topologie du réseau superposé, de sorte que le chemin du trafic est déterminé par la manière dont ces tunnels sont déployés plutôt que par la manière dont la topologie physique sous-jacente est déployée. Tous les fournisseurs de réseaux utilisent des termes différents pour décrire leur approche basée sur le SDN, mais en fin de compte, ils font tous la même chose : utiliser des tunnels pour créer un réseau superposé qui est automatisé et géré par un contrôleur central. 

Bien que nombre de ces fournisseurs soient en mesure d'étendre les réseaux superposés des centres de données sur site aux fournisseurs de clouds publics, la réalité est que de nombreuses entreprises ne déploient des réseaux superposés que localement dans leurs centres de données sur site.

Au lieu d'étendre leur solution SDN sur site au cloud public (par exemple, en étendant leur topologie de réseau tunnel à AWS ou Azure), de nombreuses entreprises créent des environnements gérés localement dans leurs instances de cloud public et gèrent ces réseaux différemment de la manière dont elles gèrent les réseaux de leur centre de données sur site. Ils choisiront souvent d'utiliser les approches de mise en réseau déjà utilisées par chaque fournisseur de cloud public, telles que les VPC dans AWS et les VNet dans Azure, puis de gérer différemment les solutions SDN dans leurs centres de données sur site.

Il en résulte un déploiement de réseau hybride en nuage qui est géré selon une approche de type "fauteuil pivotant". Le gestionnaire de réseau fera des allers-retours entre les outils utilisés pour gérer son centre de données sur site et ceux utilisés pour gérer ses réseaux publics en nuage. Le terme "nuage hybride" implique souvent une architecture unique et unifiée, ce qui n'est pas toujours le cas en ce qui concerne les opérations. 

Sécuriser votre environnement hybride

Cette approche fragmentée de la gestion du réseau est particulièrement vraie pour la sécurité dans un nuage hybride. Tout comme les outils de réseau gérés localement sont utilisés dans chaque environnement, qu'il s'agisse de centres de données sur site ou de nuages publics, il en va de même pour les solutions de sécurité. La plupart des fournisseurs de réseaux SDN disposent de leurs propres outils de sécurité intégrés de base qui peuvent être utilisés pour permettre un certain niveau d'application des politiques dans leur environnement géré localement. Et tous les principaux fournisseurs de clouds publics disposent de leurs propres solutions de sécurité, permettant également des niveaux de base d'application de politiques.

Malheureusement, ces outils de sécurité sont cloisonnés dans l'architecture globale. Chaque solution de sécurité ne joue pas bien dans le bac à sable avec les autres, et la corrélation d'une faille de sécurité entre toutes ces solutions est une tâche fastidieuse qui entraîne des retards importants dans la résolution des problèmes. 

En outre, si les charges de travail sont migrées en direct entre les environnements, par exemple entre un centre de données sur site et une instance de cloud public, l'application de la politique ne suivra généralement pas cette charge de travail jusqu'à sa destination. Il en résulte la nécessité d'adopter des approches manuelles pour transférer d'une manière ou d'une autre la politique entre les outils de sécurité dans chaque environnement ou de s'appuyer sur une solution SIEM pour obtenir des informations provenant de tous les environnements, ce qui nécessite un important travail de script en amont.

En raison de la complexité opérationnelle, ces étapes ne sont tout simplement pas souvent réalisées, ce qui entraîne des lacunes importantes en matière de sécurité et de visibilité de la charge de travail dans le nuage hybride.

Au lieu de s'appuyer sur les outils de sécurité natifs et cloisonnés de chaque environnement réseau d'un nuage hybride pour assurer la sécurité de vos charges de travail, pourquoi ne pas simplement assurer la sécurité et la visibilité directement au niveau de la charge de travail, en faisant abstraction des outils de réseau sous-jacents ?

Tout comme les réseaux superposés créent des topologies qui s'affranchissent des dépendances des routeurs et des commutateurs sous-jacents, pourquoi ne pas appliquer la même approche à la sécurité ? La sécurité devrait également être abstraite - virtualisée - des dépendances du réseau sous-jacent et activée directement au niveau de la charge de travail, indépendamment de l'endroit où cette charge de travail est hébergée ou de l'endroit où elle migre au cours de son cycle de vie. Tout comme les réseaux superposés permettent une approche cohérente de la mise en réseau dans un nuage hybride, la sécurité doit être conçue de la même manière. 

Comment la microsegmentation peut vous aider

Chez Illumio, nous appliquons la sécurité (micro-segmentation) directement à chaque charge de travail dans l'ensemble d'un nuage hybride. Comme la politique de micro-segmentation doit être appliquée au plus près de l'entité que vous essayez de protéger, nous déployons un agent léger sur chaque charge de travail, qu'elle soit virtuelle ou bare-metal :

• Cet agent n'est pas en ligne avec le trafic. Il réside simplement en arrière-plan et surveille le comportement de l'application directement sur la charge de travail.
• Les informations sont ensuite renvoyées au Policy Compute Engine (PCE) pour permettre une visibilité claire du comportement de toutes les charges de travail, indépendamment de l'endroit où elles sont hébergées ou des environnements réseau entre lesquels elles migrent. Essentiellement, nous virtualisons la sécurité, abstraction faite des dépendances sous-jacentes du réseau.
• Le PCE central utilise de simples étiquettes pour définir ce qui doit être segmenté, car la définition d'une politique en fonction des adresses IP n'est pas adaptée aux architectures dans lesquelles les charges de travail migrent de manière dynamique et les adresses IP changent. 

Bien que l'ECP crée une architecture de sécurité virtualisée, il peut également "descendre" dans la couche réseau et configurer des listes d'accès à des commutateurs matériels dans un centre de données sur site, si nécessaire. Ainsi, alors que la sécurité est virtualisée et abstraite au-dessus du réseau, Illumio peut appliquer la sécurité de la charge de travail et du réseau à partir d'un modèle opérationnel de politique centrale. 

Si vous définissez les ressources de base essentielles d'un centre de données ou d'un nuage hybride comme étant le calcul, le stockage et le réseau, ces trois ressources sont désormais couramment virtualisées et abstraites au-dessus des ressources sous-jacentes.

La quatrième ressource essentielle du centre de données est la sécurité, qui devrait également être virtualisée et sous-tendre les dépendances des ressources. L'informatique dématérialisée hybride ne doit pas être synonyme de sécurité hybride. La sécurité doit s'étendre à l'ensemble de la structure du nuage de réseau, et la sécurité de la charge de travail doit être appliquée directement à la charge de travail, en tant que "structure" de sécurité unifiée sur l'ensemble des structures de réseau. La virtualisation de la sécurité permet aux architectes du réseau sous-jacent de se concentrer sur les priorités du réseau et place la sécurité de la charge de travail là où elle doit être : directement au niveau de la charge de travail.

Découvrez comment cette approche facilite la gestion de la sécurité dans vos environnements de cloud hybride.