TYPO3 auf Kubernetes unter IT-Grundschutz, Teil 1: Welche Bausteine wirklich greifen
Einen einzelnen TYPO3-Container auf Kubernetes zu betreiben, ist technisch gelöst. Ein echtes TYPO3-Cluster mit mehreren Replikas ist es nicht: kein gemeinsames Dateisystem, dazu Sessions, Caches und Locks, die einen wegfallenden Pod überleben müssen. Noch schwieriger wird es, wenn der Betrieb den IT-Grundschutz des BSI erfüllen muss, und zwar mit hohem Schutzbedarf. Dann reicht ein funktionierendes Cluster nicht mehr. Jede Entscheidung braucht eine Anforderung, an der sie sich messen lässt.
Diese Serie zeigt Schritt für Schritt, wie das funktioniert. Vom gehärteten Image über mTLS und Secrets bis zur Hochverfügbarkeit und zur Härtung von TYPO3 selbst. Die Beispiele stammen aus der Praxis. Die Umsetzung passt auf jedes Kubernetes, nicht nur auf einen bestimmten Anbieter.
Dieser Beitrag eröffnet die Serie „TYPO3 auf Kubernetes unter IT-Grundschutz“. Die Übersicht aller vierzehn Teile steht weiter unten.
01 — Schutzbedarf zuerst, Technik danach
Der IT-Grundschutz beginnt nicht beim Cluster, sondern bei den Informationen. Für jede Anwendung wird der Schutzbedarf in drei Grundwerten festgestellt: Vertraulichkeit, Integrität und Verfügbarkeit. Die Kategorien lauten normal, hoch und sehr hoch.
Bei einer TYPO3-Plattform sieht das oft so aus:
| Objekt | Vertraulichkeit | Integrität | Verfügbarkeit |
|---|---|---|---|
| TYPO3-Website mit Formularen | hoch | hoch | normal bis hoch |
| Datenbank der Website | hoch | hoch | hoch |
| CI/CD und Container-Registry | hoch | sehr hoch | normal |
| Kubernetes-Cluster | erbt das Maximum der Anwendungen | ||
Das Maximumprinzip prägt das Cluster
Ein Cluster trägt mehrere Anwendungen. Nach dem Maximumprinzip übernimmt es den höchsten Schutzbedarf aller Anwendungen, die darauf laufen. Eine einzige Website mit hohem Schutzbedarf hebt damit die gesamte Plattform an. Das ist der Grund, warum Mandantentrennung in dieser Serie so viel Raum bekommt.
Umgekehrt gibt es den Verteilungseffekt. Wird eine Anwendung auf mehrere unabhängige Knoten verteilt, kann der Verfügbarkeitsbedarf des einzelnen Knotens sinken. Das gilt aber nur, wenn die Verteilung wirklich unabhängig ist.
Ein typischer Stolperstein
In der Praxis wird Verfügbarkeit oft reflexhaft auf hoch gesetzt. Das ist teuer. Hohe Verfügbarkeit zieht Hochverfügbarkeit für Control Plane, Knoten und Datenbank nach sich. Kläre deshalb früh, wie lange ein Ausfall wirklich tragbar ist. Vertraulichkeit und Integrität sind bei einem CMS mit personenbezogenen Daten dagegen fast immer hoch.
02 — Modellierung: welche Bausteine für TYPO3 auf Kubernetes
Die Modellierung ordnet jedem Objekt die passenden Bausteine aus dem IT-Grundschutz-Kompendium zu. Diese Serie bezieht sich auf die Edition 2023. Für TYPO3 auf Kubernetes ergibt sich ein recht stabiler Kern:
| Schicht | Baustein | Was er abdeckt |
|---|---|---|
| Container | SYS.1.6 Containerisierung | Images, Laufzeitrechte, Ressourcen, Konfiguration |
| Orchestrierung | APP.4.4 Kubernetes | Separierung, Automatisierung, Netze, Service-Accounts |
| Anwendung | APP.3.1 Webanwendungen und Webservices | TYPO3 selbst: Backend-Zugang, Eingaben, Sitzungen |
| Webserver | APP.3.2 Webserver | FrankenPHP oder der vorgeschaltete Proxy |
| Datenbank | APP.4.3 Relationale Datenbanken | MariaDB oder MySQL der Website |
| Konzepte | CON.1 Kryptokonzept, CON.3 Datensicherungskonzept | TLS und mTLS, Backup und Restore |
| Betrieb | OPS.1.1.3 Patch- und Änderungsmanagement, OPS.1.1.5 Protokollierung | Updates, Deployments, Logs |
| Detektion | DER.1 Detektion von sicherheitsrelevanten Ereignissen | Alarme, Laufzeit-Erkennung |
| Netz | NET.1.1 Netzarchitektur und -design | Zonen, Segmentierung, Zugriffswege |
Dazu kommen die prozessorientierten Bausteine wie ISMS.1 und die ORP-Schicht. Sie gelten für die gesamte Organisation und sind nicht Thema dieser Serie.
Mit Grundschutz++ stellt das BSI den IT-Grundschutz gerade neu auf, mit einem maschinenlesbaren Katalog statt Bausteinen. Wie sich ein ISMS schon jetzt dagegen prüfen lässt, zeigt die Serie Grundschutz++ als Code.
SYS.1.6 und APP.4.4 gehören zusammen
Ein häufiger Fehler ist, nur einen der beiden zu modellieren. SYS.1.6 behandelt den einzelnen Container. Orchestrierung, virtuelle Netze und Registries schließt er ausdrücklich aus und verweist dafür auf APP.4.4. Wer Kubernetes betreibt, braucht also beide Bausteine.
TYPO3 ist nicht nur ein Container
APP.3.1 wird gern übersehen, weil der Fokus auf der Plattform liegt. Doch Backend-Zugang, Mehr-Faktor-Anmeldung, Extensions und Sicherheitsupdates von TYPO3 sind Anwendungsthemen. Ein perfekt gehärtetes Cluster hilft wenig, wenn das Backend offen im Netz steht. Wie TYPO3 selbst gehärtet wird, zeigt Teil 13. Mehr zu den typischen Fehlannahmen steht in Fünf Irrtümer über TYPO3 auf Kubernetes.
03 — Was hoher Schutzbedarf zusätzlich verlangt
Jeder Baustein unterscheidet drei Stufen: Basis (B), Standard (S) und Anforderungen bei erhöhtem Schutzbedarf (H). Basis und Standard bilden die Standard-Absicherung. Die H-Anforderungen kommen in Betracht, sobald ein Grundwert hoch oder sehr hoch ist.
Die H-Anforderungen für Kubernetes und Container
- APP.4.4.A13 Automatisierte Auditierung der Konfiguration
- APP.4.4.A14 Verwendung dedizierter Nodes
- APP.4.4.A15 Trennung von Anwendungen auf Node- und Cluster-Ebene
- APP.4.4.A17 Attestierung von Nodes
- APP.4.4.A18 Verwendung von Mikro-Segmentierung
- APP.4.4.A19 Hochverfügbarkeit von Kubernetes
- APP.4.4.A20 Verschlüsselte Datenhaltung bei Pods
- APP.4.4.A21 Regelmäßiger Restart von Pods
- SYS.1.6.A21 Erweiterte Sicherheitsrichtlinien
- SYS.1.6.A22 Vorsorge für Untersuchungen
- SYS.1.6.A23 Unveränderlichkeit der Container
- SYS.1.6.A24 Hostbasierte Angriffserkennung
- SYS.1.6.A25 Hochverfügbarkeit von containerisierten Anwendungen
- SYS.1.6.A26 Weitergehende Isolation und Kapselung von Containern
Die Liste enthält nicht alle H-Anforderungen der Bausteine, aber die, die für den Betrieb am meisten verändern.
Vorschläge, keine Pflichtliste
H-Anforderungen sind Vorschläge. Welche davon umgesetzt werden, entscheidet eine Risikoanalyse nach BSI-Standard 200-3. Sie betrachtet die Objekte mit hohem oder sehr hohem Schutzbedarf gezielt. Was nicht umgesetzt wird, braucht eine Begründung und ein bewusst getragenes Restrisiko.
Der Grundschutz-Check als Nachweis
Im Grundschutz-Check wird für jede Anforderung festgehalten, ob sie umgesetzt ist: ja, teilweise, nein oder entbehrlich. Erst dieser Check macht aus einer guten Plattform eine nachweisbar sichere. In der Praxis lohnt es sich, ihn nicht am Ende zu schreiben, sondern mit jedem Umbau fortzuführen. Die folgenden Teile nennen deshalb bei jeder Maßnahme die Anforderung, die sie erfüllt.
04 — Die Serie im Überblick
Die Serie folgt dem Weg einer Anfrage und eines Releases durch die Plattform. Jeder Teil steht für sich und verweist auf die Anforderungen, die er abdeckt.
- Welche Bausteine wirklich greifen: Schutzbedarf, Modellierung, hoher Schutzbedarf. Dieser Beitrag.
- Das gehärtete TYPO3-Image: minimale Basis, FrankenPHP, Laufzeitrechte.
- Code als signiertes Artefakt: OCI-Artefakt, Signatur, Prüfung vor dem Start.
- Keine CVEs über 7: ein Scan-Gate, das wirklich blockiert.
- mTLS auf jeder Strecke: eigene CA pro Mandant, kurzlebige Zertifikate.
- Netz und Mandantentrennung: NetworkPolicies und Admission-Regeln.
- Secrets ohne Git: External Secrets und Workload Identity.
- TYPO3 zustandslos machen: Sessions, fileadmin, Caches und Locks.
- Autoscaling und Probes: HPA, PodDisruptionBudget, Rolling Updates.
- Datenbank, Backup und Restore: MariaDB im Cluster oder als Dienst, unveränderliche Backups.
- Nachweis und Betrieb: Logging, Audit, CIS-Prüfung, Laufzeit-Erkennung.
- Verfügbarkeit bei hohem Schutzbedarf: Hochverfügbarkeit für Control Plane, Knoten und Datenbank.
- TYPO3 selbst härten: Backend-Zugang, Rechte, WAF, Header und Updates.
- Das Referenz-Chart: alle Bausteine als offenes Helm-Chart, und warum es kein Operator ist.
Die Teile erscheinen nacheinander. Links auf noch nicht erschienene Teile werden aktiv, sobald der jeweilige Beitrag online ist.
Häufige Fragen
Reicht ein gehärtetes Kubernetes für den IT-Grundschutz?+
Nein. Härtung ist die Voraussetzung, der Grundschutz verlangt aber einen Nachweis pro Anforderung. Dazu gehören Schutzbedarfsfeststellung, Modellierung und der Grundschutz-Check. Ohne diese Dokumente bleibt auch ein sehr gut abgesichertes Cluster formal unbewertet.
Muss jede Anforderung bei erhöhtem Schutzbedarf umgesetzt werden?+
Nein. H-Anforderungen sind Vorschläge. Die Auswahl trifft eine Risikoanalyse nach BSI-Standard 200-3. Nicht umgesetzte Anforderungen werden begründet, und das verbleibende Risiko wird bewusst getragen.
Auf welche Edition des Kompendiums bezieht sich die Serie?+
Auf die Edition 2023 des IT-Grundschutz-Kompendiums. Prüfe vor einem Grundschutz-Check, welche Edition dein Verfahren zugrunde legt. Nummern und Titel der Anforderungen können sich zwischen Editionen ändern.
Braucht TYPO3 selbst eigene Maßnahmen neben der Plattform?+
Ja. TYPO3 wird als Webanwendung nach APP.3.1 modelliert. Dazu zählen ein eingeschränkter Backend-Zugang, Mehr-Faktor-Anmeldung, gepflegte Extensions und zeitnahe Sicherheitsupdates. Die Plattform kann diese Anwendungsthemen nicht ersetzen.
Fazit
Der IT-Grundschutz für TYPO3 auf Kubernetes beginnt mit dem Schutzbedarf. Er bestimmt, ob die Standard-Absicherung reicht oder ob H-Anforderungen dazukommen. SYS.1.6 und APP.4.4 bilden den Kern, APP.3.1 hält TYPO3 selbst im Blick. Der Grundschutz-Check macht die Umsetzung nachweisbar.
Weiter mit Teil 2: Das gehärtete TYPO3-Image.
Ich modelliere deinen TYPO3-Betrieb auf Kubernetes nach IT-Grundschutz und zeige, wo hoher Schutzbedarf wirklich greift.
Schutzbedarfsfeststellung, Modellierung und Grundschutz-Check für Plattform und Anwendung, mit einer klaren Liste der Anforderungen, die offen sind.
Plattform-Betrieb statt Beratung auf Papier: Auf Wunsch setze ich die Maßnahmen auch um und halte den Nachweis aktuell.
Über den Autor
Kai Ole Hartwig
Programmiert seit 2002 – autodidaktisch gelernt, 2012 mit KO-Web selbständig gemacht. Über 100 Projekte, Fokus auf Security, Performance, Automatisierung und Qualität. Heute freiberuflich: DevSecOps-Beratung, Schulungen und Softwareentwicklung.