Laut dem IBM Cost of a Data Breach Report 2024 dauert es im Schnitt 200 Tage, bis ein Datenleck entdeckt wird. Weitere 70 Tage sind nötig, um es einzudämmen. Macht in Summe: ein 270-Tage-Breach-Lifecycle.
Die Frage ist: Was können wir als Tech-Unternehmen, Engineering-Team oder Cybersecurity-Agentur tun, um diese Zeit drastisch zu verkürzen?
Die Antwort beginnt am Anfang der Sicherheitskette: bei den Logs.
Warum schreiben wir überhaupt Logs?
Auf den ersten Blick klingt die Frage trivial. Aber wenn man kurz innehält, steckt viel mehr dahinter.
Für wen schreiben wir eigentlich Logs? Für uns Entwickler? Für das Operations-Team? Für die Security-Analysten?
Die Wahrheit: für alle.
Logs sind die digitalen Brotkrumen, die uns zeigen, was passiert ist, wann es passiert ist und warum.
Sie sind nicht nur Debug-Ausgaben, sondern ein zentrales Werkzeug für Observability, Incident Response und digitale Forensik.
Was macht eine Log-Zeile nützlich?
Ehrlich gesagt:
…ist absolut bedeutungslos.
Warum? Weil Kontext fehlt. Was sollen wir mit dieser Information anfangen?
Genau: nichts.
Der erste Schritt zu besseren Logs: Struktur.
Statt unstrukturierte Textzeilen sollten wir strukturierte Logs verwenden – z. B. im JSON-Format.
Das ist maschinenlesbar, leicht zu parsen und spielt perfekt mit modernen Log-Aggregatoren zusammen.
Ein Beispiel:
{
„message“: „getting list of all users“,
„timestamp“: „2025-04-24T16:36:08.272577379Z“,
„user-length“: 200,
„session-id“: „123“,
„trace-id“: „456“,
„user-id“: „9f222efdfe65cba09c5726666c001f106a7fcd268abd1cea40c5a21b8a670e90“,
„user-name“: „admin“,
„customer“: „example ltd“
}
Jetzt haben wir: Zeitstempel, Session-ID, Trace-ID, Nutzer- und Kundendaten.
Damit ermöglichen wir Korrelation über Systeme hinweg, Root-Cause-Analysen und Security-Monitoring.
Wer braucht die Logs – und wohin damit?
Die Antwort: alle Teams. Deshalb macht es Sinn, gemeinsam Guidelines für Logging zu definieren.
Aber seien wir ehrlich: Volle Kontrolle haben wir nie. Denn wir schreiben nicht nur unsere eigenen Logs – wir nutzen auch NGINX, Traefik, Kubernetes oder das Betriebssystem. Und die loggen auf ihre Weise.
👉 Ich habe dazu einen eigenen Artikel veröffentlicht:
NGINX härten und Logging mit JSON verbessern
Doch egal ob App, Proxy oder Orchestrator – am Ende müssen alle Logs gesammelt und zentral ausgewertet werden.
Open Source statt Black Box: OpenSearch als Lösung
Ich setze auf OpenSearch – eine Open-Source-Plattform, die weit mehr bietet als einfache Log-Aggregation:
Logstash für die Sammlung und Weiterleitung von Logs
SIEM-Features für Anomalieerkennung und Security Analytics
Das bedeutet: Logs sind nicht mehr nur irgendwo in einer Datei vergraben, sondern liefern Observability, Traceability und Proactive Defense über den gesamten Stack.
Hands-on: Logs von Containern nach OpenSearch shippen
Ich habe dafür ein fertiges Starter-Template gebaut:
👉 fivesec-opensearch-siem-starter (GitHub)
Es enthält bereits:
NGINX mit JSON-Logging
Logstash-Integration
Direkte Anbindung an OpenSearch
Und wenn du deine Services in Docker laufen hast, kannst du Logs ganz einfach über den GELF-Logdriver nach Logstash leiten – ohne zusätzliche Agenten in den Containern.
Dein Logstash-Setup lauscht dann auf Port 5000 und schiebt die Daten in OpenSearch.
TL;DR – Logging richtig machen
Logs ≠ Debug-Ausgabe → Sicherheitsgrundlage
Frage dich zuerst: Für wen schreibe ich Logs?
Nutze JSON-Logs: maschinenlesbar, konsistent, durchsuchbar
Kontext zählt: Timestamps, User-IDs, Trace-IDs
Alle Schichten einbeziehen: App, Proxy, Orchestrator, OS
Zentral sammeln: Logstash + OpenSearch
Mehrwert schaffen: Anomalieerkennung, Echtzeit-Security, SIEM
👉 Mit meinem GitHub-Starter gibt es keine Ausreden mehr, Logging als Nebensache zu behandeln.
Logs sind das erste Signal. Machen wir sie sichtbar.
✍️ Geschrieben mit ❤️ von fivesec.de
