Arhitectură și securitate: o privire de ansamblu

Zentor App este construită ca platformă multi-tenant. Fiecare tenant dispune de propriul context de date, iar verificările de pe server limitează fiecare cerere autentificată la tenantul activ. Comutatorul vizibil de tenanți nu slăbește această separare: el schimbă doar contextul activ pentru utilizatorii cu acces la mai mulți tenanți, în timp ce backend-ul continuă să verifice permisiunile la fiecare cerere. Tenanții suplimentari nu sunt creați de utilizatorii obișnuiți. Aceștia sunt activați de Zentor, iar prețul confirmat pentru un tenant suplimentar în pachetul Individual este de 39 € pe lună.

Autentificarea în dashboard se bazează pe e-mail și parolă, cu autentificare opțională în doi factori prin TOTP și proceduri SSO acceptate. Un JWT de sesiune obișnuit este valabil 12 ore, iar un token de refresh poate rămâne valabil până la șapte zile. Pentru API-ul public documentat nu există un sistem separat de chei API pentru dezvoltatori. Formularele publice și endpoint-urile de conținut funcționează fără autentificare în dashboard, în timp ce operațiunile widgetului folosesc un token de embed dedicat, împreună cu restricții de origine. Tokenul de embed este afișat o singură dată în clar și ar trebui tratat ca un secret în timpul configurării.

Platforma combină dashboard-ul, serviciile de backend legate de tenant, o bază de cunoștințe, canale de comunicare și o implementare SIP izolată pentru telefonie. Voicebotul SIP este separat de aplicația principală din 24 iulie 2026. Fiecare tenant activat primește o instanță SIP izolată, iar activarea sau dezactivarea rămâne o sarcină a Master Admin. Această separare împiedică dashboard-ul tenantului să gestioneze direct trunk-uri sau infrastructura de telefonie de nivel inferior.

Controalele de securitate includ reguli pentru IP, domeniu și țară. Fiecare regulă nouă pornește în modul dry-run și poate fi activată abia după o perioadă de așteptare obligatorie de 24 de ore. Regulile de tip Allow au prioritate față de regulile de tip Block. Acest design le oferă administratorilor timp să verifice efectul unei reguli înainte ca aceasta să se aplice și reduce riscul de a bloca din greșeală accesul legitim.

Pagina de arhitectură nu ar trebui citită ca SLA public sau ca garanție că fiecare componentă opțională este disponibilă în fiecare pachet. Accesul la funcții depinde de entitlements și add-on-uri. Operarea on-premises este pregătită, dar nu este gata de producție, deoarece mecanismul actual de licențiere conține încă o cheie substituent. Prin urmare, ar trebui descrisă ca disponibilă la cerere și în curs de introducere, nu ca opțiune de implementare complet self-service.