Architektur & Sicherheit im Überblick

Zentor App ist als Multi-Tenant-Plattform aufgebaut. Jeder Mandant verfügt über einen eigenen Datenkontext, und serverseitige Prüfungen beschränken jede authentifizierte Anfrage auf den aktiven Mandanten. Der sichtbare Mandanten-Umschalter schwächt diese Trennung nicht: Er wechselt lediglich den aktiven Kontext für Nutzer mit Zugriff auf mehr als einen Mandanten, während das Backend die Berechtigungen bei jeder Anfrage weiterhin prüft. Zusätzliche Mandanten werden nicht von normalen Nutzern angelegt. Sie werden von Zentor freigeschaltet, der bestätigte Preis für einen zusätzlichen Mandanten im Individuell-Paket beträgt 39 € pro Monat.

Die Authentifizierung für das Dashboard basiert auf E-Mail und Passwort, mit optionaler TOTP-Zwei-Faktor-Authentifizierung und unterstützten SSO-Verfahren. Ein reguläres Session-JWT ist 12 Stunden gültig, ein Refresh-Token kann bis zu sieben Tage gültig bleiben. Für die dokumentierte öffentliche API gibt es kein separates Entwickler-API-Key-System. Öffentliche Formulare und Content-Endpunkte funktionieren ohne Dashboard-Login, während Widget-Operationen ein dediziertes Embed-Token zusammen mit Origin-Beschränkungen verwenden. Das Embed-Token wird nur einmal im Klartext angezeigt und sollte während der Einrichtung wie ein Geheimnis behandelt werden.

Die Plattform kombiniert das Dashboard, mandantenbezogene Backend-Dienste, eine Wissensdatenbank, Kommunikationskanäle und ein isoliertes SIP-Deployment für Telefonie. Der SIP-Voicebot ist seit dem 24. Juli 2026 von der Hauptanwendung getrennt. Jeder aktivierte Mandant erhält eine isolierte SIP-Instanz, Aktivierung oder Deaktivierung bleibt eine Aufgabe des Master Admin. Diese Trennung verhindert, dass das Mandanten-Dashboard Trunks oder Telefonie-Infrastruktur auf niedriger Ebene direkt verwaltet.

Zu den Sicherheitskontrollen zählen IP-, Domain- und Länderregeln. Jede neue Regel startet im Dry-Run-Modus und kann erst nach einer verpflichtenden Wartezeit von 24 Stunden aktiviert werden. Allow-Regeln haben Vorrang vor Block-Regeln. Dieses Design gibt Administratoren Zeit, die Wirkung einer Regel zu prüfen, bevor sie greift, und verringert das Risiko, versehentlich legitimen Zugriff zu sperren.

Die Architektur-Seite sollte nicht als öffentliches SLA oder als Zusage gelesen werden, dass jede optionale Komponente in jedem Paket verfügbar ist. Der Funktionszugriff hängt von Entitlements und Add-ons ab. Der On-Premises-Betrieb ist vorbereitet, aber nicht produktionsreif, da der aktuelle Lizenzierungsmechanismus noch einen Platzhalter-Schlüssel enthält. Er sollte daher als auf Anfrage verfügbar und in Einführung beschrieben werden, nicht als vollständig selbstbedienbare Deployment-Option.