Cloud-Services sind längst fester Bestandteil der IT-Landschaft. Unternehmen jeder Größe nutzen sie, um flexibel Anwendungen zu betreiben, Daten zu speichern oder Entwicklungsprozesse zu beschleunigen. Doch mit den Vorteilen kommen auch neue Risiken. Wer seine Daten und Anwendungen in die Cloud bringt, verlässt sich auf eine geteilte Infrastruktur, die von fremden Akteuren betrieben wird. Eine zentrale Frage lautet: Wie lassen sich sicherheitsrelevante Cloud-Anwendungen schützen und deren Sicherheit grundlegend bewerten?
Erfordert das Einsatzgebiet eine Zertifizierung der Cloud-Anwendung erfolgt deren Sicherheitsbewertung noch unabhängig von den Gegebenheiten beim Cloud Service Provider. Branchenspezifischen Cloud-Audits bieten dafür orientierung, aber wie aussagekräftig können diese in einem Zertifzierungsverfahren unterstützen? Besonders in dynamischen Umgebungen, in denen Software permanent weiterentwickelt und sofort in den Betrieb geschoben wird (CI/CD), entstehen Sicherheitslücken, die klassische Zertifizierungen nicht vollständig abbilden können.
Shared Responsibility – geteilte Verantwortung in der Cloud
Ein zentrales Konzept beim sicheren Einsatz von Cloud-Anwendungen ist das Shared-Responsibility-Modell.
- Cloud Service Provider (CSP) kümmern sich um den Betrieb der Infrastruktur: Server, Speicher, Netzwerk und Virtualisierung.
- Kunden sind für ihre eigenen Anwendungen, Daten und die richtige Konfiguration verantwortlich.
Das Zusammenspiel ist entscheidend: Während der Anbieter sicherstellen muss, dass die Plattform stabil und vertrauenswürdig funktioniert, liegt es am Kunden, die eigene Software abzusichern. Ein Beispiel dafür ist die Isolation von Containern. Werden mehrere Anwendungen parallel auf derselben Plattform betrieben, muss verhindert werden, dass sie sich gegenseitig beeinflussen oder Daten unkontrolliert austauschen.
Die Grenzen klassischer Zertifizierungen
Die Common Criteria sind seit vielen Jahren ein anerkannter Standard für die Bewertung von IT-Sicherheitsprodukten. Sie ermöglichen eine strukturierte Prüfung von Produkten, doch für Cloud-Umgebungen stoßen sie an Grenzen.
Ein Problem ist die Zeitachse:
- Zertifizierungen bestätigen den Sicherheitsstatus zum Zeitpunkt der Prüfung.
- Cloud-Umgebungen entwickeln sich jedoch ständig weiter. Neue Funktionen, Updates oder Konfigurationsänderungen können die Sicherheit jederzeit verändern.
Ähnlich verhält es sich mit Cloud-spezifischen Audits wie FedRAMP in den USA oder dem BSI C5 in Deutschland. Sie prüfen, ob ein Anbieter bestimmte Mindestanforderungen einhält. Doch auch hier gilt: Die Berichte spiegeln die Vergangenheit wider. Bis ein Audit abgeschlossen ist, können neue Risiken längst entstanden sein. Dieses zeitliche Auseinanderfallen bezeichnet man als Assurance Gap – eine Lücke zwischen dokumentierter und tatsächlicher Sicherheit.
Typische Risiken in der Cloud
Die Praxis zeigt, dass viele Sicherheitsprobleme weniger auf fehlende Standards zurückzuführen sind, sondern auf alltägliche Fehlkonfigurationen und mangelnde Transparenz. Einige Beispiele:
- Fehlerhafte Einstellungen in Containern oder Orchestrierungs-Tools (OWASP CNAS-1) können ungewollt Zugriff von außen ermöglichen.
- Missbrauch von Kubernetes-Zugangsdaten (OWASP K06) erlaubt Angreifern, zentrale Steuerungsfunktionen zu übernehmen.
- Bekannte Schwachstellen wie das 2025 aufgetretene IngressNightmare (CVE-2025-1974) zeigen, dass auch wichtige Komponenten der Cloud selbst Ziel von Angriffen sind.
- Software-Supply-Chain-Risiken: Moderne Anwendungen setzen auf unzählige Bibliotheken und Drittanbieter-Komponenten. Ohne einen vollständigen Software Bill of Materials (SBOM) ist kaum nachvollziehbar, welche Abhängigkeiten im System stecken und welche Schwachstellen damit möglicherweise eingeschleppt werden.
Diese Beispiele verdeutlichen: Cloud-Sicherheit ist nicht nur eine Frage der Technik, sondern auch der Prozesse und Transparenz.
Wege zur Schließung von Sicherheitslücken
Wie können Unternehmen diese Lücken schließen? Eine einfache Lösung gibt es nicht, wohl aber mehrschichtige Ansätze:
- Kombination aus Zertifizierung und Audit
Zertifikate wie die Common Criteria schaffen eine solide Basis. Ergänzend sollten Unternehmen aber auch auf kontinuierliche Audits setzen, die den laufenden Betrieb regelmäßig überprüfen.
- DevSecOps etablieren
Sicherheit darf nicht erst am Ende geprüft werden. In heutigen Entwicklungszyklen sollten nicht nur neue Features getestet, sondern auch Schwachstellen aktiv gesucht werden – von einfachen automatisierten Checks bis hin zu Penetrationstests und laufender Überwachung.
- Klare Verträge mit Cloud-Anbietern
Unternehmen sollten in Serviceverträgen festlegen, welche Sicherheitsanforderungen der Cloud-Anbieter garantieren muss. So können zusätzliche Anforderungen aus einem Common Criteria Zertifzierungsverfahren in die Vereinbarungen aufgenommen werden.
- Geteilte Verantwortung klar definieren
Damit geteilte Zuständigkeit gelebt wird, ist diese auch in jährlichen Audits zu belegen. Dies schafft das Vertrauen, dass der Betrieb eines zertifizierten IT-Sicherheitsprodukts auch in sicherer Weise durchgeführt wird.
Fazit: Sicherheit als kontinuierlicher Prozess
Cloud-Sicherheit ist kein einmaliges Projekt, das mit einer Zertifizierung erledigt ist. Stattdessen erfordert sie ständige Aufmerksamkeit und Anpassung. Standards und Audits sind wichtige Bausteine: Sie geben Orientierung, aber sie garantieren nicht, dass Angriffe auf das tägliche Cloud-Geschäft wirksam abgewehrt werden.
Unternehmen sollten sich bewusst machen, dass Sicherheit in der Cloud auf gemeinsamer Verantwortung basiert. Der Anbieter stellt die Infrastruktur bereit, der Kunde muss seine Anwendungen und Konfigurationen absichern. Vertrauen in die Cloud entsteht nur, wenn beide Seiten liefern – und das nicht einmalig, sondern indem fortlaufend überprüft und offengelegt wird.
