Wenn aus einem Dienst sechzig werden

Eine selbstgehostete Cloud beginnt meist klein: ein Reverse-Proxy, eine Anwendung, eine Datenbank. Doch das wächst. Jeder neue Dienst bringt seine eigene Datenbank mit, oft einen Cache, manchmal einen Hintergrund-Arbeiter, einen Metrik-Exporter. Aus einer Handvoll Containern werden schnell Dutzende – bei uns inzwischen über sechzig, verteilt auf dreizehn Funktionsgruppen.

Ab einer gewissen Größe stellt sich die Frage nicht mehr „Läuft es?“, sondern „Verstehe ich noch, was da läuft und warum es miteinander reden darf?“ Genau das ist der Punkt, an dem eine bewusste Architektur den Unterschied macht zwischen einem wartbaren System und einem Kartenhaus. Dieser Beitrag beschreibt das Ordnungsprinzip dahinter – bewusst generisch, als Blaupause für jeden, der vor demselben Wildwuchs steht.

Das Ordnungsprinzip: Funktion und Isolation

Zwei Fragen strukturieren die gesamte Landschaft. Erstens: Welche Funktion erfüllt ein Container? Zweitens: Mit wem muss er dafür reden – und mit wem auf keinen Fall?

Die erste Frage bündelt Container zu Funktionsgruppen: Alles, was zusammen einen Dienst ergibt, gehört zusammen. Die zweite Frage zieht die Grenzen: Jede Gruppe bekommt ihr eigenes, privates Netzwerk. Container innerhalb einer Gruppe sehen einander; über die Gruppengrenze hinweg sehen sie nichts – es sei denn, es ist ausdrücklich erlaubt.

Die Funktionsgruppen im Überblick

Nach Funktion sortiert ergibt sich eine überschaubare Landkarte. Jede Gruppe hat eine klar umrissene Aufgabe:

Die Eingangsschicht

Ein einziger Reverse-Proxy ist der alleinige Eingangspunkt für allen verschlüsselten Web-Verkehr. Er entscheidet, welche Anfrage zu welchem Dienst geht, kümmert sich um Zertifikate und setzt Sicherheits-Regeln durch. Dazu gehören ein Dienst für ausgehende E-Mail-Zustellung und die tägliche Datensicherung. Diese Schicht ist die einzige, die sowohl nach außen als auch in die Backend-Netze reicht.

Kommunikation

Eine vollständige Mail-Suite – Versand, Empfang, Webmail, Spam- und Virenfilter, ein eigener DNS-Resolver – bildet die größte einzelne Gruppe. Sie läuft komplett in ihrem eigenen, abgeschotteten Netz. Eine Mail-Infrastruktur hat eine große Angriffsfläche; sie strikt zu isolieren, begrenzt den Schaden, falls doch einmal etwas durchkommt.

Zentrale Anmeldung

Ein Single-Sign-On-Dienst übernimmt die Anmeldung für alle anderen Dienste. Statt jeder Anwendung ihre eigene Nutzerverwaltung zu geben, gibt es eine zentrale Stelle – mit eigener Datenbank und eigenem Cache in einem isolierten Backend. Das reduziert die Zahl der Orte, an denen Zugangsdaten liegen, auf genau einen.

Daten- und Anwendungsdienste

Hierzu zählen ein Cloud-Speicher für Dateien, ein Headless-CMS hinter dieser Website, ein Git-Dienst für den Quellcode und eine Workflow-Automatisierung mit angeschlossener Vektordatenbank. Das Prinzip ist bei allen gleich: Jede Anwendung bringt ihre eigene Datenbank mit, und beide teilen sich ein privates Netz, das sonst niemand betritt.

Beobachtung und Sicherheit

Zwei Gruppen wachen über den Rest. Die Beobachtungsschicht sammelt Metriken, zeichnet Dashboards, verschickt Alarme und erhebt Web-Analytik. Die Sicherheitsschicht ist ein SIEM – ein System, das sicherheitsrelevante Ereignisse aus dem gesamten Verbund zusammenführt und auswertet. Beide liegen in eigenen internen Netzen.

