Doku: Audit-Siegel (AUDIT_HMAC_KEY) verstaendlich erklaert

README und .env.example erklaeren jetzt zuerst in Alltagssprache, was das
Audit-Log ist, wogegen der Schluessel schuetzt und was passiert, wenn man ihn
weglaesst oder verliert - inklusive Bild vom Notarstempel. Die technische
Ebene bleibt vollstaendig erhalten, in der README als aufklappbarer Block
(Hash-Versionen 1/2/3, Version-Floor, Loeschungs-Manifest, Rueckgabefelder von
/verify, bekannte Grenze) und in .env.example als eigener Abschnitt.

Ausserdem dokumentiert: Schluesselwechsel ueber AUDIT_HMAC_KEY_OLD ohne
Rehash, pro Umgebung ein eigener Schluessel, und die Warnung zu den beiden
Endpunkten mit Nebenwirkung (rehash/cleanup).

AUDIT_HMAC_KEY zusaetzlich in die Production-Checkliste aufgenommen.

Korrigiert: Die Integritaetspruefung ist NICHT ueber die Oberflaeche
erreichbar (verifyIntegrity wird von keiner Komponente genutzt) - die Doku
zeigt jetzt den API-Aufruf. Rechte, Endpunkte und Rueckgabefelder gegen den
Code geprueft.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

backend/.env.example

@@ -20,20 +20,64 @@ ENCRYPTION_KEY="32-byte-hex-key-for-aes-256-gcm"
 PORT=3001
 NODE_ENV=development
 
-# ==================== AUDIT-ANKER ====================
-# Signiert Audit-Log-Eintraege per HMAC-SHA256 mit einem Schluessel, der NICHT
-# in der Datenbank liegt. Damit reicht ein reiner DB-Schreibzugriff nicht mehr
-# aus, um die Hash-Kette glaubwuerdig umzuschreiben (Pentest R166/R167).
+# ==================== AUDIT-SIEGEL ====================
+# Was ist das Audit-Log?
+#   OpenCRM protokolliert luekenlos, wer wann welche Daten gesehen oder
+#   geaendert hat. Das ist die Beweisspur, wenn es Streit gibt oder der
+#   Datenschutz nachfragt.
 #
-# Erzeugen:  openssl rand -hex 32
-# Fail-safe: Ohne Schluessel schreibt das Audit-Log weiter die unsignierte
-#            Version 2 - es faellt nichts aus, der Anker fehlt nur.
-# ACHTUNG:   Schluessel sichern. Geht er verloren, sind alle damit signierten
-#            Eintraege nicht mehr pruefbar (sie gelten dann als "nicht pruefbar",
-#            NICHT als manipuliert).
+# Wogegen schuetzt dieser Schluessel?
+#   Ohne ihn koennte jemand mit Zugriff auf die Datenbank einen Eintrag
+#   nachtraeglich umschreiben - zum Beispiel einen fehlgeschlagenen
+#   Login-Versuch in einen erfolgreichen verwandeln - und die Faelschung so
+#   glattziehen, dass die Pruefung sie fuer echt haelt.
+#   Mit dem Schluessel bekommt jeder Eintrag ein Siegel, das sich nur mit
+#   diesem Schluessel erzeugen laesst. Wer ihn nicht hat, kann nichts
+#   faelschen, ohne dass es auffliegt. Bildlich: Der Schluessel ist der
+#   Stempel des Notars - die Akte liegt zwar im Schrank, aber den Stempel
+#   hat nur der Notar.
+#
+# Wie einrichten?
+#   Einmalig einen Schluessel erzeugen und hier eintragen:
+#       openssl rand -hex 32
+#   Pro Umgebung ein EIGENER Schluessel (Entwicklung, Test, Produktion).
+#
+# Was passiert, wenn ich ihn weglasse?
+#   Nichts faellt aus. Das Audit-Log laeuft normal weiter, nur eben ohne
+#   dieses zusaetzliche Siegel.
+#
+# Was passiert, wenn ich ihn verliere?
+#   Die damit gesiegelten Eintraege lassen sich nicht mehr pruefen. Sie
+#   gelten dann als "nicht pruefbar" - NICHT als gefaelscht. Es gibt also
+#   keinen Fehlalarm, aber der Nachweis fuer diesen Zeitraum ist weg.
+#   Deshalb: Schluessel sichern, so wie ein Passwort.
 AUDIT_HMAC_KEY=
 
-# Nur waehrend eines Schluesselwechsels setzen: der vorherige Schluessel wird
-# bei der Pruefung zusaetzlich akzeptiert, damit Altbestand ohne Rehash gueltig
-# bleibt. Nach dem Wechsel wieder leeren.
+# Nur voruebergehend beim Schluesselwechsel setzen.
+#   Moechtest du den Schluessel oben austauschen (z. B. weil du vermutest,
+#   dass er in falsche Haende geraten ist), trage den ALTEN Schluessel hier
+#   ein und den NEUEN oben. Dann bleiben die bisherigen Eintraege pruefbar,
+#   waehrend neue schon mit dem neuen Schluessel gesiegelt werden.
+#   Nach ein paar Wochen kann dieses Feld wieder geleert werden - danach
+#   sind die alten Eintraege allerdings nicht mehr pruefbar.
 AUDIT_HMAC_KEY_OLD=
+
+# --- Technisch (fuer Entwickler/Admins) ---------------------------------
+# Verfahren : HMAC-SHA256 ueber alle Inhaltsspalten eines Audit-Eintrags,
+#             inkl. previousHash (Verkettung). Entspricht Hash-Version 3.
+# Abdeckung : Version 1 = 7 Felder (Altbestand), Version 2 = alle 24
+#             Inhaltsspalten (SHA-256, unsigniert), Version 3 = wie 2, aber
+#             HMAC-signiert. Die erwartete Version wird aus der Kette
+#             abgeleitet (Version-Floor), nicht aus der Selbstauskunft der
+#             Zeile - sonst liesse sich per Downgrade die schwaechere
+#             Pruefung erzwingen.
+# Fail-safe : Ohne Schluessel schreibt der Dienst weiter Version 2. Bereits
+#             signierte Zeilen landen dann in `unverifiableEntries`,
+#             ausdruecklich NICHT in `tamperedEntries`.
+# Rotation  : AUDIT_HMAC_KEY_OLD wird bei der Pruefung zusaetzlich
+#             akzeptiert - Wechsel ohne Rehash. Ein Rehash waere ohnehin zu
+#             vermeiden, er wuerde die Beweiskraft der Vergangenheit
+#             ueberschreiben.
+# Grenze    : Schuetzt gegen DB-Schreibzugriff ohne Schluessel. Wer Schluessel
+#             UND Datenbank hat, kann die Kette konsistent neu rechnen.
+# Erzeugung : openssl rand -hex 32 (256 Bit)