> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Audit-Logs: API-Aktivitäten nachverfolgen & Compliance

> Verfolgen Sie alle API-Aktivitäten in Didit mit durchsuchbaren Audit-Logs. Filtern Sie nach Benutzer, Methode, Status und Zeitraum.

Audit-Logs bieten eine umfassende, durchsuchbare Aufzeichnung aller API-Aktivitäten in Ihrer Organisation. Jede Anfrage an die Didit-Plattform, ob aus der Konsole, aus Ihrer Integration oder von Mitgliedern Ihres Teams, wird automatisch für Sicherheit, Compliance und Fehlersuche protokolliert.

![Audit-Logs in der Didit-Konsole](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-audit-logs.jpg?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=bcd436f764486143268f5c5ca67d9d14)

***

## Warum Audit-Logs

| Herausforderung | Lösung |
| - | - |
| Anforderungen an die regulatorische Compliance | Lückenloser Prüfpfad aller Aktivitäten, so weit zurück, wie Ihr Tarif es vorsieht |
| Untersuchung von Sicherheitsvorfällen | Genau nachvollziehen, wer was und wann getan hat |
| Fehlersuche bei Integrationsproblemen | Pfad, Status und geschwärzten Body jeder Anfrage einsehen |
| Verantwortlichkeit im Team | Nachvollziehen, welche Mitglieder auf welche Daten zugegriffen haben |
| Nutzungsüberwachung | Muster des API-Verbrauchs verstehen |

***

## Zugriff auf Audit-Logs

Öffnen Sie in der Didit-Konsole **Settings > Organization > Audit log**. Die Oberfläche zeigt eine chronologische Liste aller API-Anfragen, die innerhalb Ihrer Organisation gestellt wurden.

Jeder Log-Eintrag enthält:

| Feld | Beschreibung |
| - | - |
| **Zeitstempel** | Zeitpunkt, zu dem die Anfrage gestellt wurde |
| **Benutzer** | Wer die Anfrage gestellt hat: die E-Mail-Adresse des authentifizierten Mitglieds; der Name des API-Schlüssels, der die Anfrage gestellt hat, markiert mit **API-Schlüssel**; oder **Der Ermittler**, für eine Entscheidung, die er selbstständig getroffen hat |
| **Methode** | HTTP-Methode (GET, POST, PUT, DELETE) |
| **Pfad** | Der aufgerufene API-Endpoint |
| **Status** | HTTP-Statuscode der Antwort |
| **Adresse** | Ursprungs-IP der Anfrage |
| **Anwendung** | Die Anwendung, der die Anfrage zugeordnet war |

### Entscheidungen des Ermittlers

