Architecture robuste : Le Réseau virtuel

• Le VPC : le périmètre logique isolé
• Normes réseaux
• Subnets et segmentation : organiser les quartiers de votre ville
• Le routage et les Gateways : contrôler les robinets de données
• Dépasser l’architecture 3-tiers
  • VPC Peering : faire discuter les services entre eux
  • Architectures plus complexes pour des produits plus complexes
  • Une arme à double tranchant
• Conclusion
• Ressources

Dans notre précédent article, nous avons vu dans le cas du VPS que nous déléguons certaines parties de l’infrastructure de notre application au fournisseur. Nous avons vu les images machines et la réplication du service pour absorber la charge. Nous avons évoqué le stockage, qui peut être également délégué… Mais il y a bien d’autres composants.

Avant d’aller plus loin dans cette voie, nous devons comprendre un minimum comment les différents services peuvent continuer d’interagir entre eux, lorsqu’ils ne sont plus localisés au même endroit, sur une même machine virtuelle.

De plus, une VM isolée avec une adresse IP publique est une cible vulnérable et une architecture fragile. Pour transformer un prototype en un service « enterprise-ready », nous devons penser en termes de topologie réseau.

Si nous concevons notre application comme une entreprise, nous voyons bien que nous ne mettrions pas les données à la portée du premier venu : nous aurions des zones d’accueil du public, et des zones sécurisées.

Dans un précédent article, nous avions évoqué l’architecture 3-tiers : c’est un excellent exemple d’infrastructure qu’il nous faut sécuriser. C’est précisément le rôle du Virtual Private Cloud (VPC, ou « VNet »). Dans cet article, nous allons explorer comment structurer notre réseau virtuel, segmenter nos accès grâce aux subnets et sécuriser nos flux via les gateways.

§Le VPC : le périmètre logique isolé

Le VPC (ou VNet chez Azure) est la brique de base de notre réseau dans le Cloud. Il s’agit d’un réseau virtuel privé, logiquement isolé des autres réseaux virtuels du fournisseur Cloud.

Au sein de ce périmètre, nous sommes maître du jeu : il nous garantit que nos ressources ne peuvent être atteintes par défaut depuis l’extérieur grâce à une isolation logique, offrant ainsi une première couche de sécurité fondamentale.

§Normes réseaux

Cette première couche de sécurité s’appuie sur une plage d’adresses IP que nous pouvons définir selon la norme RFC 1918. Elle est le standard de base pour les réseaux dits « privés », et définit des plages d’adresses IP à respecter pour structurer notre réseau. Contrairement à l’adresse IP de votre box internet ou d’un site web public, ces adresses ne sont pas routables sur l’Internet mondial. Elles ne fonctionnent qu’à l’intérieur de notre propre réseau fermé, un peu comme une messagerie interne à une entreprise : elles permettent de communiquer au sein du réseau, mais ne peuvent être utilisés de l’extérieur.

Nous utiliserons souvent la plage 10.0.0.0/8 qui est un standard garantissant suffisamment de place pour nos services, leurs réplications et leurs dépendances. En l’occurrence le chiffre après le / (le 8) fournit jusqu’à 16,7 millions d’adresses. D’autres plages courantes utilisent 192.168.0.0/24qui offre un peu moins d’espace (le /24 laisse 256 adresses, ce qui est amplement suffisant quand nous débutons).

À noter que nous avions déjà exploré les notions de base de réseau au sein de mon précédent parcours de formation.

§Subnets et segmentation : organiser les quartiers de votre ville

Un VPC seul est un grand espace vide. Pour être efficace, nous devons le découper en Subnets (sous-réseaux). C’est ici que nous appliquons bien souvent une architecture 3-tiers classique telle que mentionnée dans notre ancien article.

Nous parlons de « 3 tiers » car nous séparons la partie interface web, ou « frontend », la partie calcul, où se trouve le code de notre application « backend » et la base de données, mais dans la logique réseau, nous utilisons deux types de subnets :

• Le Subnet Public : Il accueille les ressources qui doivent être visibles depuis Internet, comme notre serveur web (NginX) ou notre Load Balancer.
• Le Subnet Privé : C’est le sanctuaire de notre architecture. Nous y plaçons notre fameux backend et les bases de données. Ces machines n’ont pas d’adresse IP publique et sont donc invisibles pour les attaquants scannant le web.

