Für IT-Verantwortliche und Datenschutzbeauftragte
Sicherheit, Datenschutz und Betrieb
Diese Seite ist die technische Langfassung. Sie nennt jede Zusicherung zusammen mit ihrem Geltungsbereich – auch dort, wo der Geltungsbereich kleiner ist, als eine Werbeseite ihn gerne hätte.
- Eigener Betrieb je Gemeinde
- Rechenzentrum in Deutschland
- TLS mit HSTS
- Wiederherstellung geprobt
Die Kurzfassung für die Entscheidung im Gemeinderat steht auf der Startseite: neun Fakten und die acht häufigsten Fragen. Hier steht, was ein Prüfer danach fragt.
Datenhoheit
Ein eigener Betrieb je Gemeinde
Kommunova ist kein System, in dem Gemeinden Mandanten sind. Es gibt keinen gemeinsamen Datentopf, der nach Gemeinde gefiltert wird – es gibt je Gemeinde ein eigenes, vollständig getrenntes System.
Eigene Datenbank
Vorgänge, Nutzer, Gruppen und Protokolle Ihrer Gemeinde liegen in einer eigenen PostgreSQL-Instanz mit eigenem Datenträger.
Eigener Login-Dienst
Ein eigener Keycloak-Realm mit Ihren Konten, Ihren Rollen und Ihren Passwortregeln. Kein gemeinsames Benutzerverzeichnis.
Eigener Fotospeicher
Ein eigener Objektspeicher für Fotos und Anhänge, mit eigenem Bucket und eigenen Zugangsschlüsseln.
Eigenes Netz, eigene Adresse
Ein eigenes Container-Netz, eine eigene Internetadresse und ein eigenes TLS-Zertifikat. Zwischen zwei Gemeinden gibt es keine Verbindung.
Was praktisch daraus folgt
- Es gibt keine Abfrage, die Daten zweier Gemeinden zusammen sehen könnte – nicht, weil ein Filter sie trennt, sondern weil es keine gemeinsame Datenbank gibt, über die sie laufen könnte.
- Ein Konfigurationsfehler in einem Betrieb kann die Daten einer anderen Gemeinde nicht erreichen. Der übliche Mandantenfehler – eine vergessene Bedingung in einer Abfrage – hat hier kein Ziel.
- Ihr Datenbestand lässt sich einzeln sichern, anhalten, prüfen oder herausgeben, ohne dass eine andere Gemeinde davon berührt ist.
- Am Ende eines Vertrags wird ein abgegrenzter Betrieb abgeschaltet und gelöscht – kein Anteil an einem gemeinsamen Datenbestand, den jemand herausfiltern müsste.
Architektur
Woraus die Anwendung besteht
Keine Eigenentwicklung dort, wo etablierte Bausteine existieren – und keine Bausteine, die den Betrieb an einen einzelnen Anbieter binden.
- Anwendung auf dem Gerät
- Progressive Web App (Next.js). Installierbar auf Android, iOS und Desktop, ohne App Store. Offline-fähig: Erfassung, Fotos und Kommentare entstehen auf dem Gerät und werden nachgereicht.
- Schnittstelle
- NestJS auf Node.js, HTTP über Fastify. Die gesamte Schnittstelle ist als OpenAPI 3.1 beschrieben und lässt sich damit maschinell prüfen.
- Datenhaltung
- PostgreSQL 16 mit PostGIS. Standorte werden als echte Geometrie geführt, nicht als Textfeld – Umkreis- und Kartenabfragen laufen in der Datenbank, nicht im Browser.
- Anmeldung
- Keycloak, OpenID Connect mit PKCE, ein eigener Realm je Gemeinde. Die Signaturschlüssel werden über JWKS ausgetauscht und lassen sich im laufenden Betrieb rotieren.
- Fotos und Anhänge
- MinIO, S3-kompatibel. Der Zugriff läuft nie über eine offene Adresse, sondern über kurzlebige signierte Links mit 15 Minuten Gültigkeit.
- Hintergrundarbeit
- Redis mit BullMQ. Fristenprüfung, wiederkehrende Aufgaben, Miniaturbilder und die täglichen Löschläufe laufen als Jobs, nicht im Klick des Nutzers.
- Zugangsschicht
- Traefik v3 mit automatischen Let's-Encrypt-Zertifikaten. Sicherheits-Header werden zentral gesetzt, nicht je Anwendung.
- Betrieb
- Docker Compose, ein abgeschlossenes Projekt je Gemeinde, auf Servern der Hetzner Online GmbH in Gunzenhausen, Deutschland.
Zur Offline-Fähigkeit gehört eine ehrliche Nebenbemerkung: solange ein Gerät keine Verbindung hat, liegen die erfassten Vorgänge, Fotos und Kommentare im Speicher des Browsers auf dem Dienstgerät. Sie werden übertragen, sobald wieder Netz da ist, und bei jeder Abmeldung gelöscht – auch dann, wenn noch nichts übertragen wurde.
Verschlüsselung
Was verschlüsselt ist – und was nicht
Übertragung und Speicherung sind zwei verschiedene Zusicherungen mit zwei verschiedenen Geltungsbereichen. Wir führen sie deshalb getrennt auf.
Bei der Übertragung
- Jede Verbindung läuft über TLS. Unverschlüsselte Aufrufe werden am Zugangspunkt dauerhaft auf die verschlüsselte Verbindung umgeleitet, nicht nur einzelne Adressen.
- HSTS ist mit einem Jahr Gültigkeit gesetzt, einschließlich aller Subdomains. Ein Browser, der die Seite einmal erreicht hat, versucht es danach gar nicht mehr unverschlüsselt.
- Als Mindestversion ist TLS 1.2 gesetzt; TLS 1.3 wird bevorzugt. Ältere, gebrochene Protokollversionen werden abgelehnt.
Bei der Speicherung – der vollständige Geltungsbereich
Zulässig ist auf dieser Website genau ein Satz: Fotos und Datensicherungen sind mit AES-256 verschlüsselt gespeichert. Die Tabelle sagt, was das einschließt – und was nicht.
Die Tabelle lässt sich seitlich verschieben.
| Datenbestand | Verschlüsselt | Verfahren |
|---|---|---|
| Fotos und Anhänge im Objektspeicher | ja | AES-256, serverseitig beim Schreiben |
| Datenbanksicherungen samt Transaktionsprotokollen | ja | AES-256-CBC |
| Fotosicherung des Sicherungsdienstes | ja | AES-256-CBC, Schlüsselableitung mit 100.000 Durchläufen |
| Datenverzeichnis der Datenbank (Vorgänge, Nutzer, Standorte) | nein | im Klartext auf dem Datenträger |
| Datenbank des Login-Dienstes, Zwischenspeicher, übrige Datenträger | nein | im Klartext auf dem Datenträger |
| Dateisystem des Servers insgesamt | nein | keine Festplattenverschlüsselung |
Was diese Verschlüsselung leistet – und wogegen sie nicht hilft
Die Schlüssel liegen als Datei auf demselben Server wie die Daten, lesbar nur für das Systemkonto. Sie schützen damit gegen den Diebstahl oder die Aussonderung eines Datenträgers, gegen das Auslesen einer kopierten Sicherungsdatei und gegen die Weitergabe von Sicherungen an Dritte.
Sie schützen nicht gegen jemanden, der bereits volle Administratorrechte auf dem laufenden Server hat – der liest den Schlüssel mit. Wer mehr zusichern will, braucht einen externen Schlüsselspeicher und eine Festplattenverschlüsselung. Beides haben wir nicht, also sagen wir es auch nicht.
Sicherung
Gesichert wird täglich. Wiederhergestellt wurde tatsächlich.
Eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung. Diese hier ist an einem Wegwerf-System durchgespielt worden.
Takt und Aufbewahrung
- Vollsicherung der Datenbank täglich um 02:00 Uhr UTC.
- Zusätzlich alle sechs Stunden eine Zuwachssicherung.
- Die Transaktionsprotokolle laufen fortlaufend mit. Damit lässt sich der Stand eines bestimmten Zeitpunkts wiederherstellen, nicht nur der Stand der letzten Nacht.
- Sieben Vollsicherungen werden vorgehalten. Die Fotos werden mitgesichert.
Schutz und Nachweis
- Datenbanksicherung und Fotosicherung sind mit AES-256 verschlüsselt, jeweils mit einem eigenen Schlüssel.
- Wiederherstellung und Zeitpunkt-Wiederherstellung wurden an einem Wegwerf-System geprobt, nicht angenommen.
- Der Lauf der nächtlichen Sicherung wird überwacht; ein Fehlschlag bleibt nicht unbemerkt bis zum Ernstfall.
Die Reichweite dieser Sicherung
Alle Sicherungen liegen derzeit auf derselben Serverinfrastruktur in Deutschland wie die Anwendung selbst. Sie schützen gegen versehentliches Löschen, gegen fehlerhafte Änderungen und gegen Schäden an der Datenbank – nicht gegen den Verlust des Servers. Eine zusätzliche Kopie an einem zweiten Standort ist in Vorbereitung; solange sie nicht da ist, führen wir sie nicht als Schutzmaßnahme auf.
Zugriff
Drei Schichten, nicht eine Rolle
Ein einzelnes Rollenfeld reicht in einer Verwaltung nicht aus. Jede Anfrage an die Schnittstelle passiert deshalb drei voneinander unabhängige Prüfungen.
- 1
Anmeldung und Rolle
Angemeldet wird am eigenen Login-Dienst Ihrer Gemeinde. Die Rolle steht im Anmeldenachweis, und jeder einzelne Endpunkt der Schnittstelle erklärt, welche Rolle ihn aufrufen darf. Ein automatischer Test geht bei jedem Bauvorgang alle Endpunkte durch: ein neuer Endpunkt ohne Erklärung lässt den Bauvorgang scheitern.
- 2
Rechte je Rolle
Welche Schritte eine Rolle tatsächlich ausführen darf, steht nicht im Programmcode, sondern in einer Matrix, die Ihre Verwaltung selbst pflegt – Rolle für Rolle, Recht für Recht. Eine Änderung daran wirkt sofort und braucht keine neue Programmversion.
- 3
Prüfung am einzelnen Vorgang
Über der Rolle liegt die Prüfung am konkreten Vorgang: Gruppenzugehörigkeit, Zuständigkeit, Ausführung. Beauftragte Firmen sehen ausschließlich die Vorgänge, die ihnen zugewiesen wurden – nicht die Liste, aus der sie stammen.
Beim Ausscheiden eines Mitarbeiters wird das Konto deaktiviert; der Zugang ist damit sofort zu. Die Vorgänge bleiben bei der Gemeinde, offene Aufgaben lassen sich an eine andere Person oder eine Gruppe übergeben. Zugänge unserer Seite bestehen ausschließlich zum Zweck von Wartung und Störungsbehebung.
Nachvollziehbarkeit
Wer was wann geändert hat
In einer Verwaltung muss ein Vorgang auch Monate später noch belegbar sein – gegenüber dem Gemeinderat, gegenüber einer Aufsicht, im Streitfall gegenüber einem Gericht.
Änderungsprotokoll
Handelnde Person, Aktion, betroffener Datensatz und Zeitpunkt – für Anlegen, Ändern, Zuweisen, Löschen und für administrative Eingriffe.
Vorgangshistorie
Je Vorgang und je geändertem Feld: alter Wert, neuer Wert, Person, Zeitpunkt. Damit ist nicht nur nachvollziehbar, dass etwas geändert wurde, sondern was.
Foto-Integrität
Beim Hochladen wird über die Bilddatei eine SHA-256-Prüfsumme gebildet und im Objektspeicher mitgeführt. Ein nachträglich verändertes Bild ergibt einen anderen Wert – das fällt auf.
Support-Ansicht
Ein Systemadministrator Ihrer Gemeinde kann für die Unterstützung die Ansicht eines Nutzers einnehmen. Das ist auf diese Rolle beschränkt, auf vier Stunden befristet und erzeugt einen eigenen Protokolleintrag.
Betroffenenrechte
Auskunft, Übertragung, Löschung
Was die DSGVO an Rechten vorsieht, muss im System eine Schaltfläche haben – sonst bleibt es eine Absichtserklärung.
Datenexport nach Art. 15 und 20
Die zu einer Person gespeicherten Daten – Profil, von ihr angelegte und ihr zugewiesene Vorgänge, Fotodaten und Protokolleinträge – lassen sich als maschinell lesbare Datei ausgeben. Jeder Nutzer kann das für sich selbst auslösen, die Verwaltung zusätzlich für jeden Nutzer Ihrer Gemeinde.
Löschkonzept
Gelöschte Datensätze werden zunächst nur markiert, damit ein Versehen zurückgenommen werden kann. Ein täglicher Lauf entfernt sie danach endgültig: Fotos nach 30 Tagen, Nutzer, Vorgänge, Gruppen und Regeln nach 90 Tagen. Die Fristen sind je Betrieb einstellbar – Ihre Verwaltung legt sie fest, nicht wir.
Welche Daten im Einzelnen verarbeitet werden, auf welcher Grundlage und wer sie empfängt, führt die Datenschutzerklärung einzeln auf.
Verbindungen nach außen
Was den eigenen Betrieb verlässt
Eine Sicherheitsseite ist so viel wert wie ihre Liste der Ausnahmen. Das hier ist die vollständige Liste.
Adressauflösung zu Koordinaten
OpenStreetMap Foundation (Nominatim)
Wann: automatisch, sobald ein Vorgang mit Koordinaten angelegt oder geändert wird, sowie beim Verschieben des Kartenpins in der Erfassung.
Was übermittelt wird: ausschließlich Breiten- und Längengrad des Vorgangs sowie eine feste Kennung unserer Anwendung. Keine Namen, keine Vorgangsdaten, kein Bezug zu einem Vorgang oder zu einer Person.
Wer fragt: unser Server, nicht das Gerät Ihres Mitarbeiters. Die IP-Adresse des Mitarbeiters wird dabei nicht übermittelt.
Umfang: Aufgelöste Adressen werden 30 Tage zwischengespeichert, wobei die Koordinaten auf vier Nachkommastellen – ein Raster von rund elf Metern – gerundet werden. Wiederholte Vorgänge an derselben Stelle lösen deshalb keine neue Abfrage aus. Die Übermittlung ist damit verringert, nicht beseitigt: die erste Abfrage je Ort geht weiterhin hinaus, und sie enthält den exakten Standort des Vorgangs.
Navigation zum Einsatzort
Google bzw. Apple, nur auf Klick
Öffnet ein Mitarbeiter die Navigation zu einem Vorgang, verlässt der Zielpunkt das System – aber erst mit diesem Klick und nur als Koordinatenpaar, ohne Angabe der Herkunftsseite. Ohne Klick findet keine Übermittlung statt.
E-Mail-Benachrichtigungen
Der Mailserver, den Ihre Gemeinde hinterlegt
Benachrichtigungen laufen über einen Mailserver, den Ihre Verwaltung selbst einträgt – auf Wunsch den eigenen. Übermittelt werden Empfängeradresse, Titel des Vorgangs, der Statuswechsel, der Name der handelnden Person und bei Kommentaren der Anfang des Kommentartexts. Ist kein Mailserver hinterlegt, wird nichts versendet.
Kartenkacheln kommen vom eigenen Server
Keine Verbindung mehr vom Gerät Ihrer Mitarbeiter
Früher lud jedes Gerät die Kartenkacheln direkt beim Kartendienst und übermittelte dabei IP-Adresse, Browserkennung, die Adresse Ihrer Gemeinde als Herkunft und über die Kachelnummern den betrachteten Ausschnitt. Heute liefert ein Zwischenspeicher im Betrieb Ihrer Gemeinde die Kacheln aus. Nur dieser Zwischenspeicher spricht noch nach außen – mit der Server-IP, ohne Herkunftsangabe, ohne Cookies und ohne Bezug zu einem Nutzer. Die Lizenzangabe von OpenStreetMap bleibt in der Karte sichtbar; das ist Lizenzbedingung, keine Höflichkeit.
Was es nicht gibt
- Kein Tracking, keine Reichweitenmessung, keine Telemetrie – weder im Browser noch auf dem Server.
- Keine Google Fonts: die Schriften werden beim Bauen mitgeliefert und vom eigenen Server ausgeliefert.
- Kein fremdes CDN, kein fremdes Skript, kein eingebetteter Fremdinhalt in der angemeldeten Anwendung.
- Kein Push-Dienst von Google oder Apple.
Grenzen
Was wir ausdrücklich nicht behaupten
Diese Liste steht hier, weil ein Prüfer sie ohnehin erstellt. Es ist besser, sie von uns zu bekommen.
Keine Zertifizierung
Kommunova ist nicht nach ISO 27001 zertifiziert, nicht nach BSI-Grundschutz auditiert und trägt kein Prüfsiegel. Wo auf dieser Seite eines abgebildet wäre, hätten wir keines – deshalb ist keines abgebildet.
Kein Auftragsverarbeitungsvertrag von der Stange
Wir haben keinen vorgefertigten Vertrag nach Art. 28 DSGVO, den wir Ihnen als Download anbieten könnten. Die vertragliche und datenschutzrechtliche Grundlage klären wir vor Vertragsschluss persönlich mit Ihrer Gemeinde.
Keine durchgehende Verschlüsselung der Datenhaltung
Verschlüsselt gespeichert sind Fotos und Datensicherungen. Das Datenverzeichnis der Datenbank ist es nicht, und der Server hat keine Festplattenverschlüsselung. Die Tabelle weiter oben sagt genau, was gilt.
Keine Sicherung an einem zweiten Standort
Alle Sicherungen liegen derzeit auf derselben Serverinfrastruktur wie die Anwendung. Eine zusätzliche Kopie an einem zweiten Standort ist in Vorbereitung, aber sie ist heute nicht da – und was nicht da ist, führen wir nicht als Schutzmaßnahme auf.
Keine zugesicherte Verfügbarkeit in Prozent
Wir überwachen den Betrieb, aber wir haben keine über Jahre gemessene Verfügbarkeit, die eine Zusicherung tragen würde. Eine Zahl, die wir nicht gemessen haben, schreiben wir auch nicht hin.
Keine Ende-zu-Ende-Verschlüsselung
Wir können die Fachdaten technisch lesen. Das müssen wir auch, um sie zu verarbeiten, zu sichern und wiederherzustellen. Jede Aussage, die etwas anderes nahelegt, wäre falsch.
Weiterführend
Noch eine Ebene tiefer
Wenn Sie zu einem der Punkte oben eine belastbare Antwort brauchen, bekommen Sie sie – von der Person, die das System gebaut hat.
Datenschutzerklärung
Jede Datenart, jeder Speicherort, jeder Empfänger – einzeln aufgeführt, auch das, was man lieber verschweigen würde.
Datenschutzerklärung lesenDokumentation
Jeder Bereich der Anwendung, Schritt für Schritt beschrieben – offen zugänglich, ohne Anmeldung, auch vor einer Entscheidung.
Dokumentation ansehenDirekte Rückfrage
Jürgen Grünbeck, Inhaber. Keine Warteschleife, kein Ticketsystem, keine wechselnden Ansprechpartner.