Grundlagen der Cloud-Security

Cloud-Anbieter und Kunde teilen sich die Sicherheitsverantwortung – wie genau, hängt vom Servicemodell ab. Bei IaaS verantwortet der Kunde Betriebssystem, Netzwerkkontrollen und Anwendungen; bei PaaS übernimmt der Anbieter das Betriebssystem, während Anwendungs- und Netzwerkkonfiguration geteilt bleiben; bei SaaS liegt fast der gesamte Stack beim Anbieter. Unabhängig vom Modell bleiben nach Microsofts Verantwortungsmatrix jedoch vier Bereiche immer beim Kunden: Daten, Endgeräte, Konten und Zugriffsverwaltung – ebenso Konfigurationen und Einstellungen. Das häufigste Missverständnis lautet „der Anbieter kümmert sich um die Sicherheit“: Gerade bei SaaS werden Zugriffs- und Konfigurationsverantwortung regelmäßig unterschätzt, und geteilte Zuständigkeiten bleiben ohne explizite Zuordnung faktisch unbesetzt.

In der Cloud sind Verwaltungsebene und APIs über das Internet erreichbar – wer gültige Zugangsdaten besitzt, steht nicht vor der Firewall, sondern mitten in der Umgebung. Entsprechend führt die Cloud Security Alliance Identity and Access Management auf Platz 2 ihrer Top Threats 2024. Wirksame Gegenmaßnahmen sind durchgängige, möglichst Phishing-resistente Multi-Faktor-Authentifizierung, Least-Privilege-Rollen statt dauerhafter Administratorrechte, getrennte und besonders überwachte privilegierte Konten sowie kurzlebige Anmeldeinformationen. Nicht-menschliche Identitäten – Service-Accounts, API-Schlüssel, Workload-Identitäten – gehören in dieselbe Governance, denn sie werden bei Berechtigungsprüfungen häufig übersehen und selten rezertifiziert.

„Misconfiguration and Inadequate Change Control“ steht auf Platz 1 der CSA Top Threats to Cloud Computing 2024. Typische Muster sind öffentlich erreichbare Storage-Buckets, zu weit gefasste IAM-Rollen, offene Verwaltungszugänge, deaktivierte Protokollierung sowie vergessene Test- und Schattenressourcen. Die Ursache ist selten fehlendes Wissen, sondern Geschwindigkeit: Self-Service und Infrastructure as Code erzeugen täglich Änderungen, die ohne Leitplanken niemand konsistent prüft. Abhilfe schaffen als Code definierte Richtlinien (Policy as Code), Cloud Security Posture Management (CSPM) zur kontinuierlichen Erkennung von Abweichungen und ein Änderungsprozess, der ausdrücklich auch für Cloud-Ressourcen gilt.

Die Cloud Security Alliance befragt für ihre Reihe „Top Threats to Cloud Computing“ regelmäßig Fachleute; für die Ausgabe 2024 (veröffentlicht im August 2024) priorisierten über 500 Expertinnen und Experten elf Bedrohungen. Die ersten drei Plätze belegen Fehlkonfiguration und unzureichende Änderungskontrolle, Identity and Access Management sowie unsichere Schnittstellen und APIs – durchweg Themen im Verantwortungsbereich des Kunden. Der ergänzende Bericht „Top Threats to Cloud Computing - Deep Dive 2025“ (April 2025) analysiert acht reale Sicherheitsvorfälle entlang dieses Bedrohungsrasters und leitet daraus Kontrollempfehlungen ab; im Zentrum stehen menschliche Fehler, Identitäts- und Konfigurationsschwächen sowie Risiken aus der Lieferkette.

Eine Landing Zone ist eine vorstrukturierte Cloud-Umgebung, in der Governance, Netzwerk, Identität und Protokollierung verankert sind, bevor die erste Workload einzieht. Microsofts Cloud Adoption Framework unterscheidet dafür eine zentrale Plattform-Landing-Zone und je Workload eigene Anwendungs-Landing-Zones, die Sicherheitsrichtlinien über die Management-Group-Hierarchie automatisch erben. Als Konfigurations-Baseline haben sich die konsensbasierten CIS Benchmarks etabliert – über 100 Benchmarks für mehr als 25 Produktfamilien, darunter AWS, Azure, Google Cloud und Oracle Cloud. Für die Anbieterbewertung im deutschen Markt ist zudem der BSI-Kriterienkatalog C5 relevant, der 2025/26 grundlegend überarbeitet wurde (C5:2026). In Multi-Cloud-Umgebungen entscheidet weniger das einzelne Werkzeug als die Konsistenz: einheitliche Policies, zentrale Identitäts-Governance und zusammengeführte Protokollierung über alle Plattformen hinweg.

Der Einstieg beginnt mit Transparenz: Welche Cloud-Konten, Dienste und Daten existieren – einschließlich der Umgebungen, die nie ein Architektur-Review durchlaufen haben? Darauf folgen die Klärung der Verantwortlichkeiten je Servicemodell und die Absicherung der beiden größten Hebel: Identitäten (MFA, privilegierte Zugriffe) und zentrale Protokollierung. Anschließend wird eine Baseline wie die CIS Benchmarks verbindlich gemacht und ihre Einhaltung mit CSPM-Werkzeugen kontinuierlich gemessen, statt sie nur punktuell zu auditieren. Cloud-Security ist dabei ein Programm mit Regelbetrieb – mit definierten Rollen, Kennzahlen und Änderungsprozessen – und kein einmaliges Härtungsprojekt.