Cloud networking, VPC/VNet, CDN et équilibrage

Un réseau de nuage ne se câble pas, il se déclare : quelques objets dans une console ou un fichier Terraform remplacent les commutateurs, les routeurs et les pare-feu. Ces objets reprennent pourtant des concepts très classiques, sous-réseaux, tables de routage, traduction d’adresses, filtrage, avec des noms qui changent selon le fournisseur et des comportements par défaut qui surprennent. Cette fiche relie chaque objet à son équivalent physique, montre comment on accède aux services sans s’exposer, et pose les règles de gouvernance d’un réseau réparti sur plusieurs comptes ou plusieurs fournisseurs.

→ Lire l’explication complète de la marmotte

Objets réseau cloud

Le réseau privé virtuel et ses sous-réseaux

Le point de départ est un réseau isolé propre au client : VPC (Virtual Private Cloud) chez AWS (Amazon Web Services) et GCP (Google Cloud Platform), VNet (Virtual Network) chez Azure. Il reçoit une ou plusieurs plages d’adresses privées notées en CIDR (Classless Inter-Domain Routing), par exemple 10.20.0.0/16, puis se découpe en subnets (sous-réseaux). Les détails varient : un subnet AWS est rattaché à une seule zone de disponibilité, un subnet Azure ou GCP couvre toute la région ; un VPC GCP est global et ses subnets sont régionaux. Les fournisseurs réservent quelques adresses par subnet, cinq chez AWS et Azure, quatre chez GCP : un /28 n’offre donc que 11 adresses utilisables chez AWS, détail qui ruine les plans d’adressage taillés au plus juste.

Rien n’est « public » ou « privé » par nature. C’est la table de routage associée au subnet qui en décide :

Type de subnet	Route par défaut `0.0.0.0/0`	Conséquence
Public	vers l’Internet gateway	une ressource dotée d’une adresse publique est joignable depuis Internet
Privé	vers une NAT gateway	sortie possible, aucune connexion entrante initiée depuis Internet
Isolé	absente	ni entrée ni sortie vers Internet

L’Internet gateway est un routeur de bordure géré, qui traduit l’adresse publique associée à une instance vers son adresse privée. La NAT gateway réalise la NAT (Network Address Translation) de source : toutes les machines privées sortent derrière l’adresse publique de la passerelle, exactement comme une box domestique (voir NAT, translations et publication). Chez GCP, le service s’appelle Cloud NAT ; chez Azure, NAT Gateway.

Groupes de sécurité et listes de contrôle

Le filtrage s’exerce à deux niveaux. Le security group (groupe de sécurité) d’AWS s’attache à l’interface réseau d’une ressource, ne contient que des autorisations, et il est à état : une réponse à une connexion autorisée repasse automatiquement. Il peut désigner comme source un autre groupe plutôt qu’une plage d’adresses, ce qui exprime « les serveurs d’application peuvent joindre la base » sans écrire une seule adresse. La NACL (Network Access Control List) s’attache au subnet, accepte des règles d’autorisation et de refus évaluées dans l’ordre de leur numéro, et elle est sans état : il faut autoriser explicitement le trafic retour, y compris les ports éphémères 1024 à 65535, oubli qui produit des pannes intermittentes du plus bel effet.

Critère	Security group	NACL
Portée	interface d’une ressource	subnet entier
État	à état	sans état
Règles	autorisations seules	autorisations et refus, ordonnés
Usage typique	micro-segmentation par rôle	garde-fou grossier, blocage d’une plage

Azure fusionne les deux idées dans le NSG (Network Security Group), à état, avec autorisations et refus par priorité, attachable à un subnet ou à une interface. GCP utilise des règles de pare-feu au niveau du VPC, ciblées par étiquette réseau ou par compte de service. Au-dessus, les firewalls managés (AWS Network Firewall, Azure Firewall, Cloud NGFW chez GCP) apportent l’inspection applicative, le filtrage par nom de domaine et la journalisation centralisée qu’un groupe de sécurité ne fournit pas.

Correspondance avec le réseau classique

