بنية متعددة المستأجرين
كل مؤسسة عميل هي مستأجر منفصل على المستوى الأعلى. كل استعلام في قاعدة البيانات مرتبط بمؤسسة واحدة، وطبقة البيانات مبنية بحيث يكون الوصول العابر للمستأجرين مستحيلًا هيكليًا — وليس مجرد محكوم بسياسات.
تحمل الجلسات والحسابات الفرعية والتكاملات سياق المؤسسة. لم يحدث لدينا أي حادث مؤكد لكشف بيانات عابر للمستأجرين. إذا حدث، سننشر تحليلًا شفافًا لما حصل خلال 30 يومًا.
المصادقة
كلمات المرور مشفّرة بـ bcrypt ولا تُخزَّن بنص واضح أبدًا. تستخدم الجلسات ملفات تعريف ارتباط HTTP-only موقّعة وتُجدَّد عند تغييرات الصلاحيات. محاولات تسجيل الدخول الفاشلة محدودة المعدل لكل IP وحساب.
المصادقة الثنائية مدعومة لكل مستخدم عبر TOTP (Google Authenticator، 1Password، Authy، إلخ) بأسرار مشفّرة ورموز استرداد. تسجيل الدخول الموحّد عبر OIDC وSAML على خارطة طريق المؤسسات.
Passkeys متاحة للمستخدمين الذين يفضلون مصادقة مقاومة للتصيد مدعومة بـ WebAuthn.
التحكم بالوصول حسب الدور (RBAC)
تأتي Repzo بأربعة أدوار افتراضية هرمية — Owner، Admin، Manager، User — مع نظام صلاحيات شامل تحتها. يستطيع المالكون إنشاء أدوار مخصصة بلا حد مصممة لوظائف عمل محددة (مثل مدقق للقراءة فقط، مدير مبيعات، وكيل دعم).
الصلاحيات دقيقة على مستوى الإجراء (مثل leads.update_own، deals.delete) بدلًا من مستوى الوحدة. هذا يعني أنك تستطيع منح دور صلاحية رؤية العملاء المحتملين دون حذفهم، أو تحرير الصفقات الخاصة فقط مع قراءة كل الصفقات.
رؤية البيانات حسب القسم
بالإضافة إلى RBAC، تفرض Repzo ثلاثة نطاقات لرؤية البيانات لكل مستخدم ولكل وحدة: "الكل" (يرى كل شيء في المؤسسة)، "القسم" (يرى الذاتي + الأقسام الفرعية)، و"الذاتي" (يرى فقط السجلات التي يملكها أو مسندة إليه).
تُفرض الرؤية على طبقة استعلامات قاعدة البيانات — وليس في الواجهة — فلا يستطيع المستخدمون رؤية السجلات المخفية بفحص طلبات الشبكة أو تخمين المعرّفات. تدعم الأقسام تنظيمًا هرميًا بإعادة الترتيب بالسحب والإفلات.
التشفير
تُشفَّر البيانات أثناء النقل عبر TLS 1.2+ لكل اتصال بين العملاء، خوادم تطبيقاتنا، وقاعدة البيانات.
تُشفَّر البيانات في الراحة في قاعدة البيانات بـ AES-256. الحقول الحساسة (أسرار 2FA، بيانات اعتماد التكاملات، رموز OAuth) تحصل على تشفير إضافي على طبقة التطبيق بمظروف مفتاح منفصل، فحتى لقطة قاعدة بيانات مخترقة لا تكشف هذه القيم بنص واضح.
سجل التدقيق
كل تغيير لكل كيان مسجّل في سجل تدقيق غير قابل للتغيير: المستخدم (أو تطبيق التكامل)، الكيان، الإجراء، القيم قبل/بعد، عنوان IP، وكيل المستخدم، والطابع الزمني.
يظهر سجل التدقيق في الواجهة كخط زمني على كل سجل ليتمكّن المسؤولون من التحقيق في "ما الذي تغيّر ومن غيّره" دون كتابة SQL أو فتح تذكرة دعم.
الحذف الناعم
لا يُحذف أي كيان جوهري في Repzo نهائيًا. "الحذف" يضع طابعًا زمنيًا deletedAt؛ كل استعلام يصفّي السجلات المحذوفة تلقائيًا. يستطيع المسؤولون تدقيق واستعادة السجلات المحذوفة، وسجل التدقيق يلتقط الحذف وأي استعادة.
هذا يحمي من الفقد العرضي، برامج الفدية، والجهات الفاعلة المحتالة، ويبقي تاريخًا كاملًا متاحًا للتحقيقات المتعلقة بالامتثال.
وصول API
يستخدم وصول API البرمجي رموز Bearer بصيغة foxa-{orgShortId}-{secret}. يُخزَّن فقط هاش SHA-256 للسر — يُعرض النص الواضح مرة واحدة عند الإنشاء ولا يُعرض مرة أخرى.
كل رمز يحمل نطاقات لكل مورد بأسلوب Stripe (leads:write، tickets:read، إلخ) فيمكنك إصدار رموز ضيقة النطاق للتكاملات بدلًا من منح وصول واسع. رموز API محدودة المعدل، مدقّقة، وقابلة للإلغاء من إعدادات تطبيقات المطورين.
النسخ الاحتياطي والاسترداد
نأخذ نسخًا احتياطية مشفّرة يومية لقاعدة البيانات، محتفظ بها لمدة 30 يومًا. تُختبَر النسخ الاحتياطية بانتظام عبر تجارب استرداد لنقطة زمنية.
في حالة انقطاع على مستوى المنطقة، لدينا كتيبات تشغيل موثّقة لترقية البنية التحتية الاحتياطية. هدف نقطة الاسترداد (RPO) لدينا 24 ساعة؛ هدف وقت الاسترداد (RTO) 4 ساعات.
الإبلاغ عن الثغرات
إذا اكتشفت مشكلة أمان في Repzo Workstation، يرجى مراسلتنا على info@repzo.com بالتفاصيل. نعترف بالتقارير خلال يوم عمل واحد ونهدف إلى تقديم جدول زمني للمعالجة خلال خمسة أيام عمل.
لا نشغّل حاليًا برنامج مكافآت أخطاء مدفوعًا لكننا نشكر المُبلِّغين في تنبيهاتنا الأمنية بإذنهم. يرجى منحنا وقتًا معقولًا للمعالجة قبل الكشف العام.
لديك أسئلة حول الأمان؟
راسلنا على info@repzo.com أو تواصل مع المبيعات للاطلاع على استبيان الأمان.