6 Hinweise zur Anwendungsprotokollierung

Wenn Sie irgendwo einen Dienst laufen haben, müssen Sie herausfinden, ob er korrekt funktioniert. Neben den möglichen Tests, Liveness Checks und Metriken können Sie auch Anwendungsprotokolle verwenden. Aber was macht ein Anwendungsprotokoll "gut"? 1. Zweck ist alles!

Bevor Sie mit dem Schreiben von Protokollausgaben beginnen, sollten Sie zunächst einen Schritt zurücktreten. Fragen Sie sich jetzt: Für wen protokollieren Sie? Was ist das Ziel und wer ist Ihr Zielpublikum? Beabsichtigen Sie, ein Protokoll zu erstellen, das auf die Fehlersuche in der Anwendung ausgerichtet ist? Oder ist dies ein Protokoll, das alle relevanten Ereignisse als Teil eines Audit-Protokolls erfasst?

Sobald Sie den Zweck und die Zielgruppe des Protokolls definiert haben, können Sie es in Angriff nehmen. Nachfolgend finden Sie ein paar verschiedene Zwecke für die Protokollierung. Natürlich gibt es noch viele weitere, die Ihnen einfallen könnten, aber lassen Sie uns nur ein paar herausgreifen:

Anwendungsfall: Protokollierung für die Anwendungswartung

Wenn Sie die Protokollierung für die Wartung Ihrer Anwendung einrichten, sollten Sie zumindest daran denken:

• Möchten Sie Personen über bestimmte Schritte informieren, die von der Anwendung ausgeführt werden?
• Welche Ausnahmen oder Fehler in Ihrer Anwendung sind es tatsächlich wert, im Hinblick auf fehlerhafte Codepfade protokolliert zu werden? Führt die Information über diese Fehler zu einer besseren Wartung und/oder einem höheren Geschäftswert?
• Wann ist ein bestimmter Zustand der Anwendung es wert, den Standby-Modus aufzuwecken? Es gibt verschiedene Möglichkeiten, wie Sie dies lösen können. Eine davon ist: Nutzen Sie den Unterschied zwischen der Protokollierung auf Fehler- und auf Warnstufe. Fehlerstufe würde bedeuten: Jetzt in Aktion treten, Warnstufe könnte bedeuten: Wenn Sie bereit sind, machen Sie weiter. Viele Ausnahmen und Fehler, die Ihr Code auslöst, sind es vielleicht nicht wert, aufgegriffen zu werden und sollten nicht als Fehler oder Warnung protokolliert werden.

Es gibt eine Menge verschiedener Dinge zu beachten. Wir sehen oft, dass Anwendungen zu viele Ausnahmen in das Protokoll werfen, obwohl der Ausführungspfad durch die Ausnahme immer noch zu dem eigentlichen Zustand führt, der dem Kunden einen Wert liefert. Daher geht die Protokollierung zur Unterstützung Ihrer Anwendungswartung über das Schreiben und Speichern von Protokollen hinaus: Sie beginnt mit der (Neu-)Gestaltung Ihrer Anwendungskontrollflüsse.

Was hier helfen kann, ist, sich pro User Story zu fragen: "Was müssen Sie protokollieren, um zu wissen, dass die Funktion korrekt funktioniert?" & "Was müssen Sie protokollieren, wenn die Funktion nicht funktioniert?"

Anwendungsfall: Audit-Protokolle

Audit-Protokolle haben ganz andere Anforderungen als Anwendungsprotokolle. In einem Audit-Protokoll müssen Sie jedes Ereignis erfassen, das zu dem entsprechenden Änderungszustand in Ihrer Anwendung oder Ihren Geräten führt. Dies ist etwas anderes als das Protokoll für die Anwendungswartung: hier ist der Grund für einen internen Serverfehler aufgrund einer fehlenden Datenbankverbindung weniger relevant. Die Schritte, die Ihre Benutzer durchlaufen haben, um eine Transaktion auszuführen, sind jedoch für das System von zentraler Bedeutung.

