Audit-Protokollierung

DefectDojo zeichnet einen Audit-Trail der Änderungen an seinen Daten auf. Jedes verfolgte Objekt zeichnet automatisch Ereignisse für Erstellen, Aktualisieren und Löschen auf, und Beziehungstabellen (many-to-many) zeichnen Ereignisse für Hinzufügen und Entfernen auf.

Funktionsweise

Die Audit-Verfolgung wird durch Datenbank-Trigger gesteuert, die pro Modell registriert sind. Für jedes verfolgte Objekt können drei Ereignistypen ausgelöst werden:

EreignistypWann es ausgelöst wirdAktion
InsertEventEin neuer Datensatz wird erstelltErstellen
UpdateEventEin Datensatz ändert sich — nur wenn sich ein tatsächlicher Feldwert wirklich ändertAktualisieren
DeleteEventEin Datensatz wird gelöschtLöschen

Many-to-many-Beziehungstabellen (Tags, Reviewer, Firewall-IP-Bereiche) verfolgen nur Hinzufügen (InsertEvent) und Entfernen (DeleteEvent) — für eine Beziehungszeile gibt es kein „Update“.

Was bei jedem Ereignis erfasst wird

  • Wer — der handelnde Benutzer, entnommen aus dem Request-Kontext.
  • Wann — ein Zeitstempel.
  • Quell-IP — die Remote-Adresse, unter Berücksichtigung von X-Forwarded-For-Proxy-Ketten.
  • Vorher-/Nachher-Snapshot — die vollständigen Feldwerte des Datensatzes.
  • Context / Label — gruppiert Ereignisse, die aus derselben Anfrage stammen. Das Label initial_backfill kennzeichnet historische Datensätze, die importiert wurden, als die Verfolgung erstmals aktiviert wurde.

Ereignisse, die von Hintergrundjobs erzeugt werden, werden dem Kontext der ursprünglichen Anfrage wieder zugeordnet, sodass eine asynchron abgeschlossene Aktion weiterhin dem Benutzer zugeschrieben wird, der sie ausgelöst hat.

Core (Open Source) — verfolgte Aktionen

ObjektErstellenAktualisierenLöschenNotizen
Benutzerpassword von Snapshots ausgeschlossen
Produkttyp
Produkt
Engagement
Test
Befund
Befundgruppe
Befundvorlage
Risikoakzeptanz
Endpunkt
Location
URL
Benachrichtigungs-Webhookheader_name / header_value ausgeschlossen (Geheimnisse)

Core — Beziehungsereignisse (Add / Remove)

BeziehungHinzufügenEntfernen
Befund → Reviewer
Befund → Tags
Befund → Geerbte Tags
Produkt → Tags
Engagement → Tags
Engagement → Geerbte Tags
Test → Tags
Test → Geerbte Tags
Endpunkt → Tags
Endpunkt → Geerbte Tags
Befundvorlage → Tags
App-Analyse (Technologie) → Tags
Objekte/Produkt → Tags

Pro — verfolgte Aktionen

ObjektErstellenAktualisierenLöschenNotizen
Erweiterter BefundPro-Pendant zum Befund
RegelRegel-Engine
Regelaktion
Regelaktionsbedingung
Regelfiltereintrag
Regel-Engine-Vorgang
Regel-Engine-Vorgangsmeldung
Geplanter Task
Lauf eines geplanten Tasks
Mitigationsrichtlinie
Anpassbare EinstellungSystemkonfigurationsänderungen
Feature-Flag-StatusFlag-Umschaltungen + System-Pins
Feature-Flag-DefinitionMetadaten / Registry-Synchronisierung
Cloud-FirewallFeld locked ausgeschlossen
Firewall-IP-Maske

Pro — RBAC / Berechtigungen

ObjektErstellenAktualisierenLöschen
Gruppe
Rolle
Gruppenmitgliedschaft
Globale Rolle
Produkt-Gruppen-Zuweisung
Produkttyp-Gruppen-Zuweisung
Produktmitglied
Produkttyp-Mitglied

Pro — Beziehungsereignisse (Add / Remove)

BeziehungHinzufügenEntfernen
Cloud-Firewall → IP-Bereiche

Konfiguration und Aufbewahrung (On-Premise Controls)

EinstellungUmgebungsvariableStandardwertAuswirkung
Audit-Protokollierung aktivierenDD_ENABLE_AUDITLOGTrueBei False werden alle History-Trigger deaktiviert und es werden keine Ereignisse aufgezeichnet
AufbewahrungszeitraumDD_AUDITLOG_FLUSH_RETENTION_PERIOD-1 (nie leeren)Anzahl der Monate an Historie, die aufbewahrt werden; ältere Ereignisse werden vom Flush-Job stapelweise gelöscht
Flush-BatchgrößeDD_AUDITLOG_FLUSH_BATCH_SIZE1000Pro Batch gelöschte Zeilen während der Bereinigung
Maximale Flush-BatchesDD_AUDITLOG_FLUSH_MAX_BATCHES100Obergrenze für die Anzahl der Batches pro Flush-Lauf

Hinweise und Einschränkungen

  • Geheimnisse werden niemals erfasst. Benutzerpasswörter und die Header-Werte von Benachrichtigungs-Webhooks sind ausdrücklich von Ereignis-Snapshots ausgeschlossen.
  • Updates werden nur bei einer echten Änderung aufgezeichnet. Ein Speichervorgang, der keinen Feldwert ändert, erzeugt kein Update-Ereignis; automatisch verwaltete Felder wie last_updated allein lösen keines aus.
  • Authentifizierungsereignisse werden hier nicht erfasst. Nur Datenänderungen. Login-, Logout- und fehlgeschlagene Login-Versuche werden separat behandelt und sind nicht Teil dieses Audit-Protokolls.