Network Security for Azure VMware Solution

Introduction

Comme je l’avais annoncé à la fin de mon précèdent article, où j’avais fait une Overview de la mise en réseau des clouds privés Azure VMware Solution (AVS), je reviens vous parler des options que vous pouvez utiliser pour sécuriser la solution.

Lors de l'integration d’AVS avec l'écosystème cloud Azure la conception de la sécurité suivra des considérations spécifiques aux scénarios cloud natifs et aux scénarios hybrides.

Quel service faut-il prendre ? Où est ce qu’il faut le placer ? On-premises ? Dans un VNET Azure ? Ou dans AVS ? Et quelles sont les bonnes pratiques à suivre selon l’option choisie ?

Rappel : Qu’est-ce qu’AVS

Un service Microsoft validé par VMware qui permet aux clients de déplacer de manière fluide leurs workloads VMware vers une infrastructure cloud dédiée dans Azure et intégrer leur environnement VMware à Azure.

AVS est un service dit « Dedicated », à l’instar de Skytap ou SAP HANA Large instances, et est deployé sur une infrastructure Azure en bare metal dédiée. D’où lors du déploiement d’un cloud privé AVS, un lien Expressroute (ER) est automatiquement provisionné entre le rack AVS et les routeurs Microsoft Enterprise Edge dédiés (D-MSEE) fournissant une connectivité à haut débit et faible latence via le backbone Azure. Cet ExpressRoute peut être par la suite connecté à Azure ou à un autre circuit ExpressRoute vers votre site On-premises.

Uses cases

Les scénarios les plus intéressants avec AVS incluent :

• La réduction, consolidation et retrait de l'empreinte du Datacenter
• L’extension du Datacenter à la demande
• La continuité et reprise d’activité après sinistre
• La modernisation d’applications avec l’écosystème Azure

Sécuriser le cloud privé AVS

L'architecture à choisir pour votre solution AVS et la manière de structurer les services dépendent de vos workloads et des exigences de votre organisation.

Parmi les principales considérations qui influencent votre décision sont les exigences d'inspection du trafic :

• Au sein du cloud privé AVS
• Ingress (HTTP/S ou pas) et Egress des applications AVS
• Entre AVS et le réseau virtuel Azure
• Entre AVS et les datacenters On-premises

Viendront s’ajouter à ces considérations des contraintes éventuelles liées à l'infrastructure existante comme l’utilisation d’une appliance virtuelle réseau (NVA), la connectivité d’AVS à un réseau virtuel Hub (dans une topologie Hub & Spoke) ou à un Hub virtual WAN et l'utilisation de fonctionnalité Global Reach pour le circuit ER connecté On-premises.

La sécurité au sein du SDDC AVS

Lorsque vous créez un cloud privé AVS, une passerelle NSX-T T0 configurée en mode actif/actif et une passerelle NSX-T T1 configurée en mode actif/standy sont déployées pour vous. Vous pouvez ensuite connecter des segments (switches logiques) et fournir une connectivité Nord-Sud et Est-Ouest aux workloads connectés sur ces segments.

Pour inspecter le flux au sein du cloud privé, vous pouvez utiliser les fonctionnalités de sécurité prêtes à l'emploi offertes par NSX-T ou des solutions tierces pour protéger vos workloads :

• Le Pare-feu distribué (DFW) : Un pare-feu avec état s'exécutant sur les hôtes ESXi qui permet la micro-segmentation. Les règles DFW sont appliquées au niveau des vNIC des VMs du cloud privé. DFW vous permet de définir des règles Ethernet (règles L2) et des règles générales (règles L3 à L7). Même si vous disposez déjà d'un pare-feu de périmètre, le DFW vous permettra de sécuriser en plus votre trafic Est-Ouest.
• Le Pare-feu de passerelle : Un pare-feu L4-L7 Nord-Sud avec état qui peut être configuré sur la passerelle NSX-T T1. Il peut également être utilisé comme pare-feu inter-tenants ou inter-zones, c'est-à-dire filtrer le trafic entre les différents tenants de votre organisation, chacun avec une passerelle de T1 dédiée.
• Un Pare-feu tiers déployé en tant que NVA dans AVS et connecté au sud de la passerelle T1. Il peut ainsi agir comme un pare-feu Nord-Sud ou Est-Ouest selon votre cas d'usage comme illustré dans le schéma ci-dessous:

Points d’attentions !

