Sicherheit, die in der Struktur verankert ist.
Isolation, die man nicht falsch konfigurieren kann, schlägt eine Richtlinie, die niemand liest. Diese Seite listet auf, was die Daten Ihrer Kunden schützt — Zeile für Zeile geprüft anhand des Quellcodes, des Adressregisters und unseres Hosting-Anbieters.
- 12
- BCrypt-Arbeitsfaktor
- 15
- Minuten, bis ein Zugriffstoken abläuft
- 7
- Durchgesetzte Rate-Limit-Regeln
- 27
- Im STRIDE-Modell analysierte Bedrohungen
Wo Ihre Daten liegen.
Zuerst Trennung, dann Verschlüsselung — und ein Ausgang, der eine Datei ist, keine Verhandlung.
Tenant-Isolation
Ein über die Registrierung erstelltes Konto erhält eine eigene Datenbank, und jedes installierte Modul legt seine Tabellen darin in einem eigenen Schema ab. Auch in den eigenen Identitätstabellen der Plattform wird die Tenant-Trennung von der Datenschicht durchgesetzt, statt sie jeder einzelnen Abfrage zu überlassen.
Wo es läuft
Die Server der Plattform stehen in den Niederlanden und werden von TransIP gehostet. E-Mail-Zustellung und SMS laufen über Anbieter außerhalb der EU; die Datenschutzerklärung benennt jeden einzelnen und was er erhält.
Verschlüsselung im Ruhezustand
Die Datenbanken laufen mit SQL Server Transparent Data Encryption, sodass die Datenbankdateien auf der Festplatte verschlüsselt sind.
Gespeicherte Zugangsdaten
Datenbank-Verbindungszeichenfolgen und Zugangsdaten von Zahlungsanbietern werden mit ASP.NET Core Data Protection verschlüsselt, bevor sie gespeichert werden, und gelangen nie in Logs.
Ihre Daten mitnehmen
Wenn ein Konto eine eigene Datenbank hat, können wir auf Anfrage eine vollständige Kopie davon für Sie exportieren — als standardmäßige .bacpac-Datei von SQL Server.
Identität und Sitzungen.
Standardmäßig kurzlebig, in einem einzigen Schritt widerrufbar — und jede Zahl weiter unten ist im Code festgelegt.
- 15min
- Lebensdauer Zugriffstoken
- 256bit
- zufällige Refresh-Tokens
- 5min
- Ablauf Einmalcode
- 3Versuche
- Limit Einmalcode
- 5Versuche
- Sperrschwelle
- 12
- BCrypt-Arbeitsfaktor
Passwörter
Gehasht mit BCrypt bei Arbeitsfaktor 12, im Code festgelegt. Standardmäßig Sperrung nach 5 fehlgeschlagenen Versuchen — pro Tenant konfigurierbar und abschaltbar.
Sitzungen
Zugriffstoken laufen nach 15 Minuten ab. Refresh-Tokens sind zufällige 256-Bit-Werte, werden nur als Hash gespeichert, sind einmalig verwendbar und werden bei jeder Erneuerung ausgetauscht.
Einmalcodes
Optionale sechsstellige Codes per E-Mail oder SMS, im Ruhezustand gehasht, nach 5 Minuten ablaufend und auf 3 Versuche begrenzt.
Vertrauenswürdige Geräte
Cookies mit Host-Präfix, secure und SameSite auf strict, deren Wert serverseitig als Hash gespeichert ist. Wird ein inzwischen ersetztes Cookie vorgelegt, wird das Gerät widerrufen und die Anmeldung blockiert.
Zugriff widerrufen
Alle vertrauenswürdigen Geräte lassen sich auf einmal widerrufen — und der Widerruf erfolgt von selbst nach einer Passwortänderung, einer Sperrung, dem Abschalten der Zwei-Faktor-Authentifizierung oder einer Änderung von E-Mail-Adresse oder Telefonnummer.
Grenzen, Limits und das Protokoll.
Prüfungen am Rand, Obergrenzen auf dem Weg hinein und hinter jeder Änderung eine Spur, die nur wächst.
Autorisierung
Endpunkte, die eine Berechtigung voraussetzen, geben selbst an, welche Berechtigung sie erfordern; diese wird an der HTTP-Grenze gegen die Claims des signierten Tokens geprüft, ohne einen Datenbankzugriff. Endpunkte, die ausschließlich die eigenen Daten des angemeldeten Benutzers ausliefern, sind allein durch Authentifizierung geschützt.
Rate-Limits und Header
Sieben durchgesetzte Rate-Limit-Regeln und acht Sicherheitsheader auf API-Antworten, darunter HSTS und eine Content-Security-Policy, die standardmäßig alles verweigert.
Audit-Log
Änderungen an den eigenen Tabellen der Plattform — Anmeldung, Rollen, Berechtigungen, Einstellungen — werden append-only protokolliert: wer, was, welche Tabelle und Zeile, wann und die Werte nach der Änderung. Passwort-Hashes, Hashes von Einmalcodes, Geheimnisse für die Zwei-Faktor-Authentifizierung und Security Stamps bleiben ausgeschlossen. Bei einer Löschung wird der Schlüssel der Zeile festgehalten, nicht deren früherer Inhalt.
Bedrohungsmodell
Ein schriftliches STRIDE-Modell: 27 analysierte Bedrohungen über vier Vertrauenszonen und die Grenze zwischen Host und Tenant, mit vier ausdrücklich benannten akzeptierten Restrisiken.
Jede Zeile oben wurde zuletzt am 19. Juli 2026 geprüft — anhand des Quellcodes und, für Hosting und Festplattenverschlüsselung, anhand des Adressregisters und unseres Hosting-Anbieters.
Senden Sie uns Ihren Sicherheitsfragebogen.
Wir beantworten ihn Zeile für Zeile — mit den Menschen, die den Code geschrieben haben.
Kontakt aufnehmen