7 Min. Lesezeit

Lernziele

Am Ende dieses Moduls werden Sie in der Lage sein:

  • Die bewährte Unternehmensform auf IONOS darzustellen: einen öffentlichen Layer-7-Lastverteiler vor staatloser Rechenleistung, einen privaten Layer-4-Lastverteiler vor einer privaten Daten-Ebene.
  • Zu erklären, warum Segmentierung und eine private-Standard-Haltung diese Darstellung anstelle von Bequemlichkeit bestimmen.
  • Container, dedizierte VMware, KI-Dienste und Hybrid-Verbindungen auf die gleiche Form zu setzen.

Einheit 1.2: Die kanonische geschichtete Architektur

Einführung

Es gibt eine Architekturform, die in fast jedem regulierten Unternehmenseinsatz auf IONOS wiederkehrt, und es lohnt sich, diese als Standard zu erlernen, bevor man einzelne Produkte studiert. Die Entscheidung, die sie kodiert, betrifft, wo der Datenverkehr hereinkommen darf, wie weit er reisen darf und was vom Internet aus gesehen unerreichbar bleibt. Die richtige Grenze auf der Topologieebene zu setzen, ist viel günstiger, als sie später nachträglich anzupassen, da auf IONOS die Netzwerkebene, in der eine Ressource sitzt, das Hauptkriterium dafür ist, ob sie exponiert ist. Diese Einheit zeichnet die kanonische Form und erklärt die Begründung, so dass die Produkte pro Ebene in den Modulen 3 bis 6 jeweils einen offensichtlichen Platz haben.

1. Die Kanonische Form: Öffentliches L7, Zustandsloses Computing, Privates L4, Private Daten

Die Form liest sich von oben nach unten als eine Sequenz von sich verringerndem Vertrauen.

Am Rand sitzt ein öffentliches Layer-7-Load Balancer. Das Managed Application Load Balancer (ALB) verteilt den eingehenden Anwendungsverkehr auf Ziele basierend auf benutzerdefinierten Richtlinien und leitet auf Inhalt wie Host und Pfad weiter. Es ist das eine Komponente, die dem Internet zugewandt ist, und es ist dort, wo TLS beendet wird. Da es auf Anwendungs-Inhalt leitet, ist es auch dort, wo anforderungsbasierte Bedenken (pfadbasierte Weiterleitung, hostbasierte Weiterleitung) ausgedrückt werden.

Dahinter sitzt die zustandslose Computerebene: die Anwendungsserver. Diese haben keinen dauerhaften Zustand ihrer eigenen. Das ist eine bewusste Eigenschaft, nicht ein Zufall, da es die Ebene ermöglicht, frei skaliert, ersetzt oder übernommen zu werden. Alles, was persistieren muss, wird nach unten verschoben.

Zwischen der Anwendungsebene und den Daten, auf die sie angewiesen ist, sitzt ein privates Layer-4-Load Balancer. Das Managed Network Load Balancer (NLB) arbeitet auf TCP/IP-Ebene 4; es verteilt jeden TCP-basierten Verkehr und seine Regeln und Gesundheitsprüfungen sind strikt Ebene 4. Privat platziert, verteilt es Verbindungen über die Daten-Ebenen-Knoten, ohne jemals von dem Internet aus erreichbar zu sein, und es beendet nicht TLS, so dass eine Ende-zu-Ende-Verschlüsselung direkt zum Backend durchlaufen kann.

Am unteren Rand sitzt die nur-private Daten-Ebene: gemanagte Datenbanken, der Cache, gemeinsamer Speicher. Diese sind nur über private LANs durch den internen Lastenausgleich erreichbar. Sie haben keine öffentliche Schnittstelle überhaupt.

Die Zusammensetzung, öffentliches L7 bis zustandsloses Computing bis privates L4 bis private Daten, ist die plattformübergreifende Ausdrucksform der Verteidigung in der Tiefe. Jeder nach unten gerichtete Schritt entfernt die Erreichbarkeit: das Internet kann mit dem ALB sprechen, das ALB kann mit der App-Ebene sprechen, die App-Ebene kann mit der Daten-Ebene durch den NLB sprechen, und die Daten-Ebene kann mit niemandem ungeladen sprechen.

Für FinCorp ist dies die Hülle, in die seine regulierten Workload fallen. Der öffentliche ALB trägt kundenorientierte HTTPS und beendet TLS am EU-Rand; die zustandslosen Anwendungsserver führen die Geschäftslogik aus und externalisieren ihren Zustand; der private NLB ist vor den relationalen Cluster und dem Cache platziert; und die Datenbank selbst ist nie exponiert. Die Compliance-Geschichte, die in Einheit 1.4 entwickelt wird, ist wesentlich einfacher zu machen, wenn die Daten-Ebene architektonisch unfähig ist, eine eingehende Verbindung von außerhalb des VDC anzunehmen.

2. Warum Private-by-Default und wo sich alles andere anhängt

Die Layout-Auswahl ist nicht wegen ihrer Eleganz getroffen; sie ergibt sich aus dem tatsächlichen Verhalten des IONOS-Netzwerks und wie dessen Schutzmechanismen binden.

