أمان البيانات والصلاحيات في يومي ERP: طبقات حماية مصمَّمة لسوق الخليج

مقدمة: لماذا يتحول أمان نظام ERP إلى ملف استراتيجي؟

في الشركات الصغيرة والمتوسطة في السعودية والخليج، لم يعد نظام ERP مجرد برنامج فواتير ومخزون، بل أصبح المنصة التي تمر من خلالها كل حركة مالية وضريبية وبيانية في الشركة. أي ثغرة في الأمان أو الصلاحيات تعني مخاطر مباشرة: فقدان بيانات، مخالفة ضريبية أمام هيئة الزكاة والضريبة والجمارك (ZATCA)، أو تسريب معلومات حساسة عن العملاء والموردين.

يومي ERP صُمِّم من اليوم الأول كمنصة سحابية متعددة الشركات والفروع، مع بنية أمان وصلاحيات تناسب بيئة تنظيمية مثل السعودية والإمارات، وتقدّم في نفس الوقت تجربة استخدام بسيطة لفرق المبيعات والمالية والعمليات. في هذه الصفحة نشرح كيف يحمي يومي بيانات شركتك على مستوى قاعدة البيانات، والصلاحيات، والجلسات، والنسخ الاحتياطي، ومراقبة الأنشطة، مع أمثلة عملية من قلب النظام وليس وعوداً نظرية.

أولاً: عزل بيانات الشركات (Multi-Tenancy) وعدم خلط البيانات

جوهر الأمان في أي ERP سحابي هو ضمان أن بيانات كل شركة معزولة تماماً عن الشركات الأخرى، حتى لو كانوا على نفس الخادم.

في يومي ERP:

1) قاعدة بيانات للنظام وقواعد بيانات منفصلة لكل شركة

– قاعدة بيانات للنظام: تُخزَّن فيها بيانات مستوى النظام مثل حسابات مديري النظام، الشركات، الاشتراكات، الأسعار، الصناعات.

– قاعدة بيانات منفصلة لكل شركة: كل شركة لديها قاعدة بيانات مستقلة تحتوي على فواتيرها، مخزونها، عملائها، قيودها المحاسبية، إلخ.

– التبديل الديناميكي للاتصال: محرك الاتصال بقاعدة البيانات يبدّل بين اتصال system واتصال tenant بناءً على الشركة النشطة، بحيث لا يمكن لاستعلام شركة ما أن يقرأ جداول شركة أخرى.

النتيجة العملية:

– لا توجد جداول multi-tenant ضخمة تتكدس فيها بيانات كل الشركات في جدول واحد.

– لو حدث خطأ في إعدادات شركة معيّنة، تبقى بقية الشركات معزولة تماماً.

2) الوصول عبر النطاقات الفرعية لكل شركة

– كل شركة يمكن تشغيلها عبر نطاق فرعي خاص بها من نوع subdomain (مثال: company1.yoomy-erp.com).

– جلسة المستخدم وبياناته ترتبط بهذا النطاق الفرعي، ما يعني فصل الجلسات وعزلها على مستوى المتصفح والكوكيز، وتقليل احتمالات الخلط بين شركات مختلفة.

3) عزل صلاحيات النظام عن صلاحيات الشركات

– هناك نظام صلاحيات مستقل تماماً لمديري منصة يومي (system-level RBAC) يعمل على قاعدة بيانات yaomy_system.

– ونظام صلاحيات خاص بكل شركة وموظفيها (company/tenant RBAC) على قاعدة بيانات الشركة.

– لا يمكن لمستخدم شركة الوصول لملفات أو إعدادات مستوى النظام، والعكس صحيح، حتى لو كان الاثنان يعملان على نفس الخادم.

ثانياً: نموذج الصلاحيات في يومي ERP: من مستوى النظام إلى مستوى الفرع