Betrieb und Fundament

Schließlich das Rückgrat: Werkzeuge, die über neue Software-Stände informieren, bei der Stack-Verwaltung helfen und Push-Benachrichtigungen zustellen. Dazu ein selbstgehosteter VPN-Koordinationsserver für ein privates Mesh-Netz und eine private Container-Registry, die ausschließlich intern erreichbar ist.

Das wiederkehrende Muster: App, Datenbank, eigenes Netz

Wer die Gruppen nebeneinanderlegt, erkennt dasselbe Muster immer wieder. Fast jeder Dienst besteht aus:

Dieses Muster als Standard zu behandeln, hat einen unterschätzten Vorteil: Es macht die sichere Variante zur bequemen Variante. Eine neue Datenbank landet automatisch im privaten Netz, weil das die Vorlage ist – nicht, weil jemand daran denken musste, sie abzuschotten. Sicherheit, die man aktiv untergraben müsste, ist stabiler als Sicherheit, an die man sich erinnern muss.

Least Exposure: Was nie ins Internet gehört

Der wichtigste Grundsatz der ganzen Anordnung lautet: So wenig wie möglich nach außen zeigen. Der Reverse-Proxy ist der einzige Dienst, der öffentlich erreichbar sein muss. Alles andere – Datenbanken, Caches, interne Schnittstellen, Verwaltungswerkzeuge, die Registry – bleibt hinter der Grenze.

Für Dienste, die nur zwischen Maschinen sprechen, gilt das doppelt: Sie brauchen keine öffentliche Adresse. Sie über ein privates Mesh-Netz erreichbar zu machen und zusätzlich per Firewall auf genau diesen Adressbereich zu beschränken, hält sie für das offene Internet unsichtbar – so, als gäbe es sie nicht.

Warum Segmentierung Sicherheit ist

Netzwerk-Segmentierung ist keine akademische Fingerübung, sondern gelebte Schadensbegrenzung. Der Fachbegriff dafür ist Blast Radius – die Reichweite eines Einbruchs.

Stellt man sich vor, ein einzelner Container würde kompromittiert: In einem flachen Netz, in dem alle alles sehen, hätte der Angreifer sofort Sicht auf jede Datenbank, jeden Dienst, jedes Geheimnis. In einer segmentierten Landschaft sieht er zunächst nur die anderen Container seiner eigenen Gruppe – und stößt an jeder Gruppengrenze auf eine Wand. Jede Grenze, die er überwinden muss, ist Zeit, ist Spur, ist eine weitere Gelegenheit, entdeckt zu werden.

Nebeneffekt: Ein Inventar, das man versteht

Eine saubere Gruppierung zahlt sich nicht nur bei der Sicherheit aus, sondern auch im Alltag. Fragt man „Was läuft hier eigentlich alles?“, ist die Antwort nicht eine unsortierte Liste von sechzig Namen, sondern dreizehn Gruppen mit je einer klaren Aufgabe. Ein neuer Container fällt sofort auf, weil er in eine Gruppe gehört – oder eben verdächtig heimatlos ist.

Dieses Verständnis ist auch die Grundlage für gutes Monitoring: Man kann nur überwachen, was man benennen kann. Wer weiß, welche Container zusammengehören und welche Funktion jede Gruppe erfüllt, weiß auch, welcher Ausfall harmlos ist und welcher wehtut – und kann seine Alarme entsprechend schärfen.

Lessons Learned

Über sechzig Container klingen nach Komplexität – und sind es auch. Aber die Komplexität wird beherrschbar, sobald jeder Container eine klare Funktion und eine klare Grenze hat. Ordnung im Maschinenraum ist am Ende weniger eine Frage der Technik als der Disziplin: jeden Dienst dorthin stellen, wo er hingehört, und ihn nur so weit öffnen, wie er es wirklich braucht.