Wenn eine Webanwendung eine leere Seite anzeigt oder ein Server eine Verbindung verweigert, ist das Erste, was ein Administrator tut, eine Datei zu öffnen. Diese Datei ist ein Log. Sie enthält den zeitgestempelten Verlauf jedes Ereignisses, das im System aufgetreten ist: eine empfangene Anfrage, ein ausgelöstes Fehler, ein authentifizierter Benutzer. Die Logs in der Informatik zu verstehen, bedeutet, einen roten Faden zu haben, um die Ursache eines Problems zurückzuverfolgen, zu überprüfen, ob ein Dienst funktioniert, oder ein anormales Verhalten zu erkennen.
Was ein Log wirklich enthält und warum das Format alles ändert
Ein Log ist eine Ereignisaufzeichnung. Jede Zeile enthält mindestens ein Datum, eine Quelle und eine Nachricht. Auf einem Webserver beispielsweise generiert jeder Besuch eine Zeile, die die IP-Adresse des Besuchers, die angeforderte Seite, den HTTP-Antwortcode und die Verarbeitungszeit angibt.
Haben Sie schon einmal eine Textdatei mit unverständlichen Zeilen geöffnet? Das ist oft ein unstrukturiertes Log. Die Nachricht ist in Freitext verfasst, ohne festes Format. Jede Anwendung schreibt auf ihre Weise, was die Suche mühsam macht, sobald mehrere Dienste koexistieren.
Im Gegensatz dazu organisiert ein strukturiertes Log im JSON-Format jedes Feld maschinenlesbar. Das Datum, das Schweregradniveau, der betroffene Dienst und die Nachricht haben jeweils ein eigenes Feld. Der Gewinn ist direkt: Ein Analysewerkzeug kann Tausende von Ereignissen in wenigen Sekunden filtern, sortieren und kreuzen, anstatt ein Muster in rohem Text zu suchen.
Um alles über Logs in der Informatik zu erfahren, ist die Unterscheidung zwischen strukturiertem und unstrukturiertem Format das erste Konzept, das man beherrschen sollte, da es die weiteren Schritte bestimmt: Sammlung, Speicherung, Analyse.
Schweregrade von Logs: das richtige Signal zur richtigen Zeit lesen
Nicht alle aufgezeichneten Ereignisse haben die gleiche Schwere. Die Protokollierungs-Frameworks verwenden eine Schweregradskala, die es ermöglicht, das zu filtern, was sofortige Aufmerksamkeit erfordert.
- DEBUG: feine Details, die während der Entwicklung verwendet werden, in der Produktion deaktiviert, um ein übermäßiges Volumen zu vermeiden.
- INFO: normale Ereignisse, die das ordnungsgemäße Funktionieren bestätigen (Start eines Dienstes, erfolgreiche Anmeldung).
- WARN: ungewöhnliche Situation, die das Funktionieren nicht verhindert, aber ein Risiko signalisiert (geringer Speicherplatz, hohe Latenz).
- ERROR: eine Verarbeitung ist fehlgeschlagen, eine Benutzeraktion war nicht erfolgreich. Oft ist ein Eingreifen erforderlich.
- FATAL: der Dienst stoppt. Die gesamte Anwendung oder der Server ist offline.
Die häufige Versuchung besteht darin, alles auf DEBUG zu setzen, um “nichts zu verpassen”. Das Ergebnis: Dateien, die täglich um mehrere Gigabyte wachsen, explodierende Speicherkosten und ein permanentes Rauschen, das die tatsächlichen Warnungen übertönt. Die Wahl des richtigen Schweregrads reduziert das Volumen, ohne nützliche Informationen zu verlieren.
Empfindliche Daten in Logs: Was niemals aufgezeichnet werden sollte
Ein Log kann fast alles erfassen, was in einer Anwendung verläuft. Das ist genau das Problem. OWASP empfiehlt, Passwörter, Zugriffstoken, Sitzungs-IDs, Verschlüsselungsschlüssel und sensible persönliche Daten aus den Logs auszuschließen.
Warum diese Vorsicht? Weil die Logs selbst eine Quelle für Datenlecks werden können. Eine Logdatei, die ohne Zugangsbeschränkungen gespeichert wird, setzt Informationen frei, die von einem Angreifer ausgenutzt werden können. Wenn eine Nachverfolgung erforderlich bleibt, besteht die gute Praxis darin, sensible Werte vor dem Schreiben ins Log zu maskieren oder zu pseudonymisieren.
Die CNIL gibt einen Richtwert für die Zugriffs- und Aktionsprotokolle der Benutzer: eine Aufbewahrung von sechs Monaten bis zu einem Jahr, je nach Zweck. Darüber hinaus muss der gesammelte Inhalt im Verhältnis zum tatsächlichen Bedarf bleiben. Vollständige Anfragen über mehrere Jahre ohne definierte Rechtfertigung aufzubewahren, birgt sowohl rechtliche als auch technische Risiken.
Die Integrität der Logs schützen
Ein modifiziertes oder gelöschtes Log verliert jegliche Beweiskraft. OWASP empfiehlt Integritätskontrollen, einen eingeschränkten und überwachten Zugang sowie einen Schutz der Logdaten. Ein Log, das für eine Untersuchung nützlich ist, muss auch vertrauenswürdig sein. Ein Angreifer, der auf einen Server zugreift, wird oft versuchen, seine Spuren in den Logs vor jeder anderen Aktion zu verwischen.
Europäische Regulierung und Protokollierung: konkrete Verpflichtungen
Die Protokollierung ist nicht mehr nur eine gute technische Praxis. Das europäische Cyber Resilience Act schreibt die Protokollierung von Sicherheitsereignissen als eine der Anforderungen vor, die für digitale Produkte gelten. Die Richtlinie NIS 2 hingegen verpflichtet die betroffenen Stellen, Fähigkeiten zur Erkennung und Reaktion auf Vorfälle zu implementieren, was ein funktionierendes und nutzbares Log-System voraussetzt.
Ohne zuverlässige Protokollierung wird die Einhaltung von NIS 2 oder CRA unmöglich nachzuweisen. Diese Texte geben nicht vor, welches Werkzeug zu verwenden ist, verlangen aber die Fähigkeit zu verfolgen, zu erkennen und zu reagieren. Die Logs sind die technische Grundlage dieser Fähigkeit.
Gute Praktiken im Umgang mit Logs im Alltag
Logs einzurichten, reicht nicht aus. Ihr Nutzen hängt davon ab, wie sie gesammelt, zentralisiert und genutzt werden.
- Die Protokolle aller Dienste auf einer einzigen Plattform zu zentralisieren, vermeidet manuelles Suchen auf jedem Server. Ein Collector sammelt die Ereignisse und sendet sie an einen gemeinsamen Analysepunkt.
- Eine geeignete Aufbewahrungsrichtlinie für jeden Logtyp festlegen. Die Protokolle über den Benutzerzugriff haben nicht die gleiche nützliche Aufbewahrungsdauer wie die Logs zur Anwendungsdiagnose.
- Alarme für die Schweregrade ERROR und FATAL einrichten, um zu reagieren, bevor die Benutzer das Problem melden.
- Regelmäßig überprüfen, was aufgezeichnet wird. Ein während einer schnellen Entwicklung hinzugefügtes Feld kann persönliche Daten enthalten, ohne dass es jemand vorgesehen hat.
Der Wert eines Log-Systems misst sich an der Geschwindigkeit der Lösung eines Vorfalls. Ein gut strukturiertes, zentrales und nach klaren Regeln bereinigtes Log verwandelt einen mehrstündigen Ausfall in eine Diagnose von wenigen Minuten. Das trennt ein Team, das Vorfälle erleidet, von einem Team, das sie antizipiert.
