Trust Center

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 UPDATE Trigger 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: Administrator-Kontrolle (Audit-Logging) (Wer überwacht den Admin?)

Das Problem

Administratoren haben oft "Gott-Modus" und können Daten spurlos ändern.

Der BauhofOS Beweis

Unveränderbare Revisionsprotokolle
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ührenden user_id und erfordert ein Textfeld reason (Begründung) für die FiBu-Revision. Manipulationen durch Administratoren werden somit technisch unmöglich gemacht bzw. lückenlos nachvollziehbar dokumentiert.

Säule 3: Revisionssicherheit für die Kämmerei (MonthLock)

Das Problem

Inkonsistente Datenbestände: Wenn Arbeitszeiten nach einem Export oder Monatsabschluss unbemerkt geändert werden, driften Haushalts- und Realdaten auseinander.

Der BauhofOS Beweis

Zeitraum-Sperren (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 hart abweist.
Stornoprinzip statt Überschreiben
Korrekturen an bereits abgeschlossenen Monaten erfolgen ausschließlich GoBD-konform über transparente Storno- und Gegenbuchungen im aktuell offenen Zeitraum.

System-Monitoring & Datenintegrität

Um den reibungslosen Betrieb von BauhofOS in Ihrer Kommune zu garantieren, setzen wir auf Echtzeit-Observability – technisch exzellent, rechtssicher und ohne Erfassung personenbezogener Daten.

Hochverfügbarkeit

Wir überwachen die Performance unserer Schnittstellen (APIs) rund um die Uhr. Mit einer durchschnittlichen Latenz von unter 100 Millisekunden stellen wir sicher, dass Ihre Daten ohne spürbare Verzögerung verarbeitet werden – für ein flüssiges Arbeiten im Büro und im Außeneinsatz.

Privacy-by-Design im Monitoring

Unser Monitoring ist konsequent auf technische Systemstabilität ausgelegt. Wir erfassen ausschließlich anonymisierte technische Metriken. In unseren Analyse-Dashboards werden weder IP-Adressen noch personenbezogene Daten gespeichert. Zudem verzichten wir im Monitoring-Layer bewusst auf die Zuordnung von Anfragen zu einzelnen Mandanten. Das Ergebnis: Maximale Ausfallsicherheit ohne jegliche Überwachung der Nutzer oder Kommunen.

Proaktive Fehlerbehebung

Durch automatisierte, verschlüsselte Alarmierungsketten wird unser Technik-Team bei technischen Abweichungen in Echtzeit informiert. Dieser proaktive Ansatz ermöglicht es uns, potenzielle Engpässe zu optimieren, noch bevor sie Auswirkungen auf die Arbeitsabläufe in Ihrem Bauhof haben könnten. Wir agieren, während das System für Sie nahtlos weiterläuft.

Ihr Vorteil als Kommune

Sie profitieren von maximaler Ausfallsicherheit bei garantierter Datensouveränität. BauhofOS bleibt stabil, ohne dass wir dafür die Nutzung Ihrer Mitarbeiter oder einzelner Mandanten überwachen. Da unsere technischen Metriken rein der Hochverfügbarkeit dienen und keine Rückschlüsse auf spezifische Kommunen zulassen, ist eine Leistungs- oder Verhaltenskontrolle technisch ausgeschlossen. Die volle Kontrolle über Ihre Daten bleibt zu 100 % in Ihrer Kommune.

Compliance-Übersetzer

Regulatorische Anforderungen, technische Umsetzung bei BauhofOS und der konkrete Vorteil für Ihre Kommune – in einer Übersicht.

Regulatorische Anforderung	Technische Umsetzung bei BauhofOS	Vorteil für die Kommune
NIS2 Art. 21 – Störungsmanagement (Incident Handling)	Echtzeit-Monitoring aller API-Endpunkte (durchschnittliche Latenz < 100 ms). Automatisierte Alarmierung bei Anomalien. Sofortige Eskalation an das Technik-Team ohne manuelle Überwachung.	Schnelle Reaktion auf Störungen, Erfüllung der Meldepflichten. Rechtssichere Dokumentation des Vorfallmanagements.
DSGVO Art. 25 – Privacy by Design	Monitoring ohne IP-Logging und ohne Erfassung personenbezogener Daten. Zero-Knowledge-Monitoring: Keine Zuordnung technischer Metriken zu spezifischen Mandanten. Anfragen-Verarbeitung (n8n-Webhooks) erfolgt isoliert und datensparsam.	Technischer Ausschluss von Leistungs- und Verhaltenskontrollen. Maximale Datensouveränität; Prüfer und Personalräte sehen klare technische Nachweise der Anonymisierung.
DSGVO Art. 32 – Sicherheit der Verarbeitung	Mandantenisolation via Row-Level Security (RLS), AES-256 Verschlüsselung (At-Rest für HR-Dokumente), JWT-Token-Rotation. Unveränderbare Revisionsprotokolle, restriktive CORS-Policies.	Technisch nachweisbarer Schutz personenbezogener Daten. Reduziert Haftungsrisiken und erleichtert die Rechenschaftspflicht.
DSGVO Art. 17 – Recht auf Löschung	Striktes Logisches Löschen (`deleted_at`). Daten sind sofort unsichtbar, relationale Integrität für die FiBu bleibt erhalten. Endgültiges Löschens nach gesetzlichen Fristen.	Rechtssichere Umsetzung von Löschanträgen ohne FiBu-Probleme. Nachvollziehbarkeit für Rechnungsprüfer.
NIS2 – Risiko- & Vorfallmanagement (ergänzend)	Rate-Limiting gegen Brute-Force, Schutz vor IP-Spoofing (X-Forwarded-For-Handling). Unveränderbare Logs für forensische Auswertung.	Erfüllung der Anforderungen an KRITIS-nahe und wesentliche Einrichtungen. Klare Nachweisführung gegenüber Aufsicht.
GoBD – Nachvollziehbarkeit & Unveränderbarkeit	MonthLock-Trigger für abgeschlossene Buchungsperioden. Audit-Trail für jede manuelle Modifikation (old_value, new_value, user_id, reason).	Revisionssichere Buchführung für die Kämmerei. Keine nachträglichen Manipulationen – Prüfungssicherheit.

Technische Spezifikationen

Technical Fact Sheet für IT-Prüfer und Verantwortliche – zentrale Sicherheits- und Architekturmerkmale auf einen Blick.

Mandantentrennung (RLS)

Native PostgreSQL Row-Level Security (RLS) mit Context-Injection. Physische Zugriffssperre auf Datenbank-Kernel-Ebene.

Infrastruktur & Hosting

Betrieb ausschließlich in ISO 27001 zertifizierten deutschen Rechenzentren. Tägliche, verschlüsselte Backups mit räumlicher Trennung (Offsite).

Revisionssicherheit (GoBD)

Unveränderbare Audit-Logs mit SHA256-Hashing und automatisierte Zeitraum-Sperren (PeriodLocks) nach GoBD-Standard.

Netzwerk- & API-Sicherheit

Verschlüsselung via TLS 1.3 (In-Transit). Zugriffsschutz durch strikte JWT-Rotation, Rate-Limiting und restriktive CORS-Policies.

Datensicherheit (At-Rest)

Sensible Datenfelder und Dokumente werden mittels AES-256 auf Dateisystemebene verschlüsselt gespeichert.

Compliance & Monitoring

NIS2-ready durch RBAC und Echtzeit-Observability. Zero-Knowledge-Monitoring ohne Speicherung von IP-Adressen oder Mandantenbezug.

Wie sieht diese Sicherheit in der Praxis aus?

Sicherheit darf den Vorarbeiter im strömenden Regen nicht blockieren. Lesen Sie in unserem Tech-Blog, wie wir harte Mandantentrennung mit kinderleichter Bedienung vereinen.

Zum Maschinenraum (Tech-Blog) →