Die Integrität des Audit-Protokolls ist wichtig, da die Protokolle vor Gericht als Beweismittel dienen können, wenn es zu Rechtsstreitigkeiten über Aktionen eines Benutzers oder des Systems kommt. Dies erfordert einen Schutz der Integrität des Audit-Protokolls sowie die Sicherstellung, dass alle relevanten Aktionen aufgezeichnet werden. Dies funktioniert am besten, wenn Sie Ihre Protokolle so gestalten, dass eine einfache Korrelation möglich ist: Stellen Sie sicher, dass Sie die relevanten Protokolle von Anfang an miteinander verknüpfen! Dies kann über einen Sitzungsidentifikator, Trace-IDs usw. geschehen.

Beachten Sie, dass Audit-Protokollmeldungen ebenfalls eine eigene Aggregation erfordern. Achten Sie also darauf, dass Sie die Meldungen auf dieselbe Weise formatieren.

Anwendungsfall: Sicherheitsereignisprotokolle

Sicherheitsereignisprotokolle sollten so konzipiert sein, dass sie das Sicherheitsteam über alle Ereignisse informieren, die es beachten sollte. Fragen Sie das Sicherheitsteam, was es von den Protokollen benötigt: Gehören dazu die "glücklichen Abläufe" in Ihren Audit-Protokollen? Gehören dazu auch alle Fehlerzustände in Ihren Anwendungsprotokollen? Ein Sicherheitsereignisprotokoll sollte auf einem Bedrohungsmodell basieren. Wovor haben Sie Angst? Welches Szenario könnte für die Sicherheit des Systems und/oder der Benutzer problematisch sein?

2. Geheimnisse in der Protokollierung

Wir müssen oft Geheimnisse wie Anmeldedaten und/oder kryptografische Schlüssel in unsere Anwendung laden. Diese Geheimnisse können leicht missbraucht werden, wenn sie in die falschen Hände geraten. Denken Sie an Passwörter für leistungsstarke administrative Backends oder an Signierschlüssel, mit denen Sie beweisen können, dass eine Transaktion von dem System stammt, zu dem der Schlüssel gehört. In beiden Fällen kann ein Angreifer mit ihnen leicht Schaden anrichten. Daher ist es besser, diese Art von Geheimnissen nicht in der Protokollierung zu speichern. Schließlich könnte jeder, der Zugang zu diesen Protokollen hat, die Geheimnisse für eine Privilegienerweiterung nutzen. Ein schönes Beispiel dafür finden Sie in Herausforderung 8 von OWASP WrongSecrets auf GitHub.

3. Sensible Daten in der Protokollierung

Während Passwörter ein einfaches "No-Go" für die Protokollierung sind, gibt es eine ganze Reihe von Elementen, die "zu sensibel" sein könnten, um sie ohne zusätzliche Verschleierung/Verschlüsselung/Maskierung in Ihre Anwendungsprotokolle aufzunehmen:

• Finanzielle, gesundheitliche und geschäftliche Informationen, die nicht öffentlich zugänglich sein sollten
• Persönlich identifizierbare Informationen im Sinne der DSGVO oder anderer anwendbarer Gesetze und Vorschriften.
• Quellcode der Anwendung
• Jede andere Art von Informationen, die aufgrund des zugrunde liegenden Bedrohungsmodells als zu sensibel eingestuft wird.

Heißt das, dass Sie all diese Informationen gar nicht protokollieren können? Natürlich sollten sie, wenn sie relevant sind, Teil Ihres Audit-Protokolls sein. Aber es könnte eine gute Idee sein, diese Informationen nicht in Ihr Anwendungs-Debug-Protokoll aufzunehmen.

4. Protokollierung und Sicherheit

Es gibt viele sicherheitsrelevante Themen, wenn es um die Protokollierung von Daten geht. Lassen Sie uns ein paar davon ansprechen:

• Vertrauen Sie niemals externen Eingaben. Fügen Sie niemals einfach Rohdaten in Ihre Protokolle ein. Stellen Sie stattdessen sicher, dass Sie nur Daten aus vertrauenswürdigen Zonen aufzeichnen. Als nächstes: Stellen Sie sicher, dass Sie eine ordnungsgemäße Kodierung und Datenbereinigung durchführen. WebGoat auf GitHub enthält eine schöne Herausforderung, die zeigt, was passiert, wenn Sie Ihre Daten nicht richtig bereinigen.
• Härten Sie Ihre Einrichtung. Die jüngsten Ereignisse mit dem Log4J Mitigation Plan auf Xebia zeigen, dass wir sicherstellen sollten, dass unsere Protokollierungsinfrastruktur gepatcht, gehärtet und überwacht wird.
• Schützen Sie die Integrität Ihrer Protokolle: Die Integrität der Daten wird umso wichtiger, wenn die Protokolle zeigen müssen, was passiert ist. Audit-Protokolle, Transaktionsprotokolle und dergleichen müssen oft durch signierte/HMAC-verschlüsselte Nachrichten oder durch eine WORM-Speicherlösung (Write Once, Read Many) geschützt werden.
• Schützen Sie die Daten. Protokolle sollten mindestens auf demselben Niveau geschützt werden wie die Daten, mit denen der Prozess arbeitet. Das bedeutet, dass Sie eine Zugriffsverwaltung für Protokolle einrichten müssen, sie im Ruhezustand verschlüsseln müssen usw.

5. Stacktraces und Protokollierung

Stacktraces erfordern besondere Aufmerksamkeit. Wenn Stacktraces Geschäftsobjekte in ihre Beschreibungen einbeziehen, können sie Informationen preisgeben, die wir gerade aufgeführt haben, um sie nicht zu protokollieren. Seien Sie daher immer vorsichtig mit dem, was Sie in den Kontext einer Ausnahme stellen. Stellen Sie sicher, dass entweder Ihre Geschäftsobjekte oder Ihre Konfiguration für die Protokollierung und Ausnahmebehandlung sicherstellen, dass vertrauliche Informationen während eines Stacktraces gelöscht werden.

6. Handlungsfähige Protokolle (mit Kontext)

Achten Sie darauf, dass Sie nicht nur um des Protokollierens willen protokollieren. Versuchen Sie zu verstehen, was Sie zu welchem Zweck aufzeichnen müssen, und beschränken Sie sich auf diese Ebene. Oft sehen wir in den Protokollen Einträge wie "Eingehende Nachricht erhalten" und "Verarbeitung der Nachricht beginnt" ohne jeglichen Kontext der Nachricht. Das macht es schwer zu verstehen, was vor sich geht. Bei der Fehlersuche kann es hilfreich sein, um zu sehen, ob die empfangene Nachricht auch verarbeitet wird, aber danach hilft es den anderen Entwicklern nicht weiter. Denn: Je mehr Log-Statements, desto höher ist das Risiko, dass wichtige Ereignisse übersehen werden. Deshalb empfehlen wir Ihnen, Ihre Protokollnachrichten zu beschneiden (oder die Protokollstufe herabzusetzen), wenn Sie mit der Fehlersuche fertig sind.

Wohin als nächstes?

Es gibt noch viele weitere Dinge, die Sie bei der Gestaltung Ihrer Anwendungsprotokollierung berücksichtigen müssen, wie z. B:

• Welche Informationen werden für übergeordnete Geschäftsziele benötigt?
• Welche Quellen sollten Sie einbeziehen, um Ihren Protokollen einen Kontext zu geben? Denken Sie an die Protokolle, die von Ihren Host-Rechnern, Ihrer Cloud-Infrastruktur usw. stammen.
• Wo speichern Sie die Protokolle im Laufe der Zeit?

Fürs Erste: Prüfen Sie Ihre Anwendungsprotokolle und setzen Sie sich mit den Parteien in Verbindung, die auf Ihre Protokolldaten angewiesen sind! Nehmen Sie die hier vorgestellten 6 Hinweise und bewerten Sie gemeinsam: Liefern die Protokolle den Wert, den Sie brauchen? Ist die Anwendung sinnvoll gestaltet, wenn es um Fehler- und Ausnahmebehandlung geht?

Lesen Sie mehr:

• WebGoat 8: WebGoat auf GitHub
• OWASP Spickzettel: OWASP Spickzettel für die Protokollierung
• Log4J: Log4J-Abschwächungsplan auf Xebia
• Falsche Geheimnisse: OWASP WrongSecrets auf GitHub