Unité 3.1 : Topologie et segmentation des VDC
Introduction
La première décision véritable dans toute architecture IONOS CLOUD ne consiste pas à choisir quel serveur construire, mais sur quel réseau chaque couche est positionnée, car sur cette plateforme, le LAN sur lequel une ressource est hébergée est le facteur principal qui détermine si elle est accessible depuis Internet. Un LAN à l'intérieur d'un centre de données virtuel est privé jusqu'à ce que vous le connectiez explicitement à Internet. L'exposition est donc un élément que vous ajoutez délibérément, plutôt que quelque chose que vous retirez ultérieurement. Cette unité définit la topologie dans laquelle chaque construction ultérieure du module s'insère : un LAN d'extrémité public, un LAN d'application privé et un LAN de données privé. Elle commence par les décisions relatives à l'adressage et à la segmentation, et se termine par la construction de cette structure à trois LAN dans Data Center Designer pour la première charge de travail réglementée de FinCorp.
1. Le réseau privé par défaut et la structure en trois niveaux
Un LAN ne devient public que lorsqu'un élément d'accès à Internet y est rattaché ; sans cette connexion, le réseau reste privé. Ce comportement unique fait du « privé par défaut » le chemin de moindre résistance : laisser un niveau sur un LAN non connecté signifie qu'il est déjà inaccessible depuis l'extérieur du VDC. La structure en trois niveaux découle directement de ce principe :
- Un LAN d'extrémité publique ne porte que le point d'entrée exposé à Internet (l'équilibreur de charge de niveau 7 de l'unité 3.3, ainsi que toute extrémité de basculement IP de l'unité 3.5).
- Un LAN d'application privé porte le calcul sans état ou le pool de nœuds Kubernetes.
- Un LAN de données privé porte les bases de données gérées, la mise en cache et le stockage partagé, et n'est accessible que via l'équilibreur de charge interne de niveau 4 de l'unité 3.4.
La raison pour laquelle cette hiérarchisation constitue un contrôle, et non une simple commodité, réside dans la manière dont le filtrage de la plateforme s'applique. Les pare-feu au niveau des NIC et les Network Security Groups sont rattachés aux NIC des serveurs uniquement au niveau du VDC ; ils ne s'appliquent pas au Managed Application Load Balancer, au Managed Network Load Balancer, ni à l'abstraction de cluster Managed Kubernetes. Étant donné qu'il est impossible d'entourer les équilibreurs gérés par un groupe de sécurité, on ne peut pas compter sur une règle de pare-feu pour compenser le placement d'une base de données sur un chemin public. La topologie elle-même doit assurer l'isolation. La segmentation est donc la décision structurante, et la division en trois LAN est le minimum nécessaire pour l'exprimer clairement. L'unité 3.2 ajoute ensuite des règles de pare-feu et de NSG comme couche supplémentaire à l'intérieur de cette topologie, jamais comme substitut.
Pour FinCorp, la société allemande de services financiers qui héberge sa charge de travail conformément aux exigences du RGPD et du BSI, c'est le cadre dans lequel l'application réglementée s'insère. Le dossier de conformité est considérablement plus facile à établir lorsque le niveau de données est architecturalement incapable d'accepter une connexion entrante depuis l'extérieur du VDC, car l'argumentation repose sur la topologie plutôt que sur la justesse d'une liste de règles.
2. Adressage LAN : le /24, la plage réservée et la passerelle
Chaque LAN utilise par défaut un sous-réseau /24, qui constitue l'unité d'adressage à prendre en compte dans la planification. Au sein de ce /24, l'espace d'adresses n'est pas entièrement à votre disposition :
- Les adresses .2 à .9 sont réservées aux services gérés au sein du LAN /24. Ne les attribuez pas à vos propres VM.
- Les adresses .10 à .255 constituent la plage à partir de laquelle les IP des VM sont attribuées.
Les LAN privés utilisent les plages RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). L'unité de transmission maximale sur le LAN est de 1500 octets ; prendre en compte cette MTU permet d'éviter les surprises de fragmentation lorsque vous utiliserez ultérieurement des tunnels chiffrés sur le même réseau dans l'unité 3.6.
La décision entre adresse statique et DHCP est prise par niveau et par rôle. Le niveau applicatif peut tolérer le DHCP, car ses membres sont interchangeables et sans état. Le niveau de données et tout nœud adressé par IP par d'autres ressources doivent conserver une adresse statique, car un point de terminaison de base de données ou une cible d'équilibreur de charge qui change lors du renouvellement d'un bail est une interruption en puissance. La précaution pratique consiste à maintenir les adresses attribuées par DHCP et les adresses statiques dans des parties non chevauchantes de la plage .10-.255, afin qu'aucun bail ne soit en conflit avec une adresse fixe.
Le trafic interne entre les LAN d'un même VDC atteint jusqu'à 6000 Mbps, et le chemin du pare-feu de la carte réseau est dimensionné pour un débit de 6 Gbps, de sorte que la frontière de segmentation ne constitue pas un goulot d'étranglement de performance pour le trafic est-ouest entre les niveaux applicatif et de données.
3. IPv4 publics réservés et modèle IPv6
Une extrémité publique nécessite une adresse stable. Une adresse IPv4 réservée est liée à une région : elle ne peut être utilisée que dans la région du centre de données où elle a été réservée, et bien que des IP différentes d'un même bloc réservé puissent servir à des réseaux distincts, cela reste limité à la même région. La réservation d'une IP requiert le privilège Reserve IP Blocks, de sorte que seuls les titulaires de contrat, les administrateurs ou les utilisateurs auxquels ce privilège a été accordé peuvent l'effectuer ; tous les autres disposent d'un accès en lecture seule à la gestion des IP. Un bloc IPv4 réservé est facturé au tarif de 5,00 EUR par adresse et par période de 30 jours. Les IP ne peuvent pas être restituées individuellement, mais uniquement en tant que bloc, et seulement si aucune adresse du bloc n'est utilisée. De plus, si vous restituez une IP statique, vous ne pouvez pas réserver à nouveau la même adresse par la suite.
Vous réservez l'IP publique avant de créer l'élément qui l'utilise. L'équilibreur de charge de couche 7 de l'unité 3.3, la VPN Gateway et la NAT Gateway de l'unité 3.6, ainsi que l'extrémité avec basculement d'IP de l'unité 3.5, supposent toutes qu'une IPv4 publique réservée existe déjà. Provisionner d'abord le consommateur et chercher une adresse par la suite est la source la plus courante de retours évitables dans la console.
L'IPv6 suit une allocation hiérarchique plutôt qu'une réservation par adresse. Un VDC reçoit un /56 public, chaque LAN activé pour IPv6 reçoit un /64 (choisi dans ce /56 ou attribué automatiquement), et chaque carte réseau reçoit un /80. Un VDC peut avoir jusqu'à 256 LAN activés pour IPv6, et la plateforme prend en charge le fonctionnement en double pile. Une limite est importante au stade de la topologie : les services de réseau gérés (Application Load Balancer, Network Load Balancer, NAT Gateway, IP Failover et Managed Kubernetes) sont uniquement IPv4, de sorte qu'une conception orientée IPv6 termine toujours son extrémité gérée sur IPv4.
Déroulement de l'implémentation DCD
Vous allez construire la topologie à trois LAN de FinCorp : un LAN d'extrémité public, un LAN d'application privé et un LAN de données privé, avec une carte réseau sur chaque niveau et une adresse IPv4 publique réservée pour l'extrémité. Cela met en œuvre la décision de segmentation de la section 1 avant que toute construction de calcul, de sécurité ou d'équilibreur de charge ne soit déployée par-dessus.
Objectif de construction : Construire la topologie à trois LAN avec les cartes réseau et une adresse IP publique réservée.
Étapes (dans Data Center Designer) :
- Ouvrez le VDC FinCorp créé dans l'Unité 2.1 (réutilisez-le ; ne créez pas une nouvelle région). La région est déjà fixée et les réservations d'IP y seront liées.
- Allez dans Menu > Network Services > IP Management et sélectionnez Reserve IP Blocks. Réservez un bloc IPv4 public dans la même région que le VDC. Vous ne pouvez pas choisir une adresse spécifique ; vous en recevez une (ou plusieurs) depuis le pool. C'est l'adresse d'extrémité future, réservée en premier.
- Dans l'Espace de travail, placez le serveur du niveau d'application et le serveur du niveau de données. Chaque serveur reçoit une carte réseau que vous attribuerez à un LAN aux étapes suivantes.
- Créez le LAN d'application privé : faites glisser un LAN sur l'espace de travail (ou connectez la carte réseau du serveur d'application à un nouveau LAN) et laissez-le non connecté à Internet afin qu'il reste privé. Conservez le /24 par défaut.
- Créez le LAN de données privé de la même manière, en tant que deuxième LAN privé, et attachez la carte réseau du serveur du niveau de données à celui-ci. Ne le connectez pas à Internet.
- Créez le LAN d'extrémité public en attachant l'élément Internet Access à un nouveau LAN. C'est le seul LAN qui fait face à Internet ; réservez-le pour l'équilibreur de charge d'extrémité et la carte réseau de basculement d'IP construits dans les unités ultérieures.
- Sur chaque carte réseau, définissez l'adressage par niveau : une adresse statique de la plage .10-.255 pour la carte réseau du niveau de données (afin que le point de terminaison de la base de données soit stable), le DHCP étant acceptable pour la carte réseau d'application interchangeable. Gardez .2-.9 libre pour les services gérés.
- Approvisionnez les modifications. La forme à trois LAN existe désormais avec l'adresse IP publique réservée et les niveaux segmentés.
Erreurs courantes :
- Réserver l'IP publique après avoir construit le consommateur. Réservez-la d'abord ; l'équilibreur de charge, la passerelle ou le groupe de basculement s'attend à ce qu'elle existe.
- Attribuer une VM dans la plage de services gérés .2-.9 ou dans l'espace de passerelle .1/.2, ce qui entre en conflit avec l'adressage de la plateforme.
- Connecter le LAN de données à Internet « juste pour tester », ce qui contredit l'ensemble de l'argumentation de segmentation sur laquelle repose le récit de conformité.
- Placer une extrémité de basculement d'IP ou un équilibreur de charge sur le même LAN public et s'attendre à ce qu'un NSG le protège ; les équilibreurs de charge gérés ne peuvent pas être enveloppés dans un groupe de sécurité, donc la sécurité du niveau de données doit provenir du fait d'être sur un LAN privé.
- Réserver l'IP dans la mauvaise région ; une IPv4 réservée est liée à une région et inutilisable ailleurs.
Étude de cas d'entreprise (FinCorp)
Le service client soumis à des réglementations de FinCorp est la charge de travail qui sert de point d'ancrage à ce module. Son exigence est simple : les clients accèdent à un point de terminaison HTTPS public, mais les données des comptes ne doivent jamais être accessibles depuis Internet. La décision de conception consiste à exprimer cette exigence sous forme de topologie, et non sous forme d'ensemble de règles. Le LAN d'extrémité public accueillera plus tard le équilibreur de charge de niveau 7 sur l'IPv4 réservé ; la couche applicative exécute la logique métier sur un LAN privé avec des NIC attribuées par DHCP et interchangeables ; et le cluster relationnel est situé sur un LAN de données privé avec une adresse statique, n'étant accessible que par l'équilibreur de charge interne de niveau 4 construit dans l'Unité 3.4. Étant donné que le LAN de données n'est jamais connecté à Internet, FinCorp peut démontrer à ses auditeurs que la base de données ne peut pas accepter une connexion externe par conception, indépendamment de la justesse d'une règle de pare-feu à un jour donné. Chaque construction ultérieure dans ce module s'attache à cette forme exacte.
Résumé
La couche réseau sur laquelle une ressource est située constitue le principal moyen de contrôle de son exposition sur IONOS CLOUD, car un LAN est privé jusqu'à ce qu'il soit explicitement connecté à Internet, et parce que les équilibreurs de charge gérés et le cluster Kubernetes ne peuvent pas être encapsulés dans un pare-feu ou un groupe de sécurité. Cela fait de la segmentation, exprimée par la topologie à trois niveaux (bordure publique, application privée, données privées), la décision d'isolation structurale. L'adressage est planifié autour du /24 par défaut, avec la plage de services gérés .2-.9 réservée et des adresses statiques fixées pour tout nœud adressé par IP. Un IPv4 public réservé est lié à une région, coûte 5,00 EUR par période de 30 jours, nécessite le privilège Reserve IP Blocks et doit être réservé avant l'élément de bordure qui l'utilise ; l'IPv6 est alloué de manière hiérarchique, en /56 par VDC, /64 par LAN et /80 par carte réseau.
Points clés :
- Un LAN est privé tant qu'aucun élément d'accès Internet n'y est rattaché, si bien que le statut par défaut est privé et que l'exposition est ajoutée de manière délibérée.
- Les pare-feux de carte réseau et les NSG ne sont liés qu'aux cartes réseau des serveurs, jamais à l'abstraction ALB/NLB gérée ou au cluster Kubernetes, si bien que la topologie constitue le véritable contrôle d'isolation.
- Le /24 du LAN réserve .2-.9 pour les services gérés et attribue les adresses IP des VM à partir de .10-.255 ; l'adressage statique concerne tout nœud adressé par IP, tandis que le DHCP est utilisé pour les niveaux interchangeables.
- Un IPv4 réservé est lié à une région, facturé à 5,00 EUR par période de 30 jours, nécessite le privilège Reserve IP Blocks et doit être réservé avant l'élément de bordure qui l'utilise.
- L'IPv6 est hiérarchique (/56 par VDC, /64 par LAN, /80 par carte réseau, jusqu'à 256 LAN activés pour IPv6), mais les services réseau gérés sont uniquement IPv4.
Terminologie importante :
- Bloc IPv4 réservé : une adresse publique statique (ou un bloc) liée à une région, réservée dans la gestion des IP, et qui ne peut être restituée que dans son intégralité et uniquement lorsqu'elle n'est pas utilisée.
- Plage de services gérés (.2-.9) : les adresses /24 par LAN réservées aux services gérés par la plateforme, qui ne doivent jamais être attribuées aux VM des clients.
- Double pile : fonctionnement simultané IPv4 et IPv6 sur un LAN ; à noter que les services réseau gérés restent uniquement IPv4.
Lectures complémentaires
- Unité 3.2 : Sécurité réseau : pare-feu et groupes de sécurité (la couche de règles au sein de cette topologie).
- Unité 3.4 : Équilibrage de charge - couche 4 (l'équilibreur interne placé devant le LAN de données).
- Unité 3.6 : Connectivité hybride (les passerelles qui se rattachent aux chemins d'accès et de sortie).