TYPO3 auf Kubernetes unter IT-Grundschutz, Teil 11: Nachweis und Betrieb
Eine Maßnahme, die niemand nachweisen kann, zählt im Audit nicht. Und sie hilft auch im Ernstfall wenig. Dieser Teil zeigt, wie ein TYPO3-Cluster seinen Zustand selbst belegt: mit Logs an einem zentralen Ort, Alarmen auf die richtigen Signale und Prüfungen, die regelmäßig von allein laufen.
Teil 11 von 14 der Serie „TYPO3 auf Kubernetes unter IT-Grundschutz“. Die Übersicht aller Teile steht in Teil 1.
01 — Logs gehören an einen zentralen Ort
Container sind kurzlebig. Ihre Logs verschwinden mit ihnen, wenn niemand sie abholt. SYS.1.6.A7 verlangt deshalb, dass Protokollierungsdaten der Container persistent gespeichert werden. Der Baustein OPS.1.1.5 „Protokollierung“ regelt den Rahmen dazu.
Ein Collector auf jedem Knoten, etwa Grafana Alloy, liest die Container-Logs und schickt sie an einen zentralen Speicher wie Loki. Dort wird die Aufbewahrungsfrist festgelegt und dokumentiert. Bei hohem Schutzbedarf ist ein Jahr ein gängiger Wert. Die Anwendung selbst schreibt nichts in lokale Dateien. Sie schreibt nach stdout.
Dazu kommt das Audit-Log der Kubernetes-API. Es hält fest, wer welche Ressource geändert und, mit passender Policy, wer welches Secret gelesen hat. Der API-Server schaltet es mit --audit-policy-file und --audit-log-path ein, in k3s über die entsprechenden Server-Argumente. Dazu gehören eine eigene Policy und eine eigene Aufbewahrung. Bei verwalteten Kubernetes-Diensten wird es in der Konfiguration des Anbieters aktiviert. Ohne dieses Log lässt sich nach einem Vorfall nicht rekonstruieren, wer ein Secret gelesen oder ein Deployment verändert hat.
02 — Alarme, die auf das Richtige reagieren
Prometheus sammelt Metriken, Alertmanager verteilt Alarme. Die eigentliche Arbeit steckt in den Regeln. Ein Alarm auf hohe CPU-Last weckt oft umsonst. Wertvoller sind Regeln auf Symptome: Pods, die immer wieder neu starten. Zertifikate kurz vor Ablauf. Fehlgeschlagene Backup-Jobs. Secrets, die nicht mehr synchronisiert werden. Und 5xx-Antworten am Eingang. APP.4.4.A11 fasst das als Überwachung der Container zusammen.
Eine externe Verfügbarkeitsprüfung ergänzt das Monitoring im Cluster. Sie ruft die echten Domains von außen auf. Fällt der Cluster komplett aus, schweigt das interne Monitoring. Der externe Check meldet sich trotzdem.
In der Praxis zeigt sich ein Muster: Die gefährlichsten Ausfälle sind die stillen. Ein Prüfjob, der nie eingeplant wurde, meldet auch nie etwas. Deshalb braucht jeder Alarm einen Test, der zeigt, dass er auslöst.
03 — Härtung prüfen, Angriffe erkennen
kube-bench prüft den Cluster gegen den CIS-Benchmark für Kubernetes. Als geplanter Job entsteht daraus ein wiederkehrender Nachweis statt einer einmaligen Momentaufnahme. APP.4.4.A13 fordert bei hohem Schutzbedarf genau diese automatisierte Auditierung der Konfiguration.
Falco erkennt zur Laufzeit, was in Containern passiert. Eine Shell in einem Pod, der keine braucht. Schreibzugriffe auf Systempfade. Unerwartete Netzwerkverbindungen. Das deckt die hostbasierte Angriffserkennung nach SYS.1.6.A24 ab und liefert Ereignisse für die Detektion nach DER.1. Hochgeladene Dateien prüft ClamAV zweimal: beim Upload, bevor sie ausgeliefert werden, und noch einmal nachts mit aktuellen Signaturen. Der nächtliche Lauf findet Dateien, die beim Hochladen noch als sauber galten.
Auch die Cloud-Ebene gehört dazu. Ein Audit-Trail der Cloud-API, abgelegt mit Object Lock, hält jeden Zugriff fest. Ein Dienst zur Bedrohungserkennung meldet Zugriffe, die am Cluster vorbeigehen.
04 — Patches, Vorfälle und der Nachweis
Das Betriebssystem der Knoten installiert Sicherheitsupdates automatisch. Neustarts orchestriert ein Job, der Knoten nacheinander leert und neu startet. k3s selbst aktualisiert der system-upgrade-controller, gesteuert über eine Plan-Ressource im GitOps-Repository. Bei anderen Distributionen übernimmt das der jeweilige Upgrade-Weg, etwa kubeadm upgrade oder das Versionsfeld im Infrastruktur-Code eines verwalteten Dienstes. So bleibt jede Version nachvollziehbar, wie es OPS.1.1.3 für das Patch- und Änderungsmanagement verlangt.
Für Vorfälle braucht es einen festen Ablauf: erkennen, eindämmen, beheben, nachbereiten. Erst die schriftliche Retrospektive macht aus einem Vorfall eine Verbesserung. SYS.1.6.A22 verlangt bei hohem Schutzbedarf Vorsorge für Untersuchungen. Dazu gehört etwa, den Zustand eines Containers sichern zu können, bevor er gelöscht wird.
Für ein Audit zählt am Ende der Nachweis. Logs, Alarmhistorie, kube-bench-Ergebnisse, Restore-Protokolle aus Teil 10 und Retrospektiven belegen, dass die Maßnahmen nicht nur konfiguriert sind. Sie zeigen, dass sie wirken.
Häufige Fragen
Welche Logs braucht ein TYPO3-Cluster unter IT-Grundschutz?+
Container-Logs zentral mit festgelegter Aufbewahrung, das Audit-Log der Kubernetes-API und den Audit-Trail der Cloud-Plattform. Dazu kommen die Ereignisse der Sicherheitswerkzeuge, also etwa Entscheidungen der Web Application Firewall und Meldungen von Falco.
Ersetzt Falco ein SIEM?+
Nein. Falco erkennt verdächtiges Verhalten in Containern. Ein SIEM führt Ereignisse aus vielen Quellen zusammen und hält sie für Auswertungen bereit. Bei hohem Schutzbedarf gehören beide zusammen.
Wie oft sollte kube-bench laufen?+
Regelmäßig und automatisch, etwa wöchentlich. Zusätzlich nach jedem Kubernetes-Update. Die Ergebnisse werden abgelegt, damit Abweichungen über die Zeit sichtbar werden.
Wie bleiben Knoten automatisch aktuell, ohne dass TYPO3 ausfällt?+
Updates installieren sich automatisch, Neustarts laufen orchestriert Knoten für Knoten. Mit mehreren Replicas und einem PodDisruptionBudget, wie in Teil 9 beschrieben, bleibt die Website währenddessen erreichbar.
Fazit
Betrieb unter IT-Grundschutz heißt vor allem: Der Cluster erzählt selbst, was in ihm passiert. Zentrale Logs, ein Audit-Log der API, Alarme auf Symptome und regelmäßige Prüfungen machen Maßnahmen sichtbar. Wer dazu Patches automatisiert und Vorfälle nachbereitet, hat im Audit etwas vorzuzeigen.
Der nächste Teil behandelt das schwierigste Schutzziel: Teil 12: Verfügbarkeit bei hohem Schutzbedarf. Zurück zu Teil 10: Datenbank, Backup und Restore.
Ich baue Logging, Alarme und Nachweise für TYPO3 im Cluster so, dass sie im Audit bestehen.
Zentrale Protokollierung, Alarme, die auf echte Probleme reagieren, und regelmäßige Prüfungen als Beleg.
Plattform-Betrieb statt Beratung auf Papier: Auf Wunsch betreibe ich Überwachung und Patch-Management dauerhaft mit und liefere die Nachweise für dein Audit.
Ü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.