Panoramica architettura e sicurezza

Zentor App è progettata come piattaforma multi-tenant. Ogni tenant dispone di un proprio contesto di dati e i controlli lato server limitano ogni richiesta autenticata al tenant attivo. Il selettore di tenant visibile non indebolisce questa separazione: cambia solo il contesto attivo per un utente con accesso a più tenant, mentre il backend continua a validare i permessi a ogni richiesta. I tenant aggiuntivi non vengono creati dagli utenti comuni. Vengono attivati da Zentor, e il prezzo confermato per un tenant aggiuntivo nel pacchetto Individuale (Individuell) è di 39 €/mese.

L'autenticazione per il dashboard si basa su e-mail e password, con autenticazione a due fattori TOTP opzionale e flussi SSO supportati. Un normale JWT di sessione è valido per 12 ore, mentre un token di refresh può rimanere valido fino a sette giorni. Non esiste un sistema di chiavi API per sviluppatori separato per l'API pubblica documentata. I moduli pubblici e gli endpoint di contenuto funzionano senza accesso al dashboard, mentre le operazioni del widget utilizzano un token di incorporamento dedicato insieme a restrizioni di origine. Il token di incorporamento viene mostrato in chiaro una sola volta e va trattato come un segreto durante il deployment.

La piattaforma combina il dashboard, servizi backend specifici per tenant, una base di conoscenza, canali di comunicazione e un deployment SIP isolato per la telefonia. Il voicebot SIP è separato dall'applicazione principale dal 24 luglio 2026. Ogni tenant abilitato riceve un'istanza SIP isolata, e l'attivazione o disattivazione resta un compito esclusivo del Master Admin. Questa separazione impedisce al dashboard del tenant di gestire direttamente trunk o infrastruttura telefonica di basso livello.

I controlli di sicurezza includono regole per IP, dominio e paese. Ogni nuova regola parte in modalità dry-run e non può essere attivata prima di un periodo di attesa obbligatorio di 24 ore. Le regole di permesso hanno la precedenza su quelle di blocco. Questo design offre agli amministratori il tempo di verificare l'effetto di una regola prima che venga applicata e riduce il rischio di bloccare accidentalmente un accesso legittimo.

La pagina architettura non va letta come uno SLA pubblico né come garanzia che ogni componente opzionale sia disponibile in ogni pacchetto. L'accesso alle funzionalità dipende da entitlement e add-on. L'operatività on-premises è predisposta ma non pronta per la produzione, poiché l'attuale meccanismo di licenza contiene ancora una chiave segnaposto. Va quindi descritta come disponibile su richiesta e in fase di introduzione, non come opzione di deployment interamente self-service.