Schwachstellen in IT‑Systemen und ‑Prozessen sind häufig das Einfallstor für Cyberangriffe. Doch erst wenn Sicherheit auch in der Laufzeit greift – also dort, wo Anwendungen tatsächlich arbeiten –, entsteht echte Widerstandskraft.

Foto: Ines Thomsen Andreas Kroier, Application Security Solution Lead bei Dynatrace Cyberangriffe treffen Unternehmen auf zwei Ebenen: einerseits dort, wo Menschen arbeiten (Corporate Security: E‑Mail, Passwörter, Geräte), andererseits tief in der Technik (Cloud‑ und Application‑Security: Anwendungen, Frameworks, Konfigurationen). Dieser Artikel fokussiert auf die Laufzeit: Er zeigt, wie Laufzeitsicherheit im Betrieb funktioniert, typische Risiken in Cloud‑ und Anwendungslandschaften sichtbar macht – und wie praxisnahe Schritte sie wirksam etablieren.

Cloud‑ und Application‑Security klar getrennt

Für wirksame Maßnahmen lohnt die Trennung:

• Corporate Security schützt Mitarbeitende, E‑Mail, Endgeräte und Zugänge.
• Cloud‑ und Application‑Security schützt Infrastruktur, Konfigurationen und vor allem Anwendungen – inklusive Bibliotheken und Schnittstellen.

Selbst gut getestete Anwendungen bleiben verwundbar, wenn ihr Schutz in der Laufzeit fehlt. Der Betrieb ist keine „ruhige Zone“, sondern die Phase, in der Risiken konkret werden.

Observability und Sicherheit: zwei Seiten einer Medaille

Echtzeit‑Beobachtbarkeit (Observability) schafft Sicht auf das Verhalten von Systemen: sehen, verstehen, priorisieren. Laufzeitsicherheit baut darauf auf und greift aktiv ein: blockieren, isolieren, härten. Zusammen spannen sie Sicherheit über den gesamten Lebenszyklus:

• „Nach links“: frühe Prüfungen in Entwurf und Entwicklung (Shift‑Left).
• „Nach rechts“: kontinuierlicher Laufzeitschutz und Betriebsresilienz (Shift‑Right).

Diese Ergänzung ist entscheidend: Prävention bleibt wichtig, aber ohne Schutz in der Laufzeit bleibt eine Lücke offen.

Laufzeit‑Agenten: erkennen, einordnen, eingreifen

Laufzeit‑Agenten erfassen Telemetrie wie Antwortzeiten, Fehlerraten, Ressourcennutzung und Benutzerinteraktionen in Echtzeit. Sie analysieren Muster, detektieren Engpässe und Angriffsversuche, stufen die Dringlichkeit ein, blockieren schädliche Anfragen oder schlagen sofort Alarm, wenn etwas gefährlich wird. Gute Systeme liefern nicht nur Alarme, sondern konkrete Anleitungen zur Behebung – für Entwicklung, Betrieb und Sicherheitsteams.

Im Anwendungskontext entspricht dies einer Erkennungs‑ und Reaktionskette (Detection & Response, DR), wie man sie aus Laufzeit‑Selbstschutzverfahren kennt (Runtime Cloud and Application Security), eingebettet in Plattformen für den cloud‑nativen Schutz (Cloud‑Application Detection Response, CADR). Eine integrierte Oberfläche bündelt:

• Exponierungen (z. B. öffentlich erreichbare Dienste, zu weit gefasste Berechtigungen),
• Konfigurationsfehler,
• Compliance‑Verstöße,
• Laufzeit‑Detektionen von auffälligem Verhalten.

Kontext macht den Unterschied: Laufzeit‑Risiko‑Kontext

Nicht jede Schwachstelle ist im Betrieb tatsächlich gefährlich. Relevant wird sie, wenn sie erreichbar ist, sensible Daten berührt oder aktiv ausgenutzt wird. Die Priorisierung nach Laufzeit‑Risiko‑Kontext gewichtet Funde nach: Erreichbarkeit, Ausnutzbarkeit, und Datenerreichbarkeit.

So entsteht eine belastbare Kette: erkennen, einordnen, entscheiden, beheben – mit klaren Zuständigkeiten:

• Entwicklungsteams (DEV) schließen Schwachstellen im Code und pflegen Abhängigkeiten.
• Site Reliability Engineers (SRE) korrigieren Fehlkonfigurationen, straffen Berechtigungen und sichern Betriebsregeln.
• Sicherheitsteams (SecOps) setzen Leitplanken, liefern Nachweise und koordinieren im Ernstfall.

Regulatorik: DORA, NIS 2 und Cyber Resilience Act

Parallel steigt der Druck durch europäische Vorgaben:

• DORA (Digital Operational Resilience Act) verlangt im Finanzsektor (inkl. Unternehmen im weiteren Betätigungsfeld) belastbare Abläufe, Tests und Schutzmechanismen über den gesamten Lebenszyklus – ausdrücklich auch in der Laufzeit.
• NIS 2 fordert für „wesentliche“ und „wichtige“ Einrichtungen technische und organisatorische Maßnahmen sowie zügige Behebung von Schwachstellen – auch im Betrieb.
• Der Cyber Resilience Act verpflichtet Hersteller „digitaler Produkte“ zu Sicherheit über den gesamten Lebenszyklus, inklusive Überwachung und Korrekturen nach Inverkehrbringen.

Mit anderen Worten: Laufzeitsicherheit ist nicht nur klug, sondern wird zur Pflicht.

Fazit: Vom Alarm zur Verbesserung

Schulung und Grundhygiene verhindern vieles. Widerstandskraft entsteht jedoch erst, wenn Sicherheit auch in der Laufzeit greift: Risiken werden dort erkannt, wo sie tatsächlich gefährlich werden – im Betrieb. Wer Laufzeitsicherheit etabliert, Zuständigkeiten zwischen DEV und SRE klärt und nach Laufzeit‑Risiko‑Kontext priorisiert und operationalisiert, senkt technische Risiken, schützt Kundinnen und Kunden und erfüllt zugleich wachsende regulatorische Anforderungen.