M8: Mandanten-Isolation und Rollenmatrix automatisiert testen

scripts/check-m8-tenant-isolation.php: legt zwei frische, isolierte
Test-Mandanten mit je einem Teilnehmer, einer Ledger-Buchung, einem
Hinweis und einem Audit-Log-Eintrag an und prueft 10 Faelle - Lesezugriffe
(Teilnehmerlisten, Einzelabruf, letzte Buchungen, aktive Hinweise,
Audit-Log) und Schreibzugriffe (Buchung, Zugangsvergabe, Storno) sind
strikt auf den jeweils richtigen Mandanten beschraenkt. Raeumt sich selbst
auf. 10/10 gruen.

scripts/check-m8-role-matrix.php: legt einen Test-Mandanten mit je einem
Nutzer pro Rolle an (owner/admin/treasurer/member/viewer), loggt sich per
echtem HTTP-Request ein (manueller Cookie-Jar ueber file_get_contents, da
diese PHP-Installation keine curl-Extension hat) und prueft alle elf
rollen-geschuetzten Seiten gegen die erwartete Rollenliste. 55/55 gruen
(5 Rollen x 11 Seiten) - bestaetigt, dass die Rollenpruefungen ueberall
konsistent mit dem im Plan dokumentierten Rollenmodell durchgesetzt sind.

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

docs/m8-haertung.md

@@ -91,18 +91,51 @@ mailversenden.php
   eine Einstellungsänderung im UI-Protokoll mit korrektem Nutzernamen
   erscheint. Testdaten anschließend entfernt.
 
+## Mandanten-Isolation (automatisiert)
+
+Umgesetzte Datei: `scripts/check-m8-tenant-isolation.php`
+
+Legt zwei frische, isolierte Test-Mandanten mit je einem Teilnehmer, einer
+Ledger-Buchung, einem Hinweis und einem Audit-Log-Eintrag an und prüft
+10 Fälle: Teilnehmerlisten, Einzelabruf, letzte Buchungen, aktive Hinweise,
+Schreibversuche (Buchung, Zugangsvergabe, Storno) und Audit-Log sind
+strikt auf den jeweils richtigen Mandanten beschränkt; ein Zugriff über den
+falschen Mandanten liefert nichts beziehungsweise schlägt sauber fehl statt
+fremde Daten zurückzugeben. Räumt die Testdaten am Ende selbst auf.
+
+Ergebnis: grün mit 10 Assertions.
+
+## Rollenmatrix (automatisiert)
+
+Umgesetzte Datei: `scripts/check-m8-role-matrix.php`
+
+Legt einen Test-Mandanten mit je einem Nutzer pro Rolle (`owner`, `admin`,
+`treasurer`, `member`, `viewer`) an, loggt sich für jede Rolle per echtem
+HTTP-Request ein (manueller Cookie-Jar über `file_get_contents`, da diese
+PHP-Installation keine curl-Extension hat) und ruft alle rollen-geschützten
+Seiten auf: `kaffeeliste.php`, `mitarbeiterverwalten.php`, `hinweise.php`,
+`stricheintragen.php`, `einzahlung.php`, `letzteneintraege.php`,
+`csvupload.php`, `exportKaffeeliste.php`, `mailversenden.php`,
+`jahresauswertung.php`, `mandant-einstellungen.php`. Für jede
+Rolle-Seite-Kombination wird geprüft, ob der tatsächliche Zugriff (anhand
+der „Kein Zugriff"/„keine Berechtigung"-Marker in der Antwort) mit der
+erwarteten Rollenliste übereinstimmt.
+
+Ergebnis: grün mit 55 Assertions (5 Rollen × 11 Seiten). Räumt die
+Testdaten am Ende selbst auf.
+
 ## Prüfstatus
 
 - Golden Master: grün mit 104 Assertions.
 - M4 Ledger-Migration: grün mit 73 Assertions.
 - M3 Settings-Flow: grün mit 13 Assertions.
 - HTTP-Smoke: grün mit 26 geprüften Seiten.
+- M8 Mandanten-Isolation: grün mit 10 Assertions.
+- M8 Rollenmatrix: grün mit 55 Assertions.
 
 ## Noch offen in M8
 
 - Content-Security-Policy (braucht Template-Bereinigung der Inline-Styles).
-- Mandanten-Isolation automatisiert testen.
-- Rollenmatrix automatisiert testen.
 - Datenexport pro Mandant.
 - Lösch-/Anonymisierungsprozess für Teilnehmer und Kunden.
 - Backup-/Restore-Prozess und Monitoring/Fehlerlogging dokumentieren.

docs/saas-umstrukturierungsplan.md

@@ -308,7 +308,7 @@ Nicht tun:
 | M5 | App-Kern | Weit fortgeschritten: Kernseiten lesen und schreiben tenant-sicher gegen das Ledger, inklusive Hinweise und rollenbasiertem Zugang; offen ist ein eigener Zahlungs-Screen |
 | M6 | Betriebsflows | Abgeschlossen: Import, Export, Mail und Jahresabschluss sind auditierbar |
 | M7 | Landingpage | Public-Seite und Auth-Seiten sind im gemeinsamen Stil nutzbar; spätere Ausbaustufen folgen |
-| M8 | Härtung | Gestartet: Security-Headers, Rate-Limits und Audit-Log stehen; Isolation/Rollenmatrix-Tests, Datenexport, Löschung und Betrieb offen |
+| M8 | Härtung | Weit fortgeschritten: Security-Headers, Rate-Limits, Audit-Log, Mandanten-Isolations- und Rollenmatrix-Tests stehen; Datenexport, Löschung und Betriebs-Doku offen |
 | M9 | Cutover | Produktivumstellung ist vorbereitet und Legacy ist read-only |
 
 ### M0: Planungs- und Sicherheitsbaseline
@@ -652,8 +652,13 @@ Schritte:
 - Rate-Limits und Security Headers: erledigt. Globale Security-Headers
   über `app/bootstrap.php` (ohne CSP, siehe `docs/m8-haertung.md`),
   DB-gestützte Rate-Limits für Login, Registrierung und Passwort-Reset.
-- Mandanten-Isolation testen.
-- Rollenmatrix testen.
+- Mandanten-Isolation testen: erledigt.
+  `scripts/check-m8-tenant-isolation.php` legt zwei isolierte Test-Mandanten
+  an und prüft Lese- und Schreibzugriffe über den jeweils falschen
+  Mandanten (10 Assertions, grün).
+- Rollenmatrix testen: erledigt.
+  `scripts/check-m8-role-matrix.php` prüft alle fünf Rollen gegen alle
+  rollen-geschützten Seiten per echtem HTTP-Login (55 Assertions, grün).
 
 Ergebnis: