Dieser Abschnitt behandelt den laufenden Betrieb und die Wartung der Cloud-Infrastruktur: Patch Management, Infrastructure as Code, Hochverfügbarkeit, Monitoring, Backup und Management Plane.
Härtung von Betriebssystemen (OS)
Wie im vorherigen Abschnitt erläutert, müssen sowohl Bastion Hosts als auch Jumphosts gehärtet werden. Als Härtung (Hardening) bezeichnet man die gezielte Absicherung und Optimierung eines Betriebssystems. Um die Härtung zu standardisieren und für bestimmte Systemtypen immer identisch zu gestalten, werden die Maßnahmen in sogenannten Baselines definiert.
Eine Baseline ist eine standardisierte Reihe sicherheitsrelevanter Einstellungen, die einem Betriebssystem zugewiesen wird. Gleichzeitig ist es auch die minimal erlaubte Konfiguration, die erforderlich ist, damit ein System genutzt werden kann.
Die typische Härtungsmaßnahmen sind:
- Deaktivierung unnötiger Dienste und Ports
- Deinstallation von unnötiger Tools
- Änderung von Standardpasswörtern und Benutzerkonten
- Entfernung/Deaktivierung unnötigen Benutzerkonten (z.B. Gast)
- Installation sicherheitsrelevanter Tools und Agenten
- Konfiguration zentraler Protokollierung und Überwachung
- Aktivieren automatischer Updates oder definierter Patch-Prozesse.
Heutzutage werden die oberen Schritte im Rahmen von Infrastructure as Code (IaC) definiert und automatisiert. Das Ergebnis sind konsistent bereitgestellte VMs aus der sicheren Vorlage.
Eine Baseline ist oft eine Kombination aus verschiedenen Quellen und Standards:
- Provider-Baselines von CSPs
- Drittanbieter-Baselines von Systemintegratoren
- Software-Hersteller-Baselines
- STIGs (Security Technical Implementation Guides), von der US-Behörde DISA
- NIST Checklists oder CIS Benchmarks
Es reicht nicht aus, Baselines zu erstellen und zu implementieren. Die Ergebnisse müssen auch überwacht werden und dafür wird eine Configuration Management Database (CMDB) eingesetzt. Es ist ein Konzept, das durch Tools wie ServiceNow, Ansible oder Puppet umgesetzt wird. Eine CMDB erfasst den Soll- und Ist-Zustand von Systemen und erkennt Abweichungen. Die automatische Remediation (das selbstständige Korrigieren von Abweichungen) ist eine optionale Erweiterung, die durch Automatisierungstools wie z.B. Ansible oder Puppet umgesetzt realisiert werden kann.
Bei großen CSPs übernehmen Cloud-native Tools wie AWS Config, Azure Resource Graph und Google Cloud Asset Inventory automatisch die CMDB-Funktion. Sie sind aber reine Monitoring-Tools und keine Enforcement-Tools. Sie überwachen nur kontinuierlich den Ist-Zustand aller Ressourcen und melden Abweichungen von der definierten Baseline. Die AWS Systems Manager, Azure Policy und Google Cloud Organization Policy können die Konfigurationen des Systems automatisch korrigieren.
Strategie „Infrastruktur als Code“ (IaC)
Das Prinzip von Infrastructure as Code (IaC) ist durch vorherige Erläuterungen bereits bekannt: „Die Infrastruktur wird nicht mehr manuell konfiguriert, sondern in Form von Code beschrieben.“ System- und Netzwerkkonfigurationen sowie Sicherheitsrichtlinien werden in maschinenlesbaren Definitionen festgelegt. Auf dieser Grundlage kann die entsprechende Infrastruktur automatisch erstellt, konfiguriert und verwaltet werden. Dieser Ansatz bildet die Grundlage der Immutable Architecture.
Immutable Architecture ist ein Ansatz, der das klassische Patching und Konfigurieren laufender Systeme grundsätzlich ablehnt. Anstatt ein System zu verändern, wird es bei Bedarf komplett neu aus einem sicheren, vorab geprüften und unveränderlichen Image bereitgestellt. Dadurch werden potenzielle Fehlerquellen und Konfigurationsabweichungen („Configuration Drift“) vermieden, da jede Bereitstellung identisch und reproduzierbar abläuft.
Der Sicherheitsvorteil ist offensichtlich: Kein System kann durch schleichende Konfigurationsänderungen oder ungepatchte Schwachstellen kompromittiert werden. Bei jedem Deployment startet man von einem sauberen Zustand. Die Änderungen werden direkt in Code-Dateien dokumentiert und versioniert. Somit entsteht ein klarer Audit-Trail für Sicherheits- und Compliance-Zwecke.
Es gibt jedoch Fälle, in denen die Immutable Architecture an ihre Grenzen stößt: Stateful-Systeme wie z.B. Datenbankserver oder Legacy-Applikationen lassen sich nicht einfach neu bereitstellen. In der Praxis existieren daher beide Welten nebeneinander. Während die Cloud-Dienste dem Immutable-Prinzip folgen, benötigen Legacy-Systeme weiterhin klassisches Patch-Management.
Patch Management
Das Patch-Management ist Patch-Management ist ein fortlaufender Prozess, der primär dazu dient die Sicherheitslücken zu schließen und/oder Funktionsumfang zu verbessern.
Der folgende Zyklus orientiert sich an NIST SP 800-40 „Guide to Enterprise Patch Management Planning“:
1. Vulnerabilitätsidentifikation – Erkennen von Schwachstellen über Herstellerhinweise, Sicherheitsdatenbanken oder automatisierte Scans.
2. Patch-Veröffentlichung – Hersteller veröffentlichen Updates zur Behebung der erkannten Schwachstellen.
3. Evaluierung und Test – Analyse der Relevanz und Verträglichkeit des Patches mit der bestehenden Umgebung, gefolgt von Tests in einer isolierten Umgebung. Eine Suche im Internet kann ebenfalls sinnvolle Informationen liefern.
4. Bereitstellung (Deployment) – Verteilung und Installation auf allen relevanten Systemen. Idealerweise in Chargen und nicht überall gleich.
5. Überwachung und Dokumentation – Nachverfolgung, ob der Patch erfolgreich angewendet wurde. Bei auftretenden neuen Fehlern oder Inkompatibilitäten ggf. Durchführung eines Rollbacks.
6. Aktualisierung der Baselines – Die neue, gepatchte Konfiguration wird dokumentiert und als aktuelle Systembaseline festgelegt.
Ein Sonderfall sind Zero-Day-Schwachstellen: aktiv ausgenutzte Lücken, für die noch kein Patch existiert oder die eine sofortige Reaktion erfordern. In solchen Situationen wird der reguläre Prozess übersprungen und ein beschleunigtes Notfall-Patching eingeleitet.
Verfügbarkeit von geclusterten Hosts
Der Punktname ist etwas irreführend, geclusterte Hosts existieren genau deshalb, um Verfügbarkeit zu gewährleisten. Ein Cluster ist eine Gruppe von Hosts, die als koordinierte Einheit gemeinsam agieren und durch Cluster-Management-Software gesteuert werden. Diese sorgt für Lastverteilung, Ressourcenoptimierung und steuert im Fehlerfall den automatischen Failover.
Vorteile eines Clusters:
Hohe Verfügbarkeit. Fällt ein Knoten aus, übernehmen die anderen automatisch seine Aufgaben, sodass es für den Nutzer nicht einmal sichtbar ist. Dies ist durch Mechanismen wie vMotion / Live Migration (sind eigentlich klassische VMware vSphere-Konzepte), die laufende VMs unterbrechungsfrei zwischen Hosts verschieben.
Skalierbarkeit. Neue Knoten können hinzugefügt oder entfernt, ohne laufende Prozesse zu unterbrechen. Dafür kann ein Knoten in den „Maintenance Mode“ (Wartungsmodus) versetzt werden. Dabei werden alle laufenden VMs automatisch auf andere Hosts migriert, bevor die Wartungsarbeiten beginnen. Dies ist allerdings nicht pauschal gültig, sondern hängt von der Clusterart sowie der Anzahl der verfügbaren Knoten ab.
Effiziente Ressourcennutzung. Die Workloads können dynamisch auf verfügbare Systeme verteilt werden, um Performance und Energieverbrauch zu optimieren. Die entsprechenden Mechanismen heißen „Distributed Resource Scheduling (DRS)“ und „Dynamic Optimization“.
Cluster Mechanismen
Die folgenden Mechanismen stammen ursprünglich aus der VMware-Welt, gelten aber sinngemäß auch in anderen Umgebungen:
Reservation (Reservierung). Dabei wird eine Mindestmenge an Rechenleistung (z. B. CPU-Kerne, RAM) garantiert. Dadurch ist eine planbare, aber teurere Performance möglich.
Limit (Begrenzung). Durch die Festlegung einer Obergrenze kann der maximale Ressourcenverbrauch geregelt werden.
Share (Anteil). Dabei handelt es sich um eine prioritätsbasierte Verteilung der Ressourcen. Wenn mehrere Systeme gleichzeitig eine hohe Last erzeugen, erhalten VMs mit einer höheren Priorität bevorzugten Zugriff auf die Ressourcen.
Storage Clusters
Storage Clusters fassen mehrere Speichersysteme zu einer gemeinsamen, verwalteten Einheit zusammen, und bieten auch eine automatische Lastverteilung und eine Failover-Funktionalität. In Cloud-Umgebungen sind Storage Clusters die Grundlage für eine hochverfügbare und skalierbare Datenspeicherung.
Verfügbarkeit des Gastbetriebssystems (OS)
Dank des Shared Responsibility Models liegt die Verantwortung für die OS-Pflege bei IaaS vollständig beim Kunden: Patching, Updates und Absicherung des Gastbetriebssystems sind Kundensache. Bei PaaS und SaaS trägt der CSP die volle Verantwortung dafür.
Unabhängig vom Servicemodell sollte der Kunde bei IaaS folgende Aspekte im Blick behalten:
Backup und Wiederherstellung – regelmäßige VM-Snapshots ermöglichen eine schnelle Wiederherstellung im Fehlerfall. Backups sollten verschlüsselt gespeichert werden. Dazu mehr in Abschnitt 3.5.
Datenreplikation und regionale Redundanz – kritische Systeme sollten über mehrere Availability Zones oder Regionen repliziert werden, um Single Points of Failure zu vermeiden.
Monitoring – die Verfügbarkeit des Gastbetriebssystems muss kontinuierlich überwacht werden.
Standalone / Dedicated Hosts
Wenn wir schon über Cluster und Gastbetriebssysteme gesprochen haben, lohnt sich ein kurzer Blick auf Dedicated Hosts, dedizierte, physische Server, die ausschließlich für einen einzelnen Kunden reserviert sind. Das Konzept existiert seit langem bei Web-Hostern, lange bevor Cloud populär wurde (z.B. bei alfahosting). Angebote der führenden CSPs: AWS Dedicated Hosts oder Azure Dedicated Hosts.
Das Hauptargument für Dedicated Hosts ist die vollständige physische Isolierung bei gleichzeitiger voller Kontrolle des Kunden über Sicherheit und Konfiguration. Dies ist insbesondere für Branchen mit strengeren Compliance-Anforderungen relevant, die eine physische Mandantentrennung vorschreiben (z. B. Finanz- oder Gesundheitswesen).
Leistungs- und Kapazitätsüberwachung
Das Thema Monitoring wurde in diesem Buch bereits mehrfach behandelt. Dieser Abschnitt fokussiert sich auf die Überwachung von Hardware-Performance und Kapazität. Grundsätzlich werden die Basis-Überwachungsdienste von CSP bereitgestellt (z. B. AWS CloudWatch, Azure Monitor oder Google Cloud Monitoring). Die Cloud-Kunden können aber die CSP-eigene Überwachung durch spezialisierte Tools erweitern. Die Leistungs- und Kapazitätsversprechen sind in der SLA festgehalten.
Wichtige Metriken
Die folgenden Metriken werden typischerweise durch Schwellenwerte überwacht, bei Überschreitung werden automatisch Alarme ausgelöst:
Netzwerk:
- Bandbreitenauslastung
- Packet Drops
- Latenz und Response Time
Compute:
- CPU-Auslastung pro Kern und Operationen pro Sekunde
- RAM-Auslastung – häufige Ursache für Performance-Probleme
- GPU-Auslastung – besonders relevant für ML/KI-Workloads
Storage:
- Speichernutzung und IOPS-Leistung, je nach Storage-Klasse unterschiedlich (z. B. SSD vs. HDD)
- Datenzugriffslatenz und Übertragungsgeschwindigkeit
Hardware-Überwachung
Die Überwachung der darunterliegenden Hardware-Infrastruktur liegt unabhängig vom Bereitstellungsmodell immer beim CSP. Das primäre Ziel ist, Fehler oder Verschleißerscheinungen so früh wie möglich zu erkennen.
Die Infrastruktur lässt sich in zwei Bereiche aufteilen:
Physische Hardware:
- Server und Mainboards
- HDDs und SSDs – viele Komponenten verfügen über integrierte Diagnosefunktionen wie S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology), die Ausfälle frühzeitig erkennen
- Lüfter und Kühlsysteme
- CPUs und RAM-Module
- Netzwerkgeräte (Switches, Router, Firewalls, SFP-Module)
Physische Umgebung:
- Stromversorgung
- Temperatur
- Luftfeuchtigkeit
Konfiguration der Sicherungs- und Wiederherstellungsfunktionen für Host- und Gastbetriebssysteme (OS)
Die strategischen Aspekte von Backup und Disaster Recovery wurden bereits in Abschnitt 3.5 behandelt. Dieser Punkt fokussiert sich auf die technische Konfiguration.
Grundsätzlich gilt das bekannte „Shared Responsibility Model“. Nur bei IaaS ist der Kunde für die Konfiguration von Backup und Restore verantwortlich, der CSP stellt lediglich die Werkzeuge bereit. Bei PaaS und SaaS übernimmt der CSP diese Aufgabe vollständig.
Technische Aspekte bei der Konfiguration:
Guest OS Backup. Die Backups laufender VMs müssen applikationskonsistent sein. Dabei müssen laufende Prozesse und Datenbankzustände beim Snapshot berücksichtigt werden.
3-2-1-Regel gilt auch in Cloud-Umgebungen. Es müssen drei Kopien auf zwei verschiedenen Medien gespeichert werden, wobei sich eine davon außerhalb des primären Standorts aufbewahrt werden muss.
Aufgrund der Verbreitung von Ransomware-Angriffen halten die Veeam-Experten die 3-2-1-Strategie nicht mehr für ausreichend.
Verschlüsselung – Backups müssen verschlüsselt gespeichert werden, sowohl at Rest als auch bei der Übertragung.
Integritätsprüfungen stellen sicher, dass die gesicherten Daten vollständig und unverändert sind.
Regelmäßige Restore-Tests. Wie immer gilt: Ein Backup ohne getestete Wiederherstellung ist kein Backup.
Management Plane
Das Thema „Management Plane” wurde bereits im Abschnitt 3.1 detailliert behandelt. Ergänzend folgende Unterscheidungen, die im Betrieb relevant sind:
Management Plane als übergeordneter Begriff. „Management Plane“ beschreibt nicht nur die Cloud-Verwaltungsebene. Auch Netzwerkgeräte, Hypervisoren und physische Server verfügen über eine eigene Management Plane (z. B. vCenter für VMware).
Management Plane ≠ Management Console. Oft wird zwischen diesen beiden Begriffen ein Gleichheitszeichen gesetzt, was eigentlich falsch ist. Eine Management Console ist lediglich ein grafisches Frontend (Web-GUI) auf die Management Plane. Wenn die Web-GUI aus irgendeinem Grund nicht erreichbar ist, bleibt die Management Plane über API weiterhin erreichbar.
Isolation der Verwaltungsebene / Out-of-Band Management. Grundsätzlich sollte Management-Traffic vom Produktions-Traffic strikt getrennt werden, z. B. über dedizierte Management-Netzwerke. Der Zugriff auf das Intelligent Platform Management Interface (IPMI), z. B. iDRAC oder iLO, sollte auch bei einem Ausfall des Produktionsnetzwerks weiterhin möglich sein. In Cloud-Umgebungen ist das Out-of-Band-Management für den Kunden nicht zugänglich.