Audit und unveränderliche Protokolle

Audit und unveränderliche Protokolle

1) Warum es notwendig ist

Ziel des Audits ist es, das „Wer, Was, Wo, Wann und Warum“ mit nachweisbarer Integrität zu erfassen, um Sicherheit, Untersuchungen, Finanzberichterstattung und Compliance aufrechtzuerhalten.
Ein unveränderliches Protokoll ist ein Format und ein Speicher, bei dem Ereignisse nur durch Hinzufügen (append-only) aufgezeichnet werden und eine anschließende Änderung/Löschung entweder nicht möglich oder durch kryptografische Mittel und Speicherrichtlinien erkennbar ist.

2) Bedrohungsmodell und Kontrollziele

• Vorsätzliche Bearbeitung/Löschung von Ereignissen durch einen Insider.
• Austausch von Zeit/Quelle (replay/backdating).
• Ruhiges Ausschalten der Protokollierung am Knoten.
• Verlust eines Teils des Logbuchs bei Unfällen/Migrationen.
• Übermäßige PII-Gebühr und Diskrepanz mit der Privatsphäre.

1. Integrität: nachweisbar durch Schutz vor Änderungen/Löschungen.

2. Vollständigkeit: Schließung der Schlüsselströme (Kontrollebene, Datenebene, Zugänge, Geld).

3. Zeitgenauigkeit: reproduzierbare, synchronisierte Zeit.

4. Verfügbarkeit: Lesen und Suchen innerhalb des SLO.

5. Datenschutz: Minimum PII, Tokenisierung/Verschlüsselung, Rechtmäßigkeit der Nutzung.

3) Taxonomie und Ereignisprioritäten

• Steuerebene: Authentifizierung/Autorisierung, Konfigurationsänderungen, Schlüsseloperationen (KMS), Verwaltung von Geheimnissen, Änderung von Richtlinien.
• Datenebene: Zugriff auf Objekte/Aufzeichnungen/Schecks/Zahlungen; Lesen/Erstellen/Löschen.
• Admin und DevOps: SSH/Konsole, CI/CD, Infrastrukturänderungen/IaC, Rechte eskalieren.
• Produkt: Transaktionen, Abrechnung, Kundentransaktionen.
• System/Netzwerk: Kernel/Agenten/Proxy/Balancer, Broker, DB.
• Sicherheit: IDS/IPS/EDR, WAF, Anti-DDoS, Anti-Fraud, DLP.

Für jede Klasse erfassen wir: Kritikalität, Schema, Pflichtfelder, Haltbarkeit, Anforderungen an die Unveränderlichkeit.

4) Pflichtfelder und Format

Korrelations-IDs: 'trace _ id', 'span _ id', 'request _ id', 'actor _ id' (Benutzer/Dienst), 'tenant _ id', 'resource _ id'.
A & A-Kontext: Authentifizierungsmethode, Rollen/Richtlinien zum Zeitpunkt der Aktion.
Zeit: RFC3339/UTC, Millisekunden/Nanosekunden; Synchronisationsquelle.
Aktion und Ergebnis: Art der Operation, Ziel, Status, Anzahl der betroffenen Objekte.
Integrität: lokale HMAC-Einträge, Sequenznummer (Sequenz), Hash-Prev.
Schema: JSON mit stabilem Modell (z.B. kompatibel mit gängigen Event-Wörterbüchern).

Verboten: Geheimnisse, Schlüssel, Token, vollständige PANs, Passwörter, private Schlüssel. PII - nur bei Bedarf, mit Maskierung/Tokenisierung.

5) Zeit und Synchronisation

Zeitquelle: mindestens zwei unabhängige Quellen (NTP/PTP) + Offset-Überwachung.
Kritische Zeitsignaturen: Verwenden Sie TSA-Dienste (Trusted Time Stamp) oder einen internen Time-Sealing-Dienst für Ereignispakete.
Regeln: keine lokalen Zeitzonen, nur UTC; loggen und Zeitversatz/Qualität.

6) Logstream-Architektur

Agenten → Puffer → Transport → Landing → Hash-Kette/Signatur → Cold/Archiv → Index für die Suche.

Sammlung am Knoten: Light Agents (Daemonset/Sidecar) mit Puffer auf der Festplatte (Backpressure).
Transport: geschützter Kanal (TLS/mTLS), garantierte Lieferung (einmal), idempotent-ingest.
Landing Zone: Objektspeicher in „roher“ Form (Parties nach Datum/Tenant/Typ).
Index: Such-/Analyse-Engine für Online-Abfragen (Hot Layer).
Archiv (WORM): Unveränderliche Baquets/Tapes mit Retentionsrichtlinien und rechtlichen Holds.
Anchor/Seal: periodisches „Stopfen“ von Packungen von Hash-Ketten (siehe unten).

