Die unbequeme Wahrheit über Cloud-Sicherheit: Warum ein C5-Audit allein dich nicht rettet

Ein ganz normaler Dienstag, kurz nach acht: Über öffentliche Repositories und eine kompromittierte Abhängigkeit einer beliebten Library schleust ein staatlich gestützter Akteur Schadcode in die Softwareentwicklungsstrecke und damit in die SaaS-Lösung eines Cloudbetreibers ein. Was als Routine-Update begann, entwickelt sich schnell zum Worst Case. Und plötzlich sind da nur noch drei Fragen: Welche Systeme sind betroffen? Wo genau kam der Angriff her und an welchen Stellen ist tatsächlich Schadcode vorhanden?

Jetzt schlägt die Stunde von C5, dem Cloud Computing Compliance Criteria Catalogue des BSI.Dieser bietet den Rahmen, um in einem solchen Ernstfall schnell und zielgerichtet handeln zu können. Zentral für der Erfolg ist aber, dass die Mechanismen auch etabliert sind.

Werden die Prozesse und Maßnahmen in der C5-testierten Organisation gelebt oder beginnt das große Rätselraten? Kann die Beweissicherung direkt beginnen oder müssen Informationen mühsam rekonstruiert werden? Kann durch signierte Commits und identifiziert werden, welche Artefakte und Änderungen echt sind und welche nicht? Oder muss alles händisch durchgescannt werden? Greift das Lieferanten- und Abhängigkeitsmanagement und kann die Kette vom öffentlichen Repository bis zum produktiven Deployment zurückverfolgt werden? Oder braucht es Tage oder sogar Wochen bis der Root Cause identifiziert wird?

Denn an dem, was nach dem Incident folgt, machen Kunden Vertrauen fest: Über etablierte Meldewege informiert der Anbieter zeitnah, klärt den Sachverhalt transparent und liefert handlungsrelevante Informationen: betroffene Services und Regionen, betroffene Versionen/Build-IDs, Zeitlinie. Dann kommen die Sofortmaßnahmen: Token rotieren, Artefakte sperren und handfeste Arbeit, das Suchen nach verdächtigen Prozessen oder Command-Lines. Wenn Strafverfolgung ein Thema ist, gehen IOCs und Timestamps zusätzlich an die zuständigen Stellen.

Der C5-Katalog beschreibt Mindestanforderungen an die Informationssicherheit von Cloud. Entscheidend für den Ernstfall ist es, den C5‑Prüfbericht initial anzufordern und auszuwerten. Und vor allem: Diesen Prozess dann regelmäßig (typisch jährlich) zu wiederholen. C5 ist damit kein „Gütesiegel zum An-die-Wand-Hängen“. Sein Nutzen hängt davon ab, ob der Bericht wirklich gelesen, verstanden und in das eigene Risikomanagement übersetzt wird.

]init[ begleitet Anbieter bei der Einführung von C5 und dem kontinuierlichen Management des Maßnahmenkatalogs. Zwei Faktoren für die erfolgreiche Implementierung sind dabei nach unserer Erfahrung zentral: Authentizität und Lieferkettensteuerung als Teil des Betriebssystems – damit kritische Informationen im Ernstfall auf Knopfdruck lieferbar sind. Auch wenn „Angriffe“ sich nicht wegzaubern lassen, kann C5 wesentlich dazu beitragen, schnell wieder in den Normalbetrieb zu kommen.

Wie C5 wirkt: Authentizität als Schlüssel

Vertraulichkeit, Integrität und Verfügbarkeit von Informationen zu wahren: darauf zielt ein Informationssicherheits-Managementsystem nach ISO/IEC 27001. Auch im IT‑Grundschutz wird die Schutzbedarfsfeststellung klassisch entlang dieser drei Grundwerte dokumentiert. C5 macht im Cloud-Kontext darüber hinaus Authentizität explizit zum Kriterium. Das wirkt auf den ersten Blick wie ein Detail, wird aber dann relevant, wenn Cloud-Betrieb nicht nur „irgendwie sicher“, sondern auch belastbar zurechenbar sein muss. Wer im Incident nicht belegen kann, welcher Code und welche Konfiguration zu einem Zeitpunkt produktiv waren, verliert Zeit und damit die Kontrolle.

Souveränität im Alltag heißt: Änderungen müssen belegbar sein

Im Betrieb geht es um Nachweise unter Druck: Welche Version lief um 08:17 Uhr? Wer hat sie freigegeben? Welche Pipeline hat sie gebaut? Welche Parameter waren gesetzt? Diese Informationen müssen die Logs verlässlich liefern.

Für IT‑Leitung und CISO heißt das: Zustände und Änderungen sind nicht „aus dem Kopf erklärbar“, sondern aus Artefakten ableitbar, z. B. über Tags, Image-Digests, freigegebene Change-Tickets mit Referenz auf Build-ID, Deployment-Events in unveränderbaren Audit-Logs und Konfigurationshistorien mit Zeitstempel und Verantwortlichem.

Für den Einkauf bedeutet es im Umkehrschluss, dass solche Eigenschaften vertraglich und organisatorisch abgesichert werden müssen. Inklusive Kontrollrechten, Reporting und einem klaren Blick auf ausgelagerte Anteile.

Drei Nachweisfragen, die alles entscheiden

Im Incident interessieren keine Definitionen. Es zählen drei Beweisfragen:

1. Manipulation: Woran lässt sich belegen, dass Daten nicht still verändert wurden?
   Zum Beispiel über append-only/WORM-Logging, Hash-Ketten für Audit-Events, signierte Exporte kritischer Log-Slices, klar definierte Log-Quellen plus Aufbewahrung, die nicht am Admin-Account hängt.
2. Welche Version lief wirklich? Wie lässt sich nachweisen, welches Artefakt zu einem Zeitpunkt produktiv war und wie es dorthin kam?
   Konkret: Image-Digest statt „Version x.y“, verknüpft mit Commit-Hash, CI-Run-ID, Release-Tag, Signatur und einem Deployment-Eintrag im Audit-Log.
3. Konfiguration: Wie werden Konfigurationsänderungen so geführt, dass man sie in Minuten eingrenzen kann nicht in Workshops rekonstruieren muss?
   Etwa über GitOps-Historie, Change-Ticket-ID, Drift-Detection, und eine eindeutige Zuordnung von „gewollt“ vs. „ist-Zustand“.

Je weiter Delivery und Betrieb automatisiert sind, desto weniger hilft „das weiß bestimmt noch jemand“. Was trägt, ist eine durchgehende Beweiskette von Quelle bis Produktion.

Warum das kein akademisches Thema ist

Im C5:2025 Community Draft nennt das BSI unter den thematischen Schwerpunkten unter anderem Supply‑Chain‑Management sowie eine ausführlichere Betrachtung der „technischen Umsetzung von Souveränität“. Dass das kein akademisches Thema ist, zeigen Vorfälle im Ökosystem: 2025 wurde eine großflächige Supply‑Chain‑Kompromittierung im npm‑Ökosystem öffentlich gemacht, bekannt unter dem Namen „Shai‑Hulud“. Analysen zu einer erneuten Welle („Shai‑Hulud 2.0“) beschreiben trojanisierte Pakete und den Abfluss von Secrets aus Entwickler- und CI/CD‑Umgebungen. Für Entscheider ist die Konsequenz unromantisch: Lieferkette ist nicht nur „ein Thema der Entwicklung“, sondern ein Thema von Beschaffung, Steuerung und Krisenfähigkeit.

C5-Einstiegs-Check: Wie ist mein Betrieb aufgestellt?

Wie belastbar ist die eigene Nachweisfähigkeit im Cloud-Betrieb? Wer das prüfen möchte, kann mit ]init[ einen kostenfreien Einstiegs-Check ansetzen. Im Fokus steht, ob im Audit- oder Incident-Fall die relevanten Nachweise schnell und durchgängig verfügbar sind: von Änderungen in Code und Konfiguration bis hin zum laufenden System. Das Ergebnis dieses Checks ist eine kompakte Prioritätenliste für die nächsten 90 Tage. Alle Informationen zur Anmeldung finden sich hier.

Autor:
Alexander Schultz, Director Information Security Office bei der ]init[ AG

Dieser Beitrag ist bereits älter als 90 Tage. Hier finden Sie die Übersicht neuer Sponsored Articles

.

kommentar field