1. La NVA suit le modèle Bring Your Own License (BYOL) et il est de votre responsabilité d'apporter la licence et de mettre en œuvre la haute disponibilité pour la NVA.
2. La limitation VMware de huit cartes d'interface réseau virtuelles (vNIC) maximum sur la VM NVA peut vite devenir un facteur limitant. D’où il est recommandé d’adopter l’option 2 (à droite dans le schéma) dans laquelle les segments de workload sont connectés à une passerelle T1 isolée qui est à son tour connectée à la NVA. Cette topologie résout le problème du nombre limité de vNIC sur la NVA. Des niveaux 1 isolés simulent des zones de sécurité et la NVA peut fournir un filtrage Est-Ouest entre les zones de sécurité et un filtrage Nord-Sud pour tout le trafic.

La sécurité du flux internet ingress/egress d’AVS

Il existe plusieurs solutions pour sécuriser le flux internet entrant et sortant des VMs hébergées dans AVS sans qu’aucune adresse IP publique leur soit assignée directement afin de réduire la surface d’attaque. De plus, vous pouvez activer la DDoS Protection Standard pour la ou les IPs publiques de la solution choisie.

1.      Pour le trafic http/https :

Vous pouvez utiliser Azure Application Gateway pour exposer les applications Web hébergées sur AVS et sécuriser le trafic http/https entrant en tirant parti de la fonctionnalité de terminaison SSL (Secure Sockets Layer) et du Web Application Firewall (WAF) qui fournit une protection centralisée de vos applications Web contre les exploits et les vulnérabilités courants comme l'injection SQL et les scripts intersites etc.

Azure Application Gateway est actuellement la seule méthode prise en charge pour exposer à Internet des applications Web s'exécutant sur des VMs dans AVS. Elle peut également exposer les applications aux utilisateurs internes en toute sécurité.

Azure Firewall (AzFW) quant à lui, peut être utilisé pour l’inspection L7 du flux sortant uniquement.

2.      Pour le trafic non-http(s) :

Diverses solutions peuvent être utilisées pour réaliser du Destination NAT (DNAT) L4 comme AzFW ou une autre NVA pare-feu déployée dans un Vnet connecté à AVS, qui permettrait d’inspecter le flux vers/depuis Internet.

Vous pouvez également utiliser la fonctionnalité « Public IP Connectivity » d’AVS en quelques clics depuis le portail qui consiste à deployer un vWAN Hub avec une instance d’AzFW et une connectivité ER avec AVS. Bien entendu, vous pouvez tout à fait utilisez un vWAN Hub existant et inspecter le flux Internet avec AzFW ou une NVA.

Les limites de scale déterminent généralement la solution choisie. Mais quel que soit votre choix, assurez vous de la bonne coordination avec la configuration du Source NAT (SNAT) et des routes par défaut que vous mettez en place.

Integration d’AVS dans une architecture Hub & Spoke

AVS est dans la plupart des scénarios intégré dans une architecture Hub and Spoke existante ou nouvelle sur Azure. Le hub agit comme un point central de connectivité à votre datacenter sur site et au cloud privé AVS.

--> Besoin : Utiliser mon AzFW (ou NVA) existant pour inspecter tout le trafic privé et segmenter la communication entre le datacenter sur site, les spokes Azure et les workloads AVS centralisant ainsi la sécurité dans le Hub Azure. Les modèles d'ingress et egress qu’on a vu avec Application Gateway, Azure Firewall (ou NVA) restent plus ou moins similaires pour tous les scénarios. 

--> Problématique : Par défaut, le trafic privé entre le datacenter sur site et le cloud privé AVS est acheminé via le Global Reach car la passerelle ExpressRoute ne fournit pas de routage transitif entre ses circuits connectés. Le trafic ne remonte donc pas jusqu’au Hub pour être inspecté !

Je vais vous présenter ici quelques options pour contourner cette limitation et le choix dépendra en général des contraintes du client en termes de sécurité et de budget.

Option 1 : Utiliser des solutions différentes pour inspecter le trafic privé

• Pour inspecter le trafic entre les spokes Azure et AVS ou l’On-premises --> Utiliser la NVA du Hub
• Pour inspecter le trafic entre AVS et l’On-premises --> Implémenter des mécanismes de segmentation du trafic, soit sur site, soit dans AVS (voir l’exemple illustré ci-dessous)

NB: Cette solution est assez simple à mettre en place et ne demande pas beaucoup d’efforts de conception et de configuration, mais elle peut ne pas répondre aux contraintes de sécurité pour centraliser l’inspection du trafic dans le Hub.

Option 2 : Utiliser AzFW dans un hub sécurisé vWAN pour inspecter tout le trafic privé

Cette solution repose les stratégies de routage vWAN du trafic privé qui permettent de filtrer tout le trafic privé y compris le trafic de branche ER à branche ER via AzFW, chose qui n’était pas possible avant l’annonce de cette fonctionnalité (Encore en preview). En effet, dans Azure vWAN une connectivité de branche ER branche à ER ne peut être assurée que via le Global Reach entre les deux circuits.

