8 min de lecture

Objectifs d'apprentissage

À la fin de ce module, vous serez en mesure de:

  • Mettre en place la forme d'entreprise éprouvée sur IONOS : un équilibreur de charge public de couche 7 devant un calcul sans état, un équilibreur de charge privé de couche 4 devant un niveau de données privé uniquement.
  • Expliquer pourquoi la segmentation et une posture privée par défaut déterminent cette disposition plutôt que la commodité.
  • Placer des conteneurs, des serveurs dédiés VMware, des services d'intelligence artificielle et une connectivité hybride sur la même forme.

Unité 1.2 : L'architecture canonique en couches

Introduction

Il existe une forme d'architecture qui se répète dans presque tous les déploiements d'entreprise réglementés sur IONOS, et il est utile de l'apprendre comme une référence avant d'étudier un seul produit. La décision qu'elle encode est de savoir où le trafic est autorisé à entrer, jusqu'où il est autorisé à se déplacer, et ce qui reste inaccessible à partir d'internet entièrement. Définir correctement cette limite au niveau de la topologie est beaucoup moins coûteux que de la refaire plus tard, car sur IONOS le niveau de réseau auquel se trouve une ressource est la chose principale qui détermine si elle est exposée. Cette unité dessine la forme canonique et explique les raisons, afin que les produits par niveau dans les modules 3 à 6 aient chacun un emplacement évident.

1. La forme canonique : public L7, calcul étatique, privé L4, données privées

La forme se lit de haut en bas comme une séquence de confiance réduite.

