Comment déployer une architecture Hub-and-Spoke avec Azure Firewall

Article corédigé par Amine Teffahi et Gilles Etien
Azure firewall est la solution Azure permettant la sécurisation de votre réseau sur les couches 3 et 4 principalement mais aussi sur la couche 7 du modèle OSI. L’objectif de cet article est de vous présenter plusieurs cas de figure de sécurisation d’un réseau Hub and Spoke à l’aide d’Azure Firewall.
Cas pratique de sécurisation d’une plateforme : le scénario
Nous devrons déployer et sécuriser une plateforme ayant :
- Une virtual machine d’administration dans le premier spoke (1er réseau)
- Une virtual machine dans le spoke 2 (2nd réseau)
- Une webapp avec un private endpoint dans le spoke 2 (non accessible depuis Internet)
Nous souhaitons que :
- La machine VMAdmin soit accessible uniquement en passant par le firewall en RDP (Pas d’IP public rattaché à notre VM) ;
- VMAdmin accède à VM2 en passant par le firewall (réseau privé ) ;
- La WebApp soit accessible uniquement depuis la VMAdmin en passant par le firewalls.
Qu’est-ce qu’une architecture hub-and-spoke ?
Schématiquement, une architecture hub-and-spoke se compose de trois espaces réseau :
- Hub: c’est le point central d’une architecture en étoile. Il se compose a minima d’un Vnet hébergeant les services centralisés (Azure Firewall, VPN Gateway, Bastion, monitoring).
- Spoke 1 et 2: ils représentent des Vnet connectés via un peering au Hub. Ils doivent pouvoir communiquer l’un et l’autre en passant par le Hub et potentiellement publier des services à l’extérieur via le hub.
« Tous les chemins mènent au Hub dans une architecture en étoile »
Avantages et points d’attention sur une architecture en Hub-and-Spoke
Une architecture en Hub-and-Spoke présente de nombreux avantages :
- Maitriser les coûts en centralisant les services les plus onéreux tout en évitant de les multiplier par environnement.
- Interconnecter plusieurs réseaux indépendants: le point de passage doit être le hub pour une communication entre Spokes (flux Est/Ouest), vers ou venant d’Internet (Nord/Sud).
- Il s’agit d’une architecture évolutive.
- Le management des flux est centralisé sur le hub, à l’inverse des Network Security Groups.
- Les caractéristiques d’une architecture en étoile font que le Hub devient le point le plus central de la plateforme et doit bénéficier d’un service de recovery clairement défini.
- Ce type d’architecture a fait ses preuves.
Quels sont les services Azure utilisés ?
Plusieurs services Azure peuvent être utilisés :
- Virtual Network (indispensable): Composant de base qui représente le hub et les Spokes. Chaque Vnet doit avoir sa propre liste d’adresse IP indépendante. Ces IP ne doivent en aucun cas se chevaucher au risque de causer l’instabilité de toute la plateforme.
- Peering (indispensable): c’est une configuration du Vnet (Virtual Networking) utilisé pour faire communiquer les Vnets entre eux via le réseau Azure.
- User Defined Route – UDR (indispensable): c’est un service pour créer et personnaliser des flux réseaux.
- Azure Firewall: il n’est pas obligatoire dans le fonctionnement basique d’un hub-and-spoke. Cependant, il est fortement conseillé de l’implémenter pour sécuriser les flux de communications.
- Log Analytics workspace (monitoring) : c’est un service azure responsable de collecter les métriques et les logs des ressources Azure.
- Bastion: ce service Azure permet de se connecter sur les machines Azure de façon sécurisée.
- VPN Gateway ou express route: pour établir la communication avec on-prem.
Ressources Azure
Architecture Réseau
Déploiement des Services Azure
Tout d’abord, on déploie les Vnets (Hub/Spoke1/Spoke2), les peerings, l’Azure firewall et les autres ressources via Azure Portal.
Déploiement des Vnets
Nous partons pour déployer les trois Vnets
Vnet Hub
Le Vnet Hub se situera dans la resource group Hub et se nommera hub dans la région West Europe.
On définit la plage d’adresse pour le Vnet et on ajoute un subnet /26 pour le firewall avec un nom imposé par Azure « AzureFirewallSubnet » (pour en savoir plus, nous vous invitons à consulter la documentation Microsoft)
⚠️ Point de vigilance : Azure firewall exige au minimum un /26 pour le subnet (voir FAQ de Microsoft)
Cliquez sur Next et validez :
Vnet Spoke 1et Vnet spoke 2
Menons la même opération pour Spoke 1 & 2 avec les informations suivantes :
Après le déploiement des 3 Vnets, nous pouvons configurer le VNET peering.
Configuration de Vnet peering
Le peering permettra d’interconnecter les trois Vnets entre eux. Pour cela, nous commençons par le Vnet « Hub »
⚠️ Attention : le Vnet Peering n’est pas transitif par défaut. Il ne permet pas de faire communiquer Spoke 1 et Spoke 2 automatiquement. Le firewall le permet en prenant le rôle de routeur.
Le VPN Gateway peut aussi assurer ce rôle.
Allez dans le panneau de configuration du Vnet « Hub » et cliquez sur « peering » :
Peering entre Hub et Spoke 1 dans les deux sens
Cliquez sur Add.
Nommez le peering « HubToSpoke1 » et sélectionnez “Vnet1”.
On sélectionne “Allow”:
- “Traffic to remote virtual Network”
On sélectionne:
- “Block traffic that from outside this virtual network”
⚠️ (Traffic ne provenant pas de vnet1)
Pour « virtual network gateway or route server”, nous laissons l’option « none » parce que le rôle de routeur dans notre scénario sera pris en charge par le firewall.
Cliquez sur Add.
Nommez le peering « Spoke1To Hub ».
Sélectionnez “Vnet1”.
Autorisez : “Traffic to remote virtual Network”
Autorisez : “Traffic forwarded from remote virtual Network”
Pour « virtual network gateway or route server », nous laissons l’option « none » parce que le rôle de routeur dans notre scénario sera pris en charge par le firewall.
Peering entre Hub et Spoke 2 dans les deux sens
Cliquez sur Add.
Nommez le peering « HubToSpoke2 ».
On sélectionne “Allow”:
- “Traffic to remote virtual Network”
On sélectionne :
- “Block traffic that from outside this virtual network”
⚠️ (Traffic ne provenant pas de Vnet 2)
Pour « virtual network gateway or route server », nous laissons l’option « none » parce que le rôle de routeur dans notre scénario sera pris en charge par le firewall.
Cliquez à nouveau sur Add et nommez le peering « Spoke2ToHub »
Sélectionnez « Vnet2.»
Autorisez : « Traffic to remote virtual Network »
Autorisez : « Traffic forwarded from remote virtual Network »
Pour « virtual network gateway or route server », nous laissons l’option « none » parce que le rôle de routeur dans notre scénario sera pris en charge par le firewall.
Nous avons maintenant terminé la configuration du peering entre le Vnet du Hub et ceux de Spoke 1 et Spoke 2. Nous pouvons désormais déployer l’élément sécurité de notre architecture : le firewall.
Déploiement d’Azure firewall
Azure firewall sécurisera les flux Nord/Sud (flux extérieurs vers réseau privé) et les flux Est/Ouest (flux inter Vnet). En prérequis, l’installation a besoin d’un Vnet (hub) et d’un subnet appelé AzureFirewallSubnet.
Création d’Azure Firewall
Allez sur « Create a resource », tapez « Azure firewall » et cliquez sur « Create ».
Remplissez les champs ci-dessous :
- Resource Group : Hub
- Name : FirewallDemo
- Region: West Europe
- Firewall tier : Standard
Sur le champ « Firewall policy », cliquez sur « Add New » :
- Policy Name: Parent Policy
- Region: West Europe
- Policy Tier: Standard
Et cliquez sur « OK » :
Nous allons créer une IP public pour le firewall, cette étape constituant un prérequis au déploiement.
- Name : FWPIP
- SKU: standard
- Assignment : Static
Cliquez sur « OK ».
Déploiement de Virtual Machines
Nous déployons deux machines virtuelles : VMadmin comme machine admin dans Vnet1 et VM2 dans Vnet 2. Toutes les machines tourneront sous Windows server 2022.
VmAdmin
Networking
- Virtual network : VNET1
- Subnet : 192.168.16.0/24
- Pour utiliser le RDP, nous devons ouvrir le port 3389 dans le NSG.
Vm2
- Resource Group : Spoke2
- Région : Europe West Europe
Networking
- Virtual network : VNET2
- Subnet : 192.168.32.0/24
- Pour utiliser le RDP, nous devons ouvrir le port 3389 dans le NSG.
Nous avons déployé les machines virtuelles sur le réseau privé mais elles ne sont pas accessibles et ne peuvent pas communiquer entre elles. Nous devons router les flux réseaux à l’aide du service UDR (User Define Route).
UDR (User Define Route)
UDR est un service network essentiel pour la maitrise des flux réseau. Il nous permet de rediriger tous les flux vers le firewall.
Création du User Define Route
Allez sur Create => Network => Route Table
Donnez les informations suivantes :
- Resource Group : Hub
- Region : West Europe
- Name : DefaultRT
Association UDR avec Subnet :
Après la création de l’UDR, nous allons associer notre default UDR avec les subnets où sont localisées les machines virtuelles, afin que l’UDR route les flux provenant des machines.
Pour cela :
- Cliquez sur « Subnet » et « Association »
- Sélectionnez les deux subnets crées précédemment
- Après ces actions, vous devez avoir les deux subnets listés (AdminSubnet et VM subnet)
Configuration UDR
Pour la configuration, Cliquez sur « route » puis sur « Add ».
Définissez le nom de votre route dans le champ « Route Name » (ToFirewall)
Addresse prefix : 0.0.0.0/0
Next Hop : Virtual Appliance
Next Hop address : 192.168.0.4 (adresse IP privée du Firewall)
Cliquez sur “Add”.
Nous venons de configurer l’UDR pour que les IP appartenant à la plage d’adresse 0.0.0.0/0 soient redirigées vers l’adresse IP privée du Virtual Appliance (Firewall).
Pour en savoir plus, nous vous invitons à consulter la documentation Microsoft expliquant en détail le concept de routing dans Azure :
A présent, nous attaquons le service Azure Private DNS qui sera utilisé par notre web avec son private end point.
Azure Private DNS
Cette étape consiste à déployer le Azure Private Dns et à l’attacher à chaque Vnet pour que le nom de domaine soit connu par les machines virtuelles (VM).
Création de l’Azure Private DNS
- Cliquez sur « Create a resource »
- Tapez « Private DNS Zone »
- Cliquez sur « Create »
- Dans le champ « resource group » : Hub
- Name : privatelink.azurewebsite.net
⚠️ Attention : nom domaine par défaut pour les ressources webapp.
Pour plus d’information sur voir le lien
- Cliquez sur « review+create »
Association Azure private DNS Vnet
- Cliquez sur “Virtual Network Links”
- Ensuite sur “Add”
Tapez le nom d’un des trois Vnets créés dans le chapitre VNET :
Répétez cette action pour les autres Vnets (hub & Vnet2).
A la fin, nous aurons la liste de tous les Vnets :
Installation du service Web App
Le service Web App (webbAppSpoke2) est le dernier élément à installer. Il sera dans le Spoke 2 et doit être accessible uniquement à partir d’un Private ndpoint.
Création du Web App
Commençons par créer une nouvelle ressource : cliquez sur « Create Resource » et « Web App » :
Remplissez les champs ci-dessous :
- Resource group : Spoke2
- NameWebApp : Spoke2
- Publish : Config Par Default
- Runtime starck : .NET 6
- Region : West Europe
- Operating System: Window/Linux (à votre convenance)
Ensuite, cliquez sur «Review et Create ».
Et sur « Create » :
Après le déploiement, on peut utiliser l’URL public de la WebApp https://webappspoke2.azurewebsites.net pour avoir l’image ci-dessous.
Cependant, nous voulons que la WebApp ne soit pas ouverte sur Internet. Les paramètres réseaux de la WebApp doivent changer pour ne fonctionner qu’avec une private endpoint dans notre réseau.
Private Endpoint
Cliquez sur « Networking » et sur « Private Endpoint » pour en créer un point d’accès à notre WebApp.
Cliquez sur « Add » :
- Name : webappPE
- Virtual Network : VNET2
- Subnet : PrivateEndpointSubnet
Et validez le Private endpoint.
Après cette opération, la WebApp ne doit plus être accessible par Internet. Si on utilise l’URL pour y accéder, voici ce qui s’affiche :
Notre WebApp est désormais accessible uniquement à partir du réseau privé, mais pour finir la configuration il faut lier notre WebApp avec notre private DNS zone.
Enregistrement DNS
Nous avons terminé l’installation de notre infrastructure Hub and Spoke. Portez une attention particulière sur les étapes Vnet, peering, UDR pour le succès de l’installation. Nous pouvons à présent commencer le scénario 1.
Scénario 1 : accéder à VMadmin en rdp via l’IP publique du firewall
L’objectif de ce premier scénario est de permettre un accès sur VMadmin en rdp en passant par l’IP publique du Firewall.
Pour cela, nous allons configurer le DNAT du firewall et tester une connexion à distance avec l’adresse IP publique du firewall pour se connecter.
Concepts de base sur Azure Firewall
Nous vous invitons à lire ces articles qui expliquent la structure logique du Firewall Policy et l’ordonnancement des rules du Firewall.
- Azure Firewall policy rule sets | Microsoft Docs
- Azure Firewall rule processing logic | Microsoft Docs
- https://docs.microsoft.com/en-us/azure/firewall/rule-processing#dnat-rules-and-network-rules
Structure logique Azure policy / Source
Configuration du Firewall
Allez sur le Firewall Policy (ressource Azure qui porte les règles du firewall).
Cliquez sur « DNAT Rule » et « Add a rule Collection » :
On souhaite que n’importe quelle IP puisse se connecter en RDP sur la machine VMadmin à partir de l’extérieur en utilisant uniquement l’IP publique du firewall. Ce dernier doit être en mesure de rediriger le flux directement sur l’IP privée de la VMadmin.
Pour cela, on va suivre la configuration suivante :
Rule Collection :
- Name : DNATRuleCollection
- Rule collection Type : Dnat
- Priority : 500
- Rule Collection Group: DefaultDnatRuleCollectionGroup
Rule :
- Name : To VmAdminVM
- SourceType : Ap Adress
- Source : *
- Protocole : TCP
- Destination port : 3389 (Port RDP)
- Destination Type: IP address
- Destination : (IP publique du firewall)
- Translated adress : IP privée de VMadmin, dans notre exemple c’est 192.168.16.4.
Validez la configuration et laissez la nouvelle configuration du DNAT se déployer.
Même si ce n’est pas expliqué ici, nous vous invitons à activer les logs pour suivre les flux qui passent par le firewall.
Test Connexion
Après, le déploiement de la règle, nous allons nous connecter sur VMadmin à partir de l’adresse IP du firewall.
Tapez la commande mstsc.exe à partir de l’exécutable de votre poste et remplissez :
- Ordinateur : donnez l’IP publique du firewall, dans notre cas c’est 20.224.1.212
- Nom de l’utilisateur : AdminVm (compte local admin)
- Connexion
Cliquez sur « autres choix » :
Sélectionnez « Utiliser un autre compte » :
Tapez le mot passe du compte admin local de la VM admin :
Cliquez sur « oui » :
Vous êtes connecté !!!
La console du remote Desktop indique l’adresse IP du Firewall. Cependant, si vous vérifiez la configuration réseau de la machine (ipconfig /all), vous pouvez voir l’adresse privée de la machine.
Pour aller plus loin sur Azure Firewall
Nous avons réussi à accéder sur VMAdmin à partir d’Internet en utilisant l’adresse IP publique. Par cet exemple, nous avons mis en évidence le rôle de sécurisation du Firewall pour les flux Nord/sud (depuis Internet vers notre réseau sécurisé) grâce à « DNAT rule ». Par la même occasion, nous avons vérifié que notre peering était bien configuré en permettant la communication réseau entre les Vnets.
Nous vous invitons à découvrir la suite de cet article, dans laquelle nous continuerons à tester Azure Firewall avec les rules networks et les rules applications dans différents scenarios, dans le but de montrer comment Azure Firewall peut sécuriser votre plateforme.