Le networking : VPC, Subnet, Firewall — La gestion du réseau interne de votre infrastructure

Section Qu'est-ce que le réseau dans une infrastructure cloud ?

Comme un réseau classique dans une entreprise, le réseau cloud est similaire en de nombreux points, mais différent dans son usage global.

Le réseau dans une infrastructure cloud est composé de plusieurs éléments, selon le fournisseur cloud utilisé et les fonctionnalités qu'il propose. Son utilisation et sa mise en place varieront donc en fonction de vos projets, de vos ambitions et des objectifs de protection de vos infrastructures.

Vous pouvez voir le réseau comme une grande boîte qui entoure votre infrastructure et la rend opaque au regard du monde extérieur. Certaines fonctionnalités vous permettront de relier certaines de vos applications au reste du monde ou entre elles de manière sécurisée.

Si vous aimez le jeu des poupées russes, vous allez adorer créer et concevoir votre infrastructure réseau.

Section Le cœur du réacteur : le VPC

Le VPC, ou Virtual Private Cloud, est le socle de base de tout réseau autour de votre infrastructure. Il vous permet de containeriser l'ensemble d'une infrastructure dans une boîte opaque.

On pourrait le comparer à un VPN de manière idéologique, mais techniquement, il reste différent sur de nombreux points.

Ce VPC vous permet de créer une multitude de boîtes à l'intérieur, que l'on appelle des Subnets ou "sous-réseaux" en français. Ces sous-réseaux seront des boîtes avec différentes règles qui leur seront attachées, et dans lesquelles vous pourrez placer virtuellement vos applications. En fonction des règles établies, vos applications seront plus ou moins exposées sur le reste de votre infrastructure ou complètement isolées, même au regard des autres applications.

Pour comprendre comment fonctionne le réseau, il faut établir une base : l'adressage IP. C'est la base même de votre réseau et ce qui va définir beaucoup de choses sur le reste.

L'adressage réseau est partagé entre des conventions techniques et des besoins réels sur votre infrastructure.

Section Comprendre l'IPv4

Avant tout, il faut comprendre comment fonctionne la couche IP. En réalité, il s'agit d'avoir une base universelle avec quelques spécificités pour Google dans notre cas.

Une IP est constituée de 4 compartiments séparés par des points : xxx.xxx.xxx.xxx

Par défaut, une adresse IPV4 est calculée sous forme de bits -> 0 ou 1, ce qui représente une chaîne de 32 bits, soit 4 octets en langage machine. Chaque octet correspond à une partie de l'adresse IP de votre machine.

L'adressage IP n'est pas attribué au hasard. En réalité, il existe une autorité (RIR) qui a partitionné les adresses IP en fonction du monde physique. La première partie de l'IP définit de manière générale l'endroit du monde où vous vous situez :

Il existe également des plages d'IP dites locales (10.XXX.XXX.XXX, 172.16.XXX.XXX, 192.168.XXX.XXX...). Ces adresses IP sont utilisées dans le développement, les homelabs et les réseaux internes.

Section Les masques réseau

Maintenant que tu as les bases sur l'adressage IPv4, il faut comprendre le système de masques réseau, aussi appelés CIDR. Le CIDR est la partie après le "/" dans une adresse IPv4. Il permet de restreindre des plages d'utilisation en fonction du nombre de bits "réservés" pour une application ou un sous-ensemble d'applications.

Il existe plusieurs masques réseau courants :

• /0
• /8
• /16
• /24
• /32

Le calcul du masque réseau est un peu particulier. Il te permet de comprendre quelle plage d'utilisation est disponible.

Exemple :

Imaginons que nous avons un réseau VPC avec une IPv4 : 10.0.0.0/16. Cela signifie que les éléments à l'intérieur de ce VPC (les sous-réseaux) pourront uniquement avoir une adresse IPv4 comprise entre 10.0.0.0 et 10.0.255.255. Cela représente donc 65 536 adresses disponibles (10.0.0.1, 10.0.0.2, 10.0.255.253, 10.0.255.254...). Tu pourras donc théoriquement avoir 65 536 sous-réseaux à l'intérieur de ton réseau.

Si tu as bien suivi, le "/16" à la fin de l'IPv4 bloque les deux premières colonnes de notre IPv4 "10.0". Toutes les adresses IPv4 sous-jacentes commenceront donc par "10.0".