7) Kryptographische Unveränderlichkeit

7. 1 Hashketten (nur Append)

Jeder Datensatz enthält: 'hash _ curr = H (record)', 'hash _ prev' aus dem vorherigen Datensatz, 'seq'. Jede Bearbeitung bricht die Kette.

prev = GENESIS for record in stream:
payload = canonical_json(record_without_integrity_fields)
h = H(payload          prev.hash          record.seq)
store(record + {hash_prev: prev.hash, hash_curr: h})
prev = {hash: h}

7. 2 Unterschrift der Packungen und Zeitstempel

Alle N Sekunden/MB bilden wir einen Block: die Merkle-Wurzel aller 'hash _ curr'.
Wir signieren den Block mit einem Audit-Schlüssel (nachhaltig gespeichert im KMS/HSM).
Fügen Sie einen TSA-Zeitstempel hinzu und veröffentlichen Sie ein „Blockverzeichnis“ (Transparenzprotokoll).
Optional: periodisch verankern Sie den Wurzelhash in einen externen nachweisbaren Raum (z. B. eine unabhängige Zeitschrift oder einen öffentlichen unveränderlichen Speicher).

7. 3 Verwalten von Audit-Schlüsseln

Signaturschlüssel - in KMS/HSM, Rotation im Zeitplan, Multifaktor-Zugriff, Dual-Control für den Export.
Schlüsselrücknahme → neuer Vertrauenszweig; Alte Signaturen bleiben überprüfbar.

8) Aufbewahrungs- und WORM-Richtlinien

WORM/immutability: Beinhaltet unveränderliche Container/Tanks mit Retention und Legal Hold Richtlinien für P0/P1 Klassen.
Versionierung: enthalten; Entfernung - nur durch Verfahren mit Verzögerung (Verbot der sofortigen Purge).
Retention: heiß (7-30 Tage), warm (3-6 Monate), kalt/Archiv (1-7 Jahre oder mehr - abhängig von der Regulierungsbehörde/Vertrag).
mnogoarendnost: die abgesonderten Räume der Namen/utschetki/Schlüssel der Chiffrierung auf den Pächter; Berichterstattung über Protokollzugriffe.

9) Privatsphäre und Minimierung

Sammlung nach dem Prinzip der Notwendigkeit: Wir protokollieren nicht extra.
Tokenisierung/Pseudonymisierung empfindlicher Felder, Hash mit Salz für Kennungen.
AEAD-Verschlüsselung (Producer Side Field Encryption) bei Speicherung im gemeinsamen Objektspeicher.
Recht auf Löschung (falls zutreffend): wird durch Kryptolöschung von Feld-/Partienschlüsseln realisiert, ohne die Unveränderlichkeit des Containers zu beeinträchtigen (geplant während des Entwurfs).

10) Zugang, Rollen und Audit des Audits selbst

Producer ≠ Readers ≠ Admins

Nur Lesen aus WORM; Änderung der Retentionsrichtlinien - durch getrennte Rollen und ein Verfahren mit Genehmigung.
Alle Lese-/Exportvorgänge werden in einem Sekundärprotokoll protokolliert (Meta-Audit).
Export für Untersuchung/Compliance - verschlüsselt mit Hash-Block-Verzeichnis und Vertrauenskette.

11) Beobachtbarkeit und SLO

Metriken: Injection Rate, Lag to Index,% Lost/Repeat, Bruchteil der unsynchronisierten Zeit, Signatur-/Ankerfehler, Pufferfüllung.
SLO: ≥99. 9% der Ereignisse werden ≤ X Sekunden vor dem heißen Index geliefert; 0 unerklärliche „Löcher“ in Sequenzen; 100% der Blöcke sind signiert und zeitgestempelt.
Alertas: Injection-Pause> N Minuten, Invalid-Hash-Wachstum, Kettenabweichung, Signatur-/Zeitstampversagen, Zeitverschiebung über Schwelle hinaus.

12) Prüfung und Verifizierung

Rot/Blau-Tests: Versuch, einen Datensatz in verschiedenen Phasen zu bearbeiten/löschen; Überprüfung der Detektion.
Chaos: Deaktivierung des Agenten auf dem Knoten, Unterbrechung des Netzwerks, Pufferüberlauf, „Zeitaustausch“.
Krypto-Checks: regelmäßige Validierung von Ketten, Abgleich von Merkle-Wurzeln und Stempeln.
Forenzika: Wiedergabe von Untersuchungsszenarien aus End-to-End-Protokollen.

13) Betrieb und Verfahren

