audit:export gatete nichts - Export hing an audit:read

Bei der Gegenprobe zur neuen Rolle "Gegenbuch" gefunden: Ein Konto mit
ausschliesslich audit:read bekam auf GET /audit-logs/export eine 200. Die
Berechtigung audit:export stand im Katalog und in der Rollenverwaltung -
und wurde nirgends geprueft.

Der Unterschied ist nicht kosmetisch. Blaettern zeigt 50 Zeilen; der
Export liefert in einem Zug das gesamte Protokoll inklusive changesBefore
und changesAfter, also der vollstaendigen Vorher/Nachher-Datensaetze,
dazu resourceLabel mit Klartextnamen, IP-Adressen und User-Agents. Live
nachgewiesen auf Staging: 43 Eintraege mit gefuellter resourceLabel
allein fuer resourceType=Customer.

Damit konnte ausgerechnet das Dienstkonto des Gegenbuchs Personendaten
exportieren - das Konto, dessen Passwort im Klartext in der .env auf der
Notar-Maschine liegt, und dem README und Rollenname "nur Pruefwerte
lesen" zusichern.

/audit-logs/export verlangt jetzt audit:export. Betroffen ist genau eine
Rolle: Gegenbuch, und zwar gewollt. Die DSGVO-Rolle traegt audit:*
vollstaendig und behaelt den Export.

In der Oberflaeche erscheinen JSON- und CSV-Knopf nur noch mit
audit:export - sonst stuenden dort Knoepfe, die zuverlaessig 403 liefern.

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

docs/todo.md

@@ -97,6 +97,30 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
 
 ## ✅ Erledigt
 
+- [x] **🔒 `audit:export` gatete nichts – Export hing an `audit:read`** (2026-08-26)
+  - **Bei der Gegenprobe zur neuen Rolle `Gegenbuch` gefunden:** Ein Konto mit
+    ausschließlich `audit:read` bekam auf `GET /audit-logs/export` **200**.
+    Die Berechtigung `audit:export` stand im Katalog und in der
+    Rollenverwaltung – und wurde **nirgends** geprüft.
+  - **Der Unterschied ist nicht kosmetisch.** Blättern zeigt 50 Zeilen; der
+    Export liefert in einem Zug das gesamte Protokoll inklusive
+    `changesBefore`/`changesAfter` – also der vollständigen Vorher/Nachher-
+    Datensätze – dazu `resourceLabel` mit Klartextnamen, IP-Adressen und
+    User-Agents. Live nachgewiesen: 43 Einträge mit gefüllter
+    `resourceLabel` allein für `resourceType=Customer`.
+  - Damit konnte ausgerechnet das Dienstkonto des Gegenbuchs, dessen Passwort
+    im Klartext in der `.env` auf der Notar-Maschine liegt, Personendaten
+    exportieren – während README und Rollenname „nur Prüfwerte lesen"
+    versprachen.
+  - `/audit-logs/export` verlangt jetzt `audit:export`. Betroffen ist genau
+    eine Rolle: `Gegenbuch` (gewollt). Die DSGVO-Rolle hat `audit:*`
+    vollständig und behält den Export.
+  - Oberfläche: JSON- und CSV-Knopf werden nur noch mit `audit:export`
+    angezeigt – sonst stünden dort Knöpfe, die zuverlässig 403 liefern.
+  - Dateien: `backend/src/routes/auditLog.routes.ts`,
+    `frontend/src/pages/settings/AuditLogs.tsx`,
+    `tools/audit-notary/README.md`
+
 - [x] **🔑 Rolle „Gegenbuch": Leserecht aufs Audit-Protokoll ohne `audit:admin`** (2026-08-26)
   - **Beim Selbst-Nachprüfen eines Deploys aufgefallen:** Das Gegenbuch-
     Dienstkonto auf Staging meldete beim Login