Przegląd architektury i bezpieczeństwa

Zentor App jest zbudowana jako platforma multi-tenant. Każdy tenant ma własny kontekst danych, a kontrole po stronie serwera ograniczają każde uwierzytelnione żądanie do aktywnego tenanta. Widoczny przełącznik tenantów nie osłabia tej separacji: zmienia jedynie aktywny kontekst dla użytkowników z dostępem do więcej niż jednego tenanta, a backend nadal sprawdza uprawnienia przy każdym żądaniu. Dodatkowych tenantów nie zakładają zwykli użytkownicy. Odblokowuje je Zentor; potwierdzona cena za dodatkowego tenanta w pakiecie Individuell wynosi 39 € miesięcznie.

Uwierzytelnianie w panelu opiera się na adresie e-mail i haśle, z opcjonalnym uwierzytelnianiem dwuskładnikowym TOTP i obsługiwanymi metodami SSO. Zwykły token JWT sesji jest ważny 12 godzin, a token odświeżania może pozostać ważny do siedmiu dni. Dla udokumentowanego publicznego API nie ma oddzielnego systemu kluczy API dla deweloperów. Publiczne formularze i endpointy treści działają bez logowania do panelu, natomiast operacje widgetu używają dedykowanego tokenu osadzenia wraz z ograniczeniami originów. Token osadzenia jest wyświetlany jawnym tekstem tylko raz i podczas konfiguracji należy traktować go jak sekret.

Platforma łączy panel, usługi backendowe przypisane do tenantów, bazę wiedzy, kanały komunikacji oraz odizolowane wdrożenie SIP dla telefonii. Od 24 lipca 2026 r. SIP-Voicebot jest oddzielony od głównej aplikacji. Każdy aktywowany tenant otrzymuje odizolowaną instancję SIP, a aktywacja lub dezaktywacja pozostaje zadaniem Master Admina. Ta separacja uniemożliwia panelowi tenanta bezpośrednie zarządzanie trunkami lub niskopoziomową infrastrukturą telefoniczną.

Do mechanizmów kontroli bezpieczeństwa należą reguły IP, domen i krajów. Każda nowa reguła startuje w trybie dry-run i może zostać aktywowana dopiero po obowiązkowym okresie oczekiwania wynoszącym 24 godziny. Reguły allow mają pierwszeństwo przed regułami block. Taka konstrukcja daje administratorom czas na sprawdzenie skutków reguły, zanim zacznie ona działać, i zmniejsza ryzyko przypadkowego zablokowania uprawnionego dostępu.

Strony architektury nie należy traktować jako publicznego SLA ani jako zapewnienia, że każdy opcjonalny komponent jest dostępny w każdym pakiecie. Dostęp do funkcji zależy od uprawnień (entitlements) i dodatków. Tryb on-premises jest przygotowany, ale nie jest gotowy do produkcji, ponieważ obecny mechanizm licencjonowania nadal zawiera klucz zastępczy. Dlatego należy go opisywać jako dostępny na życzenie i we wdrażaniu, a nie jako w pełni samoobsługową opcję wdrożenia.