معماری و امنیت در یک نگاه

Zentor App به‌عنوان یک پلتفرم چند-tenant ساخته شده است. هر tenant زمینه داده‌ای خاص خود را دارد و بررسی‌های سمت سرور هر درخواست احراز هویت‌شده را به tenant فعال محدود می‌کند. تعویض‌کننده قابل مشاهده tenant این جداسازی را تضعیف نمی‌کند: فقط زمینه فعال را برای کاربرانی که به بیش از یک tenant دسترسی دارند تغییر می‌دهد، در حالی که backend همچنان مجوزها را در هر درخواست بررسی می‌کند. tenantهای اضافی توسط کاربران عادی ایجاد نمی‌شوند. آن‌ها توسط Zentor فعال می‌شوند، قیمت تأییدشده برای یک tenant اضافی در بسته Individuell ماهانه ۳۹ یورو است.

احراز هویت برای Dashboard بر اساس ایمیل و رمز عبور است، با احراز هویت دوعاملی اختیاری TOTP و روش‌های SSO پشتیبانی‌شده. یک JWT نشست معمولی به مدت ۱۲ ساعت معتبر است و یک توکن refresh می‌تواند تا هفت روز معتبر بماند. برای API عمومی مستندشده، سیستم جداگانه‌ای برای کلید API توسعه‌دهنده وجود ندارد. فرم‌های عمومی و endpointهای محتوا بدون ورود به Dashboard کار می‌کنند، در حالی که عملیات ویجت از یک توکن embed اختصاصی همراه با محدودیت‌های origin استفاده می‌کند. توکن embed فقط یک بار به‌صورت متن ساده نمایش داده می‌شود و باید در طول راه‌اندازی مانند یک راز با آن رفتار شود.

پلتفرم، Dashboard، خدمات backend مرتبط با tenant، یک پایگاه دانش، کانال‌های ارتباطی و یک استقرار SIP جدا برای تلفنی را ترکیب می‌کند. ربات صوتی SIP از ۲۴ ژوئیه ۲۰۲۶ از برنامه اصلی جدا شده است. هر tenant فعال‌شده یک نمونه SIP جدا دریافت می‌کند، فعال‌سازی یا غیرفعال‌سازی همچنان وظیفه Master Admin است. این جداسازی مانع از آن می‌شود که Dashboard مستقیماً trunkها یا زیرساخت تلفنی سطح پایین را مدیریت کند.

کنترل‌های امنیتی شامل قوانین IP، دامنه و کشور است. هر قانون جدید در حالت Dry-Run شروع می‌شود و تنها پس از یک دوره انتظار اجباری ۲۴ ساعته می‌تواند فعال شود. قوانین Allow نسبت به قوانین Block اولویت دارند. این طراحی به مدیران زمان می‌دهد تا اثر یک قانون را پیش از اعمال آن بررسی کنند و خطر مسدود شدن ناخواسته دسترسی مجاز را کاهش می‌دهد.

صفحه معماری نباید به‌عنوان یک SLA عمومی یا وعده‌ای مبنی بر در دسترس بودن هر مؤلفه اختیاری در هر بسته خوانده شود. دسترسی به ویژگی‌ها به entitlementها و Add-onها بستگی دارد. عملیات On-Premises آماده شده اما برای تولید آماده نیست، زیرا مکانیزم صدور مجوز فعلی هنوز شامل یک کلید جایگزین است. بنابراین باید به‌عنوان در دسترس بر اساس درخواست و در حال معرفی توصیف شود، نه به‌عنوان یک گزینه استقرار کاملاً خودخدمت.