Das Hauptthema dieses Abschnitts sind Cloud-Infrastrukturkomponenten.
Physische Umgebung
Die erste Frage, die geklärt werden muss, ist: Wer trägt die Verantwortung für die physische Sicherheit der Cloud-Infrastruktur?
Im Fall eines Public-Cloud-Modells ist die Antwort eindeutig: Die Verantwortung liegt vollständig beim CSP.
Bei der Private Cloud steht die physische Infrastruktur exklusiv einer einzelnen Organisation zur Verfügung, diese ist direkt verantwortlich. Wird die Infrastruktur jedoch vom CSP bereitgestellt, liegt die Verantwortung beim Provider.
Bei der Community Cloud ist die Situation ähnlich wie bei der Private Cloud: Die Verantwortung liegt bei einer der beteiligten Organisationen, sofern diese die Infrastruktur selbst betreiben, oder beim externen Provider, falls sie ausgelagert wird.
Physische Kontrollarten
Die physische Sicherheit ist die erste Verteidigungslinie. Wird sie kompromittiert, können auch logische oder virtuelle Sicherheitsmaßnahmen keinen ausreichenden Schutz mehr gewähren. Zur Absicherung der physischen Infrastruktur können unterschiedliche Kontrollarten eingesetzt werden.
Preventive Controls (präventive Kontrollen) – sollen verhindern, dass ein Sicherheitsvorfall überhaupt eintritt. Dazu zählen physische Zugangsbeschränkungen wie Sicherheitstüren, Zugangsschleusen (Mantraps), Schließsysteme, biometrische Scanner, Zutrittskarten, Sicherheitszäune sowie Wachpersonal.
Deterrent Controls (abschreckende Kontrollen) – sollen potenzielle Angreifer von vornherein abschrecken. Beispiele: gut sichtbare Überwachungssysteme, Sicherheitsbeleuchtung, Warnschilder oder Hinweise auf Videoüberwachung.
Detective Controls (detektive Kontrollen) – dienen der Erkennung von Sicherheitsvorfällen, wenn sie auftreten. Typische Komponenten: Überwachungskameras, Bewegungssensoren, Alarmanlagen.
Compensating Controls (kompensierende Kontrollen) – werden eingesetzt, wenn eine bestimmte Kontrollmaßnahme nicht umgesetzt werden kann. Beispiel: Wenn biometrische Zugangskontrollen nicht möglich sind, wird stattdessen auf verstärktes Wachpersonal gesetzt.
Corrective Controls (korrigierende Kontrollen) – Maßnahmen, um Systeme nach einem Sicherheitsvorfall wieder in den voll funktionsfähigen Normalzustand zu versetzen.
Recovery Controls (wiederherstellende Kontrollen) – befassen sich mit der Wiederherstellung der Verfügbarkeit nach einem Ausfall. Im Unterschied zu Corrective Controls beziehen sie sich nicht auf die primären Systeme, sondern auf redundante Alternativen – z. B. Notstromversorgung (USV), redundante Stromleitungen, alternative Kommunikationswege oder die Wiederbefüllung von Gaslöschanlagen.
Directive Controls (anweisende Kontrollen) – organisatorische Maßnahmen wie Sicherheitsrichtlinien, Verfahren und regelmäßige Schulungen, die das Verhalten von Mitarbeitenden in sicherheitsrelevanten Situationen steuern.
Virtualisierung
Im CCSP-Kontext sprechen wir über die Hypervisor-Virtualisierung. Auch wenn sich dieses Thema seit zwei Jahrzehnten nicht grundsätzlich verändert hat, muss es insbesondere im Hinblick auf die dadurch entstehende Angriffsfläche erörtert werden.
Die Hypervisor-Virtualisierung ist ein Modell, bei dem eine zusätzliche Schicht zwischen Hardware und Betriebssystem eingeführt wird. Dies ermöglicht es, mehrere voneinander unabhängige virtuelle Maschinen (VMs) auf derselben physischen Hardware zu betreiben. Jede VM erhält eine eigene isolierte Umgebung mit eigenen Ressourcen: virtuelle CPU, virtueller RAM, virtueller Speicher und virtuelle Netzwerkschnittstellen.
Hypervisoren lassen sich in zwei Typen unterteilen:
Type 2 (Hosted) – aus Cloud-Sicht weniger relevant. Es handelt sich um eine Hypervisor-Anwendung, die auf einem bestehenden Betriebssystem installiert wird. Bekannte Beispiele: VMware Workstation / Fusion, Oracle VirtualBox, Parallels Desktop.
Type 1 (Bare-Metal) – wird direkt auf der physischen Hardware installiert und übernimmt vollständig die Kontrolle über die Hardware-Ressourcen, die er nahezu vollständig den darauf laufenden VMs bereitstellt. Beispiele: VMware ESXi, XenServer, Microsoft Hyper-V, KVM.
Sicherheit des Hypervisors
Der Hypervisor ist eine kritische Komponente der Cloud-Infrastruktur, da er die logische Trennung zwischen VMs durchsetzt. Bei einem erfolgreichen Angriff kann der Angreifer potenziell Zugriff auf alle darauf laufenden VMs erhalten.
Der bekannteste Angriffstyp ist der VM Escape – ein Angreifer nutzt innerhalb einer VM eine Schwachstelle, um auf den Hypervisor oder andere Gastsysteme zuzugreifen.
Weitere relevante Angriffsszenarien:
Hyperjacking – der Hypervisor wird durch Schadsoftware infiziert oder durch einen gefälschten Hypervisor ersetzt.
Side-Channel-Angriffe – Nutzung von Hardware- oder Timing-Informationen, um Daten zwischen VMs auszulesen. Die bekanntesten Beispiele sind Spectre und Meltdown (2018).
Denial-of-Service-Angriffe – Überlastung der Hypervisor-Ressourcen durch fehlerhafte oder absichtlich bösartige VMs.
Zur Erinnerung: In Cloud-Umgebungen liegt die Verantwortung für Sicherheit und Wartung des Hypervisors ausschließlich beim CSP. Mögliche Maßnahmen sind: regelmäßige Aktualisierung und Versionskontrolle, Segmentierung und Isolation von Verwaltungs-, Kunden- und Datenverkehr sowie Minimierung der Angriffsfläche durch Deaktivierung unnötiger Funktionen.
Netzwerk und Kommunikation
In diesem Abschnitt geht es weniger um die Technik selbst, sondern mehr um die sicherheitsrelevante Verantwortungsverteilung zwischen CSP und Cloud-Kunden.
Der CSP ist für die physische Netzwerkinfrastruktur verantwortlich – Router, Switches, Firewalls, physische Verkabelung und Netzwerksegmentierung innerhalb seines Cloud-Netzwerks.
Die Verantwortung des Cloud-Kunden beginnt dort, wo die des CSP endet. Diese logische Grenze nennt man Network Boundary. Sie ist keine physische Trennlinie, sondern eine logische Grenze:
Der CSP verantwortet alles unterhalb dieser Grenze: physische Hardware, Hypervisor, Netzwerkinfrastruktur.
Der Kunde hingegen verantwortet alles oberhalb: virtuelle Netzwerke (VPCs), Firewall-Regeln, Zugriffskontrollen, Verschlüsselung des Datenverkehrs.
Sobald Daten die vom Kunden konfigurierte Umgebung verlassen und ins Internet übertragen werden, liegt die Verantwortung für den Schutz der Kommunikation ausschließlich beim Kunden. Der CSP ist lediglich für die Absicherung seiner eigenen Netzwerkinfrastruktur zuständig.
Die Sicherheitsmechanismen zur Absicherung der Datenübertragung können beispielsweise folgende sein:
- Verschlüsselung der Webkommunikation durch TLS-Zertifikate (HTTPS)
- Einsatz von VPN (Virtual Private Network), um verschlüsselte Tunnelverbindungen zwischen dem Kundennetzwerk und der Cloud-Umgebung einzurichten
- Konfiguration von Firewalls, um Verbindungen auf definierte Ports, Protokolle und IP-Bereiche zu beschränken
- Zusätzliche Ende-zu-Ende-Verschlüsselung der Daten auf Anwendungsebene
Auch im Bereich der Netzwerkkommunikation gilt: Wer etwas konfigurieren kann, ist auch für dessen Sicherheit verantwortlich.
Virtuelle Netzwerke / Software-definierte Netzwerke (SDN)
Software-definierte Netzwerke (SDNs) sind virtuelle Netzwerke, die innerhalb einer Virtualisierungsumgebung den Datenverkehr zwischen VMs und Cloud-Ressourcen steuern. Die Verantwortung dafür liegt im IaaS-Modell beim Kunden, in anderen Servicemodellen (PaaS, SaaS) beim CSP.
Ein klassisches Angriffsszenario in diesem Bereich ist das sogenannte VLAN-Hopping. Dabei überwindet ein Angreifer die logische Trennung zwischen VLANs, um auf Netzwerksegmente zuzugreifen, für die er keine Berechtigung hat. Dies wird häufig durch Fehlkonfigurationen bei der VLAN-Implementierung ermöglicht, beispielsweise durch falsch konfigurierte Trunk-Ports oder fehlende Port-Isolation.
Storage
Auch in diesem Abschnitt geht es mehr um die Abgrenzung der Verantwortlichkeiten zwischen CSP und Kunde in Bezug auf Datensicherheit als um die Technik selbst.
Analog zur Netzwerkkommunikation ist der CSP für die physische Sicherheit und Integrität der Speicherinfrastruktur verantwortlich, während der Kunde die Verantwortung für die logische Sicherheit trägt.
Verantwortungsbereich des CSP:
- Wartung und Überwachung der physischen Storage-Appliances und SANs
- Regelmäßige Sicherheits- und Firmware-Updates
- Sicherstellung der Verfügbarkeit und Integrität der Dateninfrastruktur durch redundante Systeme
Verantwortungsbereich des Cloud-Kunden:
- Datenklassifizierung
- Festlegen, welche Daten aus Datenschutzgründen gespeichert werden dürfen
- Konfiguration des Zugriffs auf Speicherressourcen (Identitäts- und Berechtigungsmanagement)
- Verschlüsselung der Daten im Ruhezustand (Data at Rest) und während der Übertragung (Data in Transit)
- Verwaltung kryptografischer Schlüssel, insbesondere bei Customer-Managed Encryption Keys (CMEK)
- Überwachung und Protokollierung von Zugriffen auf gespeicherte Daten
Herausforderungen beim Cloud Storage
Diese Punkte wurden bereits angesprochen, sind aber in diesem Kontext wiederholungswürdig. Cloud-Storage ist zwar flexibel und skalierbar, bringt dadurch aber spezifische Risiken mit sich, die sich aus mangelnder physischer Kontrolle und Multi-Tenancy ergeben:
Datenreste (Data Remnants) – Fragmente alter Daten, die auf wiederverwendeten Speicherblöcken verbleiben und von anderen Kunden theoretisch wiederhergestellt werden können.
Unsichere Datenlöschung – es gibt keine Garantie, dass Daten vollständig und unwiderruflich gelöscht wurden, insbesondere in verteilten Speichersystemen. Aus Compliance-Sicht ist dieser Punkt besonders kritisch.
Für beide Risiken gibt es eine effiziente Gegenmaßnahme: die kryptografische Löschung (Crypto-Shredding). Dabei werden nicht die Daten selbst gelöscht, sondern die kryptografischen Schlüssel vernichtet – womit die Daten dauerhaft unlesbar werden.
Zugriffskontrolle und Verschlüsselung
Zugriffsbeschränkungen auf Storage-Komponenten können folgende Maßnahmen umfassen:
- RBAC (Role-Based Access Control) oder ABAC (Attribute-Based Access Control)
- Mehrfaktor-Authentifizierung (MFA) für administrative Zugriffe
- Prinzip der geringsten Rechte (Least Privilege)
- Monitoring und Protokollierung sämtlicher Zugriffe
Verschlüsselung sollte in zwei Bereichen erfolgen:
- Data at Rest – Verschlüsselung gespeicherter Daten mit sicheren Algorithmen (z. B. AES-256)
- Data in Transit – Absicherung des Datenverkehrs durch TLS/SSL oder VPN (z. B. IPSec)
Auch die Schlüsselverwaltung (Key Management) selbst sollte sorgfältig geplant sein:
- Verwendung von Hardware Security Modules (HSMs) oder Key Management Services (KMS)
- Definierte Prozesse für Schlüsselrotation, Aufbewahrung und Vernichtung
Darüber hinaus sollten Organisationen klar definieren:
- wo und wie Daten gespeichert werden,
- wann Daten archiviert, migriert oder gelöscht werden,
- wer Zugriff auf Speicherressourcen hat,
- welche Systeme Speicherlösungen bereitstellen oder darauf zugreifen.
Durch regelmäßige Audits und Überwachungsmechanismen wird sichergestellt, dass Speicherumgebungen den internen Richtlinien und externen Vorschriften entsprechen.
Management Plane
Die Management Plane bildet die zentrale Verwaltungsebene und ist das Herzstück der Cloud-Infrastruktur. Über sie werden die Schnittstellen, Tools und APIs bereitgestellt, mit denen Administratoren Cloud-Ressourcen bereitstellen, konfigurieren und verwalten können.
Aus Sicherheitssicht ist die Management Plane der Schlüssel zu allem. Alle Verwaltungsoperationen auf Infrastrukturebene – sei es die Erstellung und Löschung virtueller Maschinen, die Konfiguration von Netzwerken oder die Verwaltung von Identitäten, Richtlinien und Storage-Ressourcen – werden über die Management Plane durchgeführt, entweder direkt über die grafische Konsole oder über API-Schnittstellen.
Genau deswegen ist sie ein bevorzugtes Angriffsziel und gilt als High-Value Target. Ein kompromittierter Zugang zur Management-Plane kann im schlimmsten Fall zur vollständigen Kontrolle über die gesamte Cloud-Infrastruktur des Kunden führen.
Schutz der Management Plane
Eine perfekte Sicherungsmethode gibt es nicht – aber mehrere Maßnahmen, die die Sicherheit erhöhen können.
Role-Based Access Control (RBAC) – Benutzern oder Systemen werden Rollen zugewiesen, die vorab festlegen:
- welche Aktionen sie ausführen dürfen,
- auf welche Ressourcen sie zugreifen dürfen.
Attribute-Based Access Control (ABAC) – ergänzt RBAC um kontextabhängige Bedingungen. Der Zugriff wird anhand von Attributen gesteuert, die sich auf den Benutzer, die Ressource, das Gerät, den Standort oder den Zeitpunkt beziehen, einzeln oder in Kombination.
Beide Modelle lassen sich kombinieren: RBAC legt die Grundrechte fest – ABAC übernimmt das Fine-Tuning durch kontextabhängige Bedingungen.
Strenge Passwortrichtlinien in Kombination mit Mehrfaktor-Authentifizierung (MFA) erhöhen die Sicherheit zusätzlich.
Zero Trust Network Architecture (ZTNA) ist ein Architekturprinzip – kein spezifisches Produkt. Es kann durch native Cloud-Dienste oder Drittanbieter-Lösungen (z. B. Cloudflare Access, Zscaler) umgesetzt werden. Das Zero-Trust-Prinzip gilt insbesondere für automatisierte und maschinelle Prozesse wie APIs, Skripte oder CI/CD-Systeme: keinem System oder Benutzer wird automatisch vertraut. Die Netzwerkzugriffe werden segmentiert, überwacht und regelmäßig neu bewertet.
Least Privilege und Segregation of Duties
Least Privilege – jeder Benutzer, jedes System und jede Anwendung erhalten nur die Rechte, die absolut notwendig sind.
Segregation of Duties (SoD) – Trennung von Verantwortlichkeiten, insbesondere bei kritischen administrativen Aufgaben, um Missbrauch und Fehler zu vermeiden.
SoD bedeutet auch Dual Control / Two-Person Integrity (TPI): eine kritische Aktion erfordert die gleichzeitige Beteiligung von zwei autorisierten Personen. Genau wie beim Raketenstart – beide müssen gleichzeitig den Schlüssel drehen.
Als Best Practice gilt:
Root-Konto – das initiale Administratorkonto sollte niemals für den täglichen Betrieb verwendet werden. Nach der Einrichtung sollten weitere administrative Benutzerrollen erstellt und das Root-Konto anschließend deaktiviert bzw. nur für Notfälle reserviert werden.
Umgebungstrennung – separate Cloud-Accounts für Produktion (Prod), Entwicklung (Dev) und Test (QA/Staging) sind Pflicht.
Lückenlose Protokollierung – alle Aktionen, die in der Management Plane durchgeführt werden, müssen vollständig und nachvollziehbar protokolliert werden.
Alle obigen Maßnahmen zusammen sorgen für eine mehrschichtige Absicherung (Defense in Depth). Wenn eine Schutzschicht versagt, greifen weitere Maßnahmen, um das Risiko zu begrenzen (auch bekannt als Blast Radius Reduction).