[Article sponsorisé par Aviatrix]

Vous êtes nombreux à me demander si vous pouvez intégrer votre propre Firewall dans l’architecture Hub&Spoke d’Aviatrix afin d’augmenter le niveau de sécurité pour toute communication EST-WEST ou NORD-SUD ainsi que la sortie Internet.

La réponse est OUI, Aviatrix s’intègre facilement avec les différents Firewalls du marché pour permettre aux clients d’utiliser la couche du Firewalling de leur choix et ceci quel que soit le Cloud Provider.

Dans cet article on va voir les différents types d’architectures recommandées par Aviatrix pour faire transiter le trafic EST-WEST et NORD-SUD par une couche de Firewalling centralisée.

Un Firewall central pour tous les Clouds :

Cette architecture est adaptée pour les clients dont la grande majorité de leurs Workloads est hébergée chez un seul opérateur Cloud (AWS par exemple) et ils ont aussi quelques Workloads chez d’autres opérateurs cloud comme illustré dans le schéma ci-dessous :

Pour ce type de clients, le VPC HUB interconnecte par le biais des Gateways Aviatrix appelées Transit FireNet, les VPC et les VNET SPOKEs ainsi que l’On-Premise via des tunnels IPsec sécurisés et performants. Le VNET HUB héberge également les Firewalls en mode Actif/Actif.

Les FireNet du VNET HUB peuvent être programmés pour rediriger une partie ou la totalité du trafic traversant le VNET HUB par la couche du Firewalling pour permettre une inspection approfondie avant de rejoindre sa destination finale :

.

Le déploiement, la configuration réseau ainsi que la supervision de l’état des Firewalls sont également gérées depuis le contrôleur Aviatrix, de façon totalement automatisée.

L’utilisation des Firewalls en mode Multi-Actif est commun dans les architectures Clouds, cela permet l’exploitation de l’ensemble des Firewalls en plein régime. En termes de performance, Aviatrix supporte un throughput pouvant atteindre les 70Gbps (https://docs.aviatrix.com/HowTos/transit_firenet_faq.html). A noter que le débit maximum supporté aujourd’hui entre deux VPC AWS connectés via TGW est de 50Gbps.

Un Firewall par Cloud Provider :

C’est le même principe de l’architecture précédente mais au lieu d’avoir une couche de Firewalling centralisée pour l’ensemble des Clouds, le client peut opter pour une couche de Firewalling par Cloud Provider comme illustré dans le schéma ci-dessous :

Cette architecture est adéquate pour les clients Multi-Cloud (et/ou Multi-Région) qui cherchent à sécuriser la communication EST-WEST et NORD-SUD localement (au sein du même Cloud) pour réduire la latence et aussi permettre à l’équipe sécurité de chaque Cloud Provider de gérer leurs Firewalls d’une manière indépendante.

Les FireNet assurent la redirection du trafic vers les Firewalls locaux pour une inspection plus approfondie et ils permettent en même temps d’établir une communication sécurisée entre les environnements clients des différents providers par le biais des tunnels IPsec.

Pour le trafic Inter-Cloud, les clients ont le choix soit de faire inspecter le trafic par le Firewall local et de l’envoyer directement vers la destination (chemin vert) soit de le faire inspecter par le firewall local ainsi que le firewall distant avant que le flux n’atteigne sa destination finale (chemin gris).

Comment FireNet partage la charge entre les différents Firewalls ?

• AWS :

Dans l’environnement AWS, FireNet partage la charge entre différents Firewalls en calculant un hash à la base du 5 tuples « IP Source, Port Source, IP de Destination, Port de Destination, Protocole ».

Ce calcul du Hash assure l’envoi de tous les paquets du même flux d’une manière persistante vers le même Firewall. Les Gateways FireNet assurent aussi l’envoi des paquets vers le même Firewall sur le chemin retour pour garantir une inspection Stateful, et ceci sans avoir recours à du Source NAT, permettant ainsi de conserver la visibilité des IP sources au niveau des Firewalls.

Aviatrix FireNet supporte par ailleurs des designs à base de Gateway Load Balancer (GWLB) AWS.

• Azure :

Dans l’environnement Azure, le FireNet peut utiliser d’autres méthodes du Hashing pour garantir la persistance des sessions comme le 2 tuples (IP source et type de protocole) ou 3 tuples (IP source, IP de destination, et type de protocole). Aviatrix FireNet intègre de façon automatisée un Load Balancer natif Azure dans le design afin réaliser le partage de charge entre les Firewalls.

Conclusion :

La solution FireNet d’Aviatrix permet aux clients d’intégrer facilement leur propre solution de Filtrage dans un environnement Multi-Cloud, les grands avantages de cette solution sont :

• Une intégration standard et simplifiée qui s’adapte à tous les Cloud Providers publics
• Inspection totale ou partielle des flux EST-WEST, NORD-SUD et vers Internet
• Levée des limitations liées à la performance (design multi-actif, pas d’IPsec) ainsi qu’à la visibilité (pas de source NAT)
• Évolutivité en permettant de déployer plusieurs instances de Firewalling en mode Scale Out.
• Un déploiement automatisé et centralisé des composants réseaux depuis le contrôleur Aviatrix.