Wer prüft eigentlich den Prüfer? Echte Revisionssicherheit im Maschinenraum

Wenn wir Kommunen unsere Software vorstellen, sitzen oft zwei Personen mit am Tisch, die scheinbar völlig gegensätzliche Ziele haben: Die Rechnungsprüfung will restlos alles wissen. Wer hat wann welchen Stundenzettel geändert? Der Personalrat und der Datenschutzbeauftragte hingegen wollen so viel wie möglich verbergen, um die Mitarbeiter vor Überwachung zu schützen.

In alter Software führte das oft zu einem faulen Kompromiss. Es gab ein sogenanntes „Logbuch“, das man mit den richtigen Admin-Rechten aber fröhlich löschen oder manipulieren konnte. Echte Sicherheit sieht anders aus.

Wir haben uns bei BauhofOS entschieden, dieses Problem nicht mit einem simplen Text-Log zu überkleben. Stattdessen haben wir ein Audit-Modul gebaut, das kryptografisch abgesichert ist. Hier ist der Blick unter die Motorhaube.

Die Hash-Kette: Warum man bei uns nicht pfuschen kann

Eine berechtigte Angst von Prüfern ist: Was passiert, wenn jemand mit direktem Datenbankzugriff (z.B. ein IT-Admin) heimlich einen Datensatz ändert? Er könnte einen Einsatz löschen und die Spuren im Logbuch einfach mitlöschen.

Um das zu verhindern, nutzen wir eine Event-Engine, die jeden wichtigen Eintrag mit dem vorherigen verkettet. Jeder Eintrag in unserer Audit-Tabelle bekommt einen kryptografischen hash und verweist gleichzeitig auf den previous_hashseines Vorgängers.

Das Prinzip kennt man aus Banksystemen. Manipuliert jemand heimlich Zeile 4 in der Datenbank, passt der Hash von Zeile 5 nicht mehr dazu. Die Kette bricht. Unser System erkennt sofort: Hier wurde von außen manipuliert. Ein Freifahrtschein für Administratoren existiert bei BauhofOS schlichtweg nicht.

Audit-the-Auditor: Wer schnüffelt, wird protokolliert

Jetzt kommt der Personalrat ins Spiel. Ein System, das alles mitschreibt, sammelt zwangsläufig sensible Daten – wie zum Beispiel die IP-Adresse oder das genutzte Gerät (User-Agent) des Mitarbeiters.

Unsere Lösung dafür nennen wir „Audit-the-Auditor“. Wenn ein Vorgesetzter oder Administrator die normale Einsatz-Historie öffnet, liefert unsere API diese sensiblen Daten überhaupt nicht aus. Das Feld bleibt auf Datenbankebene leer.

Will der Prüfer im Verdachtsfall (z.B. bei Betrugsverdacht) die IP-Adresse sehen, muss er explizit auf „Sensible Details anzeigen“ klicken. Das löst einen speziellen API-Aufruf (GET /sensitive-details) aus.

Der Clou: Genau dieser Klick wird vom System als eigenes Audit-Event gespeichert (AUDIT_LOG_DETAILS_VIEWED). Das System überwacht den Prüfer. Wer sensible Mitarbeiterdaten abruft, hinterlässt unwiderruflich seinen eigenen Fingerabdruck im System.

Das Archiv, das nicht vergisst (auch wenn Kollege Müller geht)

Ein massives Problem bei relationalen Datenbanken sind Abhängigkeiten (Foreign Keys). Was passiert mit dem Logbuch von 2024, wenn Kollege Müller 2026 in Rente geht und sein Profil DSGVO-konform gelöscht wird?

Bei klassischer Software zerreißen solche Löschungen oft die Historie, weil die Datenbank den Nutzer nicht mehr findet. Das Logbuch verliert seinen Kontext.

Wir haben das architektonisch radikal gelöst. Unsere Tabelle audit_logs_archivespeichert historische Einträge bewusst ohne direkte Fremdschlüssel-Abhängigkeit (Foreign Keys). Wenn das HR-Profil von Herrn Müller gelöscht wird, bleibt der Archiv-Eintrag seiner damaligen Einsätze völlig intakt. Die Daten sind eingefroren. Echte Revisionssicherheit bedeutet, dass die Historie robuster sein muss als die Stammdaten.

Fazit: Vertrauen ist gut, Architektur ist besser

Compliance, Revisionssicherheit und Datenschutz sind keine Checkboxen, die man kurz vor dem Release auf einer Marketing-Website abhakt. Sie müssen im tiefsten Kern der Software – im Datenbank-Design – verankert sein.

Mit der Hash-Verkettung, dem „Audit-the-Auditor“-Prinzip und dem entkoppelten Archiv liefern wir Kommunen genau diese Sicherheit. Der Kämmerer bekommt seine lückenlose Historie. Der Datenschützer bekommt den Schutz vor Neugier. Und der Bauhof kann sich darauf verlassen, dass das System gerichtsfest arbeitet.