Sicherheit & Datenschutz
Eine Datenbank für alle. Zwei Sicherungen, die beide greifen müssen.
Ein Fehler in der Anwendung darf nicht bedeuten, dass ein Kunde die Zahlen eines anderen sieht. Deshalb hängt die Mandantentrennung nicht am Anwendungscode allein.
- Trennung in zwei Schichten
- Ein Filter hängt die Organisation an jede ORM-Abfrage. Darunter liegt Row-Level-Security in PostgreSQL mit Policies auf Commerce-Modell, Aggregaten, Staging und Belegen.
- Die Anwendung ist nicht Eigentümer
- Sie verbindet sich mit einer eigenen Rolle, die der Row-Level-Security unterliegt. Als Eigentümer wäre die zweite Sicherung wirkungslos — Integrationstests prüfen genau das.
- Zugangsdaten liegen getrennt
- Der Hauptschlüssel ist nur in dem einen Container gesetzt, der die Quellen abruft. Weder die API noch der Verarbeitungs-Worker können Zugangsdaten entschlüsseln.
- Belege sind unveränderlich
- Der Belegspeicher ist nur anhängend; ein Trigger verhindert Änderung und Löschung. Beim Lesen wird die Prüfsumme geprüft — stimmt sie nicht, wird kein Beleg ausgeliefert.
- Zugriff im Team
- Sechs Standardgruppen, 13 Bereiche in vier Stufen, dazu der Datenumfang je Gruppe — ob Kosten, Kundendaten und welche Shops sichtbar sind. Zwei-Faktor-Anmeldung in jeder Edition.
- Protokoll
- Änderungen an Strategie, Kennzahlen, Rechten und Quellen stehen im Audit-Log, mit Person, Zeitpunkt und IP.
- Hosting
- Rohdaten und Datenbank in Deutschland. Auftragsverarbeitungsvertrag, technische und organisatorische Maßnahmen sowie Löschkonzept liegen als Unterlagen vor.