Un VPC joue le rôle d’un site, un subnet celui d’un VLAN (Virtual Local Area Network) avec son préfixe, la table de routage celui du routeur, l’Internet gateway celui du routeur de bordure, la NAT gateway celui du pare-feu de sortie qui traduit les adresses. La grande différence tient à la couche 2 : il n’y a ni diffusion, ni ARP (Address Resolution Protocol) usurpable entre clients, ni boucle à couper ; le fournisseur achemine tout en couche 3 dans son propre réseau. Une conséquence pratique : un subnet privé est une route privée, pas une absence d’exposition. Un équilibreur de charge public placé devant une ressource privée l’expose tout autant qu’une adresse publique.

Accès aux services

Équilibreurs, CDN et WAF

Un load balancer (répartiteur de charge) de couche 4 (transport) répartit des connexions TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol) sans lire leur contenu : Network Load Balancer chez AWS, Azure Load Balancer. Un répartiteur de couche 7 (application) termine le TLS (Transport Layer Security), lit les requêtes HTTP (Hypertext Transfer Protocol) et route selon l’hôte ou le chemin : Application Load Balancer, Application Gateway. Le second voit donc le trafic en clair, ce qui le rend utile pour filtrer et sensible à protéger (voir répartiteurs de charge et terminaison TLS).

Un CDN (Content Delivery Network) place des copies des contenus dans des points de présence proches des utilisateurs et absorbe une bonne partie des attaques volumétriques. Un WAF (Web Application Firewall) cloud, souvent couplé au CDN ou au répartiteur L7, filtre les requêtes selon des signatures et des règles de débit. Le duo ne protège que s’il est le seul chemin : une origine restée joignable directement par son adresse publique permet de contourner le WAF en toute simplicité. On restreint donc l’origine aux plages publiées par le CDN, ou mieux à un en-tête secret ou à une connexion privée.

Endpoints privés et DNS privé

Les services gérés du fournisseur (stockage objet, bases, files de messages) répondent par défaut sur des adresses publiques. Un endpoint privé crée dans le subnet du client une interface avec une adresse privée qui mène au service : PrivateLink chez AWS (interface endpoints, plus des gateway endpoints pour S3 et DynamoDB), Private Endpoint chez Azure, Private Service Connect chez GCP. Le trafic ne quitte plus le réseau privé, et la NAT gateway n’a plus besoin d’ouvrir la route vers Internet pour ces services.

Le mécanisme repose entièrement sur le DNS privé : il faut que le nom habituel du service, par exemple monstockage.blob.core.windows.net, se résolve vers l’adresse privée de l’endpoint depuis l’intérieur du réseau. Une zone DNS privée mal liée au VNet, ou un résolveur d’entreprise qui interroge directement Internet, renvoie l’adresse publique : le trafic repart par Internet, l’application fonctionne, et personne ne remarque que l’endpoint ne sert à rien. Le test se fait depuis une machine du subnet :

dig +short monstockage.blob.core.windows.net
# attendu : un CNAME vers privatelink, puis une adresse 10.x.x.x

Accès public contrôlé ou accès privé

L’accès public contrôlé expose un point d’entrée Internet, protégé par TLS, WAF, authentification et filtrage d’origine ; il convient aux services destinés au public. L’accès privé n’offre aucune adresse publique et passe par endpoint, VPN (Virtual Private Network) ou interconnexion dédiée ; il convient aux bases, aux interfaces d’administration et aux échanges entre services. Les erreurs d’exposition se ressemblent toutes : adresse publique attribuée par défaut au lancement, règle 0.0.0.0/0 sur un port d’administration, service géré créé avec l’accès public activé, compartiment de stockage lisible par tous.

Gouvernance multi-cloud

Adressage, interconnexion et chevauchements

Plusieurs VPC se relient par peering (appairage), connexion directe entre deux réseaux, non transitive chez les trois grands fournisseurs : si A est appairé à B et B à C, A ne joint pas C. Au-delà de quelques réseaux, le maillage devient ingérable et l’on passe au hub-and-spoke (en étoile) autour d’un routeur central, Transit Gateway chez AWS, hub VNet ou Virtual WAN chez Azure, Network Connectivity Center chez GCP, où se concentrent l’inspection, la sortie Internet et les liaisons vers les sites.