Ein LAN innerhalb eines VDC ist privat, bis es explizit mit dem Internet verbunden wird; die Exposition ist etwas, das hinzugefügt wird, und nicht etwas, das entfernt wird. Diese einzelne Eigenschaft ist es, die den private-by-Default-Ansatz zum Pfad des geringsten Widerstands macht: Lassen Sie eine Ebene auf einem privaten LAN und sie ist bereits unerreichbar. Die Argumentation verdichtet sich, wo die IONOS-Sicherheitskontrollen angewendet werden. NIC-Ebene-Feuerwände und Network Security Groups binden an Server-NICs auf der VDC-Ebene; sie gelten nicht für den Managed ALB oder NLB, noch für die Managed Kubernetes Cluster-Abstraktion. Da Sie die verwalteten Balancer nicht in einer Sicherheitsgruppe einbinden können, können Sie sich nicht auf eine Firewall verlassen, um die Platzierung einer Datenbank auf einem öffentlichen Pfad zu kompensieren. Die Topologie selbst, was auf einem privaten LAN sitzt, muss die Isolation übernehmen. Segmentierung ist daher die tragende Kontrolle, und die dreigliedrige Aufteilung (öffentliche Kante, private App, private Daten) ist das Minimum, das sie sauber ausdrückt.

Die gleiche Form absorbiert die REST der Plattform, ohne sich zu ändern:

  • Container. Ein Managed Kubernetes Node-Pool bindet an die LANs wie jeder andere Rechner und übernimmt die Rolle der Zustandslosen-Anwendungsebene. Ein Manifest provisioniert keinen IONOS-Balancer automatisch; der öffentliche ALB und jeder private NLB werden separat bereitgestellt und auf den Cluster verweisen, sodass der Cluster in die bestehende Form passt, anstatt sie zu ersetzen.
  • Dedicated VMware (Private Cloud). Ein regulierter VMware Workload läuft auf dem dedizierten SDDC und verbindet sich über Hybrid-Connectivity mit dem Standard-Compute-Besitz, wobei es die Rechenschicht für Workloads besetzt, die eine Single-Tenant-Isolation benötigen, während die elastische Kante auf dem Standard-Compute bleibt.
  • KI-Dienste. Der verwaltete AI Model Hub ist ein vollständig verwalteter, öffentlich erreichbarer Inferenz-API (seine OpenAI-kompatiblen und nativen Endpunkte sind internetfähig, nicht nur privat-LAN); die Anwendungsebene ruft es über einen ausgehenden Pfad auf, genauso wie sie jeden externen SaaS-API aufrufen würde, während die Datensätze, auf die es zurückgreift, immer noch in Object Storage und einer verwalteten Datenbank auf der privaten Datenebene unter der Anwendungsebene leben können.
  • Hybrid-Connectivity. VPN- und NAT-Gateways und private Interconnects binden an der Kante und dem Ausgangspfad an, wobei sie das gleiche private Gewebe zu lokalen Standorten erweitern, anstatt neue Löcher durch die Ebenen zu schlagen.

Jedes spätere Modul füllt eine Bandbreite dieses Diagramms: Netzwerke bauen die Kante und die beiden Balancer, Rechner bauen die Anwendungsebene, Daten bauen die untere Ebene, Container und KI binden darüber und daneben an. Die Form ändert sich nicht; der Inhalt schon.

Entscheidungszusammenfassung

Tier IONOS-Konstrukt Exposition Regierende Regel
Öffentliche Kante Gemanagter ALB (Layer 7) Internet-fähig Nur beabsichtigter öffentlicher Einstiegspunkt; beendet TLS; leitet auf Inhalt um.
Anwendung Zustandsloser Rechner oder Kubernetes Node-Pool Private LAN, über den ALB erreichbar Enthält keinen dauerhaften Zustand, so dass es frei skaliert oder übernommen werden kann.
Interne Ausgleich Gemanagter NLB (Layer 4) Nur privat TCP-Durchleitung, keine TLS-Beendigung; niemals internet-fähig.
Daten Gemanagte Datenbanken, Cache, gemeinsamer Speicher Nur privat, keine öffentliche Schnittstelle Nur über den internen Ausgleich über private LANs erreichbar.

Standardmäßig auf diese Form zurückgreifen und jede Abweichung begründen. Segmentierung, nicht eine Regelsammlung, hält die Datenebene sicher, so dass eine Ebene nur auf einem öffentlichen LAN platziert werden sollte, wenn sie für das Internet bestimmt ist.

Zusammenfassung

Die kanonische IONOS-Unternehmensarchitektur reduziert das Vertrauen in vier Schritten: ein öffentliches Layer-7-ALB am Rand, ein zustandsloser Compute-Tier dahinter, ein privates Layer-4-NLB vor den Daten und ein privater Daten-Tier am unteren Ende. Sie ist privat-by-default, weil LANs privat sind, bis sie verbunden werden, und weil die gemanagten Lastenausgleichsgeräte nicht in eine Sicherheitsgruppe eingeschlossen werden können, was die Topologie zur realen Isolationskontrolle macht. Container, dedizierte Dedicated Server, KI und Hybrid-Links können alle an diese Form angeschlossen werden, ohne sie zu ändern, was der Grund dafür ist, dass jedes spätere Modul einfach eine Bandbreite des gleichen Diagramms ausfüllt.

Wichtige Punkte:

  • Die Standardform ist öffentliches L7-ALB zu zustandslosem Compute zu privatem L4-NLB zu privatem Daten-Tier, wobei jeder nach unten gerichtete Schritt die Erreichbarkeit entfernt.
  • Private-by-default gilt, weil ein Dedicated Server privat ist, bis er explizit mit dem Internet verbunden wird, sodass die Exposition etwas ist, das Sie absichtlich hinzufügen.
  • Netzwerk-Schnittstellen-Feuerwände und Netzwerksicherheitsgruppen binden nur an Server-Netzwerkschnittstellen, nicht an das gemanagte ALB/NLB oder die Dedicated Server-Abstraktion, sodass die Segmentierung durch die Topologie die tragende Kontrolle ist.
  • Container, dedizierte Dedicated Server, KI-Dienste und Hybrid-Konnektivität können an die gleiche Form angeschlossen werden, anstatt sie zu ändern; spätere Module füllen jeweils eine Ebene aus.