إدارة الصلاحيات في يومي لا تقتصر على زر “مدير” و”مستخدم عادي”، بل تعتمد على نموذج أدوار وصلاحيات مرن تم تنفيذه باستخدام إطار Spatie Permission بالإضافة إلى منطق خاص بالفروع.

1) أدوار وصلاحيات على مستوى الشركة

– لكل مستخدم أدوار Roles وصلاحيات Permissions تُخزَّن مع معرف الشركة (tenant_id).

– يمكن إنشاء أدوار مثل: محاسب، مدير مبيعات، مسؤول مخزون، مدير فرع، مدير عام الشركة، مع تعيين صلاحيات دقيقة لكل دور مثل:

– عرض فواتير المبيعات فقط.

– إنشاء أو تعديل فواتير المشتريات.

– مراجعة وترحيل القيود المحاسبية.

– إدارة دليل الحسابات ومراكز التكلفة.

– عند تنفيذ أي طلب من لوحة التحكم أو من واجهة الويب، تمر الطلبات عبر طبقة middleware تتحقق من امتلاك المستخدم للصلاحية المطلوبة قبل السماح بالدخول.

2) صلاحيات هجينة على مستوى الفروع

في الشركات متعددة الفروع، التحدي الأكبر هو أن يستطيع مدير الفرع رؤية بيانات فرعه فقط، بينما يستطيع المدير المالي أو المدير العام رؤية كل الفروع.

يومي ERP يطبق “نموذج صلاحيات هجين” للفروع:

– صلاحيات على مستوى الشركة: لو كان المستخدم يملك صلاحية مثلاً tills.view على مستوى الشركة، يستطيع رؤية كافة صناديق الفروع التي يُسمح له بها.

– صلاحيات على مستوى الفرع: لو لم يملك صلاحية الشركة، يتم الرجوع إلى جدول branch_user الذي يربط المستخدم بالفروع، مع دور فرعي (manager، employee، viewer) يحدد ما يمكنه فعله على مستوى هذا الفرع.

– يتم التحقق من الفرع الحالي current_branch_id المخزَّن في الجلسة، مع قائمة الفروع المسموح له بالوصول إليها، لمنع فتح بيانات فرع غير مصرح له به.

الفائدة لمدير التقنية:

– يمكنك إعطاء مديري الفروع صلاحيات تشغيلية كاملة على فرعهم دون منحهم رؤية حسابات أو تقارير الفروع الأخرى.

– يمكنك التحكم في من يرى ماذا بدقة، بما يناسب هيكل شركتك وفروعها في السعودية والخليج.

3) حارس أمني مركزي للطلبات (Authorization Middleware)

– كل طلب حساس (مثل فتح شاشة قيود، أو تقرير مالي، أو شاشة إعدادات) يمر عبر طبقة فحص صلاحيات مركزية.

– يستخدم النظام حراس متعددة للهوية (guards) مثل system، company، tenant، لضمان أن المستخدم الصحيح يُستعمل في السياق الصحيح:

– system guard لمديري منصة يومي.

– company guard لمستخدمي الشركة على لوحة إدارة الشركة.

– tenant guard للسياقات الفرعية داخل ERP.

– يتم تحديث كاش الصلاحيات بذكاء لتفادي تخزين بيانات قديمة، وضمان أن تغيير الصلاحيات يظهر فوراً في الواجهة.

4) صلاحيات واضحة حتى في واجهة المستخدم

– في الواجهة الأمامية (Vue)، يتم مشاركة قائمة الأدوار والصلاحيات مع المتصفح.

– توجد دوال can وhasRole تستخدم نفس منطق الصلاحيات في الخلفية، بحيث:

– لا يظهر زر أو رابط لميزة لا يملك المستخدم صلاحية الوصول إليها.

– أي محاولة وصول مباشر برابط يتم منعها من قبل السيرفر إن لم تكن الصلاحية موجودة.

ثالثاً: حماية الجلسات وتسجيل الدخول في بيئة سحابية

