Datenschutz und Mandantentrennung
Auf einem WorkOffice-Server arbeiten viele Betriebe nebeneinander – auf dem gemieteten Server des Herstellers ebenso wie auf einem eigenen Server mit mehreren Firmen. Kein Betrieb darf die Daten eines anderen sehen. Dieser Artikel beschreibt, wie das Programm das sicherstellt und welche Daten es wohin gibt.
Jeder Betrieb für sich
Jede Tabelle mit Geschäftsdaten – Kunden, Belege, Ausgaben, Bankumsätze, Benutzer, Protokoll – trägt die Kennung ihres Betriebs. Getrennt wird zweifach:
- In der Anwendung: Jede Abfrage läuft über einen Zugang, der die Kennung des angemeldeten Betriebs von selbst hinzufügt – beim Lesen als Filter, beim Anlegen als Wert. Eine Abfrage, die das vergisst, gibt es so nicht.
- In der Datenbank: PostgreSQL prüft zusätzlich jede Zeile (Row-Level-Security). Die Anwendung nennt der Datenbank je Transaktion den Betrieb; ohne diese Angabe liefern die Tabellen der Betriebe keine einzige Zeile. Das greift auch, wenn in der Anwendung doch einmal etwas fehlen sollte.
Fragt jemand nach der Kennung eines Belegs, Kunden oder Geräts aus einem fremden Betrieb, antwortet WorkOffice mit „Nicht gefunden“ – genau wie bei einer Kennung, die es gar nicht gibt. So verrät die Antwort nicht einmal, dass es den Datensatz woanders gibt. Automatische Tests prüfen genau das.
Dateien – archivierte PDFs, Belegbilder, Exporte, Logo – liegen in der Dateiablage in einem eigenen Ordner je Betrieb und werden nur über angemeldete Anfragen mit den passenden Rechten ausgeliefert.
Ein Zugang, mehrere Betriebe
Eine Person kann Zugang zu mehreren Betrieben haben – typisch der Steuerberater. Das ist ein Zugangsverbund: ein Passwort, ein zweiter Faktor, und oben in der Kopfzeile Betrieb wechseln. Gewechselt werden kann nur innerhalb des Verbunds, der durch eine angenommene Einladung entsteht. Dieselbe E-Mail-Adresse allein genügt nicht – die prüft bei einer Registrierung niemand. In jedem Betrieb gelten die Rechte der Rolle, die die Person dort hat.
Was verschlüsselt oder nur als Prüfwert liegt
| Daten | Wie gespeichert |
|---|---|
| Passwörter | nur als Hash |
| API-Schlüssel, Einladungs- und Passwort-Links | nur als Prüfwert, der Klartext wird einmal angezeigt bzw. verschickt |
| Ersatzcodes der Zwei-Faktor-Anmeldung | nur als Hash |
| Schlüssel der Authenticator-App | verschlüsselt |
| Passwort des eigenen Mailservers | verschlüsselt, nie wieder angezeigt |
| API-Schlüssel aus Lexware (bei der Datenübernahme) | verschlüsselt, beim Abschluss gelöscht |
Was an Dritte geht
- Adressvorschläge (Einstellungen → Firmendaten, Karte „Belege“, Schalter „Adressvorschläge aus dem Internet“, ab Werk an): Beim Tippen einer Anschrift fragt der Server OpenStreetMap-Dienste und das amtliche Straßenverzeichnis – mit dem getippten Text, ohne Namen und ohne Betrieb. Ausgeschaltet kommen nur Anschriften, die schon eingetragen sind.
- Telegram (je Person, freiwillig): Meldungen gehen an einen Dienst außerhalb der EU, nicht Ende-zu-Ende-verschlüsselt – deshalb ab Werk ohne Kundennamen. Siehe Telegram-Benachrichtigungen.
- Stripe (Abo und Zahlungslink): Zahlungsdaten liegen nur bei Stripe.
- E-Mails der Pendelakte nennen nur den Betreff, nie den Inhalt einer Nachricht.
- Lizenzserver (nur eigener Server): übertragen werden nur Lizenzschlüssel und Kennung der Installation, keine Belege, Kunden oder Benutzer.
Nachvollziehbar und aufbewahrt
Wer was getan hat, steht unveränderbar im Prüfprotokoll. Buchhaltungsunterlagen sperrt WorkOffice bis zum Ende ihrer Aufbewahrungsfrist gegen Löschen – siehe GoBD-Archiv. Personenbezogene Daten in Rechnungen und Belegen lassen sich deshalb vor Fristende nicht löschen.
Was es noch nicht gibt
Eine eigene Funktion für die Auskunft über die gespeicherten Daten einer Person oder für ihre Löschung nach der DSGVO gibt es noch nicht. Kunden lassen sich archivieren, aber nicht löschen; Benutzerkonten werden gesperrt, nicht gelöscht. Herausgeben lassen sich Daten über die Exporte – die Datenüberlassung im GoBD-Archiv, den DATEV-Export und die CSV-Dateien der Auswertungen. Für Fragen zu Pflichten im Einzelfall ist der Datenschutzbeauftragte bzw. der Steuerberater der richtige Ansprechpartner.
Wie der Betreiber eines eigenen Servers den Datenbankbenutzer so einrichtet, dass die Row-Level-Security greift, steht unter Eigener Server.