Réseau natif du cloud : conception de VPC, passerelle de transit et maillage de services en synergie
L&8217;essentiel La conception de VPC avec des sous-réseaux segmentés constitue la base de toute architecture cloud sécurisée. La passerelle de transit relie des centaines de VPC et des réseaux sur site via …
L’essentiel
- La conception de VPC avec des sous-réseaux segmentés constitue la base de toute architecture cloud sécurisée.
- La passerelle de transit relie des centaines de VPC et des réseaux sur site via un hub centralisé.
- PrivateLink permet d’accéder à des services sans exposition Internet.
- Les stratégies réseau (Network Policies) dans Kubernetes implémentent une microsegmentation au niveau des pods.
- Les stratégies multi-comptes avec des VPC distincts par environnement isolent le « blast radius ».
La conception réseau dans le cloud est fondamentalement différente de celle sur site. Plutôt que des commutateurs et routeurs physiques, on définit des réseaux virtuels par code – plus souple, mais aussi plus sujet aux erreurs. Des groupes de sécurité mal configurés, des blocs CIDR trop larges et une segmentation absente constituent les causes les plus fréquentes d’incidents de sécurité dans le cloud. Celui qui planifie correctement sa conception de VPC a déjà accompli 80 % du travail de sécurité.
Conception de VPC : poser les bonnes bases
Un VPC (Virtual Private Cloud) est un réseau isolé dans le cloud. Les décisions de conception prises lors de sa création déterminent la sécurité et la flexibilité pendant des années. Trois règles s’imposent : premièrement, planifier généreusement les blocs CIDR – un /16 (65 536 adresses IP) par VPC, un /24 par sous-réseau. Une extension ultérieure est fortement limitée. Deuxièmement, séparer strictement les sous-réseaux publics et privés. Seuls les équilibreurs de charge (Load Balancer) et les hôtes bastion (Bastion Hosts) doivent résider dans les sous-réseaux publics. Troisièmement, utiliser au moins trois zones de disponibilité (Availability Zones) pour assurer la haute disponibilité.
Les stratégies multi-comptes, mises en œuvre via AWS Organizations ou Azure Management Groups, isolent les environnements (Production, Staging, Développement) dans des comptes distincts dotés chacun de leur propre VPC. Une violation de sécurité dans l’environnement de développement ne peut ainsi pas se propager vers la production.
Passerelle de transit : le hub réseau central
Dans les environnements d’entreprise comportant 50 à 500+ VPC, la mise en réseau pair-à-pair devient ingérable. AWS Transit Gateway, Azure Virtual WAN et GCP Network Connectivity Center agissent comme des hubs centraux : tous les VPC et réseaux sur site se connectent au hub, et non entre eux.
La passerelle de transit permet notamment : le routage centralisé entre VPC, la terminaison VPN pour la connexion aux infrastructures sur site, le peering inter-régions pour les configurations multi-régions, ainsi que des tables de routage permettant un contrôle granulaire du trafic. Son coût s’élève à 0,05 USD par heure, auxquels s’ajoutent des frais liés au traitement des données – une solution plus économique et plus simple que la gestion de centaines de peerings VPC pour les grands déploiements.
PrivateLink et points de terminaison VPC
Par défaut, les appels API vers les services AWS (S3, DynamoDB, SQS) transitent par Internet public. Les points de terminaison VPC (VPC Endpoints) et PrivateLink conservent le trafic au sein de l’infrastructure privée d’AWS : les points de terminaison de type gateway (gratuits pour S3 et DynamoDB) et les points de terminaison de type interface (pour tous les autres services) fournissent des adresses IP privées directement dans le VPC.
PrivateLink permet également un accès privé à des services tiers ou à ses propres services hébergés dans d’autres comptes – sans passer par Internet, sans passerelle NAT (NAT Gateway), et sans adresse IP publique. Pour les charges de travail critiques en matière de conformité, l’usage de PrivateLink est obligatoire.
DNS et découverte de services dans le cloud
Les zones hébergées privées Route 53 (AWS), Azure Private DNS et les zones privées Cloud DNS de GCP permettent la résolution DNS interne au sein des VPC. Les services sont adressés via leurs noms DNS plutôt que par leurs adresses IP – une exigence essentielle dans les environnements cloud dynamiques, où les adresses IP changent fréquemment.
Dans Kubernetes, CoreDNS assure la découverte de services : chaque service reçoit automatiquement un nom DNS (service-name.namespace.svc.cluster.local). External DNS synchronise automatiquement les services Kubernetes avec Route 53 ou Cloud DNS afin de garantir leur accessibilité depuis l’extérieur.
Sécurité réseau : défense en profondeur
La sécurité réseau dans le cloud repose sur un modèle multicouche : groupes de sécurité (pare-feu stateful au niveau de l’instance) → listes de contrôle d’accès réseau (Network ACLs) (pare-feu stateless au niveau du sous-réseau) → WAF (couche application au niveau de l’équilibreur de charge) → stratégies réseau (Network Policies) (communication pod-à-pod dans Kubernetes) → maillage de services (Service Mesh) (authentification mutuelle TLS et autorisation entre microservices).
La règle fondamentale : Deny by Default (interdiction par défaut). Chaque groupe de sécurité démarre sans aucune règle entrante. Chaque stratégie réseau bloque tout le trafic jusqu’à ce que des règles Allow explicites soient définies. Seul le trafic strictement nécessaire doit être autorisé.
Pour aller plus loin sur cloudmagazin.com
- Data Mesh en pratique : une architecture de données décentralisée pour les entreprises natives du cloud
- Identité native du cloud : OAuth 2.1, clés d’accès (Passkeys) et l’avenir de l’authentification
- L’essor de l’IA stimule le marché des services cloud – l’Europe reste en retrait
Pour approfondir ce sujet : D’autres articles sur mybusinessfuture
Questions fréquentes
Combien de VPC un entreprise devrait-elle posséder ?
Au minimum trois : Production, Staging et Développement – idéalement dans des comptes AWS distincts. Les grandes entreprises disposent souvent de 50 à 500+ VPC, organisés selon les unités métiers, les environnements et les exigences de conformité. Plus il y a de VPC, meilleure est l’isolation, mais plus la charge de gestion augmente.
Quel est le coût d’une passerelle NAT ?
AWS NAT Gateway : 0,045 USD par heure (~33 USD par mois), auxquels s’ajoutent 0,045 USD par Go de données traitées. À fort volume de trafic sortant, ce coût peut devenir élevé. Des alternatives existent : les instances NAT (moins coûteuses, mais gérées en interne), les points de terminaison VPC (éliminent le besoin de NAT pour le trafic vers les services AWS), ou encore le protocole IPv6 en mode double pile (Dual-Stack IPv6), qui rend le NAT inutile.
Une passerelle de transit est-elle indispensable pour les petits déploiements ?
Non. Pour 2 à 5 VPC, le peering VPC (gratuit, connexion directe) suffit amplement. La passerelle de transit devient rentable à partir de 10+ VPC, ou dès lors qu’une connexion sur site et un routage centralisé sont requis.
Comment segmenter un réseau dans Kubernetes ?
Les stratégies réseau (Network Policies), implémentées par des solutions telles que Calico ou Cilium, définissent précisément quels pods peuvent communiquer avec quels autres pods. L’isolation basée sur les espaces de noms (namespaces) constitue le point d’entrée : les pods situés dans des espaces de noms différents ne peuvent communiquer que si une stratégie réseau l’autorise explicitement.
Quelle est la différence entre les groupes de sécurité et les listes de contrôle d’accès réseau (Network ACLs) ?
Les groupes de sécurité sont stateful (le trafic de retour est autorisé automatiquement), opèrent au niveau de l’instance et ne prennent en charge que des règles Allow. Les listes de contrôle d’accès réseau (Network ACLs) sont stateless (le trafic de retour doit être autorisé explicitement), opèrent au niveau du sous-réseau et supportent à la fois des règles Allow et Deny. En pratique, les groupes de sécurité suffisent à la plupart des scénarios.
Source de l’image : Pexels / Brett Sayles
