Audit-Logs Teil 2: Protokollierungsfunktionen von Webdiensten im Vergleich

AWS, Cloudflare, Vercel, Supabase, Headless CMS – was bleibt wo übrig?

Hallo, ich bin Otsuka, CTO bei Liberogic.

Im vorherigen Artikel haben wir die Unterschiede zwischen Access-Logs, Application-Logs und Audit-Logs erläutert.

Dieses Mal schauen wir uns konkret an, welche Logs bei den Diensten verfügbar sind, mit denen wir regelmäßig arbeiten: AWS, Cloudflare, Vercel, Supabase und Headless CMS.

Dabei geht es nicht um einen detaillierten Vergleich der Tarife und Funktionen der einzelnen Dienste.

Jeder Dienst hat unterschiedliche Besonderheiten – was standardmäßig protokolliert wird und wie lange man auf die Protokolle zugreifen kann. Wir geben hier einen groben Überblick über diese Unterschiede.

Auch wenn es sich um die gleiche „Log-Funktion" handelt, unterscheiden sich die relevanten Vorgänge und die Speicherdauer.

Darüber hinaus ist die Anzeige in der Verwaltungsoberfläche eine separate Sache von der langfristigen Speicherung zu Audit-Zwecken.

AWS ist umfassend vorhanden, aber eine Konfiguration ist erforderlich

AWS verfügt über ein umfassendes Angebot von Protokollierungsdiensten.

Beispielsweise werden Ausführungsstatus von Lambda oder API Gateway in CloudWatch Logs erfasst. Operationen in der AWS-Verwaltungskonsole oder über die API können mit CloudTrail protokolliert werden.

Grob gesagt,

• CloudWatch Logs: Überwachen Sie das Verhalten von Anwendungen und AWS-Services.
• CloudTrail: Sehen Sie, wer was in Ihrer AWS-Umgebung getan hat.
• S3: Speichern Sie Protokolle langfristig.

Diese Rollenverteilung funktioniert so.

Da Suche, Überwachung, Benachrichtigungen und Langzeitspeicherung alle innerhalb von AWS aufgebaut werden, ist dies eine Architektur, die sich leicht an Systeme mit starken Audit-Anforderungen anpassen lässt.

Allerdings: Nur weil Sie AWS verwenden, heißt das nicht, dass alles automatisch erfasst wird.

Sie müssen die Protokollierung für jeden genutzten Service konfigurieren und sowohl die Aufbewahrungsdauer als auch das Ziel festlegen. Diese hohe Flexibilität erfordert eine sorgfältige Planung.

Cloudflare trennt kurzfristige Untersuchungen von externer Speicherung.

In Cloudflare Workers können Sie die mit console.log() ausgegebenen Inhalte und Fehler in Workers Logs einsehen.

Dies ist sehr praktisch für die Überprüfung während der Entwicklung und für aktuelle Fehlersuche, aber wenn Sie längerfristige Audit-Trails speichern möchten, sollten Sie sich nicht nur auf den Standard-Log-Bildschirm verlassen.

Für Logs, die langfristig aufbewahrt werden müssen, empfehlen wir eine Konfiguration, die Logpush oder ähnliche Tools nutzt, um die Logs an R2 oder externe Protokollverwaltungsdienste zu senden.

Darüber hinaus werden nicht alle Zugriffe im Ausführungsprotokoll des Workers protokolliert, wenn Sie statische Websites mit Cloudflare Pages oder Workers bereitstellen.

Die Website wird normalerweise angezeigt, man könnte also denken, „natürlich gibt es auch Zugriffsprotokolle", aber die Bereitstellung statischer Dateien und die Ausführung von Worker sind unterschiedliche Dinge.

Während Cloudflare es relativ einfach macht, eine kompakte Konfiguration zu erstellen, ist es notwendig, zu verstehen, welche Verarbeitung wo durchläuft, um die Protokollierung entsprechend zu gestalten.

Vercel macht es einfach, die Protokolle von Next.js zu überprüfen.

Bei Vercel können Sie Protokolle anzeigen, die von Next.js Functions, Server Actions und mehr in der Verwaltungsoberfläche generiert wurden.

Da Deployment- und Ausführungsprotokolle sich an nahegelegenen Stellen befinden, ist die Umgebung für Entwickler übersichtlich und ermöglicht eine einfache alltägliche Fehlersuche.

Andererseits unterscheiden sich je nach Plan der Zeitraum, für den Sie Logs einsehen können, und der Umfang der Weiterleitung an externe Systeme.

Wenn Sie die Daten längerfristig behalten möchten, benötigen Sie einen anderen Mechanismus, z. B. die Verwendung von Drains, um sie an einen externen Speicherort zu senden.

Unabhängig von Vercel ist es ein Unterschied, ob Protokolle in der Verwaltungsoberfläche angezeigt werden und ob sie zu Audit-Zwecken langfristig gespeichert sind.