أمان الجلسة Session Security هو خط الدفاع الأول لحماية بيانات ERP، خصوصاً في بيئة سحابية يدخل فيها الموظفون من فروع مختلفة وشبكات متعددة.

في يومي ERP:

1) عزل الجلسات حسب الشركة والنطاق الفرعي

– جلسة المستخدم ترتبط بالشركة والنطاق الفرعي، بحيث لا يمكن أن تختلط جلسة مستخدم في شركة بأخرى حتى لو كانت بيانات الدخول متشابهة.

– يتم تخزين معرف الشركة ومعرف الفرع الحالي في الجلسة للتأكد من أن كل استعلام وحركة يطبقان على النطاق الصحيح.

2) حراس مصادقة متعددة (Multi-Guard Authentication)

– system guard لحسابات مديري المنصة.

– company وtenant guard لحسابات موظفي الشركات.

– هذا الفصل يمنع مثلاً أن يستغل موظف شركة أي صلاحيات خاصة بمدير النظام أو العكس.

3) التحكم في عمر الجلسة وإعادة تسجيل الدخول

– يمكن ضبط زمن انتهاء الجلسات (Session Timeout) بما يناسب سياسة الأمان في الشركة، بحيث تغلق الجلسات غير النشطة تلقائياً.

– يتم التحقق من هوية المستخدم عند عمليات حساسة (مثل استعادة النسخ الاحتياطي أو تغييرات إعدادات حرجة) للتأكد من أن من ينفذ الإجراء هو المستخدم الصحيح.

4) استعداد للمصادقة الثنائية (2FA) وتقوية تسجيل الدخول

– هيكل النظام مبني بحيث يمكن إضافة طبقات إضافية مثل 2FA بسهولة كجزء من مراحل قادمة، مع ربطها بحسابات المستخدمين وأدوارهم.

– يمكن تطبيق سياسات كلمات مرور قوية على مستوى الشركة، بما يتوافق مع سياسات الأمن الداخلية أو متطلبات الامتثال.

رابعاً: حماية البيانات نفسها – من الاستعلام إلى النسخ الاحتياطي

لا يكفي أن نتحكم في من يدخل، بل يجب حماية البيانات أثناء التشغيل، وعند التخزين، وفي النسخ الاحتياطية.

1) أمان على مستوى التطبيق وقاعدة البيانات

– يستخدم يومي أحدث إصدارات Laravel وPHP مع وسائل الحماية القياسية ضد:

– حقن SQL من خلال استخدام الـ Query Builder والإلزام بالـ bindings.

– هجمات XSS من خلال ترميز المخرجات في الواجهة.

– حماية CSRF في النماذج والطلبات الحساسة.

– الجداول الأساسية مُفهرسة Indexed بشكل مدروس على الأعمدة الحساسة للأداء والاستعلام (مثل company_id، branch_id، customer_id)، ويدعم النظام الآلاف من الحركات دون إبطاء غير مبرر.

2) تشفير وحماية الاتصال

– التواصل بين المتصفح والخادم مصمم ليعمل عبر HTTPS (SSL/TLS)، بما يتماشى مع متطلبات الجهات التنظيمية في السعودية ودول الخليج.

– يمكن نشر يومي في بيئة سحابية أو على خوادم الشركة مع إلزام الاتصالات المشفرة، وربطه بسياسات جدار ناري على مستوى البنية التحتية الخاصة بكم.

3) نسخ احتياطي احترافي للبيانات

– يوجد إطار كامل للنسخ الاحتياطي Backup Manager يخدم:

– نسخ قاعدة بيانات النظام.

– نسخ قواعد بيانات الشركات بشكل مستقل.

– نسخ كاملة Full أو تزايدية Incremental حسب حاجة العميل وخطة النسخ.

– يتم ضغط الملفات، وحساب قيم تحقق SHA-256 checksum، وتسجيل الحجم، ومدة إنشاء النسخة، ومسار التخزين، لضمان إمكانية التحقق من سلامة النسخة لاحقاً.

