R188/R189-01 aus dem Pentest umgesetzt - Klasse statt Instanz

Beide Findings der Pentesterin waren berechtigt. Ihre Patches liessen
sich nicht anwenden (Basis 791711c, seitdem 42 Commits, sync-roles.ts
kollidiert), und an zwei Stellen greifen sie zu kurz.

R188 - ungueltige IDs im Pfad
-----------------------------
Gemeldet: GET /api/users/:id gibt bei nicht-numerischer ID 500 statt 400.
Ihr Fix schliesst nebenbei mehr, als sie beansprucht: parseInt('12abc')
ergibt 12, also lieferte /api/users/12abc bisher Benutzer 12 aus.

Es waren aber 181 ungepruefte Stellen in 19 Controllern, nicht eine. 181
Einzel-Guards waeren genau der Fehler aus R186-01 gewesen - drei
Filterlisten, die dasselbe bedeuten sollten und auseinanderliefen.
Stattdessen router.param(), an einer Stelle fuer alle 33 Router
registriert, ueber einen mounte()-Helfer, der Pruefung und Einhaengen
zusammenbindet.

Antwort ist 404, nicht 400: Ein Pfadsegment, das keine ID sein kann,
benennt keine Ressource. Der bestehende Praezedenzfall in
provider.controller.ts (Pentest Mai 2026) hatte es genauso entschieden.

Dabei eine aeltere Heuristik abgeloest (Pentest Runde 7). Ihr eigener
Kommentar nannte den Grund fuer sie - "app.param() greift nicht auf in
Sub-Router gemounteten Routes" - und genau das loest mounte(). Sie war zu
eng (/users/abc ging durch und endete als 500) und zu weit (ein
Einstellungs-Schluessel 12abc unter :key wurde geblockt, obwohl das keine
ID ist), und sie antwortete 400, wo jetzt 404 steht.

R189-01 - DSGVO-Rechte ohne Traeger
------------------------------------
Gemeldet: gdpr:* und audit:read/export haengen an DSGVO und Developer,
die Admin-Rolle hat sie nicht, und nach einem frischen Seed war DSGVO
keinem Konto zugewiesen. Auskunft nach Art. 15 und Loeschung nach Art. 17
konnte niemand ausfuehren.

Seed weist admin@admin.com jetzt zusaetzlich die DSGVO-Rolle zu; die
Admin-Rolle selbst bleibt ohne diese Rechte, die Trennung aus R186 bleibt
also erhalten. Label ehrlich gemacht.

Beim Pruefen ihres Patches ein eigener Fund: seed.ts vergab an die
DSGVO-Rolle weiterhin audit:* komplett, inklusive audit:admin - die
Buendelung, die fc6f39e aufgeloest hat. Ich hatte damals zwei Listen
gefunden und die dritte uebersehen. Gerettet hat es nur die Reihenfolge
im Containerstart; ein einzelnes `npm run db:seed` brachte sie zurueck.

Der Seed hilft nur bei Neuinstallation (update: {}). Deshalb zusaetzlich
eine Wache beim Start: Gibt es fuer gdpr:export, gdpr:delete oder
audit:read kein aktives Konto, steht das mit Handlungsanweisung im Log -
Erkennung der ABWESENHEIT einer Faehigkeit, wie beim Heartbeat. Bewusst
nur melden, nicht automatisch vergeben.

Getestet ueber HTTP gegen eine Wegwerf-Instanz: alle ID-Varianten quer
ueber sechs Controller, Nicht-ID-Parameter unveraendert, frischer Seed,
Wache mit und ohne vergebene Rechte.

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

README.md

@@ -398,6 +398,27 @@ lässt das Siegel aus.
 | Muss ich ihn irgendwo eintragen außer in der `.env`? | Nein. Einmal setzen, Backup anlegen, fertig. |
 | Verlangsamt das etwas? | Nein, spürbar nicht. |
 
