بناء منظومة الصلاحيات في SaaS: التصميم الصحيح منذ البداية

التحكم في الوصول المبني على الأدوار (RBAC) في منصات SaaS متعددة المستأجرين أكثر تعقيداً مما يبدو في اليوم الأول من التنفيذ. نموذج المشرف والعضو البسيط يعمل عند الإطلاق لكنه يفشل عندما يطلب أول مشترٍ مؤسسي في لبنان أو الخليج صلاحيات على مستوى الأقسام وسير عمل الموافقة وسجلات التدقيق. تصميم RBAC بشكل صحيح من البداية يتجنب إعادة الكتابة الكاملة في أسوأ لحظة ممكنة.

لماذا تفشل نماذج المشرف والعضو البسيطة عند التوسع المؤسسي؟

معظم منتجات SaaS تبدأ بدورين: مشرف وعضو. المشرف يمكنه فعل كل شيء. العضو يمكنه فعل معظم الأشياء. هذا كافٍ للعشرات الأوائل من العملاء.

المشاكل تبدأ عندما:

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

يتطلب المشتري المؤسسي امتثالاً لـ SOC2 أو ISO27001. هذه الشهادات تتطلب ضوابط وصول يمكن إثباتها تتجاوز نموذج المشرف والعضو. المدققون يريدون رؤية أن المستخدمين لديهم الحد الأدنى من الصلاحيات الضرورية وأن تغييرات الصلاحيات مُسجّلة.

ينمو المنتج ليشمل سير العمل. سير عمل الموافقة يتطلب تمييزاً بين المستخدمين الذين يمكنهم بدء إجراء والمستخدمين الذين يمكنهم الموافقة عليه.

نموذج البيانات الذي يتوسع

نموذج RBAC الذي يتوسع عبر حالات الاستخدام هذه له أربعة مكونات: المستخدمون والأدوار والصلاحيات والتعيينات.

الصلاحيات هي القدرات الذرية في النظام. order:create، order:read، order:void، menu:update، report:view، user:invite. الصلاحيات تُعرَّف من قبل فريق المنتج وتتغير نادراً.

الأدوار هي مجموعات مسماة من الصلاحيات. cashier، branch_manager، head_office_admin، viewer. تُعرَّف الأدوار على مستوى المستأجر، مما يعني أن كل مستأجر يمكنه إنشاء أدواره المسماة واختيار الصلاحيات التي تتضمنها كل دور.

تعيينات الأدوار تربط المستخدمين بالأدوار ضمن نطاق. مستخدم يمكن تعيينه كـ branch_manager للفرع A ولكن فقط كـ cashier للفرع B.

النطاق هو الوحدة التي ترتبط بها تعيينات الأدوار. في مجموعة مطاعم، قد يكون النطاق organization (جميع الفروع) أو branch:uuid.

تنفيذ فحوصات الصلاحيات في Go

فحوصات الصلاحيات يجب أن تكون سريعة. طلب ويب يفحص ثلاث صلاحيات ويجري ثلاث استعلامات قاعدة بيانات لكل فحص يضيف 50 إلى 100 ميلي ثانية من الكمون من نظام الصلاحيات وحده.

النهج المعياري: تحميل مجموعة الصلاحيات الكاملة للمستخدم عند إنشاء الجلسة وتخزينها مؤقتاً. في Go، يمكن أن يكون التخزين المؤقت في الذاكرة أو في Redis للنشرات الموزعة.

صلاحيات المستخدم الفعلية هي اتحاد جميع الصلاحيات عبر جميع تعيينات أدواره. مستخدم له دور branch_manager في الفرع A ودور cashier في الفرع B لديه اتحاد مجموعات صلاحيات كلا الدورين.

سجلات التدقيق للصلاحيات

المشترون المؤسسيون وأطر الامتثال يتطلبون تسجيل تغييرات الصلاحيات وأن تكون السجلات غير قابلة للتغيير. المتطلبات المحددة التي تظهر أكثر في مبيعات SaaS المؤسسي في منطقة الشرق الأوسط:

• من منح الصلاحية
• متى مُنحت
• متى سُحبت
• من سحبها
• ماذا فعل المستخدم خلال امتلاكه الصلاحية

سجلات التدقيق لتغييرات الصلاحيات مباشرة: مشغّل أو تسجيل على مستوى التطبيق على جدول user_roles يسجل كل إدراج وحذف مع معرف المستخدم المتصرف والطابع الزمني.

دروس من الإنتاج

صمم لصلاحيات مدركة للنطاق من البداية. إضافة الوعي بالنطاق لنموذج صلاحيات يجهل النطاق هو تغيير في مخطط قاعدة البيانات يؤثر على كل فحص صلاحيات في التطبيق.

خزّن الصلاحيات مؤقتاً عند إنشاء الجلسة، لا في كل طلب.

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

يجب تعريف الصلاحيات كسلاسل نصية في كود التطبيق، لا كأعداد صحيحة أو enums. order:create قابل للقراءة في السجلات وسجلات التدقيق. permission_id: 17 ليس كذلك.