– يمكن رفع النسخ إلى مزود سحابة خارجي (مثل S3 أو غيره) بالإضافة للتخزين المحلي، مع حفظ سجلات مفصلة لكل عملية رفع أو استعادة.

4) مراقبة صارمة لموارد الخادم قبل وأثناء النسخ

– قبل بدء أي عملية نسخ، يتم فحص:

– مساحة التخزين المتوفرة.

– استهلاك الذاكرة.

– حدود الموارد الأخرى.

– لو لم تكن الموارد كافية، يتم منع عملية النسخ وإصدار رسالة واضحة، بدلاً من بدء عملية قد تتسبب في توقف الخادم أو فساد الملفات.

5) تنظيم الاستعادة بشكل آمن

– عند استعادة نسخة احتياطية لشركة معيّنة:

– يتم تنزيل ملف النسخة من التخزين الخارجي إن لم يكن موجوداً محلياً.

– يتم فك الضغط في مسار مؤقت آمن.

– يتم تنفيذ أوامر استعادة قاعدة البيانات بعد التحقق من الملف.

– يتم تسجيل كل خطوة في سجل نشاط النسخ الاحتياطي، مع زمن التنفيذ وحجم البيانات المستعادة.

بهذا الأسلوب، لا تُعامل النسخ الاحتياطية كمجلد عشوائي من ملفات SQL، بل كسير عمل متكامل يمكن تتبعه وتدقيقه في أي وقت.

خامساً: سجل الأنشطة (Audit Log) ورؤية من فعل ماذا ومتى

الأمان الحقيقي لا يكتمل بدون إمكانية معرفة من فعل ماذا ومتى، خصوصاً مع متطلبات ZATCA والضرائب في السعودية، أو متطلبات التدقيق الداخلي في شركات الخليج.

في يومي ERP:

1) سجل أنشطة مفصل

– كل عملية مهمة في النظام (مثل إنشاء فاتورة، تعديل حد ائتمان، تغيير صلاحيات مستخدم، إنشاء نسخة احتياطية، استعادة شركة) يمكن تسجيلها مع:

– هوية المستخدم.

– نوع العملية.

– التوقيت.

– تفاصيل إضافية عن الكيان الذي تم التعديل عليه.

2) تتبع عمليات النسخ والاستعادة

– إطار النسخ الاحتياطي نفسه يكتب سجلات منفصلة لعمليات:

– إنشاء النسخة (create).

– رفع النسخة إلى مزود خارجي (upload).

– استعادة النسخة (restore).

– يمكن لقسم تقنية المعلومات الرجوع لهذه السجلات لمعرفة:

– متى أُخذت آخر نسخة.

– من طلب الاستعادة.

– هل تمت العملية بنجاح أم فشلت مع رسالة خطأ واضحة.

3) دعم الامتثال والتدقيق

– من خلال الجمع بين سجل الأنشطة، وسجلات النسخ الاحتياطي، وتقارير الحركات، يمكن للمراجع الداخلي أو الخارجي:

– تتبع خط سير المستندات من لحظة إصدار الفاتورة وحتى الترحيل المحاسبي والتسوية البنكية.

– التحقق من أن تعديلات المستخدمين على الأرصدة والصلاحيات لا تتم دون أثر يمكن رصده.

سادساً: مراقبة الأداء والصحة كجزء من منظومة الأمان

الأمان ليس فقط كلمات مرور وتشفير؛ أداء النظام واستقراره جزء أساسي من حماية أعمالك. تعطل ERP في منتصف اليوم أو بطء شديد في التقارير يمكن اعتباره خطراً تشغيلياً حقيقياً.

لذلك يضم يومي ERP طبقات مراقبة للأداء والصحة:

1) مراقبة الاستعلامات وقاعدة البيانات

