Översikt över arkitektur och säkerhet

Zentor App är uppbyggd som en multi-tenant-plattform. Varje tenant har ett eget datasammanhang, och kontroller på serversidan begränsar varje autentiserad förfrågan till den aktiva tenanten. Den synliga tenantväxlaren försvagar inte denna separation: den byter endast den aktiva kontexten för användare med åtkomst till mer än en tenant, medan backend fortsätter att kontrollera behörigheterna vid varje förfrågan. Ytterligare tenanter skapas inte av vanliga användare. De aktiveras av Zentor; det bekräftade priset för en ytterligare tenant i Individuell-paketet är 39 € per månad.

Autentiseringen för dashboarden bygger på e-post och lösenord, med valfri tvåfaktorsautentisering via TOTP och stödda SSO-metoder. En vanlig sessions-JWT är giltig i 12 timmar, en refresh-token kan vara giltig i upp till sju dagar. För det dokumenterade publika API:et finns inget separat system med API-nycklar för utvecklare. Publika formulär och innehållsslutpunkter fungerar utan inloggning i dashboarden, medan widgetåtgärder använder en dedikerad embed-token tillsammans med origin-begränsningar. Embed-token visas endast en gång i klartext och bör behandlas som en hemlighet under konfigurationen.

Plattformen kombinerar dashboarden, tenantspecifika backendtjänster, en kunskapsdatabas, kommunikationskanaler och en isolerad SIP-driftsättning för telefoni. SIP-röstboten är sedan den 24 juli 2026 separerad från huvudapplikationen. Varje aktiverad tenant får en isolerad SIP-instans; aktivering eller inaktivering förblir en uppgift för Master Admin. Denna separation förhindrar att tenant-dashboarden direkt hanterar trunkar eller telefoniinfrastruktur på låg nivå.

Till säkerhetskontrollerna hör IP-, domän- och landsregler. Varje ny regel startar i dry run-läge och kan aktiveras först efter en obligatorisk väntetid på 24 timmar. Tillåt-regler har företräde framför blockeringsregler. Denna utformning ger administratörer tid att kontrollera en regels effekt innan den börjar gälla, och minskar risken att oavsiktligt spärra legitim åtkomst.

Arkitektursidan ska inte läsas som ett offentligt SLA eller som ett löfte om att varje valfri komponent är tillgänglig i varje paket. Tillgången till funktioner beror på entitlements och tillägg. On-premises-drift är förberedd men inte produktionsmogen, eftersom den nuvarande licensmekanismen fortfarande innehåller en platshållarnyckel. Den bör därför beskrivas som tillgänglig på begäran och under införande, inte som ett helt självbetjänat driftsättningsalternativ.