Arkitektur & Sikkerhed i overblik

Zentor App er opbygget som en multi-tenant-platform. Hver tenant har sin egen datakontekst, og serverside-kontroller begrænser hver autentificeret forespørgsel til den aktive tenant. Den synlige tenant-skifter svækker ikke denne adskillelse: Den skifter blot den aktive kontekst for brugere med adgang til mere end én tenant, mens backend fortsat kontrollerer rettigheder ved hver forespørgsel. Yderligere tenants oprettes ikke af almindelige brugere. De aktiveres af Zentor, og den bekræftede pris for en ekstra tenant i Individuell-pakken er 39 € om måneden.

Godkendelse til Dashboardet er baseret på e-mail og adgangskode, med valgfri TOTP-tofaktorgodkendelse og understøttede SSO-metoder. Et almindeligt session-JWT er gyldigt i 12 timer, og et refresh-token kan forblive gyldigt i op til syv dage. For den dokumenterede offentlige API findes der ikke et separat udvikler-API-nøglesystem. Offentlige formularer og indholds-endpoints fungerer uden login til Dashboardet, mens widget-handlinger bruger et dedikeret embed-token sammen med origin-begrænsninger. Embed-tokenet vises kun én gang i klartekst og bør behandles som en hemmelighed under opsætningen.

Platformen kombinerer Dashboardet, tenant-relaterede backend-tjenester, en videnbase, kommunikationskanaler og en isoleret SIP-implementering til telefoni. SIP-talebotten har været adskilt fra hovedapplikationen siden den 24. juli 2026. Hver aktiveret tenant får en isoleret SIP-instans, og aktivering eller deaktivering forbliver en Master Admin-opgave. Denne adskillelse forhindrer, at tenant-Dashboardet direkte administrerer trunks eller telefoniinfrastruktur på lavt niveau.

Sikkerhedskontrollerne omfatter IP-, domæne- og landeregler. Hver ny regel starter i Dry-Run-tilstand og kan først aktiveres efter en obligatorisk ventetid på 24 timer. Allow-regler har forrang frem for Block-regler. Dette design giver administratorer tid til at kontrollere en regels effekt, før den træder i kraft, og reducerer risikoen for utilsigtet at blokere legitim adgang.

Arkitektursiden bør ikke læses som en offentlig SLA eller som et løfte om, at hver valgfri komponent er tilgængelig i hver pakke. Funktionsadgang afhænger af rettigheder (entitlements) og Add-ons. On-Premises-drift er forberedt, men ikke produktionsklar, da den nuværende licensmekanisme stadig indeholder en pladsholder-nøgle. Den bør derfor beskrives som tilgængelig efter forespørgsel og under indførelse, ikke som en fuldt selvbetjent implementeringsmulighed.