Zum Inhalt

Audit Logs

Audit Logs sind ein zentraler Bestandteil der ayedo Kubernetes Distribution und helfen bei der Einhaltung verschiedener Datenschutz- und Sicherheitsvorschriften.

Was sind Audit Logs?

Audit Logs sind Protokolleinträge, die die Fragen beantworten: "Wer hat was und wann getan?"

Warum sind Audit Logs wichtig?

Audit Logs unterstützen sowohl proaktive als auch reaktive Sicherheit:

  • Proaktiv: Regelmäßige Log-Reviews ermöglichen es, Angreifer zu erkennen, bevor sie Schaden anrichten
  • Reaktiv: Im Nachhinein ermöglichen Audit Logs die Beweissicherung für forensische Analysen und die Bewertung des Schadensumfangs
  • Compliance: Erfüllung regulatorischer Anforderungen (GDPR, BSI IT-Grundschutz, NIS2, ISO 27001)

Welche Audit Logs sind enthalten?

Die ayedo Kubernetes Distribution folgt einem risikobasierten Ansatz für Audit Logs. Wir aktivieren Audit Logs für alle APIs, die die Datensicherheit kompromittieren können, und filtern hochvolumige, risikoarme Logs.

Standardmäßig werden folgende Audit Logs konfiguriert:

  • Kubernetes API Audit Logs
  • SSH Access Logs (für Administratoren)
  • Application Logs (optional, anwendungsspezifisch)

Kubernetes API Audit Logs

Die Kubernetes API Audit Logs erfassen alle Zugriffe auf die Kubernetes API und beantworten:

  • Wer: Benutzer-E-Mail (via OIDC) oder ServiceAccount-Name
  • Was: API-Operation (GET, POST, PUT, DELETE, etc.)
  • Wann: Zeitstempel
  • Wo: Welcher Cluster, welcher Namespace, welche Ressource

Integration mit Identity Provider

Dank der Integration mit Keycloak zeigen die Logs die E-Mail-Adresse von Personen an. Bei System-Zugriffen (z.B. CI/CD-Pipelines) wird der Name des ServiceAccounts protokolliert.

Zugriff auf Audit Logs

Audit Logs können über VictoriaLogs und Grafana eingesehen werden:

  1. Öffnen Sie das Grafana Dashboard
  2. Wählen Sie den Audit Logs Dashboard
  3. Filtern Sie nach Benutzer, Namespace oder Zeitraum

SSH Access Logs

Die ayedo Kubernetes Distribution erfasst auch hochprivilegierte SSH-Zugriffe auf Worker Nodes. Nur Administratoren sollten solchen Zugriff haben.

Best Practice:

  • Verwenden Sie individuelle SSH-Keys für jeden Administrator
  • Speichern Sie SSH-Keys auf Hardware Security Modules (HSM) wie YubiKeys
  • Führen Sie Background-Checks für Personen mit Administrator-Zugriff durch

Log-Retention

Audit Logs werden standardmäßig für 90 Tage gespeichert. Dies kann entsprechend Ihren Compliance-Anforderungen angepasst werden.

Konfigurierbare Retention-Perioden:

  • 30 Tage (Standard für Staging)
  • 90 Tage (Standard für Production)
  • 365 Tage (für regulierte Branchen)
  • Länger auf Anfrage

Tamper-Proof Storage

Audit Logs werden in einem separaten System gespeichert, das von der Hauptinfrastruktur getrennt ist, um nachträgliche Manipulation zu verhindern:

  • Separate Cluster: Logs in dediziertem Logging-Cluster
  • Restricted Access: Nur Read-Only-Zugriff für Auditoren
  • Immutable Storage: Logs können nicht nachträglich geändert werden

Audit Logs für zusätzliche Services

Kubernetes API Audit Logs erfassen bereits kubectl exec und kubectl port-forward Befehle. Zusätzliche Services haben normalerweise keine Audit-Protokollierung aktiviert, da dies viele Log-Einträge generiert.

Empfehlung: Implementieren Sie Audit Logs in Ihrer Anwendung, um audit-würdige Ereignisse zu erfassen:

  • Login/Logout
  • Zugriff auf sensible Daten
  • Änderungen an kritischen Ressourcen
  • Administrative Operationen

Database Audit Logging

Für Datenbanken kann Audit Logging aktiviert werden:

  • PostgreSQL: via PGAudit
  • MySQL/MariaDB: via Audit Plugin
  • MongoDB: via Audit Log

Diskutieren Sie mit dem ayedo-Team:

  • Welche Datenbanken und Tabellen auditiert werden sollen
  • Welche Operationen (INSERT, UPDATE, DELETE, SELECT)
  • Von welchen Benutzern (Personen vs. Anwendungen)

Compliance Mapping

GDPR Art. 32

Audit Logs unterstützen die "Sicherheit der Verarbeitung" durch:

  • Nachvollziehbarkeit aller Zugriffe auf personenbezogene Daten
  • Erkennung von Datenschutzverletzungen
  • Forensische Analyse nach Vorfällen

BSI IT-Grundschutz APP.4.4.A5

Erfüllt die Anforderung zur "Protokollierung sicherheitsrelevanter Ereignisse".

NIS2 Art. 21(2)(b)

Unterstützt "Incident Handling" durch vollständige Ereignisprotokolle.

ISO 27001 Annex A 8.15

Erfüllt "Logging" und A 8.16 "Monitoring Activities".

Log Review

Regelmäßige Log-Reviews sind entscheidend für die Wirksamkeit von Audit Logs:

  • Wöchentlich: Review von Admin-Zugriffen
  • Monatlich: Umfassende Review aller Audit Logs
  • Bei Vorfällen: Sofortige forensische Analyse

Siehe auch: Log Review

Weiterführende Ressourcen

Support

Für Fragen zu Audit Logs: