Die Integrität eines kontinuierlichen Log-Streams zertifizieren, eine entscheidende Sicherheitsherausforderung

Warum die Integrität eines Log-Journals beweisen?

1. Die Integrationskomplexität auf Applikationsseite,
2. Die Kosten entstanden durch die Speicherung und die digitale Signatur,
3. Der operationelle Aufwand im Zusammenhang mit der Verwaltung und Überprüfung sicherer Logs.

• eine naive Implementierung basierend auf einer blockchain (was eine einfache und effiziente Lösung ist, aber keine Log-Rotation ermöglicht),
• eine effizientere und pragmatischere Version, aufgebaut um die Merkle Trees*.

type LogEntry struct {
	Message   string    `json:"message"`
	Timestamp time.Time `json:"timestamp"`
}

Naive Implementierung: eine Blockchain

Merkle-Baum: eine flexiblere Alternative

• der Hash des Blattes (das Log selbst),
• die geordnete Liste der Geschwister-Hashes, die beim Aufstieg zur Wurzel angetroffen werden, sowie ihre Links-/Rechts-Position.

• Es ist nicht mehr nötig, die gesamte Ereignissequenz erneut abzuspielen, um ein Log zu überprüfen, genügt ein Zugehörigkeitsbeweis, der nur aus den lateralen Hashes besteht.
• Jeder Unterbaum kann unabhängig berechnet werden, dies ermöglicht die Verteilung der Berechnung auf mehrere Maschinen (oder Threads), was den einer Hash-Kette inhärenten Engpass beseitigt (wo jeder Block vom vorhergehenden abhängt).
• Ein vollständiger Unterbaum kann abgeschnitten oder archiviert werden, ohne die Gültigkeit des Rests zu beeinträchtigen: Man trennt die Verbindung zum veralteten Teil, berechnet die Hashes bis zum Schnittknoten neu und betrachtet diesen Knoten als neue Wurzel für das aktuelle Fenster. Es ist nicht nötig, alle beibehaltenen Blätter zu löschen oder neu abzuspielen.
• Jeder Service oder jede VM kann parallel seinen eigenen Baum erstellen und seine Wurzel veröffentlichen, diese Wurzeln können dann in einem Baum von Wurzeln kombiniert werden, was das Modell horizontal perfekt skalierbar macht.

Proof of Concept

• Die Wurzel im Streaming über einen StreamBuilder, mit O(log n) Speicher (es gibt also keinen vollständigen Baum im RAM).
• Inklusionsbeweise generieren und überprüfen mit einem expliziten Baum, serialisierbar in SQLite für Audit und Wiederherstellung.
• Die Äquivalenz Stream <=> Baum validieren, auch unter Konkurrenzbedingungen, mittels deterministischer Tests und Fuzzing.
• Die Wurzeln (und Signaturen) regelmässig in unveränderlichem Speicher vom Typ S3 Object Lock / Äquivalent veröffentlichen, um Checkpoints zu datieren und zu sperren.

const (
  leafPrefix     byte = 0x00
  internalPrefix byte = 0x01
)

func LeafDigest(e LogEntry) [32]byte {
  m := e.Serialize()
  b := make([]byte, 1+len(m))
  b[0] = leafPrefix
  copy(b[1:], m)
  return sha256.Sum256(b)
}

func CombineDigests(l, r [32]byte) [32]byte {
  var buf [1 + 32 + 32]byte
  buf[0] = internalPrefix
  copy(buf[1:33], l[:])
  copy(buf[33:], r[:])
  return sha256.Sum256(buf[:])
}

Expliziter Baum und Beweise

• Node trägt entweder ein Blatt (Data), oder Zeiger Left/Right und einen zwischengespeicherten Hash.
• BuildMerkleRoot faltet jede Ebene bis zur Wurzel.
• GenerateProof steigt vom Blatt zur Wurzel auf, indem es die Geschwister-Hashes und deren Links-/Rechts-Position sammelt.
• VerifyProof geht den Weg erneut und vergleicht ihn mit der erwarteten Wurzel.

type ProofStep struct{ Hash [32]byte; Right bool }

func VerifyProof(leaf LogEntry, proof []ProofStep, root [32]byte) bool {
  h := LeafDigest(leaf)
  for _, s := range proof {
    if s.Right { h = CombineDigests(h, s.Hash) } else { h = CombineDigests(s.Hash, h) }
  }
  return h == root
}

Streaming in O(log n)

type StreamBuilder struct {
  mu sync.Mutex
  levels []levelDigest
  entryCount int
}

