Aktivitätsprüfungsprotokolle

(Abschnitt: Operationen und Management)

1) Zweck und Grundsätze

Das Prüfprotokoll ist die primäre Quelle der Wahrheit darüber, wer, was, wo, wann und warum es getan hat, mit der Fähigkeit, die Unveränderlichkeit und Authentizität der Aufzeichnungen zu beweisen.

• Vollständigkeit: Handlungen von Personen, Diensten und externen Partnern werden abgedeckt.
• Unveränderlichkeit: Einträge können nicht ohne sichtbare Spur umgeschrieben/gelöscht werden.
• Attribution: Die Aktion bezieht sich auf das Subjekt, die Rolle, den Kontext und die Artefakte.
• Reproduzierbarkeit: Ein Ereignis kann in einem Bericht/Argument reproduziert werden.
• PII-Minimierung: nur notwendig, mit Maske und Token.

2) Abdeckungsbereiche

Benutzeraktionen: Login/SSO/MFA, Rollen/Limits ändern, Operationen mit PII.
Privilegierte Operationen: JIT/PAM-Sitzungen, Break-Glass, Admin-Konsole.
Finanzen: Preislisten/Steuern/FX Veröffentlichungen, Zahlungen/Auszahlungen, Treuhandservice, Abschreibungen/Erstattungen.
Konfigurationen/Releases: Ficheflags, Schemamigrationen, Deploy/Rollback, Schlüssel/Zertifikate.
Integrationen: Webhooks, Signaturen, Quittungen, Idempotency-Schlüssel.
Daten: PII lesen/exportieren, Artefakte erstellen/löschen, Richtlinien ändern.

3) Architektur und Unveränderlichkeit

Ingest-Gateway mit Authentifizierung, Quoten und Schema-Validierung.
WORM-Speicher (immutable buckets/append-only): Version, Retention Lock, Legal Hold.
Kryptoquitationen: Für kritische Ereignisse wird eine' receipt _ hash 'und eine DSSE-Signatur gebildet.
Merkle-Ketten: In regelmäßigen Abständen werden Slices (Checkpoint) erstellt, der Root-Hash wird veröffentlicht.
Chain of custody: Verfolgen Sie die Bewegung von Artefakten (wer wann auf welche Grundlage zugegriffen hat).
Time Sync: NTP/PTP, Beschriftungen 'event _ time' und 'ingest _ time', Anpassung 'skew'.

4) Ereignisschema (Referenz)

audit_event {
id, event_time, ingest_time, producer, subject {
id, type: human    service    partner, roles[], mfa?, device_posture?
},
action: CREATE    READ    UPDATE    DELETE    EXECUTE    PUBLISH    APPROVE    ROLLBACK,
target { type, id, version?, region?, tenant? },
context { ip/asn, user_agent, env, trace_id, request_id },
policy_version, sod_check: pass    fail, justification?, ticket_ref?,
result: success    deny    error, error_code?,
diff_hash?, payload_hash?, receipt_hash?, dsee_signature?,
pii_classification: none    aggregated    tokenized    sensitive,
retention_class, labels[]
}

Optional: für Finanzen - 'fx _ version/tax _ rule _ version/pricelist _ version'; für Webhooks „webhook _ id“, „idempotency _ key“.

5) Daten- und Zonenmodell

Hot (operativ): 7-30 Tage, schnelle Anfragen/Dashboards.
Warm (OLAP): 6-24 Monate, Analytik/Suche.
Kalt (Archiv/WORM): bis zu 7-10 Jahre (regulatorisch).
Retentionsklassen: „operational“, „financial“, „security“, „legal _ hold“.
Richtlinienversion: Alle Ereignisse sind mit 'policy _ version' gekennzeichnet; Richtlinienänderung - Ein separates Audit-Ereignis.

6) Zugänge und Privatsphäre

RBAC/ABAC/ReBAC: Sichtbarkeit nach Rolle/Tenant/Region/Fall (Fall).
PII-Maskierung: Tokenisierung der Identitäten, Ausgabe des Primus - nur durch genehmigte Jobs.
Verbot der direkten Löschung: nur 'tombstone' + Legal Hold; „Nachreinigung“ mit separater Zeitschrift.
Audit des Audits selbst: Wer die Protokolle angesehen/hochgeladen hat, wird ebenfalls protokolliert.

7) Qualität, Konsistenz, Doppel

Datenkontrakte: striktes Schema und Lambda-Validierung am Eingang.
Idempotency & dedup: „(event_id, Produzent)“; «seen-cache» + KV.
Zeitkorrektur: Wasserzeichen für späte Ereignisse.
Vollständigkeitskontrolle: Vergleich der Quellenzähler und ingest-Metriken.

8) Dashboards und Anfragen

Operativ: privilegierte Maßnahmen, SoD-Verstöße, JIT-Rechte, Zugang zur PII.
Finanziell: Veröffentlichungen von FX/Tax/PriceList, quote↔checkout Divergenzen, Schlüsselunterschriften.
Integrationen: Quittungen von Webhooks, Lag, Retrays, Takes.
Releases/Configs: Wer/wann/was aktiviert/zurückgesetzt wurde, Verbindung zu Vorfällen.
Suchszenarien: 'trace _ id', 'subject. id`, `target. id', Zeit/Region/Tenant, 'policy _ version'.
Export: Paketentladungen auf Anfrage mit Quittung (unterschriebenes Manifest).

9) API und Webhooks

„POST/audit/ingest“ - Empfang von Ereignissen (Authentifizierung, Limits, Schema).
'GET/audit/search' - Filter, Paginierung, Grenze für das Ergebnis.
'GET/audit/trace/{ trace _ id}' ist ein Bündel von Ereignissen entlang der Kette.
„POST/audit/receipt/verify“ - Überprüfung der Quittung/DSSE.
Вебхуки: `SoDViolation`, `PrivilegedSession`, `PIIAccess`, `PolicyChanged`, `FinancialArtifactPublished`.

10) SLO/Auditqualitätsmetriken

Ingest Availability: ≥ 99. 95%.
Freshness (Operation): Lag ≤ 30 mit p95.
Completeness: ≥ 99. 5% der Quellen haben Daten an das Fenster gesendet.
Correctness: Abweichung der Prüfsummen ≤ 0. 1%.
Tamper-evidence: 100% der Perioden sind mit Merkle-Wurzeln/Unterschriften beglaubigt.
PII Hygiene: 100% Veranstaltungen mit sensibler Klasse - mit Maske/Token.

11) Playbooks und Vorfälle

Verdacht auf Datensatzwechsel: sofortige Überprüfung der Merkle-Wurzeln, Abgleich der DSSE-Belege, Zugangsisolierung, Legal Hold.
PII-Leak: Suche nach betroffenen Ereignissen/Exporten, Zugriffsprüfungen, Benachrichtigung des DSB/der Regulierungsbehörde über Fristen.
Verletzung des SoD: Block der Operation, vorübergehende Entfernung der Rolle, Untersuchung und Anpassung der Politik.
Ingest-Fehler: Pufferung, Degradationsmodus, Replikate nach Wiederherstellung, Kontrolle von Duplikaten.

12) Rechtlicher Auszug und Compliance

Retention nach Jurisdiktionen: Finanzen/Steuern - 5-10 Jahre; Sicherheit in der Politik; Personenbezogene Daten - die erforderliche Mindestdauer.
Legal Hold: Einfrieren der Löschung auf Anfrage der Regulierungsbehörde.
Gemeldete Artefakte: Periodenindex, Root-Hashes, Liste der Unterzeichner, Quelleninventar.
Nicht nachweisbar: Krypto-Signaturen, unabhängiges Timestamping (interne TSA).

13) Besonderheiten von iGaming/Fintech

Zahlungen/Auszahlungen: vollständige Verfolgung von Genehmigungen, Clearing, Ablehnungen, Chargeback; Abgleich mit Bankbelegen.
RTP/Limits: Profilveröffentlichungen, Änderungen, beobachtete RTP und Limitentscheidungen - mit Signaturen und Version.
Affiliates: Annahme von Webhooks, Dedup-Conversions, Einwänden/Treuhand - nur für signierte Artefakte.
Preislisten/Steuern/FX: Version des Artefakts in jeder Bestellung; Rollbacks - mit Quittungen.

14) RACI

15) Risiken und Anti-Muster

Bearbeitbare Protokolle ohne Spuren → eine rechtliche Nichtinterpretation.
Fehlende Zeitsynchronisation → Zeitlimits.
Shadow-Exporte ohne Quittungen → Lecks/Streitigkeiten.
Die Geheimnisse in den Protokollen → kompromittiert.
Es gibt keine Verbindung zu SLOs/Vorfällen → „Datenfriedhof“ ohne Nutzen.

16) Checkliste Umsetzung

• Bestimmen Sie die Bereiche der Abdeckung und policy_version.
• Bereitstellen von ingest mit Authentifizierung, Schemas und Kontingenten.
• WORM, Merkle-Slices, DSSE-Signaturen, TSA einschließen.
• Konfigurieren Sie Retentionen nach Klasse und Legal Hold.
• RBAC/ABAC/ReBAC und Protokollzugriffsprüfung einführen.
• Aufbau von Dashboards: Privilegien, PII, Finanzen, Releases/Configs.
• Aktivieren Sie die Playbooks: Tamper, PII-Leck, Ingest-Fehler, SoD-Verletzung.
• Testen Sie Replika und Dedup auf dem Testkit.
• Export mit Quittungen und Anforderungsregister einrichten.
• Vierteljährliches Audit der Qualitätsmetriken (freshness/completeness/tamper).

17) FAQ

Kann ich alles in einer normalen DB speichern?
Für die operative - ja, aber kritische Zeitschriften müssen in WORM/append-only mit Signaturen und Merkle-Slices dupliziert werden.

Muss ich jedes Mal, wenn ich Daten lese, protokollieren?
Lesen PII/Finanzen - erforderlich; Der Rest ist Politik und Kosten.

Wie beweist man Unveränderlichkeit?
Root-Hashes, DSSE-Signaturen, unabhängige TSA und reproduzierbare Überprüfungsverfahren.

Was tun mit dem „Recht auf Löschung“ (DSGVO)?
Entfernen Sie die Primzahl in Verarbeitungssystemen; in Audit-Logs - Speichern Sie Token/Hashes ohne wiederherstellbare PII und führen Sie bei Bedarf Legal Hold.

Zusammenfassung: Audit-Protokolle sind keine „Protokolle in S3“, sondern eine kryptografisch nachweisbare Aktivitätshistorie mit klarer Richtlinie, unveränderlicher Speicherung, kontrolliertem Zugriff und Streitbereitschaft/regulatorischer Überprüfung. Bauen Sie ingest auf Verträgen, unterschreiben Sie kritische Ereignisse, pflegen Sie Merkle-Slices und Dashboards - und Sie haben eine solide Grundlage für Vertrauen, Sicherheit und Compliance.