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>
This commit is contained in:
@@ -206,15 +206,21 @@ Mit `audit:read` allein kann dieses Konto **nur Prüfwerte lesen** – keine
|
||||
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:
|
||||
Gegenprobe nach dem Einrichten – **200, dann dreimal 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 '{}'
|
||||
B="Authorization: Bearer $TOKEN"
|
||||
curl -s -o /dev/null -w 'checkpoint %{http_code}\n' https://<crm>/api/audit-logs/checkpoint -H "$B"
|
||||
curl -s -o /dev/null -w 'export %{http_code}\n' https://<crm>/api/audit-logs/export -H "$B"
|
||||
curl -s -o /dev/null -w 'seal-backlog %{http_code}\n' -X POST https://<crm>/api/audit-logs/seal-backlog -H "$B" -H 'Content-Type: application/json' -d '{}'
|
||||
curl -s -o /dev/null -w 'kunden %{http_code}\n' https://<crm>/api/customers -H "$B"
|
||||
```
|
||||
|
||||
Der Export gehört ausdrücklich dazu: Er liefert `changesBefore`/`changesAfter`,
|
||||
also die vollständigen Vorher/Nachher-Datensätze samt Klartextnamen. Prüfwerte
|
||||
lesen und das Protokoll herausziehen sind zwei verschiedene Dinge – deshalb
|
||||
hängt der Export an `audit:export`, das die Rolle `Gegenbuch` nicht hat.
|
||||
|
||||
Für Produktion und Test jeweils ein eigenes Konto in der jeweiligen Instanz.
|
||||
|
||||
> Jede Anmeldung erscheint im Audit-Log der jeweiligen Instanz. Das ist so
|
||||
|
||||
Reference in New Issue
Block a user