Diese beiden Aspekte müssen separat überprüft werden.

Supabase hat viele Protokolle neben der Datenbank

Supabase ist zwar ein auf PostgreSQL basierendes Service, besteht aber tatsächlich aus mehreren Funktionen: nicht nur aus Datenbank, sondern auch aus Authentifizierung, API, Speicher und Edge Functions.

Da Sie die Protokolle der einzelnen Komponenten über die Verwaltungsoberfläche einsehen können, ist es einfach, die Gesamtfunktionalität der Anwendung nachzuvollziehen.

Darüber hinaus gibt es auch Authentifizierungsprotokolle und Audit-Protokolle, um die in der Supabase-Verwaltungsoberfläche ausgeführten Operationen zu überprüfen.

Auch hier ist wichtig zu beachten, dass die Verwaltungsvorgänge von Supabase und die Vorgänge in der von Ihnen erstellten Anwendung unterschiedlich sind.

Beispielsweise können Serviceseite-Änderungen an den Supabase-Projekteinstellungen aufzeichnen, wer diese vorgenommen hat. Aber Änderungen an Kundeninformationen in Ihrer eigenen Verwaltungsoberfläche müssen auf Anwendungsseite protokolliert werden.

Überprüfen Sie auch die Bedienungsverlauf des Headless-CMS

Headless-CMS wie microCMS, Kuroco und NILTO bieten Aktualisierungsverlauf für Inhalte und Betriebsprotokolle der Verwaltungsoberfläche.

Aufzeichnungen darüber, wer einen Artikel aktualisiert hat, wann er veröffentlicht wurde oder welche Einstellungen und Berechtigungen geändert wurden, sind als Audit-Logs für den Betrieb von Websites wichtig.

Allerdings unterscheiden sich je nach Service die erfassten Vorgänge, der überprüfbare Zeitraum und die verfügbaren Pläne.

Selbst wenn Sie die Aktualisierungsverlauf des Inhalts überprüfen können, müssen nicht alle Verwaltungsvorgänge als Audit-Logs erhalten bleiben.

Außerdem enthält ein CMS grundsätzlich nur Operationsprotokolle innerhalb des CMS selbst. Zugriffe auf die veröffentlichte Website und Fehler, die auf der Frontend-Seite auftreten, müssen in der Hosting-Umgebung überprüft werden.

Bei Headless-CMS-Projekten ist es verständlicher, das CMS, Frontend, Hosting und API als ein einziges System zu betrachten.

Beim Hinzufügen von Datadog oder Sentry

Wenn Logs auf mehrere Services verteilt sind, müssen Sie bei jedem Fehler mehrere Admin-Dashboards öffnen und untersuchen.

Durch die Zusammenfassung in einem Log-Management-Service wie Datadog können Sie Logs mehrerer Umgebungen zusammen durchsuchen und Anomalien erkennen, um Benachrichtigungen zu erhalten.

Sentry wird auch häufig genutzt, aber dieser Service ist spezialisiert darauf, die Stelle und den Umfang der Auswirkungen von Fehlern zu ermitteln.

Beide sind praktisch, aber die Implementierung führt nicht automatisch zu einem vollständigen Audit-Log.

Sie müssen auf der Anwendungsseite entscheiden, was ausgegeben werden soll. Wenn Sie alle Protokolle über längere Zeit speichern, steigen die Kosten je nach Datenmenge.

Es ist praktisch, zwischen Protokollen für die tägliche Suche und Protokollen für die Archivierung im Falle eines Problems zu unterscheiden.

Welcher Service ist besser? Das lässt sich nicht einfach entscheiden.

Wenn man nur Protokolle vergleicht, kann man nicht sagen, dass AWS oder Cloudflare am besten ist.

Wichtig ist, was für das jeweilige Projekt protokolliert werden muss.

• Ich möchte Service-Fehler untersuchen.
• Ich möchte Administrator-Aktionen dokumentieren.
• Ich möchte die Update-Historie des CMS einsehen.
• Ich möchte Authentifizierung und Berechtigungsänderungen nachverfolgbar machen.
• Ich möchte Protokolle langfristig für Audits aufbewahren.

Wenn klar ist, was benötigt wird, lassen sich die Funktionen, die die Standard-Features der einzelnen Services abdecken, und die Funktionen, für die zusätzliche Implementierung nötig ist, leicht erkennen.

Auch wir bereiten nicht von Anfang an eine große Protokollinfrastruktur vor, sondern passen die Konfiguration an die Anforderungen und das Budget des jeweiligen Projekts an.

Das nächste Mal werden wir uns damit befassen, welche Protokolle die Anwendungsseite ausgibt und wo diese gespeichert werden, wenn solche Dienste kombiniert werden. Wir werden einen Blick auf etwas werfen, das näher an der praktischen Anwendung liegt.

Naja dann.