Dans l'hypothèse où nous aurions choisi un masque réseau de /8, la colonne bloquée aurait été uniquement "10". Nous aurions donc eu beaucoup plus d'adresses IPv4 disponibles pour les sous-réseaux (10.0.0.0, 10.1.0.0, 10.2.0.0...) jusqu'à 10.255.255.255.

Pour les plus perspicaces, le masque réseau représente le nombre de bits filtrés. C'est pour ça que je présente uniquement les masques par multiples de "8" (0, 8, 16, 24, 32) car, en calcul informatique, 8 représente 255 bits soit un octet. Il est possible, bien sûr, de créer des masques autres que des multiples de 8 comme 6 ou 4, mais le calcul de tête est un peu plus compliqué. Il existe bien sûr des applications pour calculer et convertir. Mais par convention, on utilise des multiples de 8, c'est plus simple et ça bloque une colonne entière car, oui, le chiffre 8 représente 255 bits.

Pour résumer :

Section Le VPC

Maintenant que la partie théorique sur l'adressage IPv4 est terminée, passons à la théorie sur les services réseau de GCP.

Le VPC est comme la plus grande boîte pour ton réseau infrastructure. Quand tu créés un VPC, il couvre toutes les régions possibles, donc tu peux créer des sous-réseaux attachés à ce VPC n'importe où dans le monde.

Tu peux donc avoir ce type d'infrastructure :

1VPC (10.0.0.0/16)
2  ├── Sous-réseau Public (10.0.1.0/24)
3  ├── Sous-réseau Privé App (10.0.2.0/24)
4  └── Sous-réseau Base de données (10.0.3.0/24)

Ou alors comme ceci :

1VPC (10.0.0.0/16)
2  ├── Sous-réseau Public France (10.0.1.0/24)
3  ├── Sous-réseau Privé France (10.0.2.0/24)
4  └── Sous-réseau Base de données France (10.0.3.0/24)

Section Le Firewall

Contrairement à d'autres providers cloud ou en on-premise, le système de firewall est directement intégré au niveau du VPC avec un système de tags à mettre sur vos VM /services GCP. Un tag, c'est un label qui permet de définir qui peut aller où dans le réseau interne. Par exemple :

• TAG http-server : Autorise le trafic TCP vers le port 443 depuis n'importe quelle adresse IP (0.0.0.0/0) sur chaque VM attachée avec ce tag. Cela signifie que n'importe qui depuis l'extérieur peut accéder à ton serveur via HTTPS.

Cette approche permet de mieux contrôler l'accès à tes ressources en fonction de leurs rôles et besoins spécifiques.

Il faut savoir également qu'un VPC possède une Default Internet Gateway implicite. Dès qu'une instance possède une adresse IP externe (publique), elle peut communiquer automatiquement avec l'extérieur en empruntant cette passerelle par défaut, sans configuration supplémentaire.

À quoi sert un sous-réseau ?

Un sous-réseau est une boîte de plus qui permet de ranger des applications à l'intérieur d'un VPC. Il existe deux types principaux de sous-réseaux :

• Public : Accès direct depuis Internet.
• Privé : Accès uniquement depuis d'autres ressources du VPC.

Cette segmentation permet de mieux organiser et sécuriser ton infrastructure. Par exemple, tu peux avoir des sous-réseaux publics pour les applications accessibles depuis Internet et des sous-réseaux privés pour les bases de données ou les services internes.

Section Conclusion

Nous avons vu une petite partie théorique du réseau, mais il existe d'autres mesures de sécurité à prendre en compte dans ton projet, en dehors du firewall. Par exemple :

• Cloud Armor : Il permet de filtrer les paquets entrants avant même qu'ils n'atteignent ton VPC, notamment sur la couche 7 du modèle OSI. Cela peut inclure des filtres basés sur les top 10 OWASP pour une meilleure cybersécurité.
• Reverse Proxy : Des solutions comme Kong peuvent agir comme un bouclier à l'intérieur de tes sous-réseaux, en gérant le trafic et en ajoutant une couche de sécurité supplémentaire.

Le réseau est conçu pour être un ensemble de briques que tu peux assembler selon tes besoins et tes applications. Il existe des schémas répétitifs pour sécuriser et filtrer de manière optimale, mais ils peuvent être adaptés et modifiés en fonction de tes exigences spécifiques.