+**Wichtig bei einer bestehenden Installation: den Altbestand versiegeln**
+
+Das Siegel gilt nur für Einträge, die **ab** dem Setzen des Schlüssels
+geschrieben werden. Alles, was vorher im Protokoll steht, bleibt ungeschützt –
+Änderungen daran wären nicht erkennbar. Die Integritätsprüfung sagt das auch:
+
+    Hinweis: Der Altbestand ist nicht versiegelt – Änderungen daran wären
+    nicht erkennbar. Behebbar mit POST /api/audit-logs/seal-backlog
+    {"confirm":"SEAL"}.
+
+Das ist ein **einmaliger** Schritt: Er zieht ein Siegel über den vorhandenen
+Bestand, sodass spätere Änderungen daran auffallen. Der Ablauf – wer es darf
+(Haken **„Audit-Betrieb"** in der Benutzerverwaltung), was vorher zu prüfen ist
+und wie man das Ergebnis gegenprüft – steht Schritt für Schritt unter
+**[Den Altbestand versiegeln](tools/audit-notary/README.md#den-altbestand-versiegeln-einmalig-im-crm)**.
+Die Anleitung liegt beim Gegenbuch, gilt aber **auch ohne** – es ist ein
+Vorgang im CRM.
+
+Den Zustand siehst du jederzeit unter **Einstellungen → Audit-Protokoll**, ganz
+oben.
+
 **Schlüssel wechseln (`AUDIT_HMAC_KEY_OLD`)**
 
 Möchtest du den Schlüssel austauschen – etwa weil du vermutest, dass er in

backend/prisma/seed.ts

@@ -106,7 +106,7 @@ async function main() {
     update: {},
     create: {
       name: 'Admin',
-      description: 'Voller Zugriff auf alle Funktionen',
+      description: 'Voller Zugriff auf alle Fachfunktionen (ohne Audit & Datenschutz – dafür die separaten Rollen DSGVO und Audit-Betrieb)',
       permissions: {
         create: adminPermissions.map((p) => ({ permissionId: p.id })),
       },
@@ -129,16 +129,29 @@ async function main() {
   });
   await syncRolePermissions(developerRole.id, developerPermissions.map((p) => p.id));
 
-  // DSGVO - audit and gdpr permissions (hidden role, controlled via hasGdprAccess)
+  // DSGVO - Datenschutz-Verwaltung plus LESENDER Zugriff aufs Audit-Protokoll.
+  //
+  // Bewusst OHNE `audit:admin`: Wer das Protokoll beaufsichtigt, darf seine
+  // eigene Beweisgrundlage nicht ersetzen koennen (Pentest R186). Die
+  // eingreifenden Rechte liegen in der Rolle `Audit-Betrieb`.
+  //
+  // Diese Liste stand hier bis 09/2026 noch auf `audit:*` komplett und war
+  // damit die dritte Stelle, die denselben Rechtesatz beschrieb - neben
+  // `sync-roles.ts` und dem Notfallpfad in `user.service.ts`. Gerettet hat es
+  // nur die Reihenfolge im Container-Start (sync-roles laeuft danach und
+  // raeumt Ueberzaehliges weg); ein einzelnes `npm run db:seed` brachte die
+  // Buendelung zurueck.
   const gdprPermissions = allPermissions.filter(
-    (p) => p.resource === 'audit' || p.resource === 'gdpr'
+    (p) =>
+      p.resource === 'gdpr' ||
+      (p.resource === 'audit' && (p.action === 'read' || p.action === 'export'))
   );
   const gdprRole = await prisma.role.upsert({
     where: { name: 'DSGVO' },
     update: {},
     create: {
       name: 'DSGVO',
-      description: 'DSGVO-Zugriff: Audit-Logs und Datenschutz-Verwaltung',
+      description: 'DSGVO-Zugriff: Audit-Logs lesen und Datenschutz-Verwaltung',
       permissions: {
         create: gdprPermissions.map((p) => ({ permissionId: p.id })),
       },
@@ -265,8 +278,19 @@ async function main() {
       password: hashedPassword,
       firstName: 'Admin',
       lastName: 'User',
+      // Zusaetzlich die DSGVO-Rolle (Pentest R189-01).
+      //
+      // Ohne sie kann nach einem frischen Seed NIEMAND eine Auskunft nach
+      // Art. 15 oder eine Loeschung nach Art. 17 ausfuehren - die Rechte
+      // haengen an DSGVO und Developer, und beide waren keinem Konto
+      // zugewiesen. Ein Ausfall mit Fristwirkung, ausgeloest durch nichts
+      // weiter als eine Neuinstallation.
+      //
+      // Die Trennung bleibt: Die Admin-ROLLE bekommt diese Rechte weiterhin
+      // nicht. Nur dieses eine Bootstrap-Konto traegt beide, damit ueberhaupt
+      // jemand handlungsfaehig ist.
       roles: {
-        create: [{ roleId: adminRole.id }],
+        create: [{ roleId: adminRole.id }, { roleId: gdprRole.id }],
       },
     },
   });

backend/prisma/sync-roles.ts

@@ -175,7 +175,7 @@ async function main() {
     .map((p) => p.id);
 
   const rolesSpec: Array<{ name: string; description: string; permIds: number[] }> = [
-    { name: 'Admin', description: 'Voller Zugriff auf alle Funktionen', permIds: adminPermIds },
+    { name: 'Admin', description: 'Voller Zugriff auf alle Fachfunktionen (ohne Audit & Datenschutz – dafür die separaten Rollen DSGVO und Audit-Betrieb)', permIds: adminPermIds },
     { name: 'Developer', description: 'Voller Zugriff inkl. Entwickler-Tools', permIds: developerPermIds },
     { name: 'DSGVO', description: 'DSGVO-Zugriff: Audit-Logs lesen und Datenschutz-Verwaltung', permIds: gdprPermIds },
     { name: 'Audit-Betrieb', description: 'Darf das Audit-Protokoll versiegeln, aufräumen und die Aufbewahrung ändern', permIds: auditBetriebPermIds },

backend/src/controllers/auditLog.controller.ts

@@ -273,6 +273,49 @@ export async function verifyIntegrity(req: AuthRequest, res: Response) {
                 'Behebbar mit POST /api/audit-logs/seal-backlog {"confirm":"SEAL"}.'
               : '';
 
+    // Eine Neuberechnung der Kette gehoert IMMER erwaehnt – auch und gerade,
+    // wenn sonst alles grün ist. Nach einem Rehash ist die Kette
+    // zwangslaeufig stimmig, auch ueber Loeschungen hinweg. „Lueckenlos
+    // verkettet“ heisst dann nur noch „seit dem Rehash“, und wer das nicht
+    // mitliest, nimmt eine Entwarnung mit, die es so nicht gibt.
+    const rehashText = (() => {
+      if (result.rehashes.length === 0) return '';
+      const letzter = result.rehashes[result.rehashes.length - 1];
+      const datum = new Date(letzter.zeitpunkt).toLocaleString('de-DE', {
+        dateStyle: 'short',
+        timeStyle: 'short',
+      });
+      const wieOft =
+        result.rehashes.length === 1
+          ? 'Die Kette wurde einmal neu berechnet'
+          : `Die Kette wurde ${result.rehashes.length}× neu berechnet, zuletzt`;
+      // Nur benennen, was es zu benennen gibt. Bei sauberem Vorzustand ist die
+      // Auskunft „nichts uebertuencht“ selbst eine nuetzliche Information –
+      // ein Rehash ueber einer unbeanstandeten Kette wiegt anders als einer
+      // ueber 700 Luecken.
+      const vb = letzter.vorbefund;
+      const uebertuencht = !vb
+        ? ' Der Zustand vor dieser Neuberechnung ist nicht mehr feststellbar.'
+        : vb.manipuliert === 0 && vb.luecken === 0
+          ? ' Die Kette war unmittelbar davor unbeanstandet – es wurde nichts überdeckt.'
+          : ' Unmittelbar davor: ' +
+            `${vb.manipuliert} beanstandete${vb.manipuliert === 1 ? 'r Eintrag' : ' Einträge'}` +
+            ` und ${vb.luecken} Lücke${vb.luecken === 1 ? '' : 'n'}. ` +
+            'Diese Spuren sind seitdem nicht mehr in der Kette sichtbar, sondern nur noch im ' +
+            `Vorbefund des Rehash-Eintrags (id ${letzter.id}).`;
+      const ohneSignatur = result.rehashes.some((r) => !r.signiert)
+        ? ' Achtung: Mindestens ein Rehash-Eintrag trägt keine gültige Signatur.'
+        : '';
+      return (
+        ` ⚠ ${wieOft} am ${datum}` +
+        (letzter.neuBerechnet !== null ? ` (${letzter.neuBerechnet} Einträge)` : '') +
+        '. Ein Rehash verknüpft alle Einträge neu – die Aussage dieser Prüfung ' +
+        'reicht deshalb nur bis dorthin zurück, nicht weiter.' +
+        uebertuencht +
+        ohneSignatur
+      );
+    })();
+
     // Erneutes Siegeln kann legitim sein, verdient aber einen Blick: es
     // ersetzt die zuvor beglaubigte Wurzel (Pentest R173-03).
     const mehrfach =
@@ -303,7 +346,10 @@ export async function verifyIntegrity(req: AuthRequest, res: Response) {
           : beglaubigt > 0
             ? 'Alle Einträge sind unverändert. Seit dem Bestandssiegel ist keine neue Lücke ' +
               'entstanden.'
-            : 'Alle Einträge sind unverändert und lückenlos verkettet.';
+            : result.rehashes.length > 0
+              ? 'Alle Einträge sind unverändert und lückenlos verkettet – allerdings erst ' +
+                'seit der letzten Neuberechnung.'
+              : 'Alle Einträge sind unverändert und lückenlos verkettet.';
 
     res.json({
       success: true,
@@ -319,8 +365,10 @@ export async function verifyIntegrity(req: AuthRequest, res: Response) {
         unexplainedGaps: result.unexplainedGaps,
         // Alt-Lücken, die das Bestandssiegel als bereits vorhanden beglaubigt.
         attestedGaps: result.attestedGaps,
+        // Protokollierte Neuberechnungen – begrenzen die Reichweite der Aussage.
+        rehashes: result.rehashes,
         tampered: tampered > 0,
-        message: message + beglaubigtText + keinSchluessel + siegel + mehrfach,
+        message: message + beglaubigtText + rehashText + keinSchluessel + siegel + mehrfach,
         unverifiableEntries: result.unverifiableEntries,
         // Zustand des Bestandssiegels ueber den nicht signierbaren Altbestand.
         backlogSealStatus: result.backlogSealStatus,

backend/src/index.ts

@@ -1,4 +1,4 @@
-import express from 'express';
+import express, { Router } from 'express';
 import cookieParser from 'cookie-parser';
 import cors from 'cors';
 import helmet from 'helmet';
@@ -69,9 +69,11 @@ import { startContractStatusScheduler } from './services/contractStatusScheduler
 import { startBlzUpdateScheduler } from './services/blzUpdateScheduler.service.js';
 import { startSecurityMonitorScheduler } from './services/securityAlert.service.js';
 import monitoringRoutes from './routes/monitoring.routes.js';
+import { registriereIdPruefung } from './middleware/routeIds.js';
 import { auditContextMiddleware } from './middleware/auditContext.js';
 import { auditMiddleware } from './middleware/audit.js';
 import { starteHeartbeatMonitor } from './services/heartbeatMonitor.service.js';
+import { pruefePflichtrechte } from './services/pflichtrechte.service.js';
 import { authenticate } from './middleware/auth.js';
 
 // ==================== SECURITY: Pflicht-Umgebungsvariablen prüfen ====================
@@ -326,69 +328,76 @@ app.use('/api', (_req, res, next) => {
   next();
 });
 
-// Numerische ID-Parameter strikt validieren. parseInt('6abc') liefert 6, was
-// dazu führt, dass `/api/customers/6abc` als `/api/customers/6` interpretiert
-// wurde – kein Auth-Bypass (Prisma fängt SQL-Injection), aber fehlende Input-
-// Validierung. Pentest Runde 7 (2026-05-17), LOW.
+// HIER STAND eine Pfad-Heuristik gegen abgeschnittene IDs (Pentest Runde 7,
+// 2026-05-17): Sie blockte Segmente der Form `^\d+[a-zA-Z]+$` – also `6abc`,
+// weil `parseInt('6abc')` die 6 ergibt und `/api/customers/6abc` still als
+// Kunde 6 gelesen wurde. Ihr eigener Kommentar nannte den Grund fuer die
+// Heuristik: „`app.param()` greift nicht auf in Sub-Router gemounteten Routes".
 //
-// `app.param()` greift nicht auf in Sub-Router gemounteten Routes, deshalb
-// machen wir es als Pfad-Heuristik. Geblockt wird NUR `^\d+[a-zA-Z]+$` –
-// reine Ziffern gefolgt von reinen Buchstaben (`6abc`, `12foo`). UUIDs wie
-// `3018c9b9-b337-4c9a-a402-b47872f8ddae` (Consent-Hash) und Datumsstrings
-// `2024-05-17` haben Bindestriche / gemischten Aufbau und werden korrekt
-// nicht geblockt.
-const TRUNCATED_ID_PATTERN = /^\d+[a-zA-Z]+$/;
-app.use('/api', (req, res, next) => {
-  for (const seg of req.path.split('/')) {
-    if (seg.length > 0 && TRUNCATED_ID_PATTERN.test(seg)) {
-      res.status(400).json({ success: false, error: 'Ungültige ID im URL-Pfad' });
-      return;
-    }
-  }
-  next();
-});
+// Genau das loest `mounte()` weiter unten – die Pruefung wird an jedem Router
+// registriert, nicht am App-Objekt. Damit ist die Heuristik abgeloest, und
+// zwar in beide Richtungen:
+//
+//   – Sie war zu eng: `/api/users/abc` ging durch (keine Ziffer vorn) und
+//     endete als 500. Die Parameter-Pruefung kennt dagegen die tatsaechlichen
+//     ID-Parameter und laesst nur kanonische Zahlen zu.
+//   – Sie war zu weit: Ein Einstellungs-Schluessel `12abc` unter
+//     `/api/settings/:key` wurde geblockt, obwohl `:key` gar keine ID ist.
+//
+// Und sie antwortete 400, wo die Parameter-Pruefung 404 gibt – zwei Antworten
+// fuer dieselbe Eingabeklasse. Siehe middleware/routeIds.ts.
 
 // Globaler Backstop-Rate-Limiter für ALLE /api-Requests (Pentest R148).
 // Großzügige Obergrenze pro IP – ergänzt die feineren Limiter (Login etc.),
 // die als erste greifen. Siehe middleware/rateLimit.ts für die Begründung.
 app.use('/api', apiBackstopRateLimiter);
 
+// Router einhängen – IMMER über `mounte`, nie über `app.use` direkt.
+//
+// `mounte` haengt die zentrale Pruefung numerischer Pfad-Parameter an (R188)
+// und montiert danach. Wer hier kuenftig `app.use` schreibt, umgeht sie
+// stillschweigend – deshalb steht die Pruefung im selben Handgriff wie das
+// Einhaengen und nicht in einer zweiten Liste, die man vergessen kann.
+const mounte = (pfad: string, router: Router): void => {
+  app.use(pfad, registriereIdPruefung(router));
+};
+
 // Öffentliche Routes (OHNE Authentifizierung)
-app.use('/api/public/consent', consentPublicRoutes);
+mounte('/api/public/consent', consentPublicRoutes);
 
 // Routes
-app.use('/api/auth', authRoutes);
-app.use('/api/customers', customerRoutes);
-app.use('/api/addresses', addressRoutes);
-app.use('/api/bank-cards', bankcardRoutes);
-app.use('/api/documents', documentRoutes);
-app.use('/api/meters', meterRoutes);
-app.use('/api/stressfrei-emails', stressfreiEmailRoutes);
-app.use('/api/contracts', contractRoutes);
-app.use('/api/credit-notes', creditNoteRoutes);
-app.use('/api/company-profile', companyProfileRoutes);
-app.use('/api/platforms', platformRoutes);
-app.use('/api/cancellation-periods', cancellationPeriodRoutes);
-app.use('/api/contract-durations', contractDurationRoutes);
-app.use('/api/providers', providerRoutes);
-app.use('/api/tariffs', tariffRoutes);
-app.use('/api/users', userRoutes);
-app.use('/api/upload', uploadRoutes);
-app.use('/api/developer', developerRoutes);
-app.use('/api/contract-categories', contractCategoryRoutes);
-app.use('/api', contractTaskRoutes);
-app.use('/api/settings', appSettingRoutes);
-app.use('/api/email-providers', emailProviderRoutes);
-app.use('/api', cachedEmailRoutes);
-app.use('/api/energy-details', invoiceRoutes);
-app.use('/api', contractHistoryRoutes);
-app.use('/api/audit-logs', auditLogRoutes);
-app.use('/api/gdpr', gdprRoutes);
-app.use('/api/email-logs', emailLogRoutes);
-app.use('/api/pdf-templates', pdfTemplateRoutes);
-app.use('/api/birthdays', birthdayRoutes);
-app.use('/api/factory-defaults', factoryDefaultsRoutes);
-app.use('/api/monitoring', monitoringRoutes);
+mounte('/api/auth', authRoutes);
+mounte('/api/customers', customerRoutes);
+mounte('/api/addresses', addressRoutes);
+mounte('/api/bank-cards', bankcardRoutes);
+mounte('/api/documents', documentRoutes);
+mounte('/api/meters', meterRoutes);
+mounte('/api/stressfrei-emails', stressfreiEmailRoutes);
+mounte('/api/contracts', contractRoutes);
+mounte('/api/credit-notes', creditNoteRoutes);
+mounte('/api/company-profile', companyProfileRoutes);
+mounte('/api/platforms', platformRoutes);
+mounte('/api/cancellation-periods', cancellationPeriodRoutes);
+mounte('/api/contract-durations', contractDurationRoutes);
+mounte('/api/providers', providerRoutes);
+mounte('/api/tariffs', tariffRoutes);
+mounte('/api/users', userRoutes);
+mounte('/api/upload', uploadRoutes);
+mounte('/api/developer', developerRoutes);
+mounte('/api/contract-categories', contractCategoryRoutes);
+mounte('/api', contractTaskRoutes);
+mounte('/api/settings', appSettingRoutes);
+mounte('/api/email-providers', emailProviderRoutes);
+mounte('/api', cachedEmailRoutes);
+mounte('/api/energy-details', invoiceRoutes);
+mounte('/api', contractHistoryRoutes);
+mounte('/api/audit-logs', auditLogRoutes);
+mounte('/api/gdpr', gdprRoutes);
+mounte('/api/email-logs', emailLogRoutes);
+mounte('/api/pdf-templates', pdfTemplateRoutes);
+mounte('/api/birthdays', birthdayRoutes);
+mounte('/api/factory-defaults', factoryDefaultsRoutes);
+mounte('/api/monitoring', monitoringRoutes);
 
 // Health check – BEWUSST ohne Auth (Container-Healthcheck und Reverse-Proxy
 // pingen das ohne Bearer-Token). Antwort enthält absichtlich nur statisch
@@ -491,6 +500,8 @@ const LISTEN_ADDR = process.env.LISTEN_ADDR
 // Wachhund auf ausbleibende Dienstkonto-Anmeldungen (Pentest R182/R183):
 // Ein stillgelegtes Gegenbuch soll auffallen, nicht als Ruhe durchgehen.
 starteHeartbeatMonitor();
+// Erkennt die ABWESENHEIT der DSGVO-/Audit-Faehigkeit (R189-01).
+void pruefePflichtrechte();
 
 app.listen(PORT as number, LISTEN_ADDR, () => {
   console.log(`Server läuft auf ${LISTEN_ADDR}:${PORT}`);

backend/src/middleware/routeIds.ts

@@ -0,0 +1,106 @@
+import { Request, Response, NextFunction, Router, RequestParamHandler } from 'express';
+import { ApiResponse } from '../types/index.js';
+
+/**
+ * Numerische Pfad-Parameter zentral pruefen (Pentest R188).
+ *
+ * Ausgangslage: In den Controllern stand 181-mal `parseInt(req.params.<x>)`
+ * ohne Pruefung. Das hatte zwei Folgen, und die zweite ist die unangenehmere:
+ *
+ *   1. Ein nicht-numerisches Segment ergab `NaN`, Prisma lief auf und der
+ *      Handler antwortete mit **500**. `GET /api/users/permissions` etwa
+ *      trifft `/:id` und war damit ein Serverfehler statt „gibt es nicht".
+ *
+ *   2. `parseInt` liest so weit, wie es kann: `parseInt('12abc')` ist **12**.
+ *      `GET /api/users/12abc` lieferte also Benutzer 12 aus. Eine schlampig
+ *      geratene ID wurde stillschweigend zu einer gueltigen gemacht.
+ *
+ * Die naheliegende Antwort waere gewesen, an allen 181 Stellen einen Guard
+ * einzusetzen. Genau daran haben wir uns in dieser Reihe mehrfach die Finger
+ * verbrannt: Was an vielen Stellen gepflegt werden muss, laeuft auseinander
+ * (zuletzt R186-01, drei Filterlisten, die dasselbe bedeuten sollten). Deshalb
+ * eine Stelle statt 181 – und eine neue Route ist automatisch mit abgedeckt.
+ *
+ * Umgesetzt ueber `router.param()`: Express ruft den Callback, bevor der
+ * Handler laeuft, und nur fuer Routen, die den Parameter wirklich benutzen.
+ *
+ * **Antwort ist 404, nicht 400.** Ein Pfad-Segment, das keine ID sein kann,
+ * benennt keine Ressource – das ist „nicht gefunden", nicht „falsch gefragt".
+ * Der Codebestand hat es an der einzigen bereits abgesicherten Stelle
+ * (`provider.controller.ts`, Pentest Mai 2026) genauso entschieden. Nebenbei
+ * verraet eine einheitliche 404 einem Probierenden nicht, ob ein Endpunkt
+ * existiert und eine Zahl erwartet oder ob es den Pfad gar nicht gibt.
+ */
+
+/**
+ * Parameternamen, die eine Datenbank-ID bezeichnen – abgeglichen mit allen
+ * Routendateien. Bewusst NICHT dabei und deshalb unberuehrt: `consentType`,
+ * `filename`, `hash`, `key`, `localPart`, `name`, `tableName`.
+ *
+ * Die Namensregel „heisst `id` oder endet auf `Id`" gilt im gesamten Bestand;
+ * eine neue Route mit `:fooId` gehoert hier ergaenzt.
+ */
+const ID_PARAMETER = [
+  'id',
+  'contractId',
+  'contractMeterId',
+  'customerId',
+  'documentId',
+  'ecdId',
+  'emailId',
+  'entryId',
+  'invoiceId',
+  'meterId',
+  'phoneNumberId',
+  'providerId',
+  'readingId',
+  'referralId',
+  'representativeId',
+  'simCardId',
+  'subtaskId',
+  'taskId',
+] as const;
+
+/** Obergrenze von MySQL INT – darueber gibt es keine Zeile, nur einen Fehler. */
+const MAX_ID = 2147483647;
+
+/**
+ * Gueltig ist ausschliesslich eine kanonische positive Ganzzahl.
+ *
+ * Fuehrende Nullen werden abgelehnt: `007` und `7` wuerden dieselbe Zeile
+ * bezeichnen, und zwei Schreibweisen fuer dieselbe Ressource sind eine
+ * unnoetige Einladung – etwa fuer Zaehler, Zwischenspeicher oder Sperren, die
+ * auf dem Pfad als Schluessel arbeiten.
+ */
+export function istGueltigeId(wert: string): boolean {
+  if (!/^[1-9][0-9]*$/.test(wert)) return false;
+  const n = Number(wert);
+  return Number.isSafeInteger(n) && n <= MAX_ID;
+}
+
+const pruefeIdParameter: RequestParamHandler = (
+  _req: Request,
+  res: Response,
+  next: NextFunction,
+  wert: unknown,
+) => {
+  if (typeof wert === 'string' && istGueltigeId(wert)) {
+    next();
+    return;
+  }
+  // Bewusst ohne Angabe, WELCHER Parameter beanstandet wurde: Die Meldung
+  // soll nicht zur Landkarte werden, welche Endpunkte welche IDs erwarten.
+  res.status(404).json({ success: false, error: 'Nicht gefunden' } as ApiResponse);
+};
+
+/**
+ * Haengt die Pruefung an einen Router. Namen, die der Router gar nicht
+ * verwendet, kosten nichts – Express ruft den Callback nur fuer Parameter,
+ * die in einer getroffenen Route vorkommen.
+ */
+export function registriereIdPruefung<T extends Router>(router: T): T {
+  for (const name of ID_PARAMETER) {
+    router.param(name, pruefeIdParameter);
+  }
+  return router;
+}

backend/src/services/audit.service.ts

@@ -909,6 +909,24 @@ export async function verifyIntegrity(fromId?: number, toId?: number): Promise<{
    * nicht mehr (siehe ausfuehrliche Begruendung an der Berechnung unten).
    */
   attestedGaps: number[];
+  /**
+   * Protokollierte Neuberechnungen der Kette (Rehash), aelteste zuerst.
+   *
+   * Ein Rehash verknuepft alle Eintraege neu. Danach ist die Kette
+   * zwangslaeufig stimmig - auch ueber Loeschungen hinweg, die vorher als
+   * Luecken sichtbar waren. „Lueckenlos verkettet“ heisst nach einem Rehash
+   * also nur noch: seit dem Rehash. Wer das nicht mitliest, nimmt eine
+   * Entwarnung mit, die es nicht gibt.
+   */
+  rehashes: Array<{
+    id: number;
+    zeitpunkt: string;
+    neuBerechnet: number | null;
+    /** Marker mit gueltiger HMAC-Signatur? Siehe Kommentar an der Auswertung. */
+    signiert: boolean;
+    /** Befund unmittelbar VOR dem Rehash - was also uebertuencht wurde. */
+    vorbefund: { manipuliert: number; luecken: number } | null;
+  }>;
   /**
    * Zustand des Bestandssiegels ueber den nicht signierbaren Altbestand.
    * `kein_siegel` = nie erstellt. `entfernt` = Blaetter vorhanden, aber kein
@@ -1044,6 +1062,68 @@ export async function verifyIntegrity(fromId?: number, toId?: number): Promise<{
   const gapErklaert = (prevId: number, curId: number) =>
     deletionRanges.some((r) => r.from <= curId && r.to >= prevId);
 
+  // ---------------------------------------------------------------------
+  // Protokollierte Neuberechnungen (Rehash) einsammeln.
+  //
+  // Ein Rehash macht die Kette rechnerisch stimmig - auch dort, wo vorher
+  // Loeschungen als Luecken sichtbar waren. Genau das ist auf Staging passiert:
+  // zwei Cleanups mit Aufbewahrung 0 entfernten 3155 Eintraege, der folgende
+  // Rehash liess rund 700 Kettenluecken verschwinden, und die Pruefung meldete
+  // danach „unveraendert und lueckenlos verkettet“. Wahr - und trotzdem das
+  // Gegenteil dessen, was ein Leser mitnimmt.
+  //
+  // Umgekehrte Beweislast als bei Manifest und Siegel: Dort zaehlen NUR
+  // signierte Traeger, weil ein gefaelschter Marker Luecken wegerklaeren
+  // koennte - Misstrauen ist die sichere Richtung. Hier erzeugt ein Marker eine
+  // WARNUNG. Wuerden wir nur signierte gelten lassen, koennte jemand einen
+  // Rehash unsichtbar machen, indem er dessen Signatur zerstoert. Deshalb
+  // zaehlt hier jeder auswertbare Marker; ob er signiert ist, wird nur
+  // mitgeteilt.
+  const rehashKandidaten = await prisma.auditLog.findMany({
+    where: { resourceType: 'AuditLog', action: 'UPDATE', endpoint: '/api/audit-logs/rehash' },
+    orderBy: { id: 'asc' },
+  });
+  const rehashSchluessel = [auditHmacKey(), ...auditHmacKeysOld()].filter(
+    (k): k is string => !!k,
+  );
+  const rehashes: Array<{
+    id: number;
+    zeitpunkt: string;
+    neuBerechnet: number | null;
+    signiert: boolean;
+    vorbefund: { manipuliert: number; luecken: number } | null;
+  }> = [];
+  for (const row of rehashKandidaten) {
+    let neuBerechnet: number | null = null;
+    let vorbefund: { manipuliert: number; luecken: number } | null = null;
+    try {
+      const nach = JSON.parse(row.changesAfter || '{}');
+      if (typeof nach.neuBerechnet !== 'number') continue; // kein Rehash-Marker
+      neuBerechnet = nach.neuBerechnet;
+      const vor = JSON.parse(row.changesBefore || '{}');
+      if (Array.isArray(vor.manipuliert) && Array.isArray(vor.ketten_luecken)) {
+        vorbefund = {
+          manipuliert: vor.manipuliert.length,
+          luecken: vor.ketten_luecken.length,
+        };
+      }
+    } catch {
+      continue;
+    }
+    const signiert =
+      row.hashVersion >= 3 &&
+      rehashSchluessel.some(
+        (k) => row.hash === generateHashV3(row as unknown as AuditHashV2Input, k),
+      );
+    rehashes.push({
+      id: row.id,
+      zeitpunkt: row.createdAt.toISOString(),
+      neuBerechnet,
+      signiert,
+      vorbefund,
+    });
+  }
+
   const tamperedEntries: number[] = [];
   const chainGaps: number[] = [];
   const unexplainedGaps: number[] = [];
@@ -1217,6 +1297,34 @@ export async function verifyIntegrity(fromId?: number, toId?: number): Promise<{
   }
   tamperedEntries.push(...backlogTampered, ...backlogMissing);
 
+  // ---------------------------------------------------------------------
+  // Fehlender ANFANG des Protokolls.
+  //
+  // Die Verkettung wird zeilenweise gegen die Vorgaengerin geprueft - die
+  // erste Zeile hat keine, also fiel bisher NICHTS auf, wenn ein
+  // zusammenhaengender Anfang entfernt wurde. Kein Kettenbruch, kein Befund,
+  // `valid` blieb gruen. Das ist die stillste Loeschung von allen: Wer die
+  // aeltesten Eintraege loswerden will, muss nur vorne anfangen.
+  //
+  // Erkennbar ist es trotzdem: Die allererste Zeile eines Protokolls wird ohne
+  // Vorgaenger geschrieben und traegt deshalb einen leeren `previousHash`.
+  // Traegt die erste vorhandene Zeile einen Wert, hat es eine Vorgaengerin
+  // gegeben - und die ist weg.
+  //
+  // Nur bei Pruefung des GESAMTEN Bereichs; bei `fromId` ist ein gefuellter
+  // `previousHash` selbstverstaendlich und kein Befund.
+  if (fromId === undefined && logs.length > 0 && logs[0].previousHash) {
+    chainGaps.push(logs[0].id);
+    // Ein protokolliertes Loeschungs-Manifest erklaert auch diese Luecke; die
+    // Pruefung laeuft ueber denselben Weg wie bei jeder anderen.
+    if (!gapErklaert(0, logs[0].id)) {
+      unexplainedGaps.push(logs[0].id);
+      if (erwarteteVersion(logs[0].id) === 3) {
+        tamperedEntries.push(logs[0].id);
+      }
+    }
+  }
+
   for (let i = 0; i < logs.length; i++) {
     const log = logs[i];
 
@@ -1349,6 +1457,7 @@ export async function verifyIntegrity(fromId?: number, toId?: number): Promise<{
     unexplainedGaps,
     unverifiableEntries,
     attestedGaps,
+    rehashes,
     backlogSealStatus,
     backlogTampered,
     backlogMissing,

backend/src/services/pflichtrechte.service.ts

@@ -0,0 +1,82 @@
+import prisma from '../lib/prisma.js';
+
+/**
+ * Prueft beim Start, ob die gesetzlich gebundenen Rechte ueberhaupt jemand
+ * ausueben kann (Pentest R189-01).
+ *
+ * Hintergrund: `gdpr:export`, `gdpr:delete` und `gdpr:admin` haengen an den
+ * Rollen DSGVO und Developer – nicht an der Admin-Rolle. Nach einem frischen
+ * Seed war keine der beiden einem Konto zugewiesen. Ergebnis: Eine Auskunft
+ * nach Art. 15 oder eine Loeschung nach Art. 17 konnte NIEMAND ausfuehren,
+ * obwohl mehrere „Admin"-Konten existierten. Ein Ausfall mit Fristwirkung,
+ * ausgeloest durch nichts weiter als eine Neuinstallation.
+ *
+ * Der Seed weist das Recht jetzt zu – aber nur bei NEUINSTALLATION. Auf einer
+ * laufenden Datenbank aendert er nichts, und niemand merkt es, bis es darauf
+ * ankommt. Deshalb diese Wache: Sie erkennt die ABWESENHEIT einer Faehigkeit,
+ * so wie der Heartbeat das Ausbleiben eines Dienstkontos erkennt.
+ *
+ * Bewusst nur eine Meldung, keine automatische Vergabe: Rechte zu verteilen,
+ * ohne dass ein Mensch es veranlasst hat, waere der groessere Fehler.
+ */
+
+/** Rechte, deren Fehlen ein rechtliches und kein technisches Problem ist. */
+const PFLICHTRECHTE: Array<{ resource: string; action: string; wofuer: string }> = [
+  { resource: 'gdpr', action: 'export', wofuer: 'Auskunft nach Art. 15 DSGVO' },
+  { resource: 'gdpr', action: 'delete', wofuer: 'Löschung nach Art. 17 DSGVO' },
+  { resource: 'audit', action: 'read', wofuer: 'Prüfung des Audit-Protokolls' },
+];
+
+export async function pruefePflichtrechte(): Promise<void> {
+  try {
+    const fehlend: string[] = [];
+
+    for (const recht of PFLICHTRECHTE) {
+      const traeger = await prisma.user.count({
+        where: {
+          isActive: true,
+          roles: {
+            some: {
+              role: {
+                permissions: {
+                  some: {
+                    permission: { resource: recht.resource, action: recht.action },
+                  },
+                },
+              },
+            },
+          },
+        },
+      });
+      if (traeger === 0) {
+        fehlend.push(`${recht.resource}:${recht.action} (${recht.wofuer})`);
+      }
+    }
+
+    if (fehlend.length === 0) return;
+
+    console.warn(
+      '\n' +
+      '========================================================================\n' +
+      '  ACHTUNG: Für folgende Rechte gibt es KEIN aktives Konto:\n' +
+      fehlend.map((f) => `    – ${f}\n`).join('') +
+      '\n' +
+      '  Das ist kein Fehler der Anwendung, sondern eine Lücke in der\n' +
+      '  Rechtevergabe – und sie fällt erst auf, wenn eine Frist läuft.\n' +
+      '\n' +
+      '  Beheben: In der Benutzerverwaltung bei einem verantwortlichen Konto\n' +
+      '  den Haken „DSGVO-Zugriff" setzen (Audit-Protokoll lesen und\n' +
+      '  Datenschutz-Verwaltung). Für Eingriffe am Protokoll – versiegeln,\n' +
+      '  aufräumen, Aufbewahrung ändern – zusätzlich „Audit-Betrieb".\n' +
+      '========================================================================\n',
+    );
+  } catch (err) {
+    // Eine Wache darf den Start nicht verhindern. Aber schweigen darf sie
+    // auch nicht: „nicht geprüft" ist nicht dasselbe wie „nichts gefunden".
+    console.warn(
+      '[Pflichtrechte] Prüfung nicht möglich – der Zustand der Rechtevergabe ist ' +
+      'damit UNBEKANNT, nicht in Ordnung:',
+      err instanceof Error ? err.message : err,
+    );
+  }
+}

docs/todo.md

@@ -97,6 +97,170 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
 
 ## ✅ Erledigt
 
+- [x] **🔢 R188: Ungültige IDs im Pfad – zentral statt 181-mal** (2026-09-03)
+  - Meldung der Pentesterin: `GET /api/users/:id` gibt bei nicht-numerischer
+    ID **500** statt 400 (`/api/users/permissions` trifft `/:id`). Ihr Patch
+    setzt einen Guard in `getUser`.
+  - **Berechtigt – und größer als gemeldet.** Ihr Fix schließt nebenbei etwas,
+    das sie nicht beansprucht: `parseInt('12abc')` ergibt **12**, also lieferte
+    `GET /api/users/12abc` bisher Benutzer 12 aus. Und es waren **181**
+    ungeprüfte Stellen in 19 Controllern, nicht eine.
+  - 181 Einzel-Guards wären genau der Fehler aus R186-01 gewesen (drei
+    Filterlisten, die auseinanderliefen). Stattdessen `router.param()`, an
+    **einer** Stelle für alle 33 Router registriert – über einen `mounte()`-
+    Helfer, der Prüfung und Einhängen zusammenbindet. Wer künftig `app.use`
+    schreibt statt `mounte`, umgeht sie nicht versehentlich, sondern sichtbar.
+  - **Antwort ist 404, nicht 400:** Ein Pfadsegment, das keine ID sein kann,
+    benennt keine Ressource. Der bestehende Präzedenzfall
+    (`provider.controller.ts`, Pentest Mai 2026) hatte es genauso entschieden.
+  - **Eine ältere Heuristik abgelöst** (Pentest Runde 7): Sie blockte
+    `^\d+[a-zA-Z]+$` im Pfad – ihr eigener Kommentar nannte den Grund,
+    „`app.param()` greift nicht auf in Sub-Router gemounteten Routes", und
+    genau das löst `mounte()`. Sie war **zu eng** (`/users/abc` ging durch →
+    500) und **zu weit** (ein Einstellungs-Schlüssel `12abc` unter `:key` wurde
+    geblockt, obwohl das keine ID ist), und sie antwortete 400, wo jetzt 404
+    steht – zwei Antworten für dieselbe Eingabeklasse.
+  - Getestet über HTTP: `abc`, `permissions`, `12abc`, `6abc`, `0`, `-1`,
+    `007`, `1e3`, Überlauf, `1;DROP` → alle **404**; `1` → 200. Quer über
+    sechs Controller gleich. Nicht-ID-Parameter (`roles/list`,
+    `permissions/list`, `settings/:key`) unverändert.
+  - Dateien: `backend/src/middleware/routeIds.ts` (neu), `backend/src/index.ts`
+
+- [x] **⚖️ R189-01: DSGVO-Rechte hingen an keinem Konto** (2026-09-03)
+  - Meldung: `gdpr:*` und `audit:read/export` hängen an den Rollen DSGVO und
+    Developer – die Admin-Rolle hat sie **nicht**, und nach einem frischen Seed
+    war DSGVO **keinem Konto** zugewiesen. Auskunft nach Art. 15 und Löschung
+    nach Art. 17 konnte damit niemand ausführen. Ausfall mit Fristwirkung.
+  - Seed weist `admin@admin.com` jetzt zusätzlich die DSGVO-Rolle zu. Die
+    Admin-**Rolle** bekommt diese Rechte weiterhin nicht – die Trennung aus
+    R186 bleibt, nur das eine Bootstrap-Konto trägt beides.
+  - Label ehrlich gemacht: „Voller Zugriff auf alle **Fachfunktionen** (ohne
+    Audit & Datenschutz – dafür die separaten Rollen DSGVO und Audit-Betrieb)".
+  - **Eigener Fund beim Prüfen ihres Patches:** `seed.ts` vergab an die
+    DSGVO-Rolle weiterhin `audit:*` **komplett**, inklusive `audit:admin` –
+    also die Bündelung, die in `fc6f39e` aufgelöst wurde. Ich hatte damals zwei
+    Listen gefunden (`sync-roles.ts`, `user.service.ts`) und die dritte
+    übersehen. Gerettet hat es nur die Reihenfolge im Containerstart; ein
+    einzelnes `npm run db:seed` brachte sie zurück. Korrigiert.
+  - **Der Seed hilft aber nur bei Neuinstallation** (`update: {}`). Deshalb
+    zusätzlich eine Wache beim Start: Gibt es für `gdpr:export`, `gdpr:delete`
+    oder `audit:read` **kein aktives Konto**, steht das mit Handlungsanweisung
+    im Log. Erkennt die *Abwesenheit* einer Fähigkeit – dasselbe Muster wie der
+    Heartbeat. Bewusst nur melden, nicht automatisch vergeben.
+  - Getestet: frischer Seed → Admin hat `audit:read, audit:export, gdpr:*` und
+    **kein** `audit:admin`. Rolle entzogen → Warnung erscheint mit allen drei
+    Rechten. Rolle zurück → still.
+  - Dateien: `backend/prisma/seed.ts`, `backend/prisma/sync-roles.ts`,
+    `backend/src/services/pflichtrechte.service.ts` (neu), `backend/src/index.ts`
+
+- [x] **🕳️ Entfernter Protokoll-ANFANG wurde nicht erkannt** (2026-08-26)
+  - Gefunden bei der Vorbereitung des Prod-Siegels: Die Verkettung wird
+    zeilenweise gegen die Vorgängerin geprüft – die **erste** Zeile hat keine,
+    also fiel bisher **nichts** auf, wenn ein zusammenhängender Anfang des
+    Protokolls entfernt wurde. Kein Kettenbruch, kein Befund, `valid` blieb
+    grün. Die stillste Löschung von allen: Wer die ältesten Einträge loswerden
+    will, muss nur vorne anfangen.
+  - Erkennbar ist es trotzdem: Die allererste Zeile wird ohne Vorgänger
+    geschrieben und trägt einen leeren `previousHash`. Trägt die erste
+    **vorhandene** Zeile einen Wert, hat es eine Vorgängerin gegeben – und die
+    ist weg. Wird jetzt als Kettenlücke an dieser Zeile geführt, mit derselben
+    Manifest- und Beglaubigungslogik wie jede andere Lücke.
+  - Nur bei Prüfung des Gesamtbereichs; mit `fromId` ist ein gefüllter
+    `previousHash` selbstverständlich (gegengeprüft, kein Fehlalarm).
+  - Getestet über HTTP: vollständiges Protokoll → `valid:true`; erste drei
+    Zeilen entfernt → **vorher** unverändert `valid:true`, **jetzt**
+    `valid:false`, `chainGaps:[4]`, wegen Hash-Version 3 zusätzlich als
+    Manipulation eskaliert.
+  - Auf Prod ausgeschlossen: Das Protokoll beginnt bei ID 1 (07.05.2026,
+    Inbetriebnahme), kein Cleanup, keine Neuberechnung.
+  - Datei: `backend/src/services/audit.service.ts`
+
+- [x] **⏱️ Neuberechnung der Kette ist jetzt eine eigene Gegenbuch-Alarmbedingung (Pentest R186, Frage b)** (2026-08-26)
+  - Der Tester fragte präzise: Löst `cleanup` → `rehash` **ohne** erneutes
+    Siegeln, über **nicht versiegelten** Inhalt, etwas **Automatisches** aus –
+    oder nur die Prosa in `verify`, die ein Mensch lesen muss?
+  - **Gemessen statt behauptet:** Es löste bereits aus, aber als *Nebenwirkung*.
+    Ein Rehash ändert jeden Hash, also stimmt der beglaubigte Kettenkopf nicht
+    mehr und der bestehende Vergleich schlug an. Funktioniert – ist aber ein
+    Zufallstreffer: Verschöbe sich der Anker, wäre der Melder lautlos weg. Und
+    die Meldung hieß „Eintrag wurde verändert" statt „die Kette wurde neu
+    berechnet", also Wirkung statt Ursache.
+  - Jetzt hängt der Alarm an der Sache selbst: Das Gegenbuch führt
+    `rehashCount`/`rehashLast` im Buch mit und meldet jede neue Neuberechnung
+    seit der letzten Beglaubigung mit **exit 2** – samt Zeitpunkt, Zeilenzahl
+    und dem Befund, der unmittelbar davor galt. Dieselbe Lehre wie R184-01
+    (Gate am Auslöser, nicht an der Wirkung) und R185-01 (Wurzelwechsel statt
+    `valid`).
+  - **Reihenfolge geändert, und das war nötig:** Der neue Melder steht **vor**
+    dem Kopf-Hash-Vergleich, sonst hätte immer die unpräzisere Meldung
+    gewonnen. Und der Kopf-Vergleich wird nach einer *bestätigten*
+    Neuberechnung übersprungen – sonst wäre die Bestätigung wertlos gewesen,
+    weil ein Rehash den Kopf zwangsläufig ändert. Beim Bauen aufgefallen, nicht
+    im Entwurf.
+  - `NOTARY_REHASH_ACK` wird mit der **ID des Rehash-Eintrags** bestätigt, nicht
+    mit `true`. IDs steigen streng – ein stehen gelassener Wert passt beim
+    nächsten Vorgang nicht mehr. Analog zu `NOTARY_SEAL_ACK`.
+  - Ein **fehlender** beglaubigter Eintrag alarmiert weiterhin immer: Bestätigt
+    wird die Neuberechnung, nicht das Verschwinden von Zeilen.
+  - Bestandsbücher ohne das neue Feld alarmieren nicht rückwirkend, sondern
+    setzen die Grundlage – mit Ausgabe, statt es stillschweigend zu tun.
+  - **Getestet mit echtem Gegenbuch gegen ein echtes CRM** (SSH-signiertes
+    lokales Buch): Wäsche ohne Datenbankzugriff (3 Zeilen gelöscht → Rehash)
+    → CRM meldet `valid:true`, `chainGaps:[]`; Gegenbuch **exit 2** und nennt
+    die Neuberechnung als Ursache. Falsche Ack-ID → weiter exit 2, richtige →
+    exit 0 mit neuer Grundlage, Folgelauf ruhig.
+  - Dateien: `tools/audit-notary/notary.mjs`,
+    `tools/audit-notary/{docker-compose.yml,.env.example,README.md}`
+
+- [x] **🔍 `verify` meldet jetzt, dass die Kette neu berechnet wurde** (2026-08-26)
+  - **Im Betrieb entdeckt, nicht im Test.** Das Staging-Gegenbuch meldete
+    „Der beglaubigte Eintrag 5352 existiert nicht mehr". Rekonstruktion aus dem
+    Protokoll: am 22.08. wurden die Aufbewahrungsfristen auf **0** gesetzt,
+    zwei Cleanups löschten **3.155** Einträge (id 1–5356), danach lief ein
+    **Rehash**. Seither meldet die Prüfung „Alle Einträge sind unverändert und
+    **lückenlos** verkettet".
+  - Wahr – und praktisch das Gegenteil dessen, was ein Leser mitnimmt. Der
+    Rehash verknüpft alles neu; die rund **700** Kettenlücken, die davor
+    bestanden, sind seitdem unsichtbar. Nachweisbar im Vorbefund, den der
+    Rehash selbst mitschreibt (R170-01) – nur schaute den nie jemand an.
+  - Das Gegenbuch war der einzige Zeuge. Innerhalb des CRM war die Löschung
+    nicht mehr feststellbar.
+  - `verifyIntegrity` sammelt jetzt die Rehash-Marker; die Antwort enthält
+    `rehashes[]` (Zeitpunkt, Anzahl, Signatur, Vorbefund). Die Meldung nennt
+    sie **immer**, auch im grünen Fall, und der Einstiegssatz lautet dann
+    „…lückenlos verkettet – allerdings erst seit der letzten Neuberechnung".
+  - **`valid` bleibt unberührt.** Ein Rehash ist eine legitime Maßnahme; ihn
+    dauerhaft als Befund zu führen wäre der Dauer-Alarm, den wir mit den
+    beglaubigten Lücken gerade beseitigt haben. Melden, nicht alarmieren.
+  - **Umgekehrte Beweislast als bei Manifest und Siegel:** Dort zählen nur
+    signierte Träger, weil ein gefälschter Marker Lücken *wegerklären* könnte.
+    Hier erzeugt ein Marker eine *Warnung* – würden nur signierte zählen,
+    könnte man einen Rehash unsichtbar machen, indem man seine Signatur
+    zerstört. Deshalb zählt jeder auswertbare Marker; fehlende Signatur wird
+    zusätzlich gemeldet.
+  - Getestet über HTTP gegen eine Wegwerf-DB, mit echtem Rehash über den
+    regulären Endpunkt: sauberer Vorzustand → „es wurde nichts überdeckt";
+    Löschung + Rehash (der Staging-Ablauf im Kleinen) → `chainGaps` fällt von
+    1 auf 0, die Meldung nennt Zeitpunkt und Vorbefund; zerstörte Signatur →
+    Marker wird weiterhin gemeldet, mit Hinweis.
+  - Dateien: `backend/src/services/audit.service.ts`,
+    `backend/src/controllers/auditLog.controller.ts`,
+    `frontend/src/services/api.ts`,
+    `frontend/src/pages/settings/AuditIntegrityCard.tsx`
+
+- [x] **📄 `status.txt` nennt jetzt den Grund, nicht nur das Etikett** (2026-08-26)
+  - In der Statusdatei des Gegenbuchs stand für **jeden** Exit-2 derselbe Satz:
+    „BEFUND – Widerspruch zwischen CRM und Gegenbuch". Ein echter Widerspruch
+    sah damit genauso aus wie eine quittierpflichtige Erstsiegelung.
+  - Aufgefallen im Betrieb: Der Betreiber las „BEFUND" auf Staging und konnte
+    nicht entscheiden, ob er handeln muss – obwohl die Kette dort `valid:true`
+    meldet und der Alarm nur den erwarteten Siegelwechsel betraf. Wer nur die
+    Statusdatei liest (und dafür ist sie da – „damit eine Überwachung sie
+    abgreifen kann, ohne Logs zu durchsuchen"), bekam ein Etikett ohne Inhalt.
+  - Der Lauf wird jetzt mitgeschnitten; die erste `ALARM:`-Zeile landet als
+    `Grund:` in `status.txt`. Ohne Alarm die erste Ausgabezeile.
+  - Datei: `tools/audit-notary/entrypoint.sh`
+
 - [x] **⚖️ Aufsicht und Eingriff getrennt: neuer Haken „Audit-Betrieb"** (2026-08-26)
   - Die DSGVO-Rolle trug `audit:*` **komplett**, also auch `audit:admin`. Ein
     DSGVO-Beauftragter konnte damit `seal-backlog`, `rehash` und `cleanup` –

frontend/src/pages/settings/AuditIntegrityCard.tsx

@@ -126,7 +126,12 @@ export default function AuditIntegrityCard() {
             <div className={`flex items-start gap-4 p-4 rounded-lg border ${stil.box}`}>
               <AmpelIcon ampel={ampel} />
               <div className="min-w-0">
-                <p className={`font-medium ${stil.titel}`}>{AMPEL_TITEL[ampel]}</p>
+                <p className={`font-medium ${stil.titel}`}>
+                  {AMPEL_TITEL[ampel]}
+                  {ampel === 'ok' && ergebnis.rehashes.length > 0 && (
+                    <span className="font-normal"> – seit der letzten Neuberechnung</span>
+                  )}
+                </p>
                 <p className={`text-sm mt-1 ${stil.text}`}>{ergebnis.message}</p>
                 <p className="text-sm text-gray-500 mt-2">
                   {ergebnis.checkedCount.toLocaleString('de-DE')} Einträge geprüft ·
@@ -156,9 +161,36 @@ export default function AuditIntegrityCard() {
                 <Zahl label="Ohne Schlüssel nicht prüfbar" ids={ergebnis.unverifiableEntries} ton="text-gray-700" />
                 {ergebnis.tamperedEntries.length === 0 &&
                   ergebnis.chainGaps.length === 0 &&
-                  ergebnis.unverifiableEntries.length === 0 && (
+                  ergebnis.unverifiableEntries.length === 0 &&
+                  ergebnis.rehashes.length === 0 && (
                     <p className="text-sm text-gray-500 italic">Nichts zu berichten.</p>
                   )}
+                {ergebnis.rehashes.length > 0 && (
+                  <div className="pt-2 border-t mt-2">
+                    <p className="text-sm font-medium text-gray-700">Neuberechnungen der Kette</p>
+                    {ergebnis.rehashes.map((r) => (
+                      <p key={r.id} className="text-sm text-gray-600 mt-1">
+                        {new Date(r.zeitpunkt).toLocaleString('de-DE')} · Eintrag {r.id}
+                        {r.neuBerechnet !== null && ` · ${r.neuBerechnet} Einträge neu verkettet`}
+                        {r.vorbefund && (
+                          <span className="text-gray-500">
+                            {' '}· davor: {r.vorbefund.manipuliert} beanstandet,{' '}
+                            {r.vorbefund.luecken} Lücken
+                          </span>
+                        )}
+                        {!r.signiert && (
+                          <span className="text-red-700"> · ohne gültige Signatur</span>
+                        )}
+                      </p>
+                    ))}
+                    <p className="text-xs text-gray-500 mt-2">
+                      Ein Rehash verknüpft alle Einträge neu. Was davor als Lücke oder
+                      Beanstandung sichtbar war, ist danach nicht mehr in der Kette zu sehen –
+                      nur noch im Vorbefund des jeweiligen Eintrags. Die Aussage dieser Prüfung
+                      reicht deshalb bis zur letzten Neuberechnung zurück, nicht weiter.
+                    </p>
+                  </div>
+                )}
                 <p className="text-xs text-gray-500 pt-2">
                   <strong>Verändert</strong> heißt: der Inhalt einer bestehenden Zeile passt nicht
                   mehr zu ihrer Prüfsumme – das ist ernst.

frontend/src/services/api.ts

@@ -1749,6 +1749,18 @@ export interface IntegrityResult {
   unexplainedGaps: number[];
   /** Alt-Luecken, die das Bestandssiegel als bereits vorhanden beglaubigt. */
   attestedGaps: number[];
+  /**
+   * Protokollierte Neuberechnungen der Kette. Nach einem Rehash ist die Kette
+   * zwangslaeufig stimmig - auch ueber Loeschungen hinweg. Die Aussage der
+   * Pruefung reicht dann nur bis zur letzten Neuberechnung zurueck.
+   */
+  rehashes: Array<{
+    id: number;
+    zeitpunkt: string;
+    neuBerechnet: number | null;
+    signiert: boolean;
+    vorbefund: { manipuliert: number; luecken: number } | null;
+  }>;
   /** Signierte Zeilen, die ohne AUDIT_HMAC_KEY nicht pruefbar sind. */
   unverifiableEntries: number[];
   backlogSealStatus: 'kein_siegel' | 'intakt' | 'leer' | 'gebrochen' | 'entfernt' | 'nicht_noetig';

tools/audit-notary/.env.example

@@ -67,6 +67,15 @@ PROD_ADOPT_ACK=
 # durchwinken.
 PROD_SEAL_ACK=
 
+# Normalerweise leer lassen.
+# Gültige Werte:  die ID des Rehash-Eintrags  |  (leer)
+# Das Gegenbuch schlägt Alarm, wenn die Hash-Kette neu berechnet wurde. Ein
+# Rehash verknüpft alle Einträge neu – Lücken, die eine Löschung sichtbar
+# gemacht hätten, verschwinden dabei aus der Kette, und die Prüfung im CRM
+# meldet danach wieder „lückenlos". War die Neuberechnung geplant, hier die
+# ID eintragen, die der Alarm nennt, einmal laufen lassen und wieder leeren.
+PROD_REHASH_ACK=
+
 # Wo das Buch liegt – relativ zu diesem Verzeichnis.
 # DIESES VERZEICHNIS GEHÖRT INS BACKUP (enthält Buch und Signaturschlüssel).
 PROD_DIR=./data/prod
@@ -83,4 +92,5 @@ STAGING_INTERVAL=3600
 STAGING_GENESIS_ACK=
 STAGING_ADOPT_ACK=
 STAGING_SEAL_ACK=
+STAGING_REHASH_ACK=
 STAGING_DIR=./data/staging

tools/audit-notary/README.md

@@ -11,6 +11,37 @@ kurzen Kontrollwert vom CRM, prüft ihn gegen seine eigene Historie und schreibt
 ihn signiert fort. Wird später im CRM etwas nachträglich verändert,
 widerspricht das dem Gegenbuch.
 
+## Was du hier suchst
+
+**Einrichten**
+[Betriebsart wählen](#zwei-betriebsarten--erst-hier-entscheiden) ·
+[mit Docker](#einrichten-mit-docker-empfohlen) ·
+[erster Start](#erster-start--drei-schritte) ·
+[Zugangskonto im CRM](#zugang-einrichten-das-brauchst-du-vorher) ·
+[ohne Docker](#einrichten-ohne-docker)
+
+**Im Betrieb**
+[**Altbestand versiegeln**](#den-altbestand-versiegeln-einmalig-im-crm) ·
+[Rückgabecodes](#rückgabecodes) ·
+[Überwachung](#überwachung) ·
+[wo die Daten liegen](#wo-die-daten-liegen)
+
+**Wenn Alarm kommt**
+[Siegelwurzel hat gewechselt](#wenn-sich-die-siegelwurzel-ändert-alarm-und-warum) ·
+[Kette wurde neu berechnet](#wenn-die-kette-neu-berechnet-wurde-ebenfalls-alarm) ·
+[Zurückspulen erkannt](#der-rewind-wächter) ·
+[Gedächtnis fehlt](#wenn-das-gedächtnis-trotzdem-fehlt)
+
+**Zum Nachlesen**
+[was erkannt wird](#was-das-skript-erkennt) ·
+[was nicht – ehrlich](#was-es-nicht-leistet--ehrlich) ·
+[Prüfmodus für Auditoren](#prüfmodus-für-auditoren)
+
+> **Nur schnell versiegeln?** Der Abschnitt
+> [Altbestand versiegeln](#den-altbestand-versiegeln-einmalig-im-crm) ist
+> eigenständig und gilt **auch ohne Gegenbuch** – es ist ein Vorgang im CRM,
+> nicht hier.
+
 ## Zwei Betriebsarten – erst hier entscheiden
 
 | | **Lokal** (Normalfall) | **Mit externem Repository** |
@@ -86,57 +117,128 @@ soll nicht versehentlich passieren.
 getrennte Dienste mit getrennten Verzeichnissen und getrennten Schlüsseln.
 Welche laufen, steuert `COMPOSE_PROFILES` in der `.env`.
 
-### Wenn der erste Lauf `exit=2` meldet: den Altbestand versiegeln
+### Den Altbestand versiegeln (einmalig, im CRM)
 
 Ein CRM, das schon länger läuft, hat fast immer einen **Altbestand** – Einträge
 aus der Zeit, bevor das Protokoll signiert wurde. Solange der nicht versiegelt
-ist, meldet die Prüfung `valid: false`, und das Gegenbuch schlägt zu Recht
-Alarm. Typischerweise steht dann im Log:
+ist, meldet die Prüfung `valid: false`, das Gegenbuch schlägt zu Recht Alarm –
+und, wichtig: **es beglaubigt so lange gar nichts.** Es bricht vor dem Anhängen
+ab, weil ein Checkpoint über einen ungeklärten Zustand diesen mitbeglaubigen
+würde. Ein unversiegeltes CRM ist also nicht „bewacht mit Warnung", sondern
+unbewacht.
 
-    Hinweis: Der Altbestand ist nicht versiegelt – Änderungen daran wären
-    nicht erkennbar.
+Das Siegeln ist **einmalig** und passiert im CRM, nicht hier.
 
-Das ist **einmalig** zu erledigen, im CRM, nicht hier:
+#### Wer darf das
+
+Das Recht `audit:admin`. Das bekommt man über den Haken **„Audit-Betrieb"** in
+der Benutzerverwaltung – **nicht** über die Admin-Rolle (die hat bewusst keine
+Audit-Rechte) und **nicht** über den DSGVO-Haken (der darf lesen, nicht
+eingreifen). Das Gegenbuch-Dienstkonto hat es erst recht nicht.
 
 ```bash
-TOKEN=$(curl -s -X POST https://<crm>/api/auth/login \
-  -H 'Content-Type: application/json' \
-  -d '{"email":"…","password":"…"}' | jq -r '.data.token')
-
-curl -s -X POST https://<crm>/api/audit-logs/seal-backlog \
-  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
-  -d '{"confirm":"SEAL"}' | jq
+CRM=https://<crm>
+read -s -p "Passwort: " PASS; echo
+AT=$(curl -s -X POST $CRM/api/auth/login -H 'Content-Type: application/json' \
+  -d "{\"email\":\"…\",\"password\":\"$PASS\"}" | jq -r '.data.token')
+curl -s -X POST $CRM/api/auth/login -H 'Content-Type: application/json' \
+  -d "{\"email\":\"…\",\"password\":\"$PASS\"}" | jq -r '.data.user.permissions[]' | grep audit
 ```
 
-Dafür braucht es das Recht `audit:admin` – das Gegenbuch-Dienstkonto hat es
-absichtlich **nicht**. Nimm dein Administratorkonto.
+Muss `audit:read` **und** `audit:admin` zeigen.
 
-**Zuerst nachsehen, was versiegelt wird.** Das Siegel schreibt den aktuellen
-Zustand fest, samt aller vorhandenen Lücken. Wer blind siegelt, beglaubigt
-gegebenenfalls auch eine Lücke, die von einer Löschung stammt. Deshalb vorher:
+#### Erst nachsehen, was du festschreibst
+
+Das Siegel hält den **aktuellen** Zustand fest, samt aller vorhandenen Lücken.
+Wer blind siegelt, beglaubigt womöglich eine Lücke, die von einer Löschung
+stammt. Der Schritt ist praktisch einwegs: Danach ist die Beglaubigung tragend,
+und ein Siegel wieder zu entfernen erzeugt den Zustand `entfernt` – also selbst
+einen Befund.
 
 ```bash
-curl -s -X POST https://<crm>/api/audit-logs/verify \
-  -H "Authorization: Bearer $TOKEN" \
-  | jq '.data | {valid, chainGaps, unexplainedGaps, tamperedEntries}'
+B="Authorization: Bearer $AT"
+curl -s -X POST $CRM/api/audit-logs/verify -H "$B" \
+  | jq '.data | {valid, checkedCount, rehashes, chainGaps, unexplainedGaps,
+                 tamperedEntries, backlogSealStatus}'
 ```
 
-Stehen dort Lücken, sieh dir die betroffenen IDs und ihre Nachbarn an
-(`GET /api/audit-logs/<id>`). Liegen sie jeweils **innerhalb einer Sekunde**
-zusammen mit ihren Nachbarn und fehlt kein Eintrag (kein `404`), sind es
-Schreibkollisionen aus paralleln Anfragen – harmlos. Fehlt dagegen ein Eintrag
-oder steht etwas in `tamperedEntries`, **erst klären, dann siegeln**.
+Vier Dinge müssen stimmen:
 
-Nach dem Siegeln meldet die Prüfung wieder `valid: true`, und die bekannten
-Alt-Lücken erscheinen als **beglaubigt**:
+| Feld | Erwartung | Warum |
+|---|---|---|
+| `rehashes` | `[]` | Eine Neuberechnung verknüpft alles neu – danach ist die Kette *zwangsläufig* stimmig, auch über Löschungen hinweg. Steht hier etwas, sagt `chainGaps` nichts über die Zeit davor aus. |
+| `tamperedEntries` | `[]` | Veränderter Inhalt gehört geklärt, nicht beglaubigt. |
+| `chainGaps` | erklärbar | siehe unten |
+| `backlogSealStatus` | `kein_siegel` | sonst ist es kein Erst-Siegeln (siehe nächster Abschnitt) |
 
-    Alle Einträge sind unverändert. Seit dem Bestandssiegel ist keine neue
-    Lücke entstanden. 6 Lücken stammen aus der Zeit vor dem Bestandssiegel
-    und sind darin als Vorbefund beglaubigt (IDs …).
+**Lücken einordnen.** Sieh dir die betroffenen IDs und ihre Nachbarn an:
 
-Sie verschwinden also nicht aus dem Bericht – sie zählen nur nicht mehr als
-offener Befund. Jede **neue** Lücke, jede veränderte oder entfernte Altzeile
-und jedes gebrochene Siegel lösen weiterhin sofort Alarm aus.
+```bash
+for id in <lücke-1> <nachbar> …; do
+  printf '%-6s ' "$id"
+  curl -s -o /tmp/r.json -w 'HTTP %{http_code}  ' "$CRM/api/audit-logs/$id" -H "$B"
+  jq -r 'if .success then (.data|"\(.createdAt[0:19])  v\(.hashVersion)  \(.action)/\(.resourceType)") else .error end' /tmp/r.json
+done
+```
+
+> **Den HTTP-Code mit ausgeben, immer.** Zugangstoken laufen nach 15 Minuten ab.
+> Ohne den Code liest sich eine abgelehnte Anfrage (401) wie ein fehlender
+> Eintrag – ein Prüfwerkzeug, das ein verweigertes Lesen als Löschung meldet.
+> Uns ist genau das passiert, mitten in der Vorbereitung eines Prod-Siegels.
+
+Liegen die Lücken jeweils **innerhalb einer Sekunde** zusammen mit ihren
+Nachbarn, betreffen nur `Authentication` und fehlt kein Eintrag, sind es
+Schreibkollisionen aus parallelen Anfragen – harmlos, historisch, nicht mehr
+reproduzierbar. Fehlt dagegen ein Eintrag oder passt eine Lücke nicht in dieses
+Bild: **erst klären, dann siegeln.**
+
+*(Ein abgeschnittener **Anfang** des Protokolls wird seit dem Anfangs-Detektor
+mitgeprüft: Die erste Zeile eines Protokolls trägt einen leeren `previousHash`;
+trägt die erste vorhandene Zeile einen Wert, fehlt eine Vorgängerin. Das
+erscheint als ganz niedrige Lücke und kippt `valid` – du musst es nicht selbst
+suchen.)*
+
+#### Siegeln
+
+```bash
+curl -s -X POST $CRM/api/audit-logs/seal-backlog -H "$B" \
+  -H 'Content-Type: application/json' -d '{"confirm":"SEAL"}' | jq
+```
+
+`SEAL` ist das Erst-Siegeln. Besteht bereits ein Siegel, verlangt der Endpunkt
+stattdessen `RESEAL` – siehe nächster Abschnitt. Notiere `root` aus der Antwort.
+
+#### Danach: drei Punkte gegenprüfen
+
+```bash
+curl -s -X POST $CRM/api/audit-logs/verify -H "$B" \
+  | jq '.data | {valid, chainGaps, attestedGaps, backlogSealStatus, backlogSealCount}'
+
+SID=$(curl -s "$CRM/api/audit-logs?resourceType=AuditBacklogSeal&limit=1" -H "$B" | jq -r '.data[0].id')
+curl -s "$CRM/api/audit-logs/$SID" -H "$B" \
+  | jq '{vorbefund:.data.changesBefore.befund.ketten_luecken, siegel:.data.changesAfter}'
+```
+
+1. `valid: true`, und `chainGaps` = `attestedGaps` = die bekannten Lücken
+2. `backlogSealStatus: "intakt"` – **nicht** `leer`. `leer` heißt: Das Siegel
+   umschließt nichts, es gab keinen Altbestand. Kein Fehler, aber auch keine
+   Zusage.
+3. Die Lücken stehen im `changesBefore.befund.ketten_luecken` des Markers –
+   genau daran hängt die Beglaubigung.
+
+Die Lücken verschwinden also **nicht** aus dem Bericht. Sie zählen nur nicht
+mehr als offener Befund. Jede **neue** Lücke, jede veränderte oder entfernte
+Altzeile und jedes gebrochene Siegel lösen weiterhin sofort Alarm aus.
+
+#### Zuletzt: das Gegenbuch quittieren
+
+Der nächste Lauf meldet **einmal** `exit=2` („Erstmals ein Bestandssiegel
+gesetzt") – erwartet, kein Befund. Wurzel aus `data/<instanz>/status.txt` in
+`PROD_SEAL_ACK` bzw. `STAGING_SEAL_ACK` eintragen, `docker compose up -d`, nach
+dem Lauf mit `exit=0` wieder leeren. Details im nächsten Abschnitt.
+
+Ab da schreibt das Gegenbuch wieder Checkpoints fort – und setzt im selben Lauf
+die Grundlage für die Rehash-Überwachung.
 
 ### Wenn sich die Siegelwurzel ändert: Alarm, und warum
 
@@ -177,6 +279,58 @@ Im CRM selbst ist erneutes Siegeln zusätzlich gegatet: es verlangt
 `{"confirm":"RESEAL"}` statt `{"confirm":"SEAL"}` — ein Austausch der
 Beweisgrundlage soll nicht dasselbe Wort haben wie das Einrichten.
 
+### Wenn die Kette neu berechnet wurde: ebenfalls Alarm
+
+Ein **Rehash** verknüpft alle Einträge neu. Danach ist die Kette
+zwangsläufig stimmig — auch über Löschungen hinweg, die vorher als Lücken
+sichtbar gewesen wären. Die Reihenfolge `cleanup` → `rehash` macht aus einem
+beschnittenen Protokoll ein scheinbar makelloses, und die Prüfung im CRM meldet
+danach wieder „lückenlos verkettet". Beides braucht nur `audit:admin`, keinen
+Datenbankzugriff.
+
+Genau das ist im Betrieb vorgekommen: Auf einer Testinstanz wurden 3.155
+Einträge gelöscht und anschließend neu berechnet. Die Prüfung war danach grün,
+die 656 Kettenlücken standen nur noch im Vorbefund des Rehash-Eintrags — den
+niemand liest. Das Gegenbuch war der einzige Zeuge.
+
+Deshalb ist eine neue Neuberechnung seit der letzten Beglaubigung ein **Alarm**
+(exit 2). Er nennt Zeitpunkt, Zahl der betroffenen Zeilen und den Befund, der
+unmittelbar davor galt:
+
+```
+ALARM: Die Hash-Kette wurde neu berechnet (1 neuer Vorgang seit der letzten Beglaubigung).
+  zuletzt: 2026-08-26T16:28:25.467Z (Eintrag 13, 9 Zeilen)
+  Befund unmittelbar davor: 1 beanstandet, 1 Lücken
+  …
+  NOTARY_REHASH_ACK=13
+```
+
+**War die Neuberechnung gewollt**, bestätigst du sie mit der genannten ID:
+
+```bash
+# in der .env
+PROD_REHASH_ACK=13
+docker compose up -d
+PROD_REHASH_ACK=          # danach wieder leeren
+```
+
+Auch hier wird nicht mit `true` bestätigt, sondern mit einem Wert, der zum
+Vorgang gehört. IDs steigen streng — ein stehen gelassener Wert passt bei der
+nächsten Neuberechnung nicht mehr.
+
+**Warum ein eigener Melder, wo doch schon der Kettenkopf verglichen wird?**
+Eine Neuberechnung ändert jeden Hash, der beglaubigte Kopf stimmt also
+ohnehin nicht mehr — der Alarm käme auch so. Aber als *Nebenwirkung*, nicht als
+gebaute Warnung: Verschöbe sich der Anker irgendwann, wäre der Melder lautlos
+weg. Und die Meldung hieße „Eintrag wurde verändert" statt „die Kette wurde neu
+berechnet" — die Wirkung statt der Ursache. Deshalb hängt der Alarm an der
+Sache selbst und steht **vor** dem Kopf-Vergleich; nach einer bestätigten
+Neuberechnung wird dieser übersprungen, weil der veränderte Kopf dann die
+erwartete Folge ist.
+
+Ein fehlender beglaubigter Eintrag bleibt davon unberührt und alarmiert immer:
+Bestätigt wird die Neuberechnung, nicht das Verschwinden von Zeilen.
+
 ### Zugang einrichten (das brauchst du vorher)
 
 Das Gegenbuch braucht ein **eigenes Benutzerkonto** im CRM – kein Token. Der
@@ -556,6 +710,7 @@ an, bis er geklärt ist.
 | Bestandssiegel-Blätter entfernt | beglaubigte Blattzahl auf null gefallen |
 | **Altzeile gelöscht und neu gesiegelt** (Wäsche) | **Wurzel des Bestandssiegels hat gewechselt – `valid` allein bleibt dabei `true`** |
 | Erstmals gesiegelt, ohne dass es jemand veranlasst hat | vorher keine Wurzel beglaubigt, jetzt eine |
+| **`cleanup` + `rehash` ohne erneutes Siegeln** (Wäsche ohne Datenbankzugriff) | **neue Neuberechnung seit der letzten Beglaubigung – `valid` und Kette sind danach makellos** |
 
 Bei jedem dieser Fälle bricht das Skript mit **Exit-Code 2** ab und **hängt
 nichts an** – der manipulierte Zustand wird also nicht als neue Wahrheit

tools/audit-notary/docker-compose.yml

@@ -36,6 +36,8 @@ services:
       NOTARY_ADOPT_ACK: ${PROD_ADOPT_ACK:-}
       # Nur nach einem GEWOLLTEN Siegelwechsel, mit der neuen Wurzel:
       NOTARY_SEAL_ACK: ${PROD_SEAL_ACK:-}
+      # Nur nach einer GEWOLLTEN Neuberechnung, mit der ID des Rehash-Eintrags:
+      NOTARY_REHASH_ACK: ${PROD_REHASH_ACK:-}
     volumes:
       # Buch, Schlüssel, Beobachtungsspeicher und Statusdatei.
       # Dieses Verzeichnis ist das Gegenbuch – es gehört ins Backup.
@@ -56,5 +58,6 @@ services:
       NOTARY_GENESIS_ACK: ${STAGING_GENESIS_ACK:-}
       NOTARY_ADOPT_ACK: ${STAGING_ADOPT_ACK:-}
       NOTARY_SEAL_ACK: ${STAGING_SEAL_ACK:-}
+      NOTARY_REHASH_ACK: ${STAGING_REHASH_ACK:-}
     volumes:
       - ${STAGING_DIR:-./data/staging}:/gegenbuch

tools/audit-notary/entrypoint.sh

@@ -70,8 +70,16 @@ fi
 # Logs zu durchsuchen.
 while true; do
   ZEIT=$(date -Iseconds)
-  node /opt/notary/notary.mjs
+  # Ausgabe mitschneiden, um den GRUND in die Statusdatei zu bekommen.
+  #
+  # Vorher stand dort nur das Etikett ("BEFUND"), und das ist fuer jeden
+  # Exit-2 dasselbe - ein echter Widerspruch sieht darin aus wie eine
+  # quittierpflichtige Erstsiegelung. Wer nur die Statusdatei liest, kann
+  # nicht entscheiden, ob er handeln muss. Genau die Sorte Signal, gegen die
+  # dieses Werkzeug gebaut ist.
+  node /opt/notary/notary.mjs > /tmp/lauf.log 2>&1
   CODE=$?
+  cat /tmp/lauf.log
   case $CODE in
     0) LAGE="in Ordnung" ;;
     1) LAGE="Betriebsfehler (Konfiguration, CRM nicht erreichbar, Commit)" ;;
@@ -82,6 +90,18 @@ while true; do
     *) LAGE="unbekannter Code" ;;
   esac
   echo "[$INSTANZ] $ZEIT exit=$CODE ($LAGE)"
-  printf '%s exit=%s %s\n' "$ZEIT" "$CODE" "$LAGE" > /gegenbuch/status.txt
+  # Die aussagekraeftigste Zeile mitnehmen, nicht einfach die erste.
+  #
+  # Bei Alarm ist das die ALARM-Zeile. Sonst die Zusammenfassung ("OK: …") -
+  # denn ein Lauf kann davor beilaeufige Hinweise ausgeben (etwa das einmalige
+  # Setzen einer Ueberwachungs-Grundlage), und die verdeckten sonst das
+  # Ergebnis. Erst wenn beides fehlt, die erste Zeile ueberhaupt.
+  GRUND=$(grep -m1 '^ALARM: ' /tmp/lauf.log | sed 's/^ALARM: //')
+  [ -z "$GRUND" ] && GRUND=$(grep -m1 '^OK: ' /tmp/lauf.log)
+  [ -z "$GRUND" ] && GRUND=$(grep -m1 -v '^[[:space:]]*$' /tmp/lauf.log)
+  {
+    printf '%s exit=%s %s\n' "$ZEIT" "$CODE" "$LAGE"
+    [ -n "$GRUND" ] && printf 'Grund: %s\n' "$GRUND"
+  } > /gegenbuch/status.txt
   sleep "$INTERVALL"
 done

tools/audit-notary/notary.mjs

@@ -153,6 +153,17 @@ const SEAL_ACK = (process.env.NOTARY_SEAL_ACK || '').trim();
 const siegelBestaetigt = (wurzel) =>
   SEAL_ACK.length >= 16 && !!wurzel && wurzel.startsWith(SEAL_ACK);
 
+// Bestaetigung fuer eine Neuberechnung der Kette (Pentest R186, Frage (b)).
+//
+// Bestaetigt wird mit der ID des juengsten Rehash-Eintrags. IDs steigen
+// streng, ein stehen gelassener Wert passt also beim naechsten Rehash nicht
+// mehr - dasselbe selbstentwertende Prinzip wie bei NOTARY_SEAL_ACK, nur mit
+// einem Wert, den man vorlesen kann.
+const REHASH_ACK = (process.env.NOTARY_REHASH_ACK || '').trim();
+// Wurde in diesem Lauf eine Neuberechnung ausdruecklich bestaetigt? Dann ist
+// der veraenderte Kettenkopf die erwartete Folge und kein eigener Befund.
+let rehashBestaetigt = false;
+
 if (!CRM_URL) {
   console.error('CRM_URL muss gesetzt sein.');
   process.exit(1);
@@ -755,6 +766,17 @@ const letzter = bisher[bisher.length - 1];
 if (!CRM_TOKEN) await anmelden();
 const aktuell = await hole('/api/audit-logs/checkpoint');
 
+// Die Vollpruefung wird IMMER geholt, auch beim allerersten Lauf: Aus ihr
+// stammt die Zahl der protokollierten Neuberechnungen, und die gehoert schon
+// in den ersten Eintrag - sonst gaebe es beim zweiten Lauf keine Grundlage,
+// gegen die sich ein neuer Rehash abheben koennte.
+const pruefung = await hole('/api/audit-logs/verify', 'POST');
+const rehashListe = Array.isArray(pruefung?.rehashes) ? pruefung.rehashes : null;
+const rehashAnzahl = rehashListe ? rehashListe.length : null;
+const rehashLetzte = rehashListe && rehashListe.length
+  ? rehashListe[rehashListe.length - 1].id
+  : null;
+
 if (letzter) {
   if (aktuell.maxId !== null && aktuell.maxId < letzter.maxId) {
     alarm(
@@ -767,7 +789,6 @@ if (letzter) {
   // Eintraege endgueltig loeschen und die Luecken per Tombstone als „erklaert“
   // ausweisen – die Meldung liest sich dann harmlos. Fuer das Gegenbuch zaehlt
   // das Feld, nicht der Satz.
-  const pruefung = await hole('/api/audit-logs/verify', 'POST');
   if (pruefung && pruefung.valid === false) {
     alarm(
       'Die Prüfung im CRM meldet die Kette als NICHT unversehrt (valid: false).\n' +
@@ -779,8 +800,77 @@ if (letzter) {
   }
 
   const rueck = await hole(`/api/audit-logs/checkpoint?atId=${letzter.maxId}`);
+  // Ein fehlender beglaubigter Eintrag ist IMMER ein Befund - auch wenn eine
+  // Neuberechnung bestaetigt wurde. Bestaetigt wird der Rehash, nicht das
+  // Verschwinden von Zeilen.
   if (rueck.atHash === null) alarm(`Der beglaubigte Eintrag ${letzter.maxId} existiert nicht mehr.`);
-  if (rueck.atHash !== letzter.chainHead) {
+
+  // ---------------------------------------------------------------
+  // Neuberechnung der Kette (Rehash) als EIGENE Alarmbedingung.
+  //
+  // Ein Rehash wurde bisher nur als Nebenwirkung gefangen: Er aendert jeden
+  // Hash, also stimmt der beglaubigte Kettenkopf nicht mehr und der Vergleich
+  // weiter oben schlaegt an. Das funktioniert - aber es ist ein Zufallstreffer
+  // und keine gebaute Warnung. Verschoebe sich der Anker irgendwann (anderer
+  // beglaubigter Wert, anderer Vergleich), waere der Melder lautlos weg.
+  //
+  // Deshalb haengt der Alarm jetzt an der Waffe selbst, nicht an ihrer Spur -
+  // dieselbe Lehre wie R184-01 (Gate am Ausloeser statt an der Wirkung) und
+  // R185-01 (Wurzelwechsel statt `valid`).
+  //
+  // Das Restrisiko, das dieser Melder abdeckt: `cleanup` + `rehash` OHNE
+  // erneutes Siegeln, ueber Inhalt, der gar nicht versiegelt ist. Dort greift
+  // weder das Bestandssiegel noch der Wurzelwechsel.
+  if (rehashAnzahl !== null && typeof letzter.rehashCount === 'number') {
+    if (rehashAnzahl > letzter.rehashCount) {
+      const neue = rehashAnzahl - letzter.rehashCount;
+      if (REHASH_ACK && String(rehashLetzte) === REHASH_ACK) {
+        rehashBestaetigt = true;
+        console.log(
+          `Neuberechnung bestätigt (NOTARY_REHASH_ACK=${REHASH_ACK}). ` +
+          'NOTARY_REHASH_ACK danach wieder leeren.',
+        );
+      } else {
+        const l = rehashListe[rehashListe.length - 1];
+        const vb = l.vorbefund;
+        alarm(
+          `Die Hash-Kette wurde neu berechnet (${neue} neue${neue === 1 ? 'r' : ''} Vorgang` +
+          `${neue === 1 ? '' : 'e'} seit der letzten Beglaubigung).\n` +
+          `  zuletzt: ${l.zeitpunkt} (Eintrag ${l.id}, ${l.neuBerechnet} Zeilen)\n` +
+          (vb
+            ? `  Befund unmittelbar davor: ${vb.manipuliert} beanstandet, ${vb.luecken} Lücken\n`
+            : '  Der Zustand davor ist nicht mehr feststellbar.\n') +
+          (l.signiert ? '' : '  ACHTUNG: Dieser Rehash-Eintrag trägt keine gültige Signatur.\n') +
+          'Ein Rehash verknüpft alle Einträge neu. Lücken, die vorher eine Löschung\n' +
+          'sichtbar gemacht hätten, verschwinden dabei aus der Kette – die Prüfung im CRM\n' +
+          'meldet danach wieder „lückenlos". Genau deshalb ist das hier ein Alarm und\n' +
+          'kein Hinweis.\n' +
+          'War es geplant, bestätigen und danach wieder leeren:\n' +
+          `  NOTARY_REHASH_ACK=${rehashLetzte}`,
+        );
+      }
+    }
+  } else if (rehashAnzahl !== null && typeof letzter.rehashCount !== 'number') {
+    // Gegenbuch aus der Zeit vor diesem Melder: Es gibt keine Grundlage, gegen
+    // die sich etwas abheben koennte. Stillschweigend zu alarmieren waere ein
+    // Fehlalarm bei jedem Bestandsbuch; stillschweigend zu uebernehmen waere
+    // eine unsichtbare Annahme. Also: uebernehmen und es sagen.
+    console.log(
+      `Grundlage für die Rehash-Überwachung wird gesetzt: ${rehashAnzahl} protokollierte ` +
+      'Neuberechnung(en) im CRM. Ab dem nächsten Lauf fällt jede weitere auf.',
+    );
+  }
+
+
+  // Der Kopf-Hash-Vergleich steht bewusst NACH der Rehash-Pruefung.
+  //
+  // Zwei Gruende: Erstens benennt der Rehash-Alarm die Ursache, waehrend
+  // „Eintrag wurde veraendert“ nur die Wirkung beschreibt - bei gleicher Lage
+  // ist die praezisere Meldung die nuetzlichere. Zweitens aendert eine
+  // Neuberechnung ZWANGSLAEUFIG jeden Hash; stuende dieser Vergleich davor
+  // oder ungeschuetzt dahinter, liesse sich eine bestaetigte Neuberechnung nie
+  // aufloesen und die Bestaetigung waere wertlos.
+  if (rueck.atHash !== letzter.chainHead && !rehashBestaetigt) {
     alarm(
       `Der Eintrag ${letzter.maxId} wurde nachträglich verändert.\n` +
       `  beglaubigt: ${letzter.chainHead}\n  jetzt     : ${rueck.atHash}`,
@@ -910,6 +1000,9 @@ const eintrag = {
   chainHead: aktuell.chainHead,
   sealRoot: aktuell.sealRoot,
   sealLeafCount: aktuell.sealLeafCount,
+  // Grundlage fuer die Rehash-Ueberwachung des naechsten Laufs.
+  rehashCount: rehashAnzahl,
+  rehashLast: rehashLetzte,
 };
 const neuerInhalt = [...bisher, eintrag].map((e) => JSON.stringify(e)).join('\n') + '\n';