Rolle "Gegenbuch": Leserecht aufs Audit-Protokoll ohne audit:admin

Beim Selbst-Nachpruefen eines Deploys auf Staging aufgefallen: Das
Gegenbuch-Dienstkonto meldete beim Login audit:read, audit:export,
audit:admin, gdpr:export, gdpr:delete und gdpr:admin. Es braucht genau
eines davon - audit:read -, denn es ruft nur /audit-logs/checkpoint und
/audit-logs/verify auf.

Das war kein Bedienfehler, sondern ein Konstruktionsfehler: Es gab keine
Rolle, die nur Leserecht aufs Protokoll gibt. Wer das wollte, musste den
Haken "DSGVO-Zugriff" setzen - und der vergibt audit:* komplett, also
auch audit:admin mit seal-backlog, rehash und cleanup. Das Label
("Audit-Logs, Datenschutz") legt Lesen nahe und liefert Vollzugriff.

Warum das ernst ist: Das Passwort des Dienstkontos liegt im Klartext in
tools/audit-notary/.env auf der Gegenbuch-Maschine. Mit audit:admin
haette ein Einbruch dort nicht nur den Waechter gehabt, sondern gleich
die Mittel zur Waesche aus R185-01 - und damit genau die Trennung
aufgehoben, wegen der das Gegenbuch auf einer eigenen Maschine laeuft.

Neue Rolle "Gegenbuch" in sync-roles.ts mit ausschliesslich audit:read.
sync-roles laeuft beim Containerstart mit, die Rolle erscheint danach in
der Benutzerverwaltung. README des Gegenbuchs umgeschrieben: Rolle statt
"selbst anlegen", ausdrueckliche Warnung vor dem DSGVO-Haken, dazu eine
Gegenprobe (checkpoint -> 200, seal-backlog -> 403).

Bewusst NICHT angefasst: dass die DSGVO-Rolle selbst audit:admin traegt,
ist ein Gewaltenteilungs-Problem - wer das Protokoll beaufsichtigt, kann
seine Beweisgrundlage ersetzen. Das zu aendern entzieht bestehenden
DSGVO-Konten Rechte und gehoert entschieden, nicht nebenbei gemacht.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

tools/audit-notary/README.md

@@ -186,16 +186,34 @@ jedem Lauf selbst an.
 
 Im CRM, als Administrator:
 
-1. **Rolle anlegen**, z. B. `Gegenbuch` – und ihr **ausschließlich** das Recht
-   `audit:read` geben. Sonst nichts.
-2. **Benutzer anlegen**, z. B. `gegenbuch@deine-domain.de`, mit dieser Rolle
-   und einem langen, zufälligen Passwort.
-3. E-Mail und Passwort in die `.env` des Gegenbuchs eintragen
+1. **Benutzer anlegen**, z. B. `gegenbuch@deine-domain.de`, mit einem langen,
+   zufälligen Passwort.
+2. Ihm die Rolle **`Gegenbuch`** geben – **nur diese**. Sie bringt genau ein
+   Recht mit: `audit:read`.
+3. Zusätzlich **„Dienstkonto"** ankreuzen. Dann gelten seine Anmeldungen als
+   Routine statt als kritisches Ereignis – und sein *Ausbleiben* wird gemeldet.
+4. E-Mail und Passwort in die `.env` des Gegenbuchs eintragen
    (`PROD_CRM_EMAIL` / `PROD_CRM_PASSWORD`).
 
+> **Nicht den DSGVO-Haken benutzen.** Der sieht naheliegend aus („Audit-Logs,
+> Datenschutz"), vergibt aber `audit:` **komplett** – einschließlich
+> `audit:admin` mit `seal-backlog`, `rehash` und `cleanup`. Ein Einbruch auf
+> dieser Maschine hätte damit nicht nur den Wächter, sondern gleich die Mittel,
+> das Bewachte umzuschreiben. Das Passwort steht hier im Klartext in der
+> `.env`; es muss so wenig wert sein wie möglich.
+
 Mit `audit:read` allein kann dieses Konto **nur Prüfwerte lesen** – keine
-Kundendaten, keine Verträge, nichts ändern. Selbst wenn die Zugangsdaten
-abhandenkommen, ist damit nichts anzufangen.
+Kundendaten, keine Verträge, nichts ändern und nichts versiegeln. Selbst wenn
+die Zugangsdaten abhandenkommen, ist damit nichts anzufangen.
+
+Gegenprobe nach dem Einrichten – die erste Zeile muss 200 geben, die zweite 403:
+
+```bash
+curl -s -o /dev/null -w '%{http_code}\n' https://<crm>/api/audit-logs/checkpoint \
+  -H "Authorization: Bearer $TOKEN"
+curl -s -o /dev/null -w '%{http_code}\n' -X POST https://<crm>/api/audit-logs/seal-backlog \
+  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' -d '{}'
+```
 
 Für Produktion und Test jeweils ein eigenes Konto in der jeweiligen Instanz.