Au bord se trouve un public Layer 7 Load Balancer. Le Managed Application Load Balancer (ALB) distribue le trafic de couche application entrant aux cibles en fonction de politiques définies par l'utilisateur, en routant 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é. Puisqu'il route sur le contenu de l'application, c'est également là que les préoccupations au niveau de la requête (routage basé sur le chemin, routage basé sur l'hôte) sont exprimées.

Derrière lui se trouve le niveau de calcul étatique : les serveurs d'applications. Ceux-ci ne contiennent aucun état durable en propre. C'est une propriété délibérée, et non un accident, car cela permet au niveau d'être mis à l'échelle, remplacé ou basculé librement. Tout ce qui doit persister est poussé vers le bas.

Entre le niveau d'application et les données dont il dépend se trouve un privé Layer 4 Load Balancer. Le Managed Network Load Balancer (NLB) fonctionne au niveau TCP/IP Layer 4 ; il distribue tout trafic basé sur TCP et ses règles et vérifications de santé sont strictement au niveau 4. Placé en privé, il répartit les connexions sur les nœuds du niveau 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 fonctionner directement jusqu'au backend.

Au bas se trouve le niveau de données privé uniquement : bases de données gérées, cache, stockage partagé. Ceux-ci ne sont accessibles que sur des LAN privées via l'équilibreur interne. Ils n'ont aucune interface publique du tout.

La composition, de public L7 à calcul étatique à privé L4 à données privées, est l'expression idiomatique de la plateforme de défense en profondeur. Chaque étape vers le bas supprime la possibilité d'accès : Internet peut communiquer avec l'ALB, l'ALB peut communiquer avec le niveau d'application, le niveau d'application peut communiquer avec le niveau de données via le NLB, et le niveau de données peut communiquer avec personne sans invitation.

Pour FinCorp, ceci est le shell dans lequel sa charge de travail réglementée est insérée. L'ALB public transporte les HTTPS orientés client et termine le TLS à la limite de l'UE ; les serveurs d'applications étatiques exécutent la logique métier et externalisent leur état ; le NLB privé fait face aux Cluster relationnels et au cache ; et la base de données elle-même n'est jamais exposée. L'histoire de conformité, que l'unité 1.4 développe, est matériellement plus facile à établir lorsque le niveau de données est incapable, sur le plan architectural, d'accepter une connexion entrante en dehors du VDC.

2. Pourquoi Private-by-Default, et où tout le reste s'attache

La disposition n'est pas choisie pour son élégance ; elle découle de la façon dont le réseau IONOS se comporte 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 vous ajoutez, et non quelque chose que vous supprimez. Cette seule propriété est ce qui rend le private-by-default le chemin de moindre résistance : laissez un niveau sur un LAN privé et il est déjà inaccessible. Le raisonnement se combine avec l'endroit où les contrôles de sécurité IONOS s'appliquent. Les pare-feu au niveau NIC et les Network Security Groups sont liés aux NIC des serveurs au niveau du VDC uniquement ; ils ne s'appliquent pas au Managed ALB ou NLB, ni à l'abstraction Managed Kubernetes Cluster. Puisque vous ne pouvez pas envelopper les équilibreurs gérés dans un groupe de sécurité, vous ne pouvez 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 se trouve sur un LAN privé, doit faire l'isolation. La segmentation est donc le contrôle porteur de charge, et la division en trois niveaux (bordure publique, application privée, données privées) est le minimum qui l'exprime clairement.

La même forme absorbe les REST de la plateforme sans changer :

  • Conteneurs. Un pool de Managed Kubernetes Node s'attache aux LAN comme n'importe quel autre calcul et prend le rôle du niveau d'application sans état. Un manifeste n'auto-provisionne pas un équilibreur IONOS ; l'équilibreur ALB public et tout équilibreur NLB privé sont provisionnés séparément et pointent vers le Cluster, donc le Cluster s'intègre dans la forme existante plutôt que de la remplacer.
  • Serveurs dédiés VMware (Private Cloud). Une charge de travail réglementée VMware s'exécute sur le SDDC dédié et se connecte à l'ensemble de calcul standard via une connectivité hybride, en occupant la couche de calcul pour les charges de travail qui nécessitent une isolation à locataire unique, tandis que le bord élastique reste sur le calcul standard.
  • Services d'intelligence artificielle. Le service géré AI Model Hub est un service d'inférence entièrement géré, accessible publiquement (ses points de terminaison OpenAI compatibles et natifs sont orientés vers Internet, et non uniquement vers un LAN privé) ; le niveau d'application l'appelle via un chemin sortant de la même manière qu'il appellerait tout service SaaS externe API, tandis que les jeux de données sur lesquels il se base peuvent toujours vivre dans un Object Storage et une base de données gérée sur le niveau de données privé en dessous du niveau d'application.
  • Connectivité hybride. Les passerelles VPN et NAT et les interconnects privés s'attachent au bord et au chemin de sortie, en étendant la même toile privée aux sites sur site plutôt que de percer de nouveaux trous à travers les niveaux.

Chaque module ultérieur remplit une bande de ce diagramme : le réseau construit le bord et les deux équilibreurs, le calcul construit le niveau d'application, les données construisent le niveau inférieur, les conteneurs et l'intelligence artificielle s'attachent au-dessus et à côté. La forme ne change pas ; le contenu change.

Résumé de la décision

Niveau Constructeur IONOS Exposition Règle de gouvernance
Bord public ALB géré (Couche 7) Exposition à internet Seul point d'entrée public prévu ; met fin à TLS ; routage en fonction du contenu.
Application Calcul sans état ou pool Kubernetes Node LAN privé, accessible via l'ALB Ne contient aucun état durable, il peut donc être mis à l'échelle ou basculer librement.
Équilibrage interne NLB géré (Couche 4) Uniquement privé Pass-through TCP, pas de termination TLS ; jamais exposé à internet.
Données Bases de données gérées, cache, stockage partagé Uniquement privé, pas d'interface publique Accessible uniquement via l'équilibrage interne sur des réseaux LAN privés.

Revenir à cette forme par défaut et justifier toute déviation. La segmentation, et non un ensemble de règles, maintient la sécurité du niveau des données, il est donc recommandé de placer un niveau sur un LAN public uniquement lorsqu'il est destiné à être exposé à internet.

Résumé

L'architecture d'entreprise canonique d'IONOS réduit la confiance en quatre étapes : un ALB de niveau 7 public à la périphérie, un niveau de calcul sans état derrière lui, un NLB de niveau 4 privé devant les données, et un niveau de données privé uniquement au bas. Il est privé par défaut car les LAN sont privés jusqu'à ce qu'ils soient connectés et parce que les équilibreurs de charge gérés ne peuvent pas être entourés d'un groupe de sécurité, ce qui fait que la topologie est le véritable contrôle d'isolement. Les conteneurs, les serveurs dédiés VMware, l'IA et les liens hybrides s'attachent à cette forme sans la modifier, c'est pourquoi chaque module ultérieur remplit simplement une bande du même diagramme.

Points clés :

  • La forme par défaut est ALB L7 public vers calcul sans état vers NLB L4 privé vers données privées uniquement, avec chaque étape descendante supprimant la portée.
  • Le privé par défaut est valable car un LAN est privé jusqu'à ce qu'il soit explicitement connecté à Internet, donc l'exposition est quelque chose que vous ajoutez délibérément.
  • Les pare-feu de carte réseau et les groupes de sécurité réseau se lient aux cartes réseau de serveur uniquement, et non à l'ALB/NLB géré ou à l'abstraction Kubernetes Cluster, donc la segmentation par topologie est le contrôle porteur de charge.
  • Les conteneurs, les serveurs dédiés VMware, les services d'IA et la connectivité hybride s'attachent à la même forme plutôt que de la modifier ; les modules ultérieurs remplissent une tierce chacun.