Tout cela ne fonctionne qu’avec des plages sans chevauchement : deux VPC en 10.0.0.0/16, créés avec les valeurs proposées par défaut, ne pourront jamais être routés l’un vers l’autre sans traduction d’adresses. Un plan d’adressage central, attribué par compte et par région, se décide avant le premier VPC (voir IPv4, CIDR et plans d’adressage).

L’IPv6 (Internet Protocol version 6) mérite une attention particulière. Chez AWS, les préfixes IPv6 fournis par Amazon sont des adresses publiques routables, et aucune NAT ne vient masquer un subnet « privé » : un subnet doté d’un préfixe IPv6 et d’une route ::/0 vers l’Internet gateway rend ses ressources joignables depuis Internet si les groupes de sécurité le permettent ; la sortie seule se fait par une egress-only Internet gateway. Un audit qui ne regarde que les règles IPv4 passe à côté.

Journaux et contrôle des sorties

Les flow logs enregistrent les métadonnées de chaque flux : adresses, ports, protocole, volume, décision. Un enregistrement AWS au format par défaut ressemble à ceci :

2 123456789012 eni-0a1b2c3d 203.0.113.45 10.20.20.15 51544 5432 6 10 840 1696000000 1696000060 ACCEPT OK

Une adresse Internet qui atteint le port 5432 d’une base avec la mention ACCEPT n’appelle pas de commentaire. Le traffic mirroring (Traffic Mirroring chez AWS, Packet Mirroring chez GCP) copie les paquets eux-mêmes vers une sonde, pour une analyse approfondie ciblée. L’egress control filtre ce qui sort : un pare-feu managé qui n’autorise que les domaines nécessaires, des endpoints privés pour les services du fournisseur, et le refus par défaut du reste. Sans lui, la NAT gateway laisse une machine compromise exfiltrer vers n’importe quelle destination.

Réseau, identité et responsabilité

La sécurité réseau et l’IAM (Identity and Access Management) se complètent sans se remplacer. Un compartiment de stockage peut être inaccessible par le réseau et lisible par une identité trop permissive depuis Internet par l’API (Application Programming Interface) du fournisseur ; à l’inverse, une politique IAM stricte ne protège pas une base dont le port est ouvert au monde avec un mot de passe faible. Le modèle de responsabilité partagée fixe la frontière : le fournisseur sécurise l’infrastructure physique et l’hyperviseur, le client sa configuration réseau, ses identités et ses données (voir responsabilité partagée, frontière floue et IAM). En multi-cloud, la même intention doit être traduite en objets différents chez chaque fournisseur, avec un adressage commun, une collecte de journaux unifiée et une séparation des comptes par environnement ; les écarts de traduction sont détaillés dans complexité de la sécurité multi-cloud.

Atelier : lire une architecture et repérer une base exposée

Soit un VPC 10.20.0.0/16 sur deux zones. Les subnets publics 10.20.0.0/24 et 10.20.1.0/24 portent un Application Load Balancer et une NAT gateway, avec une route 0.0.0.0/0 vers l’Internet gateway. Les subnets privés 10.20.10.0/24 et 10.20.11.0/24 portent les serveurs d’application, avec une route par défaut vers la NAT gateway. Les subnets isolés 10.20.20.0/24 et 10.20.21.0/24 portent la base PostgreSQL, sans route par défaut. Le groupe de la base n’autorise le port 5432 que depuis le groupe des serveurs d’application.

L’architecture est saine sur le papier. Les recherches classiques vérifient qu’elle l’est en réalité :

aws ec2 describe-security-groups \
  --filters Name=ip-permission.cidr,Values=0.0.0.0/0 \
  --query 'SecurityGroups[].[GroupId,GroupName]'
aws rds describe-db-instances \
  --query 'DBInstances[?PubliclyAccessible==`true`].DBInstanceIdentifier'