§Le routage et les Gateways : contrôler les robinets de données

Pour que ces sous-réseaux fonctionnent, nous utilisons des Route Tables (tables de routage), qui agissent comme des aiguilleurs indiquant aux paquets de données quel chemin prendre. La table de routage utilise des Gateways comme portes d’accès à nos flux internes. Il en existe deux types, correspondant à deux usages :

• L’Internet Gateway (ou « IGW ») permet au subnet public de discuter avec le monde entier. Dit autrement, elle permet aux ressources d’être joignables depuis le monde extérieur.
• La NAT Gateway est une pièce maîtresse de la sécurité. Elle permet aux services internes d’accéder au monde extérieur (dans le sens inverse de l’Internet Gateway) : nos serveurs en subnet privé s’en servent pour accéder à Internet – par exemple pour télécharger une mise à jour Python – sans que l’inverse ne soit possible. Depuis Internet seule l’IP de la gateway est visible, jamais celle de nos serveurs critiques.

§Dépasser l’architecture 3-tiers

§VPC Peering : faire discuter les services entre eux

Parfois, nous avons besoin de faire communiquer deux VPC distincts, par exemple si nous séparons notre environnement de test de celui de production, ou si deux équipes collaborent sur des services différents.

Le VPC Peering permet de créer un pont direct entre ces deux mondes. Le trafic circule alors de manière sécurisée sur le réseau interne du fournisseur Cloud, sans jamais passer par l’Internet public, garantissant une latence faible et une sécurité accrue.

§Architectures plus complexes pour des produits plus complexes

En maîtrisant ces concepts, nous passons naturellement d’une architecture 3-tiers classique (Interface / Traitement / Données) à des architectures plus modulaires : les micro-services.

Dans cette approche, chaque fonctionnalité de notre application peut habiter son propre domaine isolé. Cette modularité, héritée de la philosophie Unix (« faites une seule chose et faites-la bien »), permet de mettre à jour ou de mettre à l’échelle une partie de notre réseau sans risquer de faire tomber l’intégralité du système.

§Une arme à double tranchant

Les micro-services nous ouvrent la voie vers des produits beaucoup plus complexes, combinant à la fois robustesse et souplesse. Cependant, les architectures de micro-services sont également bien plus complexes à administrer.

Un exemple type de problématique qu’elles soulèvent concerne la gouvernance de la donnée. Chaque composant de notre application accède et modifie des données selon les actions des utilisateurs. Cependant, une partie de ces données sont également accessibles, et parfois modifiables, par d’autres composants. Tant que le nombre de composants est réduit, nous trouvons assez facilement des moyens pour éviter ces situations en appliquant les mêmes principes qu’en développement logiciel (par exemple avec la « Separation of Concern » que nous avons déjà vu il y a peu).

Mais lorsque le nombre d’applications augmente, ces choix deviennent moins évidents et leur gestion peut dépendre d’autres considérations, comme l’organisation des équipes travaillant sur ces services… Ces considérations dépassent du cadre de cet article, qui traite d’architectures encore relativement simples. Les micro-services sont une évolution future de nos application par laquelle nous seront fatalement amenés à passer, mais nous avons encore le temps de voir venir !

§Conclusion

Le réseau virtuel n’est pas qu’une contrainte technique, c’est l’armature qui rend notre application résiliente. En segmentant correctement nos accès et en contrôlant nos points d’entrée et de sortie, nous créons un environnement où l’IA peut nous aider à déployer vite, tout en gardant un contrôle humain rigoureux sur la sécurité.

Maîtriser cette première brique nous prépare également à la gestion d’architectures plus complexes, tels que les micro-services. D’autres briques nous aiderons également à définir des architectures robustes et anticiper le futur, dont une que nous verrons dans notre prochain article, sur le Well Architected Framework (WAF), une référence pour valider que notre déploiement respecte les plus hauts standards professionnels.

§Ressources

• RFC 1918 sur rfc-editor.
• Software Architecture with Python, Anand Balachandran Pillai