Prüfprotokolle und Zugangsspuren

1) Zweck und Anwendungsbereich

Zweck: Sicherstellung der Nachweisbarkeit der Handlungen der Nutzer/Dienste, Transparenz der Untersuchungen, Einhaltung der Anforderungen der Regulierungsbehörden und interner Standards (GDPR/AML, Verträge mit PSP/KYC-Anbietern, ISO/PCI, sofern anwendbar).
Abdeckung: alle Prod-Systeme, Plattform-Services (Konto, Zahlungen, Betrugsbekämpfung, CUS/Sanktionen, RG), Admin-Panels, API-Gateways, DWH/BI, Infrastruktur (K8s/Cloud), Vendor-Integrationen.

2) Was zu protokollieren ist (Ereignisklassen)

1. Identifikation und Zugang: Login/Logout, MFA, Passwort-/Schlüsselwechsel, SSO, „break-glass“ Zugang.
2. Administrative Aktionen: Änderungen an Rollen/Rechten, Konfigurationen, Anti-Fraud/Sanktionsregeln, Ficha-Flags.
3. Operationen mit PII/Daten: Lesen/Exportieren/Löschen, Hochladen, KYC-Zugriff, Anzeigen von VIP-Profilen.
4. Transaktionen und Geld: Cash Outs/Einzahlungen, Stornierungen, Rückerstattungen, Chargeback-Entscheidungen.
5. Compliance/AML/KYC: Screening-Ergebnisse (Sanktionen/PEP/Adverse Media), Entscheidungen (TP/FP), EDD/STR/SAR.
6. Vorfälle und Sicherheit: Eskalationen, Änderungen der WAF/IDS-Regeln, Isolation von Diensten, Rotation von Geheimnissen.
7. Integrationen/Anbieter: API-Aufrufe, Fehler, Timeouts, Exporte, Lösch-/Rückgabebestätigungen.

3) Pflichtfelder der Veranstaltung (Minimum)

`event_id` (UUID), `ts_utc`, `ts_local`, `source_service`, `trace_id`/`span_id`

'actor _ type' (user/service/vendor), 'actor _ id' (persistent identifier), 'actor _ org' (falls B2B)

`subject_type` (account/tx/document/dataset), `subject_id`

`action` (e. g., `READ_PII`, `EXPORT_DATA`, `ROLE_UPDATE`, `WITHDRAWAL_APPROVE`)

`result` (success/deny/error) и `reason`/`error_code`

"ip", "device _ fingerprint'," geo "(Land/Region)," auth _ context "(MFA/SSO)

'fields _ accessed '/' scope' (beim Arbeiten mit PII/Findans) - maskiert

'purpose '/' ticket _ id' (Basis: DSAR, Incident, Regulation Request, Operating Task)

4) Unveränderlichkeit und Nachweisbarkeit

WORM-Speicher für die „goldene“ Kopie (immutable buckets/retention policies).
Crypto Subscription/Hash Chain: Periodische Signierung von Ereignispaketen und/oder Aufbau einer Hash Chain (Hash Chaining) zur Identifizierung von Modifikationen.
Schema/Regeländerungsprotokoll: Wir versionieren Schemas und Protokollierungsrichtlinien; alle Bearbeitungen werden von CAB durchgeführt.
Zweikreisspeicherung: operativer Index (Suche) + Archiv/immutability.

5) Zeitsynchronisation und Ablaufverfolgung

Ein einziges NTP/Chrony in allen Umgebungen; in logs - 'ts _ utc' als Quelle der Wahrheit.
In jedem Log steht 'trace _ id '/' span _ id' für die End-to-End-Abfrageverfolgung (Korrelation zwischen Diensten, Anbietern und Front).

6) Privatsphäre und Geheimnisse

Verboten: Passwörter, Token, vollständige PAN/CSC, vollständige Dokumentnummern, „rohe“ Biometrie.
Standard-Maskierung: E-Mail/Telefon/IBAN/PAN → Token/Teilanzeige.
Pseudonymisierung: „user _ id“ → stabiles Token in der Analytik; an eine reale ID binden - nur in einer geschützten Schleife.
DSAR-Kompatibilität: Möglichkeit, Protokolle selektiv nach Subjekt zu extrahieren, ohne fremde PIIs offenzulegen.

7) Aufbewahrungsfristen und Niveaus (retention)

8) Zugang und Kontrolle (RBAC/ABAC)

Die Leserollen der Prüfungsprotokolle sind von den Administratorrollen getrennt.
MFA und Just-in-Time-Zugang (break-glass) mit Auto-Response/Ursachenprotokollierung.
„Minimum“ -Politik: Zugang zu PII/Findatenfeldern nur bei Bedarf und mit der Angabe „Zweck“.
Export/Upload: weiße Listen von Zielen und Formaten; obligatorische Signatur/Hash, Upload-Protokoll.

9) Integration mit SIEM/SOAR/ETL

Der Audit-Event-Stream geht an den SIEM für Korrelationen (e. g., Masse' READ _ PII'+ Eingabe vom neuen Gerät).
SOAR-Playbooks: Auto-Tickets bei Verletzung von Richtlinien (kein „Purpose“, anomales Volumen, Zugriff außerhalb des Fensters).
ETL/DWH: Vitrinen 'audit _ access', 'pii _ exports', 'admin _ changes' mit Qualitätskontrolle und Versionierung der Schaltungen.

10) Datenqualität und Validatoren

Schemata als Code (JSON/Protobuf/Avro): Pflichtfelder, Typen, Wörterbücher; CI-Validatoren.
Ablehnung und Quarantine-Queue für Ereignisse mit Schemafehlern; Die Metriken der Ehe.
Deduplizierung/Idempotenz nach'(event_id, trace_id, ts)'; Nachsendekontrolle.