– يتم تسجيل الاستعلامات البطيئة مع:

– نص الاستعلام.

– زمن التنفيذ.

– الشركة المعنيّة.

– يمكن لمدير التقنية تحليل هذه السجلات لمعرفة:

– التقارير أو الشاشات التي تحتاج تحسين في الفهرسة أو تصميم الاستعلام.

– أوقات الذروة التي تزداد فيها الاستعلامات البطيئة.

2) فحص صحة النظام بشكل دوري

– هناك خدمة مخصَّصة لفحص صحة:

– اتصال قاعدة البيانات.

– الكاش (Redis).

– الطوابير (Queues).

– مساحة القرص.

– استهلاك الذاكرة.

– يتم تخزين نتائج هذه الفحوصات في جداول مخصَّصة، ويمكن عرضها في لوحة إشرافية كجزء من مراقبة النظام.

3) كاش للأداء على مستوى API

– توجد طبقة Performance Cache لطلبات GET من واجهات API:

– تولّد مفتاح كاش لكل طلب بناءً على المسار، المعاملات، ومعرّف الشركة.

– تحفظ ناتج الاستجابة لفترة زمنية محددة (TTL).

– تقلل عدد الاستعلامات المتكررة على نفس التقارير أو الشاشات التحليلية.

النتيجة:

– أداء أكثر ثباتاً تحت ضغط آلاف الحركات من فروع متعددة.

– تقليل فرص تعطل النظام بسبب ازدحام الاستعلامات أو بطء الكاش.

سابعاً: ملاءمة أمان يومي ERP لسوق الخليج والسعودية

ما يميز يومي ERP عن حلول أخرى أنه صُمّم منذ البداية ليخدم أسواقاً مثل السعودية والخليج ومصر، وليس مجرد ترجمة عربية لمنتج عالمي:

1) توافق مع متطلبات الفاتورة الإلكترونية والضرائب

– بنية الفواتير ضريبية بالأساس، مع دعم:

– أنواع فواتير ZATCA (فاتورة ضريبية، فاتورة مبسطة).

– ترقيم ضريبي منفصل لكل فرع ونوع مستند.

– تخزين بيانات الفواتير بطريقة تتيح إنتاج ملفات متوافقة مع بوابة الفوترة الإلكترونية.

– هذا ينعكس على الأمان من زاويتين:

– حماية سلامة بيانات الفواتير حتى لا تتعرض الشركة لمخاطر ضريبية.

– القدرة على تبرير الحركات أمام الجهات التنظيمية من خلال سجلات دقيقة.

2) دعم تعدد الفروع مع صلاحيات تناسب الشركات الخليجية

– معظم الشركات في السعودية والخليج تعمل بنموذج الفروع: فرع رئيسي، عدة فروع مبيعات، مستودعات، نقاط بيع.

– نموذج الأمان في يومي يدعم هذا النمط بشكل طبيعي:

– صلاحيات على مستوى الشركة لمجلس الإدارة والإدارة المالية المركزية.

– صلاحيات على مستوى الفرع لمديري الفروع وموظفي نقاط البيع.

3) استضافة مرنة وسياسات أمان قابلة للتخصيص

– يمكن نشر يومي:

– على سحابة عامة مع تأمين SSL، جدار حماية، وشبكات خاصة.

– أو على خوادم مملوكة للشركة مع سياسات أمان داخلية مشددة (شبكة داخلية، VPN، إلخ).

– النظام نفسه لا يفرض بيئة استضافة واحدة، بل يتكامل مع سياسات الأمان لدى العميل.

ثامناً: ماذا يعني هذا عملياً لمدير التقنية وأمن المعلومات؟

لو كنت مدير تقنية أو مسؤول أمن معلومات في شركة سعودية أو خليجية، فهذا ما ستحصل عليه عند اعتماد يومي ERP:

1) طبقات حماية متعددة:

– عزل على مستوى قاعدة البيانات لكل شركة.

