docs(PROJ-72): Feature-Spec nachtragen + Audit-Log-Härtung für abgelehnte Privilege-Checks

Feature-Spec, INDEX.md und features.ts für PROJ-72 (Superadmin-Peer-Patch-Fix)
ergänzt inkl. QA-Ergebnisse. Zusätzlich: abgelehnte Privilege-Escalation-/
Tenant-Isolation-Versuche (403) werden jetzt als Success:false im Audit-Log
protokolliert (vorher nur erfolgreiche Updates) - Härtungspunkt aus QA-Runde.
This commit is contained in:
sysops
2026-07-27 00:08:43 +02:00
parent c580a7c05d
commit 2e952f111d
4 changed files with 102 additions and 1 deletions
+2 -1
View File
@@ -87,7 +87,8 @@
| PROJ-69 | Admin-Dashboard Tab-Gruppierung (2-Ebenen-Navigation) | Deployed | [PROJ-69](PROJ-69-admin-tabs-gruppierung.md) | 2026-07-06 |
| PROJ-70 | User-Self-Service IMAP-Rückholung (Archiv-Mail zurück ins Postfach) | Deployed | [PROJ-70](PROJ-70-imap-rueckholung-self-service.md) | 2026-07-07 |
| PROJ-71 | TLS-Pflicht (optional) für eingehenden SMTP-BCC-Journaling-Kanal | Deployed | [PROJ-71](PROJ-71-smtp-require-tls.md) | 2026-07-08 |
| PROJ-72 | Fix Superadmin kann Passwort/Rolle von Superadmin-Peers nicht ändern (Sicherheitsbug) | Deployed | [PROJ-72](PROJ-72-fix-superadmin-peer-patch.md) | 2026-07-27 |
<!-- Add features above this line -->
## Next Available ID: PROJ-72
## Next Available ID: PROJ-73
@@ -0,0 +1,67 @@
---
id: PROJ-72
title: Fix Superadmin kann Passwort/Rolle von Superadmin-Peers nicht ändern (Sicherheitsbug)
status: Deployed
created: 2026-07-26
---
## Problem
`handleUpdateUser` (`internal/api/admin_users_handlers.go`) blockierte per
SEC-01-Privilegien-Check (`roleLevel(target.Role) >= roleLevel(sess.Role)`)
jede Modifikation an Ziel-Usern mit gleichem oder höherem Rollen-Level wie der
Aufrufer. Da Superadmin das höchste Level ist (`roleLevel = 5`), traf dieser
Vergleich auch Superadmin-vs-Superadmin zu: ein Superadmin konnte weder sich
selbst noch andere Superadmins bearbeiten — u.a. kein Passwort-Reset für
andere Superadmins möglich.
## Lösung
Peer-Level-Check (`>=`-Vergleich für Ziel-Rolle und Rollen-Zuweisung) gilt nur
noch für `sess.Role != userstore.RoleSuperAdmin`. Superadmin ist die höchste
Stufe — es gibt keine höhere Rolle, vor der geschützt werden müsste, daher ist
Superadmin von diesem Peer-Check ausgenommen.
Zusätzlich: abgelehnte Privilege-Escalation-/Tenant-Isolation-Versuche (403)
werden jetzt im Audit-Log als `Success: false` protokolliert (vorher nur
erfolgreiche Updates geloggt) — Härtung, während QA-Verifikation entdeckt.
## Implementation Notes
- `internal/api/admin_users_handlers.go` `handleUpdateUser`:
- Peer-Level-Check (Ziel-Rolle + Rollen-Zuweisung) in
`if sess.Role != userstore.RoleSuperAdmin { ... }` gekapselt.
- Audit-Log-Eintrag (`Success: false`) bei: Cross-Tenant-Zugriff verweigert,
Privilegien für Ziel-User-Modifikation fehlen, Privilegien für
Rollen-Zuweisung fehlen.
- `handleCreateUser`: Audit-Log-Eintrag (`Success: false`) bei verweigerter
Rollen-Zuweisung beim Anlegen.
- Tenant-Isolation-Check (SEC-02) unverändert — Superadmin hat `TenantID ==
nil`, überspringt diesen Block ohnehin.
## Acceptance Criteria
- [x] Superadmin kann eigenes Passwort/Rolle/aktiv-Status ändern (Self-Patch).
- [x] Superadmin kann Passwort/Rolle/aktiv-Status eines anderen Superadmins
ändern (Peer-Patch).
- [x] domain_admin kann weiterhin KEINE Peer- oder höherrangigen User
(inkl. Superadmin) patchen (403).
- [x] Cross-Tenant-Zugriff (IDOR) weiterhin blockiert (403).
- [x] Kein Auth-Bypass (401 ohne gültigen Token).
- [x] Abgelehnte Privilege-Escalation-Versuche erscheinen im Audit-Log
(`Success: false`).
## QA Test Results (2026-07-27, gegen 192.168.1.132)
| TC | Erwartung | Ergebnis |
|---|---|---|
| Superadmin patcht Peer-Superadmin (Rolle+Passwort+aktiv) | 200 | PASS |
| Superadmin Self-Patch | 200 | PASS |
| domain_admin patcht Superadmin (global) | 403 | PASS |
| domain_admin patcht Peer-domain_admin (gleicher Tenant) | 403 | PASS |
| domain_admin patcht User aus fremdem Tenant (IDOR) | 403 | PASS |
| PATCH ohne JWT | 401 | PASS |
| domain_admin weist eigenem Tenant-User Rolle "admin" zu | 403 | PASS |
| domain_admin patcht regulären User im eigenen Tenant (Positivkontrolle) | 200 | PASS |
Deployed auf 131 (Produktiv) und 132 (teilproduktiv) am 2026-07-26/27.