Runbook „Integritätsprüfung“ (On-Demand und Zeitplan).
Rechtliches Halteprozess und vorübergehendes „Einfrieren“ von Parteien.
Entdeckungs- und Exportverfahren unter Beibehaltung der Vertrauenskette.
Prüfschlüsselrotationsplan und Kompromittierungsreaktionen (neuer Vertrauenszweig, Blockrücksignatur, Benachrichtigungen).

14) Mini-Rezepte

records = read_partition(ts_window)
leaves = [H(canonical_json(r)) for r in records]
root  = merkle_root(leaves)
sig   = KMS.sign(root          ts_now)
tsa   = TSA.timestamp(sig)
store_block({root, sig, tsa, count=len(leaves), window})
append_transparency_log(H(root          sig          tsa))

for i in 1..N:
assert rec[i].hash_prev == rec[i-1].hash_curr assert rec[i].hash_curr == H(canonical_json(rec[i]_no_hash)          rec[i].hash_prev          rec[i].seq)

• Control/Data plane P0: heiß 30 Tage → warm 6 Monate → Archiv 7 Jahre (WORM).
• DevOps: heiß 14 Tage → warm 3 Monate → Archiv 1 Jahr.
• Securiti-Signale: heiße 90 Tage (für Untersuchungen), dann 1-3 Jahre.

15) Häufige Fehler

„Logs sind Text ohne Schema“. Ohne Schema gibt es keine deterministische Integrität und Suche; Canonical JSON und feste Felder sind obligatorisch.
Keine Korrelation. Das Fehlen von 'trace _ id' stört die Untersuchungen.
Lokale Zeit. Nur UTC und Offset-Steuerung.
Schreiben in betroffene Volumes. Ohne WORM ist jede Unveränderlichkeit eine Fiktion.
Sie protokollieren keine Lesungen. Das Lesen sensibler Daten ist ebenso wichtig wie das Aufzeichnen.
Geheimnisse in den Protokollen. Aktivieren Sie Desinfektionsmittel vor dem Senden, „rote Listen“ von Mustern.
Ein Schlüssel für alles. Signatur- und Verschlüsselungsschlüssel - getrennt, mit Rolle und Rotation.

16) Compliance und Regulierung

Die Aufbewahrungs-/Unveränderlichkeitsanforderungen hängen von der Domäne ab (Finanzen, Zahlung, Telekommunikation usw.).
Nachweisbarkeit: Verfügbarkeit von WORM/Retentionsprotokollen, Kettenvalidierungsberichten, Protokollzugriffsprotokollen, legalen Halte- und Exportverfahren.

17) Checklisten

Vor dem Verkauf

• Ereignistaxonomie und Schema genehmigt (Pflichtfelder).
• Agenten, Puffer, geschützter Transport, Rückdruck konfiguriert.
• Enthalten: Hashketten, Blocksignatur, Zeitstempel, Transparenzprotokoll.
• WORM/Retention Repository enthalten; Test auf Unmöglichkeit des Überschreibens/Löschens.
• Maskierung/Tokenisierung empfindlicher Felder.
• Zeitsynchronisation und Offset-Überwachung.
• Rotationsplan und Speicherung der Audit-Schlüssel im KMS/HSM.

Betrieb

• Wöchentliche Validierung von Schaltungen und Blöcken (+ Bericht).
• Alerty auf den Bruch der Kette/Fehlers der Unterschrift/Absetzung der Zeit.
• Regelmäßige Red-Team-Austausch-/Löschtests.
• Regelmäßige Überprüfung der Retentionen und Kosten.

18) FAQ

F: Reicht ein „Nur-Hinzufügen“ auf DB-Ebene aus?
Oh, nein. Wir brauchen kryptographische Garantien (Hashketten, Blocksignaturen, Zeitstempel) und WORM-Richtlinien.

F: Was ist mit dem Recht auf Datenlöschung?
A: Entwerfen Sie Krypto-Löschung (Schlüssellöschung) für Felder/Parteien, während Sie die Unveränderlichkeit des Mediums und die Nachweisbarkeit der Protokolle beibehalten.

F: Brauche ich einen separaten Schlüssel, um die Blöcke zu signieren?
A: Ja. Trennen Sie die Blocksignaturschlüssel von den Speicherverschlüsselungsschlüsseln; in KMS/HSM, mit Rotation und Audit speichern.

F: Kann man in den öffentlichen Raum „ankern“?
A: Optional. Dies erhöht die Überprüfbarkeit und schneidet das „Umschreiben der Geschichte“ innerhalb der Kontur ab.

• „At Rest Verschlüsselung“
• „Verschlüsselung im Transit“
• „Management von Geheimnissen“
• „Schlüsselmanagement und Rotation“
• „Signieren und Verifizieren von Anfragen“