Dans le contexte d’AVS, les deux Branches ER connectées à un Hub vWAN représentent les circuits ER On-premises et AVS, et le trafic entre les deux passera et sera inspecté par l’AzFW déployé dans le Hub vWAN, comme illustré dans le schéma ci-dessus.

NB: Cette solution répond au besoin de centraliser l’inspection du trafic privé pour les architectures basées sur le vWAN. Cependant, vu qu’elle est encore en Preview nous ne vous recommandons pas de la mettre en place pour vos environnements de PROD pour le moment.

Option 3 : Utiliser la NVA du hub pour inspecter tout le trafic privé

Cette solution consiste à influencer le routage du flux entre AVS et l’on-premises à passer par la ou les NVAs du Hub en utilisant le protocole de routage Border Gateway Protocol (BGP).

Pour simplifier le routage avec les NVAs dans Azure, le nouveau service Azure Route Server (ARS) permet l’échange des informations de routage entre la NVA le VNET Azure par le biais du BGP. Vous n'avez plus besoin de mettre à jour manuellement la table de routage sur votre NVA chaque fois que vos adresses de VNET sont mises à jour ou encore les UDRs (user defined routes) chaque fois que votre NVA annonce de nouveaux itinéraires ou supprime les anciens. ARS s’intègre également aux passerelles de VNET (ER ou VPN).

--> Problématique : Pour inspecter le trafic entre l’On-premises et AVS, vous aurez besoin d'une route UDR sur le sous-réseau de la passerelle ER pour envoyer le trafic vers la NVA. La NVA traiterait le trafic et le renverrait au sous-réseau de la passerelle car il s'agit de la direction du trafic AVS. Cela créera une boucle entre la NVA et la passerelle ER dans le sous-réseau de la passerelle comme c’est illustré dans le schéma ci-dessous :

--> Solution : Vous devez créer une architecture réseau différente avec une passerelle ER distincte pour AVS. Comme on ne peut en avoir qu’une dans un VNET, un VNET distinct est également requis.

Azure Route Serveur est déployé dans chaque VNET avec l’option branche à branche activée afin de permettre l’échange de route BGP entre la passerelle ER et la NVA. 

Un tunnel VXLAN (Virtual Extension LAN : une technologie de virtualisation de réseau qui fournit des réseaux superposés de couche 2 au-dessus d'un réseau de couche 3 en utilisant l'encapsulation de l'adresse MAC dans le protocole UDP) et une session eBGP sont établis entre les deux NVAs. La solution est illustrée ci-dessous et décrite en détail dans le Github:

NB: Cette solution peut être complexe à mettre en place et implique l’utilisation d'un overlay de routage basé sur les capacités de la NVA mais l’avantage avec le tunnel VXLAN est qu'aucune route UDR n'est requise et que le système met à jour automatiquement les nouvelles routes sans intervention manuelle.

--> Points d’attention :

Le nombre de passerelles ER et de NVA peut influencer la latence et le débit de l'environnement. Pour valider cette solution, vous devez tester la latence et les performances en utilisant des outils comme qperf ou iperf (Et non pas le Ping car le trafic ICMP n'est pas prioritaire sur Azure).

Le choix de la série de VM de la NVA, et donc de la bande passante de la carte réseau associée, peut également être un facteur limitant.

Il est fortement recommandé aussi d'utiliser des passerelles ER ultra performantes et la fonctionnalité FastPath qui permet de bypasser la passerelle ER pour le chemin des données.

Conclusion :

Plusieurs options, plus ou moins simples, s’offrent aux clients pour sécuriser les clouds privés AVS et la solution choisie peut être une combinaison qui permet de répondre à leurs contraintes de sécurité pour les différents types de trafics : Nord-Sud ou Est-Ouest, Internet ou Privé etc.

Les options les plus complexes à mettre en place restent celles où les clients souhaitent conserver une cohérence opérationnelle avec leurs plates-formes de mise en réseau et de sécurité tierces existantes.

Voilà ! J’espère que cet article vous a aidé à comprendre les différentes solutions et les paramètres à prendre en compte lorsque vous allez faire votre choix. Ce sujet évolue assez rapidement donc je vous conseille de garder un œil sur les publications et annonces de Microsoft sur les différents canaux.

Je remercie Franck Villaume et Alexandre Weiss pour leur support lors de la préparation de cet article, et je termine comme d’habitude avec quelques liens intéressants : 

Network topology and connectivity for Azure VMware Solution

Integrate Azure VMware Solution in a hub and spoke architecture

Entreprise scale network security

Connecting 3rd Party Networking and Security Platforms

Firewall integration in Azure VMware Solution