11) RACI

12) SOP: Untersuchung des Datenzugriffs

1. Auslöser: SIEM alert (anomal 'READ _ PII '/Export), Reklamation, Signal vom Anbieter.
2. Sammlung von Artefakten: Upload von Ereignissen durch 'actor _ id '/' subject _ id '/' trace _ id', 'purpose' -Protokoll, zugehörige Protokolle (WAF/IdP).
3. Rechtmäßigkeitsprüfung: Vorliegen einer Grundlage (DSAR/Incident/Service Task), Genehmigungen, Zugriffsfenster.
4. Folgenabschätzung: Umfang/Kategorien der PII, Zuständigkeiten, Risiken für die Akteure.
5. Lösung: Incident Bridge (bei High/Critical), Containment (Rückruf von Zugriffen, Schlüsselrotation).
6. Bericht und CAPA: Ursachen, verletzte Richtlinien, Maßnahmen (Maskierung, Schulung, RBAC-Änderungen), Fristen.

13) SOP: Datenexport (Regulator/Partner/DSAR)

1. Anfrage → Überprüfung der Grundlage und Identität (für DSAR) → Erstellung einer Anfrage an die DWH.
2. Standard-Anonymisierung/Minimierung; Einbeziehung von PII nur auf einer Rechtsgrundlage.
3. Upload-Generierung (CSV/JSON/Parket) → Signatur/Hash → Eintrag im Upload-Log (wer/wann/was/an/Basis).
4. Übertragung über einen genehmigten Kanal (sFTP/Secure Link); Aufbewahrungsfrist der Kopie - gemäß der Richtlinie.
5. Nachkontrolle: Empfangsbestätigung, Löschen temporärer Dateien.

14) Metriken und KRIs/KPIs

Coverage: Der Anteil der kritischen Systeme, die Audit-Ereignisse senden, ≥ 95%.
DQ-Fehler: Vom Validator abgelehnte Ereignisse ≤ 0. 5% des Stroms.
MTTD Strömungsverlust: ≤ 15 min (alert bei Stille).
Abnormale Zugriffe ohne' purpose': = 0 (KRI).

Reaktionszeit: Median ≤ 4 Stunden, P95 ≤ 24 Stunden

Exporte mit Signatur/Hashes: 100%.
Einhaltung der Retention: Löschung/Archivierung innerhalb ≥ 99%.

15) Anforderungen an Anbieter und Unterauftragsverarbeiter

DPA/SLA: Beschreibung der Audit-Protokolle (Schemata, Zeitrahmen, Geografie, Exportformat), WORM/immutability, SLA der Meldung von Vorfällen.
Lieferantenzugriff: benannte Servicekonten, Protokolle ihrer Aktivitäten, die Möglichkeit eines selektiven Audits.
Offboarding: Schlüsselrückruf, Export/Löschung von Protokollen, Schließungsakt, Bestätigung der Zerstörung von Backups.

16) Sicherheit und Manipulationsschutz

Rollenaufteilung: Quelladmin ≠ Speicheradmin ≠ Auditor.
Signatur der Agenten/Sammler, mTLS zwischen den Komponenten.
Anti-Tamper-Kontrollen: Hash-Vergleich, regelmäßige Integritätsprüfungen, Warnungen vor Abweichungen.
Geo-Replikation von WORM-Kopien und regelmäßige Wiederherstellungstests.

17) Typische Fehler und Anti-Muster

Protokollierung empfindlicher Werte (PAN/Secrets) → sofortige Aktivierung von Redaction-Middleware.
Keine' purpose '/' ticket _ id 'beim Zugriff auf die PII.
Lokale Uploads „auf den Desktop“ und Weiterleitung per E-Mail.
Das Fehlen eines einzigen Schemas und der Validierung → „stumme“ Felder, die Unmöglichkeit der Korrelation.
Ein einziges Super-Konto ohne Bindung an eine Person oder einen Dienst.

18) Checklisten

18. 1 Launch/Revue der Politik

• Genehmigte Schemata und Wörterbücher; Pflichtfelder enthalten
• Masken- und Geheimhaltungsverbote inklusive
• NTP konfiguriert, 'trace _ id' überall
• Hot/Warm/Cold/WORM Schichten gestartet
• RBAC/ABAC und break-glass dekoriert
• SIEM/SOAR integriert, Alerts getestet

18. 2 Monatliche Prüfung

• Stichprobe der Ausfuhren: Die Unterschriften/Protokolle sind korrekt
• Retention/Löschprüfung/Legal Hold
• DQ-Metriken sind normal, Quarantine-Analyse
• Vendor Logs verfügbar/vollständig

19) Umsetzungsfahrplan

Wochen 1-2: Inventarisierung von Systemen, Abstimmung von Schemata und Pflichtfeldern, Zeit- und Ablaufverfolgungseinstellungen.
Wochen 3-4: Aktivieren der Maskierung, WORM-Schicht, Integration mit SIEM/SOAR, Starten von Exportprotokollen.
Monat 2: Validatoren/Alert-Automatisierung, investigative Playbooks, Teamschulung.
Monat 3 +: regelmäßige Audits, Integritäts-Stresstests, Wertoptimierung (Tiering), Lieferanten-/Vertragsrevision.

TL; DR

Starke Prüfungsprotokolle = vollständige und strukturierte Ereignisse + Immutability (WORM) und Signaturen + PII Masking + Hard Access und Upload Log + SIEM/SOAR Integration. Das beschleunigt Untersuchungen, reduziert Risiken und macht Compliance nachweisbar.