– أدوار وصلاحيات دقيقة على مستوى الشركة والفرع.

– سجل أنشطة ونسخ احتياطية يمكن تتبعها وتدقيقها.

– مراقبة أداء وصحة تُمكّنك من التدخل قبل أن يتحول الضغط التشغيلي إلى تعطل حقيقي.

2) قابلية الضبط حسب سياسة شركتك

– يمكنك تصميم أدوارك وصلاحياتك بما يتماشى مع سياسة الجهات الداخلية، دون أن تضطر لتعديل الكود.

– يمكنك التحكم في جداول النسخ الاحتياطي، وسياسات الاستعادة، بما يناسب درجة تحمل المخاطر في شركتك.

3) استعداد أفضل أمام الجهات التنظيمية

– بفضل سجلات الحركات، الفواتير الإلكترونية، والنسخ الاحتياطية المنظمة، تصبح جاهزاً لأي فحص ضريبي أو مراجعة داخلية.

تاسعاً: سيناريو واقعي مختصر

تخيّل شركة توزيع مواد غذائية في الرياض لديها:

– فرع رئيسي.

– ثلاثة فروع بيع جملة.

– مستودع مركزي.

تقوم بتشغيل يومي ERP بالشكل التالي:

– مدير عام الشركة يملك أدواراً تسمح له برؤية كل الفروع والتقارير الموحدة.

– مدير كل فرع لديه صلاحيات كاملة على فرعه فقط (مبيعات، مخزون، تقارير فرعية).

– محاسب الشركة يملك صلاحيات على كل الفروع لكن على مستوى الحسابات والقيود.

– يتم أخذ نسخ احتياطية يومية تلقائياً لقواعد بيانات الشركة، وتُرفع نسخة أسبوعية إلى مزود سحابة خارجي.

– عند حدوث مشكلة في أحد الفروع (مثل حذف فاتورة بالخطأ)، يمكن الرجوع لسجل الأنشطة لمعرفة من قام بالإجراء، ثم تقييم الحاجة لاستخدام النسخ الاحتياطي لاستعادة البيانات.

هذا السيناريو ليس تصميم PowerPoint، بل سير عمل مدعوم فعلياً بما هو موجود في بنية Yaomy ERP.

دعوة لاتخاذ خطوة عملية (CTA)

لو كنت تبحث عن نظام ERP عربي يوفر مستوى أمان وصلاحيات يناسب متطلبات السوق السعودي والخليجي، دون تعقيد مبالغ فيه، فإن يومي ERP يمنحك:

– عزل بيانات حقيقي لكل شركة.

– نموذج صلاحيات مرن ومدعوم على مستوى الكود والواجهة.

– نسخ احتياطية واستعادة يمكن الوثوق بهما.

– مراقبة أداء وصحة منظومة تساعدك على النوم مطمئناً.

الخطوة التالية:

– اطلب جلسة استشارة قصيرة مع فريق يومي لمراجعة وضع الأمان في نظامك الحالي، ومناقشة كيف يمكن نقل بياناتك وتشغيل يومي ERP بطريقة متوافقة مع سياسات الأمان والضرائب في السعودية والخليج.

روابط داخلية مقترحة

– صفحة: الفاتورة الإلكترونية وZATKA في يومي ERP (Cluster 4 – id 101).

– صفحة: الامتثال الضريبي والفواتير الإلكترونية في السعودية (Cluster 14 – id 501).

– صفحة: الصلاحيات والأدوار والمجموعات (RBAC) في يومي ERP (Cluster 4 – id 112).

– صفحة: سجل الأنشطة والتدقيق (Activity Log) في يومي (Cluster 4 – id 111).

– صفحة: النسخ الاحتياطي والاستعادة (Backup & Recovery) في يومي ERP (Cluster 15 – id 522).

– صفحة: أداء يومي ERP مع آلاف الحركات والفروع (Cluster 15 – id 523).