Les trouvailles habituelles : un groupe ouvert sur 0.0.0.0/0 au port 5432 « pour un test » d’il y a dix-huit mois, une instance de base créée avec l’accès public dans un subnet public par un script hérité, ou un Network Load Balancer public ajouté devant la base pour un partenaire. Les flow logs disent ensuite depuis quand, et qui en a profité, à condition d’avoir été activés avant.

Pièges et confusions

Croire qu’un subnet privé suffit, ouvrir 0.0.0.0/0 par commodité et ne pas activer les flow logs forment le trio le plus fréquent des audits ; le groupe de sécurité par défaut, qui autorise toute sortie, et la NACL par défaut, qui autorise tout, complètent le tableau.

Un security group n’est pas un pare-feu traditionnel : il filtre par interface, sans inspection applicative, sans journal de ses décisions hors flow logs, et sans notion de zone. Un private endpoint n’est pas un VPN : il expose un service précis dans un sens, du consommateur vers le service, sans relier deux réseaux (voir VPN, tunnels et bastions). Un CDN n’est pas un reverse proxy interne : il sert le public depuis des points de présence externes et met en cache, tandis qu’un reverse proxy interne route entre services privés sans rien exposer.

🐝 Ce qui arrive si on s’en passe

Sans journaux de flux, une base de données exposée par erreur l’est aussi sans témoin : on découvre l’ouverture, jamais depuis quand elle existait ni quelles adresses en ont profité, ce qui rend toute notification d’incident très approximative. Sans contrôle des sorties, une machine compromise dans un sous-réseau privé expédie ce qu’elle veut vers l’extérieur par la passerelle de traduction d’adresses, qui fait son travail avec une loyauté parfaite. Et des plages d’adresses choisies sans concertation interdisent plus tard de relier deux réseaux, ce qui pousse à exposer publiquement ce qui aurait dû rester privé.

🦫 Explication de la marmotte 🍫

Chez un fournisseur de nuage, chaque client dispose d’un réseau privé virtuel, appelé VPC ou VNet selon le fournisseur. Il le découpe en sous-réseaux, et ce sont les tables de routage qui décident de leur nature. Un sous-réseau public possède une route vers une passerelle Internet ; un sous-réseau privé sort vers Internet par une passerelle de traduction d’adresses, qui permet de sortir mais pas d’être joint directement ; un sous-réseau isolé n’a aucune route vers l’extérieur.

Le filtrage se fait à deux niveaux : les groupes de sécurité, attachés à chaque machine ou service, et les listes de contrôle attachées au sous-réseau. Un groupe de sécurité ouvert à toutes les adresses annule l’intérêt d’un sous-réseau privé. Des répartiteurs de charge distribuent les connexions entre plusieurs serveurs, soit au niveau du transport, soit au niveau des requêtes web. Un réseau de diffusion de contenu place des copies près des utilisateurs, et un pare-feu applicatif filtre les requêtes web.

Les points d’accès privés permettent de joindre un service du fournisseur sans passer par Internet, avec des noms résolus dans un annuaire privé. Plusieurs réseaux se relient par appairage, par une passerelle de transit ou selon un schéma en étoile ; cela ne fonctionne que si leurs plages d’adresses ne se chevauchent pas. Les journaux de flux enregistrent les connexions, et le contrôle des sorties limite ce qui peut quitter le réseau. Le fournisseur sécurise l’infrastructure ; la configuration reste à la charge du client.

Pages voisines

La citent

Cloud networking, VPC/VNet, CDN et équilibrage

Elle cite

: les deux pages se citent l’une l’autre.

Cloud networking, VPC/VNet, CDN et équilibrage

Cloud networking, VPC/VNet, CDN et équilibrage

Objets réseau cloud

Le réseau privé virtuel et ses sous-réseaux

Groupes de sécurité et listes de contrôle

Correspondance avec le réseau classique

Accès aux services

Équilibreurs, CDN et WAF

Endpoints privés et DNS privé

Accès public contrôlé ou accès privé

Gouvernance multi-cloud

Adressage, interconnexion et chevauchements

Journaux et contrôle des sorties

Réseau, identité et responsabilité

Atelier : lire une architecture et repérer une base exposée

Pièges et confusions

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines