Audit-Log Teil 3: Protokolldesign für Webservices in der Praxis umsetzen

Was und wie viel sollte auf der Anwendungsseite protokolliert werden?

Hallo, ich bin Otsuka, CTO bei Liberogic.

Im letzten Beitrag haben wir die Log-Funktionen verschiedener Services wie AWS, Cloudflare, Vercel, Supabase und headless CMS miteinander verglichen.

Jeder Service bietet Ausführungsprotokolle, Fehlerprotokolle und Verwaltungsoperationsaufzeichnungen.

Aber reicht es aus, diese einfach zu kombinieren, um alle notwendigen Protokolle für einen Web-Service zu erhalten?

Leider ist es nicht so einfach.

Das liegt daran, dass sich die Protokolle, die Cloud-Services automatisch erstellen, von denen unterscheiden, die auf der Anwendungsseite selbst erfasst werden müssen.

In diesem Beitrag werden wir überlegen, wie die Log-Gestaltung in echten Web-Services funktioniert und die praktischen Aspekte systematisch ordnen.

Was man nicht allein aus den Service-Protokollen erfahren kann

Wenn Sie Cloudflare Workers oder Vercel Functions verwenden, werden Ausführungsergebnisse und Fehler bis zu einem gewissen Grad automatisch protokolliert.

Mit Supabase können Sie Protokolle für Datenbanken, Authentifizierung, APIs und mehr einsehen.

Allerdings kann die Dienstseite nur das sehen, was innerhalb des Dienstes selbst passiert.

Beispielsweise können wir sehen, dass ein Datenbankschreibvorgang erfolgreich war, aber nicht, ob es sich um eine akzeptierte Anfrage, eine Änderung von Mitgliedsinformationen oder etwas anderes handelte.

Solche geschäftlichen Ereignisse müssen auf Anwendungsseite mit Bedeutung versehen und protokolliert werden.

Nicht alles sollte in das Protokoll geschrieben werden

Man könnte denken, dass man zur Vorbereitung auf Untersuchungen so viele Informationen wie möglich in das Protokoll schreiben sollte.

Aber mehr Protokoll ist nicht unbedingt besser.

Wenn alle Vorgänge im Detail protokolliert werden, gehen die wirklich wichtigen Informationen unter. Mit zunehmender Protokollmenge steigen auch die Kosten für Speicherung und Suche.

Daher gestalten wir Protokolle mit Blick auf die "Grenzen" der Verarbeitung.

Zum Beispiel bei einem Kontaktformular würde

• Erfolgreich eingereicht
• Die eingegebene Information war fehlerhaft und wurde abgelehnt.
• „Von Spam-Filter abgelehnt"
• Die Speicherung in der Datenbank ist fehlgeschlagen
• Benachrichtigungsemail konnte nicht versendet werden

Und so werden die kritischen Punkte erfasst, an denen sich die Verarbeitungsergebnisse ändern.

Es geht nicht darum, alle Zwischenvariablen und Verarbeitungsschritte beizubehalten, sondern gezielt jene Ereignisse auszuwählen, die später notwendig sind, um den Verlauf nachvollziehen zu können.

Protokolle als Daten speichern, nicht als Text

Es ist praktisch, in Logs nicht nur „Ein Fehler ist aufgetreten" zu schreiben, sondern Informationen einzufügen, die später durchsucht werden können.

Die Erfassung solcher Elemente in einem einheitlichen Format wird strukturiertes Logging genannt.

Wenn die Elemente in einem Format wie JSON strukturiert sind, wird die Suche nach spezifischen Informationen vereinfacht – etwa nach der Verarbeitung einer bestimmten Antrags-ID oder nach Fehlern beim E-Mail-Versand.

Personenbezogene Daten nicht in Logs schreiben

Bei der Protokollierung von Kontaktformularen werden manchmal Namen, E-Mail-Adressen und der gesamte Nachrichtentext aufgezeichnet.

Dies mag für die Analyse praktisch erscheinen, ist aber eine Designentscheidung, die vermieden werden sollte.

Protokolle werden an mehrere Dienste weitergeleitet oder über längere Zeiträume gespeichert. Wenn sie personenbezogene Daten oder Authentifizierungsinformationen enthalten, können die Protokolle selbst zur Ursache eines neuen Datenlecks werden.

Geschäftsdaten wie Anfrageinhalte werden in einer Datenbank gespeichert, während Protokolle nur die Anfrage-ID und die Tatsache der erfolgreichen Annahme enthalten.

Wenn nötig, wird diese ID mit den Informationen auf der Datenbankseite abgeglichen.

Überlegungen zum Kontaktformular

In Kontaktformularen sehen wir häufig eine Konfiguration, die nur eine Benachrichtigungs-E-Mail versendet.

Allerdings ist es möglich, dass eine E-Mail nicht beim Empfänger ankommt, selbst wenn der Versendungsprozess erfolgreich war.

Daher ist es sicherer, die Anfrageinhalte zunächst in der Datenbank zu speichern und E-Mails nur als Benachrichtigungen für die Mitarbeiter zu behandeln.

Mit dieser Konfiguration können Sie unterscheiden, ob „die Anfrage gar nicht eingegangen ist" oder ob „die Anfrage gespeichert wurde, aber nur die Benachrichtigungsemail fehlgeschlagen ist".

Solche subtilen Unterschiede sind in der tatsächlichen Bearbeitung von Anfragen wirklich sehr wichtig, nicht wahr?

Kurzzeitige Suche und langfristige Speicherung trennen

Bei alltäglichen Störungsuntersuchungen ist es wichtig, dass die neuesten Logs sofort durchsucht werden können.

Andererseits ist es für Logs, die für Audits und Incident-Untersuchungen bestimmt sind, wichtig, dass sie zwar normalerweise kaum verwendet werden, aber Monate oder Jahre später noch abgerufen werden können.

Platzieren Sie die Informationen, die Sie für die neueste Untersuchung benötigen, an einem leicht durchsuchbaren Ort, und verschieben Sie langfristige Nachweise an einen kostengünstigen Speicherort.

Dies ist einfach, aber in der Praxis ist diese Unterscheidung sehr wirksam.

Logs und Dashboards sind zwei verschiedene Dinge

Mit Logs scheint es möglich zu sein, alles zu verstehen – Zugriffszahlen, Fehlerquoten und mehr.

Allerdings unterscheiden sich die in Logs und Dashboards angezeigten Werte in ihrer Funktion.

• Logs: Detaillierte Untersuchung einzelner Ereignisse
• Metriken: Aggregation von Anzahl, Prozentsätzen, Verarbeitungszeiten usw.
• Dashboard: Erfassung von Systemtrends im Überblick

Nutzen Sie täglich das Dashboard zur Statusüberwachung und untersuchen Sie mit Logs detailliert, wenn Anomalien auftreten.

Die Kombination dieser beiden ermöglicht eine leichtere Verwaltung.

Mindestanforderungen, die Sie im Voraus festlegen sollten

Abschließend fasse ich die Punkte zusammen, die Sie bei der Log-Konzeption beachten sollten.

• Ereignisse protokollieren
• In das Protokoll aufzunehmende Elemente
• Ausschluss personenbezogener Daten und Authentifizierungsinformationen
• Zeitraum für die Suche in aktuellen Protokollen
• Umfang der Protokolle für Langzeitarchivierung
• Speicherort für Langzeitprotokolle
• Mitarbeiter mit Zugriff auf Protokolle
• Löschmethode für Protokolle nach Ablauf der Aufbewahrungsfrist

Wenn Sie den Begriff Audit-Protokoll hören, könnte es den Anschein haben, dass Sie alle Vorgänge protokollieren und eine umfangreiche Protokollverwaltungsinfrastruktur einführen müssen.

Bei typischen Websites oder Nachrichtenportalen können Sie dagegen damit beginnen, zunächst wichtige Operationen und Verarbeitungsergebnisse festzulegen und die kurzfristige Suche von der Langzeitarchivierung zu trennen.

Das Wichtigste ist nicht, die Protokollierungsfunktionen der einzelnen Dienste aufzuzählen, sondern zu überprüfen, ob das gesamte System die notwendigen Aufzeichnungen speichert.

Was wollen wir hinterlassen?

Wofür wird es behalten?

Wie lange dauert es?

Wenn Sie diese drei Punkte klären, können Sie die Struktur nicht größer als nötig machen und ein Logging-Design entwerfen, das zu Ihrem Projekt passt.

Logs fallen normalerweise nicht besonders auf.

Aber ob Sie erklären können, „was passiert ist", wenn etwas schiefgeht, hängt von Ihrem anfänglichen Design ab.

Es ist wichtig, diese grundlegenden Dinge korrekt zu schaffen, nicht wahr?

Naja dann.