Jede Entscheidung, die der [Ermittler](https://docs.didit.me/de/console/investigator.md) selbstständig trifft, wird unter **Der Ermittler** erfasst, nicht unter einem Mitglied oder einem API-Schlüssel: das Genehmigen oder Ablehnen einer Sitzung oder das Anfordern einer erneuten Einreichung, das Setzen des Status einer Transaktion sowie das Abschließen eines Falls, das Eskalieren oder das Anfordern von Informationen dazu.
Der Eintrag verweist auf den Ermittler-Bericht, auf dem die Entscheidung beruht.
Wenn eine Person eine Empfehlung des Ermittlers akzeptiert oder überschreibt, wird der Eintrag dieser Person zugeordnet.

***

## Filtern und Suchen

Die Oberfläche der Audit-Logs bietet leistungsstarke Filtermöglichkeiten, damit Sie genau finden, wonach Sie suchen.

### Intelligente Suche

Die Suchleiste erkennt automatisch, wonach Sie suchen:

| Suchtyp | Beispiel | Verhalten |
| - | - | - |
| **Exakter Pfad** | `/v1/organization/.../sessions/` | Findet Logs mit genau diesem Anfragepfad |
| **Exakte E-Mail** | `admin@company.com` | Findet Logs von genau diesem Benutzer |
| **Exakte IP** | `192.168.1.100` | Findet Logs von dieser Adresse |
| **Platzhalter** | `/v1/*/analytics/*` | Findet Muster mit Platzhaltern |
| **Freitext** | `sessions` | Unscharfe Suche über alle Felder |

### Verfügbare Filter

| Filter | Beschreibung | Beispiel |
| - | - | - |
| **Anwendung** | Nach einer bestimmten Anwendung filtern | Aus dem Dropdown auswählen |
| **Mitglieder und API-Schlüssel** | Nach dem API-Schlüssel filtern, der die Anfragen gestellt hat | Einen Schlüssel der gewählten Anwendung auswählen |
| **Akteur** | Nur anzeigen, was Mitglieder, API-Schlüssel oder der Ermittler getan haben | **Der Ermittler** |
| **Methode** | Nach HTTP-Methode filtern | `GET`, `POST`, `PUT`, `DELETE` |
| **Statuscode** | Nach Antwortstatus filtern | `200`, `401`, `500` |
| **Zeitraum** | Nach Zeitraum filtern | Letzte 7 Tage, benutzerdefinierter Zeitraum |

***

## Datenaufbewahrung

Ihr Tarif legt fest, wie weit zurück Sie das Audit-Log einsehen können und ob Sie es exportieren dürfen:

| Tarif | Zeitraum rückwirkend | Export |
| - | - | - |
| Free | 30 Tage | Nein |
| Growth | 1 Jahr | Nein |
| Scale | 3 Jahre | Ja |
| Enterprise | Laut Vertrag festgelegt | Ja |

Ein Export in einem Tarif ohne diese Funktion liefert `403` mit `"code": "plan_limit_exceeded"`.

***

## Sicherheit und Datenschutz

### Was protokolliert wird

Audit-Logs erfassen Metadaten zu API-Anfragen:

* Zeitstempel und Dauer der Anfrage
* Benutzeridentität (E-Mail, Benutzer-ID) oder der API-Schlüssel, der die Anfrage gestellt hat (dessen Name und die ersten Zeichen seines Secrets, niemals das vollständige Secret)
* Anfragepfad und Query-Parameter
* HTTP-Statuscodes der Antworten
* Client-Adresse und User-Agent

### Request- und Response-Bodys von API-Schlüssel-Aufrufen

Bei einem Aufruf mit einem API-Schlüssel speichert das Audit-Log außerdem eine geschwärzte Kopie des JSON-Request-Bodys eines Schreibvorgangs sowie der Antwort auf einen Schreibvorgang oder auf einen Fehler, damit Sie sehen können, warum ein Aufruf fehlgeschlagen ist.
Die Antwort auf einen erfolgreichen Lesevorgang wird nicht gespeichert.

Die Schwärzung folgt dem Prinzip „standardmäßig verweigert“:

* Die Struktur bleibt erhalten: Feldnamen, Verschachtelung, Werttypen, Array-Längen und String-Längen.
* Ein Wert bleibt nur erhalten, wenn es sich um einen eigenen Identifikator, Status, Code, Zähler oder Zeitstempel von Didit handelt, in einem Feld, das Didit definiert, und mit dem Format, das dieses Feld erwartet.
* Ein Boolean bleibt nur in einem Feld erhalten, das Didit definiert.
* Jeder andere Wert wird durch eine Markierung ersetzt, die Typ und Länge angibt, etwa `[redacted:string:12]`, `[redacted:number:5]` oder `[redacted:boolean]`. `null` bleibt `null`.
* Ein Feldname, der kein einfacher Bezeichner ist, etwa eine E-Mail-Adresse oder eine Telefonnummer als Schlüssel, wird durch `[redacted:key:23]` ersetzt.
* Ein Body, der kein JSON ist, etwa ein Formular oder ein Datei-Upload, wird durch einen Hinweis ersetzt, der angibt, um was es sich handelte.
* Der verbleibende Inhalt wird nach 4.096 Zeichen abgeschnitten.

Query-Parameter durchlaufen dieselbe Schwärzung.
Nur Standard-Header wie `content-type`, `user-agent` und die Rate-Limit-Header werden gespeichert. Alle anderen Header werden mit ihrem Wert verworfen.
Ein Wert, den Ihr eigenes System sendet, etwa in `metadata` oder `vendor_data`, wird niemals gespeichert, auch dann nicht, wenn sein Feld wie ein Feld von Didit benannt ist.

### Was NICHT protokolliert wird

Zum Schutz sensibler Daten werden die folgenden Inhalte automatisch ausgeschlossen:

* Authentifizierungs-Tokens und Zugangsdaten
* Passwörter und Geheimnisse
* Personenbezogene Daten aus Verifizierungssitzungen

### Zugriffskontrolle

Zum Einsehen des Audit-Logs sind die Berechtigungen `audit-logs` zum Lesen und Auflisten erforderlich. Die Rollen Reader, Compliance Officer, Developer, Admin und Owner verfügen alle über diese Berechtigungen. Eine [benutzerdefinierte Rolle](https://docs.didit.me/de/console/roles-permissions.md) erhält sie, indem Sie im Rollen-Editor **Audit logs** auswählen.

***

## Typische Anwendungsfälle

> [accordion] Compliance-Prüfung
>
> Weisen Sie Prüfern nach, dass Sie vollständige Transparenz darüber haben, wer auf Verifizierungsdaten zugegriffen hat:
>
> 1. Filtern Sie nach dem Zeitraum, der dem Prüfzeitraum entspricht
> 2. Filtern Sie bei Bedarf nach bestimmten Anwendungen oder Benutzern
> 3. Exportieren Sie die Ergebnisse oder erstellen Sie Screenshots zur Dokumentation

> [accordion] Sicherheitsuntersuchung
>
> Wenn Sie einen unbefugten Zugriff vermuten:
>
> 1. Suchen Sie nach der E-Mail-Adresse des betroffenen Benutzers oder nach verdächtigen IP-Adressen
> 2. Filtern Sie nach einem Zeitraum rund um den vermuteten Vorfall
> 3. Achten Sie auf ungewöhnliche Muster: fehlgeschlagene Authentifizierungsversuche, unerwartete Endpoints, ungewöhnliche Uhrzeiten

> [accordion] Fehlersuche bei der Integration
>
> Bei der Behebung von Problemen mit der API-Integration:
>
> 1. Suchen Sie nach dem jeweiligen Endpoint-Pfad
> 2. Filtern Sie nach den Statuscodes `4xx` oder `5xx`, um Fehler zu finden
> 3. Notieren Sie die Zeitstempel, um sie mit Ihren Anwendungs-Logs abzugleichen

> [accordion] Überprüfung der Teamaktivitäten
>
> Überwachen Sie, wie Ihr Team die Plattform nutzt:
>
> 1. Filtern Sie nach den E-Mail-Adressen einzelner Teammitglieder
> 2. Prüfen Sie, auf welche Sitzungen und Funktionen sie zugegriffen haben
> 3. Stellen Sie sicher, dass Teammitglieder die vorgesehenen Verfahren einhalten

***

## Bewährte Methoden

1. **Regelmäßige Prüfungen**: Prüfen Sie Audit-Logs in regelmäßigen Abständen, um Auffälligkeiten frühzeitig zu erkennen.
2. **Suche eingrenzen**: Verwenden Sie gezielte Filter, um die Menge der Einträge zu verringern und relevante Einträge schneller zu finden.
3. **Zeiträume**: Geben Sie bei großen Datenmengen immer einen Zeitraum an, damit die Suche schneller abgeschlossen wird.
4. **Suchen als Lesezeichen speichern**: Speichern Sie häufig verwendete Filterkombinationen als Lesezeichen im Browser, um schnell darauf zuzugreifen.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.