func (s *StreamBuilder) AddEntry(e LogEntry) {
  d := LeafDigest(e)
  s.mu.Lock()
  s.foldDigestLocked(0, d)
  s.entryCount++
  s.mu.Unlock()
}

func (s *StreamBuilder) Root() ([32]byte, bool) {
  s.mu.Lock(); defer s.mu.Unlock()
  var out [32]byte; var ok bool
  for _, slot := range s.levels {
    if !slot.filled { continue }
    if !ok { out, ok = slot.hash, true; continue }
    out = CombineDigests(slot.hash, out)
  }
  return out, ok
}

Persistenz und Audit

• den Baum wieder abzuspielen / Beweise lokal zu überprüfen
• die Originalblätter für ein N-Tages-Fenster rückwirkend zu exportieren
• die Struktur durch Sortieren nach Level / Position zu inspizieren.

Tests, Robustheit und Fuzzing

Hash- und Ordnungsinvarianten

• Effektive Domänentrennung: Ein Blatt-Hash darf niemals einem internen Hash mit demselben Payload gleichen (Präfixe 0x00 / 0x01).
• Nicht-Kommutativität: Das Vertauschen von Links/Rechts muss einen anderen Digest ergeben, was ein Neuanordnen der Kinder ohne Warnung verhindert.
• Stabilität: Bei identischer Eingabe ist der Digest stabil (kein versteckter Zustand noch eine Zufallsquelle).

Baum, Beweise und Negative

Gleichzeitigkeit

Fuzzing

Checkpointing und unveränderliche Verankerung für die Compliance

Warum Checkpoints verankern?

• man berechnet einen Root für einen bestimmten Zeitraum (z.B. ein Tag)
• man veröffentlicht ihn in einem unveränderlichen Speicher
• er wird nie wieder geändert

Wie oft soll der Root veröffentlicht werden?

• Häufiger veröffentlichen (z.B. stündlich oder alle 10k Einträge). Die Kosten sind vernachlässigbar, da ein Checkpoint nur ein Hash + Signatur ist.
• Einen fortlaufend generierten «Arbeits»-Root beibehalten (der StreamBuilder jederzeit den Root liefern kann) und ihn im Object Store verankern, sobald ein Audit angefordert wird. Dieser sofortige Root wird dann zum Referenzpunkt für diesen Log.

S3 Object Lock: auf Speicherebene garantierte Unveränderbarkeit

• Das Objekt kann weder geändert noch gelöscht werden, solange der Aufbewahrungszeitraum nicht abgelaufen ist (Write Once Read Many)
• Jeder Ersetzungsversuch erstellt eine neue Version; man kann auch einen legal hold anwenden, um die administrative Löschung zu blockieren.

aws s3api put-object \
  --bucket merkle-checkpoints \
  --key roots/2025-10-01.json \
  --object-lock-mode COMPLIANCE \
  --object-lock-retain-until-date 2025-12-31T00:00:00Z \
  --body checkpoint.json

Alternativen bei anderen Anbietern

• Azure Blob Storage : bietet immutable blob policies und legal holds, mit ähnlichen Mechanismen (Aufbewahrungsdauer oder rechtlicher Sperre).
• Google Cloud Storage : bietet die Object Retention Policies und Bucket Lock, die Objekte für vordefinierte Zeiträume sperren.
• MinIO : im Self-Hosting, implementiert auch Object Lock, kompatibel mit der S3 API (zuverlässig unter der Bedingung einer Zero-Trust-Infrastruktur).

Warum dieser Ansatz ideal ist

1. Sie erfüllt direkt die Aufbewahrungsanforderungen von Normen wie NF525, PCI-DSS oder HDS : der Checkpoint befindet sich im Write Once, Read Many (WORM)-Modus. Wenn Roh-Logs anderswo gelöscht würden, würde der Inklusionsbeweis fehlschlagen, wodurch die Löschung erkennbar wird; zur Prävention werden die Logs auch in einem Bucket mit Aufbewahrung/Object Lock gespeichert.
2. Jeder Checkpoint ist ein Objekt von wenigen Bytes, das nur einmal gespeichert wird, weshalb die Kosten im Vergleich zum Volumen der Logs selbst vernachlässigbar sind.
3. Eine Wurzel pro Tag / Woche genügt; sie können repliziert und signiert werden, um die Nachvollziehbarkeit zu verstärken.

Kostenoptimierung und operationelles Design

Speicherung

• die Roh-Logs können komprimiert und in einem S3 Glacier bis zum Ende ihrer Aufbewahrungsfrist
• die Checkpoints werden dauerhaft zu geringeren Kosten gespeichert

Compute

Fazit