À une époque où le cloud est généralisé, il est essentiel de concevoir une architecture réseau sécurisée et maintenable.
Cela permet de se protéger contre les attaques extérieures. Mais c’est également un moyen d’éviter les déconvenues habituelles pour les développeurs :
- accès réseau définis de manière inconstante ce qui peut ralentir les développements
- évolutions et maintenances difficiles
- faible résilience pour les pannes de réseau
- etc.
Rapide tour d’horizon des autres architectures utilisées sur Azure
L’architecture Hub & Spoke est loin d’être la seule à être utilisée. Voici une rapide présentation des principales architectures communément utilisées, avec leurs avantages et leurs inconvénients.
Le réseau “simple”
Cette architecture n’a pas de nom particulier car il s’agit de la plus simple à mettre en place sur Azure.
La brique principale utilisée est Azure Virtual Network, elle permet de créer un réseau privé virtuel qui interconnecte des ressources Azure, devenant accessibles uniquement depuis des connexions autorisées.
Il est possible de créer plusieurs réseaux virtuels privés pour améliorer l’organisation et avoir une gestion plus fine des accès.
L’avantage principal de cette architecture est la facilité de mise en place, mais les inconvénients sont nombreux, en voici les principaux :
- On doit configurer individuellement chaque réseau privé virtuel. Cela amène souvent à dupliquer les mêmes configurations et devient naturellement source de nombreuses erreurs en plus d’une faible maintenabilité.
- La nécessité de tout configurer peut donner lieu à des accès publics non désirés vers ces réseaux privés.
- Il est également difficile de contrôler les flux sortants (réseau privé → extérieur)
Le réseau en “full mesh”
Le principe de base de cette architecture est de créer des ponts de connexion entre tous les sous-réseaux existants, un peu comme une toile d’araignée.
L’avantage principal de cette méthode est la très grande résilience : un nœud qui tombe en panne ne coupera pas la communication entre les autres nœuds fonctionnels.
La grosse limite est que cette architecture est peu maintenable sur le long terme, en particulier pour les gros réseaux : le nombre de connexions à mettre en place lors de la création de nouvelles ressources explose : on doit en créer n(n - 1)/2 où n correspond au nombre de ressources.
L’architecture Hub & Spoke
Principe général
L’idée directrice de cette architecture est simple : il s’agit là d’établir un réseau de transit qui permet de créer une politique réseau uniforme à travers tout un réseau, afin d’éviter les redondances et d’avoir une politique potentiellement différente par environnement applicatif.
Elle se décompose généralement en deux parties :
- Un hub est un réseau privé virtuel central dans cette architecture puisqu’il permet d’orchestrer et de mutualiser les connexions entre les spokes. Il sert aussi à surveiller et à donner des accès spécifiques.
- Les spokes sont des réseaux privés virtuels dont l’interconnexion se fait via ce même hub : les spokes ne communiquent donc pas entre eux sans passer par cet intermédiaire. Leur rôle est purement applicatif : ce sont eux qui contiennent les ressources concrètes (bases de données, logiques applicatives, serveurs d’APIs, files d’attente, function apps, etc…).
Pour optimiser au maximum la latence entre les spokes liée à ce passage obligatoire par le hub, un mécanisme de VNet peering est souvent utilisé : il consiste à établir des connexions privées directes entre deux VNets, comme s’ils appartenaient au même réseau privé. Dans notre cas de figure et pour éviter de créer des liens directs entre deux spokes, chaque peering consiste en un lien entre un spoke et le hub. On crée ensuite des UDR (User Defined Routes) en indiquant aux spokes que leur trafic sortant doit obligatoirement passer par le hub — et notamment par son pare-feu — avant d’arriver à la destination voulue.
La raison pour laquelle la latence est plus optimisée est que l’on reste dans le réseau Azure, sans faire de détours par internet ou par un VPN, car nous établissons un routage optimal entre les spokes et le hub.
Fonctionnement du hub
Le hub, pour pouvoir orchestrer et sécuriser toutes les connexions, doit avoir un certain nombre de composants incontournables :
- Azure VPN Gateway : il s’agit d’un service de passerelle VPN qui permet de garantir le chiffrage du trafic réseau, notamment lorsqu’il y a une connexion Client vers Azure, ou encore une connexion entre On-Prem et Azure, ou inversement. (Documentation d’Azure VPN Gateway)
- Azure ExpressRoute : ce composant est optionnel. Il permet d’établir une connectivité privée entre un réseau on-premises et Azure. Dans une architecture Hub & Spoke, lorsqu’une connectivité hybride est nécessaire, il peut être utilisé à la place d’Azure VPN Gateway et mutualisé au niveau du hub.
- Azure Firewall : comme son nom l’indique, il s’agit d’un pare-feu. Il permet de définir les accès et les interdictions des différentes connexions entrantes et sortantes dans le hub. Les tables de routage des spokes sont configurées de sorte à ce que leur route par défaut (
0.0.0.0/0) passe par ce pare-feu central, afin de garantir le contrôle du trafic sortant.Le pare-feu Azure permet également de mettre en place un mécanisme de “next hop” vers un pare-feu On-Prem : ainsi, tout trafic sortant en direction d’internet devra passer par ce pare-feu en amont (d’où le nom de “next hop” : on force le prochain rebond réseau vers le pare-feu avant d’accéder à internet). (Documentation d’Azure Firewall)
- Azure Bastion : ce service permet d’établir une connexion RDP ou SSH en direction des machines virtuelles éventuellement présentes dans les spokes. Il est habituellement déployé sur le hub car c’est lui qui réceptionne les connexions HTTPS et qui, à partir de là, établit les connexions RDP ou SSH vers les machines virtuelles ciblées. (Documentation d’Azure Bastion)
Fonctionnement des spokes
Les spokes ont également besoin de bon nombre de composants pour fonctionner dans une architecture Hub & Spoke :
- Les ressources applicatives : ce sont les principales briques qui permettent de réaliser le besoin métier. La communication entre toutes ces briques est à la fois sécurisée et facilitée car elles appartiennent au même spoke.
- Azure Private Endpoint : ce service permet de créer une interface de réseau privée (donc une IP privée) afin de supprimer l’exposition publique, ce qui est sécurisant car cela réduit fortement le risque d’accès non autorisés avec l’extérieur, notamment internet. (Documentation d’Azure Private Endpoint)
- Network Security Groups (NSG) : les NSG permettent de filtrer le trafic réseau entrant et sortant au niveau d’un sous-réseau ou d’une interface réseau. Dans une architecture Hub & Spoke, ils sont généralement utilisés dans les spokes pour renforcer l’isolation des workloads. Ainsi, on peut n’autoriser que les flux strictement nécessaires entre les sous-réseaux, les composants applicatifs et, le cas échéant, le hub. Ils complètent les mécanismes de filtrage plus centralisés, comme Azure Firewall. Cela apporte un niveau de contrôle plus fin au plus près des ressources hébergées dans chaque spoke.
Ressources additionnelles
En complément des briques réseau classiques, cette architecture peut intégrer des services de répartition de charge. On va ainsi retrouver Azure Application Gateway, Azure Load Balancer, Azure Front Door ou Azure Traffic Manager. Ces composants répondent à des usages différents selon que le besoin porte sur :
- un équilibrage local, régional ou global
- l’exposition d’applications vers internet
- etc.
Ils ne sont donc pas systématiquement positionnés au même endroit dans l’architecture. Certains trouvent naturellement leur place dans les spokes, au plus près des workloads. Tandis que d’autres interviennent plutôt en frontal global. Le schéma ci-dessous présente un exemple de fonctionnement avec Azure Application Gateway.
Avantages et inconvénients de l’architecture Hub & Spoke
Avantages
- La sécurité est centralisée : le hub permet de ne pas dupliquer la configuration. Cela corrige ainsi le défaut de la plupart des architectures réseau.
- De la même manière, les passerelles ExpressRoute et VPN sont partagées grâce au hub. Il n’y a pas besoin d’en créer une par réseau privé virtuel.
- La décomposition en plusieurs spokes permet de mieux organiser les workloads. Comme vu dans l’un des exemples précédents : un spoke pour le traitement des vidéos, et un second pour le traitement des images.
- Il est très facile de créer de nouveaux spokes. Les configurations étant partagées par le hub et par Azure Virtual Network Manager, il n’y a pas grand-chose à faire si ce n’est le raccordement au hub central.
- La résilience est très bonne. Un spoke qui tombe en panne ne menace que lui-même et son workload du fait de la séparation entre réseaux privés virtuels différents. Les autres spokes, et le hub, ne sont donc pas ou peu affectés.
Inconvénients
- La centralisation autour du hub a les défauts de ses qualités. La présence de composants uniques dans ce dernier le rend extrêmement critique. Ainsi, un hub qui tombe en panne met en berne tous les spokes. Ils ne peuvent plus communiquer avec l’extérieur de leur propre réseau privé virtuel.
- La configuration manuelle du routage nécessite une attention toute particulière. Il est très facile de mal les configurer et de laisser passer du trafic non désiré.
- Le passage obligatoire par le hub augmente mécaniquement la latence (bien qu’il soit possible de l’optimiser ). De plus cela nécessite un pare-feu robuste. Cela a bien entendu un coût et nécessite, là encore, une configuration méticuleuse.
- Le principe du hub unique fonctionne moins bien lorsque les spokes sont répartis dans plusieurs régions du monde. En effet, la latence et la dépendance à un point central deviennent plus problématiques. Une approche classique consiste alors à déployer un hub par région. Pour des besoins de connectivité globale plus avancés, il est également possible de s’orienter vers Azure Virtual WAN. Ce dernier propose une variante managée du pattern Hub & Spoke, adaptée aux environnements multi-région. (Voir la documentation de ce pattern)
