Defense-in-Depth: Wie BauhofOS kommunale Daten schützt.
Für den öffentlichen Sektor reicht ein einfaches Passwort nicht aus. BauhofOS wurde von Grund auf nach dem Prinzip Security by Design und Defense-in-Depth entwickelt.
Wir verlassen uns nicht auf Anwendungslogik, um Mandanten zu trennen, sondern verankern die Sicherheit tief im Datenbank-Kernel. Hier machen wir unsere Architektur für IT-Prüfer und Datenschützer transparent.
Die 3 Säulen der Architektur
Die technische Beweisführung unserer Sicherheitsversprechen.
Säule 1: Mathematisch garantierte Mandantentrennung (Multi-Tenancy)
Das Problem
In alten Systemen trennt oft nur ein fehleranfälliger Software-Filter (WHERE tenant_id = 1) die Daten. Ein Bug, und Kommune A sieht die Daten von Kommune B.
Der BauhofOS Beweis
- Row-Level Security (RLS) mit FORCE
Wir nutzen native PostgreSQL-RLS. Bevor eine Abfrage die Datenbank erreicht, wird der Mandanten-Kontext (
set_app_context) kryptografisch injiziert. Die Datenbank verweigert physisch die Herausgabe fremder Daten. - Tenant-Boundary-Trigger
Ein
BEFORE INSERT OR UPDATETrigger auf Datenbankebene verhindert sogenannte "Cross-Tenant-Referenzen". Es ist mathematisch unmöglich, dass ein Mitarbeiter aus Alfdorf auf eine Kostenstelle aus Stuttgart gebucht wird.
Säule 2: Auditing the Auditor (Wer überwacht den Admin?)
Das Problem
Administratoren haben oft "Gott-Modus" und können Daten spurlos ändern.
Der BauhofOS Beweis
- Immutable Audit-Logs
Jede sicherheits- oder abrechnungskritische Änderung (z.B. das Korrigieren einer Stempelzeit durch die Leitung) wird in einer separaten, unveränderbaren (append-only) Audit-Tabelle protokolliert.
- Transparenz
Das System speichert zwingend
old_value,new_value, den ausführendenuser_idund erfordert ein Textfeldreason(Begründung) für die FiBu-Revision. Manipulationen durch Admins sind somit restlos ausgeschlossen und nachvollziehbar.
Säule 3: Revisionssicherheit für die Kämmerei (MonthLock)
Das Problem
Daten driften. Ein Export wird gezogen, danach ändert jemand noch eine Arbeitszeit.
Der BauhofOS Beweis
- Period Locks
Sobald ein Monatsabschluss generiert wird, greift ein Datenbank-Trigger (
enforce_period_lock_on_bauhof), der jegliche Schreiboperationen (INSERT/UPDATE/DELETE) für diesen Zeitraum blockiert. - Storno statt Überschreiben
Korrekturen an abgeschlossenen Monaten erfolgen ausschließlich GoBD-konform über offizielle Storno-/Gegenbuchungen im aktuellen, offenen Monat.
Compliance-Mapping
Transparente Übersicht, wie BauhofOS technische Anforderungen der Gesetzgebung und Normen erfüllt.
| Gesetz / Norm | Anforderung | Wie BauhofOS das technisch löst |
|---|---|---|
| DSGVO (Art. 32) | Sicherheit der Verarbeitung | Mandantenisolation via RLS, AES-256 Verschlüsselung (At-Rest in S3 für HR-Dokumente), JWT-Token Rotation. |
| DSGVO (Art. 17) | Recht auf Vergessenwerden | Striktes Soft-Delete ( deleted_at). Daten sind sofort unsichtbar, die relationale Integrität bleibt für die FiBu erhalten, Hard-Deletes erfolgen nach gesetzlichen Fristen. |
| NIS2 | Risiko- & Vorfallmanagement | Rate-Limiting gegen Brute-Force (IP-Spoofing Schutz via X-Forwarded-For), Immutable Logging, restriktive CORS-Policies. |
| GoBD | Nachvollziehbarkeit & Unveränderbarkeit | MonthLock-Trigger für Buchungsperioden, Audit-Trail für jede manuelle Modifikation. |
Ask our Architecture
Technisches FAQ für IT-Prüfer und Systemadministratoren.
Wie verhindert BauhofOS Datenlecks zwischen verschiedenen Kommunen?
BauhofOS nutzt PostgreSQL Row-Level Security (RLS) mit aktivierter FORCE-Direktive. Die Mandanten-ID (tenant_id) wird aus dem validierten JWT-Token extrahiert und als sicherer Datenbank-Kontext (set_app_context) gesetzt. Zugriffe auf fremde Daten werden direkt im Datenbank-Kernel blockiert, selbst wenn die Anwendungslogik einen Fehler aufweisen sollte.
Ist BauhofOS für kritische Infrastrukturen nach NIS2 geeignet?
Ja. Die Architektur verwendet Role-Based Access Control (RBAC), striktes Rate-Limiting gegen Brute-Force-Angriffe, Content-Security-Policies (CSP) ohne Third-Party-Objects und immutable Audit-Logs zur Vorfallerkennung. Das System läuft als Docker-Stack in isolierten Containern.
Wie stellt BauhofOS sicher, dass exportierte FiBu-Daten nicht nachträglich manipuliert werden?
Jeder Monatsabschluss (Billing Closing Run) erzeugt einen unveränderbaren SHA256-Hash des Export-Artefakts. Gleichzeitig wird ein PeriodLock in der Datenbank aktiviert, der über Trigger jegliche weiteren INSERT, UPDATE oder DELETE Befehle in den Zeiterfassungstabellen für diesen Zeitraum hart abweist.