Ein typischer Fall: Eine Testumgebung, angelegt für ein Wochenende, läuft seit vier Monaten. Sie enthält eine Kopie echter Kundendaten, und das Dienstkonto, das ihr zugeordnet ist, hat mehr Rechte, als es je gebraucht hätte. Drei Sicherheitswerkzeuge haben diese Umgebung im Blick – und in keinem der drei Systeme fühlt sich jemand für sie zuständig. Szenen wie diese erklären, warum Unternehmen ihre Cloud-Sicherheit derzeit neu ordnen wollen – eine Entwicklung, für die die Branche einen eigenen Namen gefunden hat: CNAPP, ausgeschrieben Cloud Native Application Protection Platform. Interessanter als das Kürzel ist die Frage, warum es überhaupt nötig wurde – und warum der Wechsel auf eine Plattform allein das Problem nicht löst.
Wie aus richtigen Einzelentscheidungen ein Flickenteppich wird
Kaum ein Unternehmen hat seine Cloud-Sicherheit am Reißbrett entworfen. Sie ist gewachsen, Anschaffung für Anschaffung. Ein Werkzeug prüft Konfigurationen auf Fehler, ein zweites überwacht die laufenden Workloads. Als die Zugriffsrechte unübersichtlich wurden, kam ein drittes hinzu, später eines für die Entwicklungsumgebungen. Jede dieser Entscheidungen löste ein reales Problem, und jede war zu ihrem Zeitpunkt vernünftig.
Verändert hat sich das Umfeld. Viele cloud-native Anwendungen arbeiten mit Containern oder kurzlebigen Workloads, die teils nur Stunden existieren; Infrastruktur entsteht aus Code, wird kopiert, verschoben, wieder gelöscht. Umgebungen ändern sich schneller, als ein Quartalsbericht sie erfassen könnte. Werkzeuge, die für einzelne Ausschnitte gebaut wurden, sehen davon immer nur Momentaufnahmen. Und weil Entwicklung und Betrieb längst ineinandergreifen, entstehen die Lücken genau dort, wo ein Werkzeug endet und das nächste beginnt. Aus solchen Erfahrungen hat sich die Kategorie entwickelt, die unter dem Kürzel CNAPP bekannt ist: der Versuch, den Weg einer Anwendung von der Entwicklung bis in den laufenden Betrieb in einem Zusammenhang zu betrachten statt in vier getrennten Konsolen.
Warum drei Meldungen noch keine Verantwortung schaffen
Zurück zur Testumgebung. Das Konfigurationswerkzeug meldet sie als von außen erreichbar und stuft sie mit mittlerer Priorität ein. Der Schwachstellenscanner findet auf derselben Maschine eine veraltete Softwarebibliothek – ein zweiter Scanner bewertet dieselbe Lücke eine Stufe niedriger. Und das Berechtigungssystem führt das Dienstkonto der Umgebung seit Monaten auf seiner Liste überprivilegierter Konten.
Drei Meldungen, drei Konsolen, drei Adressaten. Die Sicherheitsabteilung sieht alle drei, kann aber keine davon selbst beheben. Das Entwicklungsteam könnte es, arbeitet aber nicht in diesen Konsolen und erfährt von den Befunden bestenfalls über Umwege. Das Betriebsteam richtet sich nach dem, was im Ticketsystem ankommt – und dort kommt nichts an, weil niemand festgelegt hat, wer daraus ein Ticket machen müsste. Die Verantwortung für Cloud-Sicherheit liegt damit überall und nirgends. Befunde verschwinden so nicht; sie zirkulieren – manche seit Jahren.
Wenn Warnungen ohne Kontext die falschen Prioritäten setzen
Für sich genommen ist keine der drei Meldungen ein Notfall. Zusammen beschreiben sie ein einziges, sehr konkretes Risiko: echte Kundendaten, erreichbar über eine vergessene Umgebung, bedient von einem Konto mit mehr Rechten, als je gebraucht wurden. Diese Verbindung stellt keines der beteiligten Systeme her, weil jedes nur seinen Ausschnitt kennt. Stattdessen entsteht eine stetige Flut einzelner Warnungen – und Teams lernen, viele davon zu übergehen.
Das Umfeld, in dem solche Fälle entstehen, ist groß. Aktuelle Zahlen des Digitalverbands Bitkom zur Cloud-Nutzung in deutschen Unternehmen zeigen: 86 Prozent setzen auf Cloud-Dienste, 38 Prozent verteilen sie über mehrere Anbieter, gut ein Drittel kombiniert private und öffentliche Cloud-Umgebungen. Bemerkenswert ist eine andere Zahl aus derselben Erhebung: Drei Viertel der Unternehmen nennen ausgerechnet die Sicherheit als wichtiges Motiv für den Weg in die Cloud. Je mehr Anbieter und Umgebungen zusammenkommen, desto schwerer lassen sich Risiken in Multi-Cloud-Umgebungen jedoch nach einem gemeinsamen Maßstab bewerten – und desto weiter gehen Anspruch und tägliche Meldungsflut auseinander.
Warum Cloud-Sicherheit ohne Nachweise nicht prüfbar ist
Spätestens vor einem Audit wird der Flickenteppich teuer. Nicht zwingend, weil Sicherheit fehlte, sondern weil sich schwer belegen lässt, was tatsächlich geprüft wurde. Nachweise werden dann aus einem halben Dutzend Systemen zusammengetragen, per Export, Screenshot und Erinnerungsvermögen. Dabei geht es bei der Cloud-Sicherheit im Unternehmen längst nicht nur darum, Risiken intern zu erkennen: Es zählt auch, nachvollziehbar zeigen zu können, welche Kontrollen greifen, wer auf welche Daten zugreift und wie Befunde bearbeitet werden – gegenüber Prüfern wie gegenüber Kunden und Geschäftspartnern. Je verteilter die Werkzeuge sind, desto stärker wird diese Nachweisarbeit zum eigenen Projekt, das bei jedem Prüfungstermin von Neuem beginnt. Das Muster kennt man aus Nachbardisziplinen: Auch beim Datenschutz im Unternehmensalltag hängt viel davon ab, ob dokumentierte Routine vorhanden ist – oder ob jede Anfrage neuen Aufwand auslöst.
Was Konsolidierung ändern kann und was nicht
Der Kern der Konsolidierung ist nüchtern: dieselben Informationen an einem Ort, bewertet nach einer Logik, auf die sich Sicherheits-, Entwicklungs- und Betriebsteams geeinigt haben. Aus drei mittleren Einzelwarnungen wird ein Zusammenhang mit klarer Dringlichkeit – im besten Fall mit klarer Verantwortlichkeit. Auch die Nachweisfrage wird einfacher, wenn Prüfern ein System gezeigt werden kann statt sechs, und zwar über den gesamten Lebensweg einer Anwendung hinweg.
Genauso nüchtern fällt aus, was eine Plattform nicht leistet: Auch eine CNAPP räumt keine Zuständigkeiten auf, die vorher niemand geklärt hat – sie macht ungeklärte Verantwortung nur schneller sichtbar. Für Unternehmen mit wenigen Cloud-Diensten ist ein solcher Schritt deshalb nicht automatisch dringend. Anders sieht es aus, wenn mehrere Cloud-Anbieter, Entwicklungsumgebungen, externe Dienstleister und interne Betriebsteams zusammenkommen: Dann ist Konsolidierung keine Komfortfrage mehr, sondern die Voraussetzung dafür, Risiken überhaupt nach demselben Maßstab bewerten zu können. Wer seine Cloud-Security-Tools konsolidieren will, beginnt trotzdem nicht beim Einkauf. Zuerst muss festgelegt werden, welches Team künftig welche Art von Befund verantwortet. Dann braucht es eine gemeinsame Antwort auf die Frage, wonach sich die Reihenfolge der Behebung richtet. Und schließlich braucht es einen realistischen Fahrplan für bestehende Abhängigkeiten. Wie schwer Wechsel in Cloud-Umgebungen fallen können, zeigt dieselbe Erhebung: 59 Prozent der Unternehmen nennen Lock-in-Effekte wie aufwendige Datenexporte und Migration als Hindernis. Wer konsolidiert, sollte dabei die eigene Wahlfreiheit in der Cloud im Blick behalten: Eine Plattform, die alles bündelt, darf nicht zur nächsten Abhängigkeit werden. Etappen entlang auslaufender Verträge sind weniger spektakulär als der große Wurf, dafür funktionieren sie.
In einem solchen Fall würde die eingangs beschriebene Testumgebung am Ende nicht durch ein weiteres Werkzeug verschwinden, sondern durch eine einfache Regel: Jede Umgebung gehört einem Team, und was niemandem gehört, wird abgeschaltet. Eine Plattform kann solche Entscheidungen sichtbar machen und überprüfbar halten. Treffen müssen sie Menschen. In dieser Reihenfolge – erst Verantwortung, dann Technik – liegt der Unterschied zwischen einem weiteren Werkzeug im Schrank und Cloud-Sicherheit, die diesen Namen verdient.
