Pourquoi le cloud hybride ne doit pas être synonyme de sécurité hybride

Les structures de réseaux cloud hybrides permettent de résoudre de nombreux défis auxquels sont confrontés les réseaux d'entreprise actuels. Ils permettent de créer une architecture réseau unique, qui est abstraite au-dessus 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 réseau qui ne dépend d'aucun 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 tous ces environnements ?

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

Mais avec l'avènement de Réseau défini par logiciel (SDN) Dans le secteur des réseaux, la majorité des fournisseurs de réseaux peuvent aujourd'hui créer leur propre « cloud ». Dans la terminologie des réseaux, un cloud est essentiellement un réseau virtuel, dont 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 un ensemble de tunnels, tous gérés par un contrôleur SDN central. Ce cloud peut créer une structure réseau unique et unifiée pour tous les environnements d'hébergement gérés.

Un protocole de tunneling, tel que VXLAN, est utilisé pour créer la topologie du réseau superposé, de sorte que le chemin du trafic soit 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 pour y parvenir, mais en fin de compte, ils font tous la même chose : utiliser des tunnels pour créer un réseau superposé automatisé et géré par un contrôleur central.

Alors que bon nombre de ces fournisseurs ont la capacité d'étendre les réseaux superposés des centres de données sur site aux fournisseurs de cloud public, 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 la topologie de leur 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 leurs réseaux de centres de données sur site. Ils choisissent souvent d'utiliser les approches réseau déjà utilisées par chaque fournisseur de cloud public, telles que les VPC dans AWS et VNet dans Azure, puis gèrent différemment les solutions SDN dans leurs centres de données sur site.

Le résultat est un déploiement de réseau cloud hybride géré selon une approche « fauteuil pivotant ». Le gestionnaire du réseau fera pivoter son fauteuil d'avant en arrière entre les outils utilisés pour gérer son centre de données sur site et les autres outils utilisés pour gérer ses réseaux de cloud public. Le terme cloud hybride implique souvent une architecture unique et unifiée, ce qui n'est souvent pas exact en termes d'opérations.

Sécurisation de votre environnement hybride

Cette approche fragmentée de la gestion du réseau est particulièrement vraie en ce qui concerne la sécurité dans un cloud hybride. Tout comme les outils réseau gérés localement sont utilisés dans chaque environnement des centres de données sur site et des clouds 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 cloud public disposent de leurs propres solutions de sécurité, permettant également des niveaux de base d'application des politiques.

Malheureusement, ces outils de sécurité sont cloisonnés dans l'architecture globale. Chaque solution de sécurité ne fonctionne pas bien dans le bac à sable avec les autres, et la mise en 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.

En outre, si les charges de travail sont migrées en direct entre des 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. Cela nécessite des approches manuelles pour transférer d'une manière ou d'une autre les politiques entre les outils de sécurité de chaque environnement ou le recours à une solution SIEM pour alimenter les informations de tous les environnements, ce qui nécessite un travail de script initial important.

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

Au lieu de vous fier aux outils de sécurité natifs cloisonnés de chaque environnement réseau d'un cloud hybride pour renforcer la sécurité de vos charges de travail, pourquoi ne pas simplement renforcer la sécurité et la visibilité directement au niveau de la charge de travail, indépendamment des outils réseau sous-jacents ?

De la même manière que les réseaux superposés créent des topologies abstraites au-dessus des dépendances aux routeurs et commutateurs sous-jacents, pourquoi ne pas appliquer la même approche en matière de sécurité ? La sécurité doit également être dissociée (virtualisée) des dépendances sous-jacentes de la structure réseau et activée directement au niveau de la charge de travail, quel que soit l'endroit où cette charge de travail est hébergée ou vers laquelle elle migre en direct au cours de son cycle de vie. De la même manière que les réseaux superposés permettent une approche cohérente de la mise en réseau dans un cloud 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 sur l'ensemble d'un cloud hybride. Étant donné que la politique de microsegmentation 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, virtuelle ou nue :

• Cet agent n'est connecté à aucun trafic. Il se trouve simplement en arrière-plan et surveille le comportement des applications directement sur la charge de travail.
• Les informations sont ensuite renvoyées au Moteur de calcul des politiques (PCE) pour permettre une visibilité claire du comportement de toutes les charges de travail, quel que soit leur lieu d'hébergement ou les environnements réseau entre lesquels elles migrent en direct. Essentiellement, nous virtualisons la sécurité, indépendamment des dépendances réseau sous-jacentes.
• Le PCE central utilise des étiquettes simples pour définir ce qui doit être segmenté, car la définition d'une politique relative aux adresses IP n'est pas évolutive dans les architectures où les charges de travail migrent en direct de manière dynamique et les adresses IP changent.

Bien que le PCE crée une architecture de sécurité virtualisée, il peut également « descendre » jusqu'à la couche réseau et configurer des listes d'accès aux commutateurs matériels d'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 fois la charge de travail et sécurité du réseau à partir d'un modèle opérationnel stratégique central.

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

La quatrième ressource essentielle du centre de données est la sécurité. Elle doit également être virtualisée et les dépendances sous-jacentes en matière de ressources. Le cloud hybride ne doit pas être synonyme de sécurité hybride. La sécurité doit couvrir l'ensemble de la structure cloud du réseau, et la sécurité de la charge de travail doit être appliquée directement à la charge de travail, sous la forme d'une « structure » de sécurité unifiée sur toutes les structures réseau. La virtualisation de la sécurité permet aux architectes réseau sous-jacents 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.

En savoir plus sur la façon dont cette approche facilite gérez la sécurité dans vos environnements de cloud hybride.