Audit-Protokolle nutzen

Jede API-Anfrage in Ihrer Organisation wird 365 Tage lang aufgezeichnet - wer, was, wann, von wo und unter welcher Anwendung. Das ist die erste Anlaufstelle, wenn Sie wissen müssen, was passiert ist.

Verfasst vom Didit-Support · Aktualisiert am 19. August 2026

#Was aufgezeichnet wird

1234

1. Filtern Sie nach Mitglied, Pfad, Methode oder Datum, um zu beantworten, wer das geändert hat.
2. Methode und Status unterscheiden einen Lesezugriff von einer Änderung, die tatsächlich wirksam wurde.
3. Das Mitglied, das den Aufruf gemacht hat.
4. Woher es kam - das Detail, das aus einem Protokoll einen Nachweis macht.

Jede Anfrage, die innerhalb Ihrer Organisation an die Didit-Plattform gerichtet wird, unabhängig davon, wodurch sie ausgelöst wurde. Jeder Eintrag enthält:

Protokolle werden 365 Tage lang aufbewahrt und danach automatisch gelöscht.

#Wofür es wirklich gut ist

Vier Situationen, in denen es das richtige Werkzeug ist:

• "Wer hat diesen Workflow geändert?" Wenn sich ein Ablauf anders verhält als gestern, steckt meist eine Änderung dahinter, und das Protokoll nennt, wer sie vorgenommen hat.
• Einen Vorfall untersuchen. Genau nachvollziehen, worauf zugegriffen wurde, von wem, von welcher Adresse aus, in welcher Reihenfolge.
• Eine Integration debuggen. Sehen, welche Anfragen Ihr eigener Code tatsächlich gestellt hat, statt derer, von denen Sie glauben, dass er sie gestellt hat - einschließlich derer, die mit 4xx endeten.
• Zugriffskontrolle belegen. Einem Prüfer zeigen, dass der Zugriff auf Verifizierungsdaten zugeordnet und überprüfbar ist.

#Filtern

Filtern Sie nach Nutzer, Endpunkt oder Zeitraum, um eine lange Liste einzugrenzen. Wenn Sie etwas Bestimmtes untersuchen, beginnen Sie beim Zeitstempel und arbeiten Sie sich nach außen vor - eine Anfrage kommt selten allein, und die Aufrufe direkt davor und danach erzählen meist die Geschichte.

#API-Schlüssel-Anfragen werden der Anwendung zugeordnet, nicht einer Person

Eine API-Schlüssel-Anfrage hat keinen Nutzer, dem sie zugeordnet werden könnte, daher erscheint sie gegen die Anwendung. Das ist die ehrliche Darstellung - die Plattform weiß schlicht nicht, welcher Ihrer Dienste oder Entwickler den Aufruf gemacht hat.

Die praktische Konsequenz: Ein einzelner Schlüssel, der von mehreren Diensten gemeinsam genutzt wird, macht einen Vorfall erheblich schwerer untersuchbar. Wenn Ihnen die Zuordnung wichtig ist, geben Sie jedem Konsumenten seine eigene Anwendung und seinen eigenen Schlüssel.

#Was im Protokoll steht, und was nicht

Das Protokoll erfasst Aktivität - wer was aufgerufen hat, wann, von wo und welcher Status zurückkam. Es ist eine Metadatenspur, keine Kopie der Verifizierungsdaten.

Wenn Sie wissen müssen, ob personenbezogene Daten von Kunden in diesen Einträgen erscheinen - eine Frage, die bei Datenschutzprüfungen aufkommt - holen Sie die Antwort bei Ihrem Didit-Kontakt ein und dokumentieren Sie sie, statt sie aus einer Hilfeseite abzuleiten. Genau eine solche Aussage wird Ihre eigene DPIA voraussichtlich belegen müssen.

#Wer es sehen kann

Der Zugriff auf Audit-Protokolle richtet sich nach der Rolle. Compliance Officer hat ihn; Reader hat keinen umfassenden Zugriff. Owner können ihn einer benutzerdefinierten Rolle zuweisen. Siehe Teammitglieder einladen und Rollen festlegen.

Das Entfernen eines Teammitglieds entfernt nicht dessen Historie aus dem Protokoll - das ist der Sinn der Sache. Eine Spur, die Sie bearbeiten können, ist keine Spur.

#Auch Exporte und Berichte werden protokolliert

Das Erzeugen eines Session-PDFs oder eines CSV-Exports ist ein API-Aufruf und erscheint daher hier, mit der Angabe, wer ihn ausgelöst hat. Das ist nützlich, wenn Sie zeigen müssen, dass der Zugriff auf Verifizierungsnachweise kontrolliert und nicht offen ist. Siehe einen Verifizierungsbericht herunterladen.

#Wenn Sie mehr als 365 Tage benötigen

Die Aufbewahrung ist fest auf 365 Tage eingestellt. Wenn Ihre Pflicht länger reicht, exportieren Sie regelmäßig, was Sie benötigen, und bewahren Sie es in Ihrem eigenen System auf - dasselbe Muster wie beim eigenständigen Aufbewahren von Session-Nachweisen. Die Entscheidung über den erforderlichen Zeitraum ist eine Compliance-Entscheidung Ihres Teams; gestalten Sie nichts auf Basis einer Annahme.