Unité 1.2 : L'architecture en couches canonique
Introduction
Il existe une forme d'architecture qui se retrouve dans pratiquement tous les déploiements d'entreprises soumises à des réglementations sur IONOS CLOUD, et il est judicieux de l'apprendre comme configuration par défaut avant d'étudier un produit particulier. La décision qu'elle encode concerne l'endroit où le trafic est autorisé à entrer, la distance qu'il est autorisé à parcourir, et ce qui reste totalement inaccessible depuis Internet. Définir correctement cette frontière au niveau de la topologie est beaucoup moins coûteux que de l'ajuster a posteriori, car sur IONOS CLOUD, la couche réseau dans laquelle se trouve une ressource est le principal facteur qui détermine si elle est exposée. Cette unité présente la forme canonique et explique le raisonnement sous-jacent, afin que les produits par couche des Modules 3 à 6 aient chacun une place évidente.
1. La forme canonique : L7 public, calcul sans état, L4 privé, données privées
La forme se lit de haut en bas comme une séquence de confiance restreinte.
À la périphérie se trouve un équilibrage de charge public de couche 7. Le Managed Application Load Balancer (ALB) distribue le trafic entrant de la couche application vers les cibles en fonction de politiques définies par l'utilisateur, en effectuant l'acheminement sur le contenu, tel que l'hôte et le chemin. C'est le seul composant destiné à faire face à Internet, et c'est là que le TLS est terminé. Comme il effectue l'acheminement sur le contenu applicatif, c'est également là que les préoccupations au niveau de la requête (acheminement basé sur le chemin, acheminement basé sur l'hôte) sont exprimées.
Derrière lui se trouve la couche de calcul sans état : les serveurs d'application. Ceux-ci ne conservent aucun état durable propre. C'est une propriété délibérée, et non un accident, car elle permet à la couche d'être mise à l'échelle, remplacée ou basculée librement. Tout ce qui doit persister est poussé vers le bas.
Entre la couche applicative et les données dont elle dépend se trouve un équilibrage de charge privé de couche 4. Le Managed Network Load Balancer (NLB) opère à la couche 4 TCP/IP ; il distribue tout trafic basé sur TCP et ses règles et vérifications d'état sont strictement de couche 4. Placé en privé, il répartit les connexions sur les nœuds de la couche de données sans jamais être accessible depuis Internet, et il ne termine pas le TLS, de sorte que le chiffrement de bout en bout peut se dérouler directement jusqu'au serveur distant.
En bas se trouve la couche de données uniquement privée : bases de données gérées, cache, stockage partagé. Celles-ci ne sont atteintes que via des LAN privées à travers l'équilibreur interne. Elles n'ont aucune interface publique du tout.
La composition, du L7 public au calcul sans état, au L4 privé, puis aux données privées, est l'expression idiomatique de la défense en profondeur de la plateforme. Chaque étape vers le bas supprime l'accessibilité : Internet peut communiquer avec l'ALB, l'ALB peut communiquer avec la couche applicative, la couche applicative peut communiquer avec la couche de données via le NLB, et la couche de données ne peut communiquer avec personne sans invitation.
Pour FinCorp, c'est le cadre dans lequel sa charge de travail réglementée s'insère. L'ALB public porte le HTTPS destiné aux clients et termine le TLS à la périphérie de l'UE ; les serveurs d'application sans état exécutent la logique métier et externalisent leur état ; le NLB privé fait face au cluster relationnel et au cache ; et la base de données elle-même n'est jamais exposée. Le récit de conformité, que l'Unité 1.4 développe, est considérablement plus facile à établir lorsque la couche de données est architecturalement incapable d'accepter une connexion entrante en provenance de l'extérieur du VDC.
2. Pourquoi le mode privé par défaut, et où tout le reste se connecte
La disposition n'est pas choisie pour des raisons d'élégance ; elle découle de la manière dont le réseau IONOS CLOUD fonctionne réellement et de la façon dont ses protections s'appliquent.
Un LAN à l'intérieur d'un VDC est privé jusqu'à ce qu'il soit explicitement connecté à Internet ; l'exposition est quelque chose que l'on ajoute, et non quelque chose que l'on retire. Cette propriété unique est ce qui fait du mode privé par défaut le chemin de moindre résistance : laisser une couche sur un LAN privé suffit à la rendre déjà inaccessible. Le raisonnement se renforce en fonction de l'endroit où les contrôles de sécurité d'IONOS CLOUD s'appliquent. Les pare-feu au niveau des NIC et les Network Security Groups sont liés aux NIC des serveurs uniquement au niveau du VDC ; ils ne s'appliquent ni au Managed ALB ou NLB, ni à l'abstraction de cluster Managed Kubernetes. Comme il n'est pas possible d'entourer les équilibreurs gérés par un groupe de sécurité, on ne peut pas compter sur un pare-feu pour compenser le fait de placer une base de données sur un chemin public. La topologie elle-même, ce qui est situé sur un LAN privé, doit assurer l'isolement. La segmentation est donc le contrôle porteur, et la division en trois couches (frontière publique, application privée, données privées) est le minimum nécessaire pour l'exprimer clairement.
La même structure absorbe le reste de la plateforme sans modification :
- Conteneurs. Un pool de nœuds Managed Kubernetes se connecte aux LANs comme tout autre calcul et assume le rôle de la couche d'application sans état. Un manifeste ne provisionne pas automatiquement un équilibreur IONOS CLOUD ; le ALB public et tout NLB privé sont provisionnés séparément et pointés vers le cluster, de sorte que le cluster s'insère dans la structure existante plutôt que de la remplacer.
- VMware dédié (Private Cloud). Une charge de travail VMware soumise à des réglementations s'exécute sur le SDDC dédié et se reconnecte au parc de calcul standard via une connectivité hybride, occupant la couche de calcul pour les charges de travail nécessitant un isolement monolocataire, tandis que la frontière élastique reste sur le calcul standard.
- Services IA. Le AI Model Hub géré est une API d'inférence entièrement gérée et accessible publiquement (ses points de terminaison compatibles OpenAI et natifs sont orientés Internet, et non réservés aux LAN privés) ; la couche d'application l'appelle via un chemin sortant de la même manière qu'elle appellerait toute API SaaS externe, tandis que les jeux de données auxquels elle accède peuvent toujours résider dans Object Storage et une base de données gérée sur la couche de données privées sous la couche d'application.
- Connectivité hybride. Les passerelles VPN et NAT et les interconnexions privées se connectent à la frontière et au chemin de sortie, étendant le même tissu privé aux sites sur site plutôt que de percer de nouveaux trous à travers les couches.
Chaque module ultérieur remplit une bande de ce diagramme : le réseau construit la frontière et les deux équilibreurs, le calcul construit la couche d'application, les données construisent la couche inférieure, les conteneurs et l'IA se connectent au-dessus et à côté. La structure ne change pas ; le contenu, si.
Résumé de la décision
| Niveau | Construct IONOS CLOUD | Exposition | Règle régissant |
|---|---|---|---|
| Bordure publique | ALB géré (couche 7) | Orienté Internet | Seul point d'entrée public prévu ; termine TLS ; achemine en fonction du contenu. |
| Application | Calcul sans état ou pool de nœuds Kubernetes | LAN privée, accessible via l'ALB | Ne conserve aucun état durable afin de pouvoir mettre à l'échelle ou basculer librement. |
| Équilibrage interne | NLB géré (couche 4) | Privé uniquement | Transparence TCP, sans terminaison TLS ; jamais orienté Internet. |
| Données | Bases de données gérées, cache, stockage partagé | Privé uniquement, aucune interface publique | Accessible uniquement via l'équilibreur interne sur des LAN privées. |
Adoptez par défaut cette architecture et justifiez toute déviation. La segmentation, et non un ensemble de règles, assure la sécurité du niveau de données ; placez donc un niveau sur une LAN publique uniquement s'il est destiné à faire face à Internet.
Résumé
L'architecture d'entreprise canonique d'IONOS CLOUD restreint la confiance en quatre étapes : un ALB de couche 7 public à la périphérie, un niveau de calcul sans état derrière celui-ci, un NLB de couche 4 privé devant les données, et un niveau de données exclusivement privé en bas. Elle est privée par défaut, car les LAN sont privés tant qu'elles ne sont pas connectées, et parce que les équilibreurs de charge gérés ne peuvent pas être encapsulés dans un groupe de sécurité, ce qui fait de la topologie le véritable contrôle d'isolation. Les conteneurs, VMware dédié, l'IA et les liens hybrides se rattachent tous à cette structure sans la modifier, ce qui explique pourquoi chaque module ultérieur se contente de compléter une bande du même diagramme.
Points clés :
- La structure par défaut est un ALB L7 public vers un calcul sans état, vers un NLB L4 privé, vers des données exclusivement privées, chaque étape vers le bas supprimant l'accessibilité.
- Le principe de confidentialité par défaut tient car une LAN est privée jusqu'à ce qu'elle soit explicitement connectée à Internet, de sorte que l'exposition est quelque chose que l'on ajoute délibérément.
- Les pare-feu de NIC et les NSG sont liés uniquement aux NIC des serveurs, et non à l'ALB/NLB géré ou à l'abstraction du cluster Kubernetes, de sorte que la segmentation par topologie est le contrôle porteur.
- Les conteneurs, VMware dédié, les services d'IA et la connectivité hybride se rattachent à la même structure au lieu de la modifier ; les modules ultérieurs complètent chacun un niveau.