تعمل معظم منصات المحاسبة بنظام SaaS بالطريقة نفسها: تطبيق واحد وقاعدة بيانات واحدة وجميع العملاء داخلها. وهذا مجدٍ للمورّد — لكنه يعني أن جميع العملاء يتشاركون المصير نفسه. يشرح هذا المقال كيف يعمل هذا النموذج، وكيف يبدو الاختراق داخله، وكيف بُني FiscFort بشكل مختلف.
كيف تخزّن منصة SaaS مشتركة نموذجية بياناتك
في المنصة متعددة المستأجرين، يخدم التطبيق نفسه — وغالباً قاعدة البيانات نفسها — عدداً كبيراً من العملاء ("المستأجرين"). يحمل كل سجل معرّف المستأجر، ويضيف التطبيق عبارة "هذا المستأجر فقط" إلى كل استعلام. والفصل بين العملاء هنا منطق برمجي في التطبيق: لا يصمد إلا ما دام كل استعلام وتقرير وتصدير وتكامل يطبّق المرشّح بشكل صحيح.
تذكر إرشادات OWASP بشأن أمان البيئات متعددة المستأجرين المفاضلة بوضوح: هذه البنية فعّالة من حيث التكلفة وهي أساس SaaS الحديثة، لكن ثغرة واحدة قد تكشف بيانات جميع المستأجرين، وخطأ في الإعداد قد يسرّب البيانات عبر حدود المستأجرين (OWASP). ويؤكد خبراء اختبار الأمان الأمر نفسه: ففي منصة ذات قاعدة بيانات مشتركة، قد يكشف حقن SQL واحد أو مرشّح واحد خاطئ النطاق جميع المستأجرين دفعة واحدة، لأن العزل قائم في طبقة التطبيق فقط ولا تفرضه قاعدة البيانات نفسها (AppSecure).
ماذا يعني "الاختراق" في كل نموذج
| الحالة | SaaS مشتركة متعددة المستأجرين | نسخ FiscFort المخصصة |
|---|---|---|
| أين توجد بيانات العميل | في جداول يشترك فيها جميع العملاء، ويفصل بينها معرّف المستأجر | في قاعدة بيانات منفصلة لكل عميل، داخل نسخة Odoo الخاصة بذلك العميل |
| ما الذي يفرض الفصل | شيفرة التطبيق التي يجب أن تكون صحيحة في كل استعلام | قاعدة البيانات والحاويات والشبكات وبيانات الاعتماد نفسها |
| خطأ في مرشّح المستأجر | قد يكشف عدداً كبيراً من العملاء أو جميعهم | يقتصر على نسخة ذلك العميل وحدها؛ فلا توجد فيها بيانات أي عميل آخر |
| تسرّب قاعدة بيانات أو بيانات اعتماد المسؤول | يفتح القاعدة المشتركة: أي جميع العملاء | يفتح قاعدة بيانات عميل واحد فقط؛ فالعملاء الآخرون يستخدمون بيانات اعتماد مختلفة |
| الاستيلاء على حساب أحد العملاء | يبدأ المهاجم من داخل المنصة المشتركة | يبقى المهاجم محصوراً في نسخة ذلك العميل |
| الاستضافة | منصة سحابية مشتركة | بنية تحتية مخصصة مستضافة في الاتحاد الأوروبي |
كيف بُني FiscFort
- نسخة Odoo واحدة وقاعدة بيانات PostgreSQL واحدة ومساحة تخزين خاصة لكل عميل. الفصل خاصية في قاعدة البيانات نفسها، لا في مرشّح يجب أن يبقى صحيحاً إلى الأبد. فوضع الشركات المتعددة في Odoo يبقي جميع الشركات في قاعدة بيانات واحدة ويعتمد على صحة قواعد السجلات في كل نموذج؛ وقد اخترنا عدم استخدامه لهذا السبب تحديداً.
- شبكة وقواعد جدار ناري خاصة به. تعمل حاويات كل عميل على شبكة مثبّتة خاصة به، ولمنافذ كل عميل قواعد جدار ناري صريحة خاصة بها.
- بيانات اعتماد خاصة به. يحصل كل عميل على كلمة مرور قاعدة بيانات ومفاتيح API خاصة به، تُنشأ لذلك العميل ولا تُنسخ أبداً من عميل آخر.
- عناوين وحسابات دخول خاصة به. يصل المحاسب إلى Odoo الخاص بكل عميل عبر عنوان URL مستقل وحساب دخول مستقل؛ ويصل العميل إلى بوابته الخاصة بحساب دخوله الخاص. ولا تُعرض قائمة قواعد البيانات إطلاقاً — إذ يحدد Odoo قاعدة بيانات العميل من اسم المضيف، ولا يمكن استعراض أي شيء.
من يستطيع الوصول إلى ماذا
- العميل يسجّل الدخول إلى بوابته الخاصة ولا يرى سوى نسخته هو.
- المحاسب يسجّل الدخول إلى Odoo الخاص بكل عميل على حدة — عنوان URL واحد وحساب دخول واحد لكل عميل — فلا يعني الوصول إلى عميل ما الوصول إلى عميل آخر.
- فريق عمليات FiscFort يملك صلاحية المسؤول في كل نسخة، لأن التحديثات والتغييرات التنظيمية تتطلبها. وتستخدم هذه الصلاحية وكلاء وسير عمل آلية عبر حساب خدمة مخصص، لا أشخاص يسجّلون الدخول، وبيانات اعتمادها مختلفة على كل خادم ومخزّنة بتشفير.
- أي شخص آخر لا يملك شيئاً: فالخوادم نفسها ليس لها عنوان عام.
داخل Odoo، يُظهر كل سجل من أنشأه أو من عدّله آخر مرة، ولا يمكن إلا عكس القيود المحاسبية المرحَّلة، ولا يمكن تعديلها أبداً. ولا يسجّل Odoo من اكتفى بعرض سجل ما؛ فالذي يُسجَّل هو التغييرات.
المحيط الأمني حوله
لا تصل الحركة إلى العميل إلا عبر Cloudflare (الحماية من هجمات DDoS وجدار حماية تطبيقات الويب) وطبقة الوكيل العكسي لدينا عبر HTTPS. ليس للخوادم عنوان IP عام، ولا يُعرَّض سوى البوابة وOdoo، ولا يمكن الوصول إلى الإدارة من الإنترنت. وتعلوها الطبقات الأخرى الموضحة في صفحات منتجاتنا — الجدار الناري المؤسسي، والتشفير المزدوج على مستوى التخزين، وروابط الاتحاد الأوروبي الاحتياطية، والفحص الفوري لمكافحة الفيروسات، ومراقبة عناوين URL. وتُراقَب الخوادم على مدار الساعة، ويُحدَّث نظام التشغيل وDocker وبرامج المورّدين أسبوعياً، مع لقطة وإمكانية للتراجع.
محدَّث دائماً، دون نقل بياناتك
يخدم المحرك نفسه ليتوانيا وبلجيكا. وتتحقق عملية محددة وعدة وكلاء ذكاء اصطناعي من المصادر الرسمية للبلدين، ومع كل فجر عند الساعة 3 صباحاً يحدّثون Odoo الخاص بكل عميل بالقواعد الحالية. يغيّر التحديث القواعد لا البيانات، ويُطبَّق داخل نسخة كل عميل — فلا تنتقل بيانات عميل إلى آخر أبداً.
أسئلة توجّهها إلى أي مورّد SaaS
- هل بياناتي في قاعدة بيانات يشاركني فيها عملاء آخرون؟
- ما الذي يمنع خطأً في مرشّح المستأجر من كشف الجميع؟
- كم عميلاً يفتح تسرّب بيانات اعتماد واحد؟
- من لدى المورّد يستطيع قراءة بياناتي، وكيف يُمنح هذا الوصول، وأين يُسجَّل؟
- أين تُستضاف المنصة، ومن يشغّلها؟
ذو صلة
إقامة البيانات في الاتحاد الأوروبي لبيانات مسك الدفاتر للعملاء، موضَّحة
المصادر
- OWASP — Multi-Tenant Security Cheat Sheet
- AppSecure — penetration testing for multi-tenant SaaS architectures (2026)
وصف منصات SaaS المشتركة هو النمط الشائع؛ وتختلف المورّدات فيما بينها.