أذونات SaaS متعددة المستأجرين: شرح المنظمات والفرق والأدوار بوضوح

وعد يستحق الالتزام: أدوار أقل، ملكية أوضح، إعدادات افتراضية أكثر أمانًا. ابدأ بمجموعة صغيرة من الأدوار المرتبطة بالمهام الحقيقية، اجعل الملكية واضحة لكل مورد، واجعل الافتراض الافتراضي هو أقل وصول. ثم اسمح بالمشاركة بقصد، لا بالصدفة.

خريطة بلغة بسيطة: المنظمات، الفرق، المستخدمون، والموارد

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

اختر معنى واحد لحدود المستأجر وتمسّك به. العديد من المنتجات تستخدم "المنظمة" كالمستأجر: كل البيانات تعيش داخل منظمة، ولا يمر شيء ذلك الحد إلا إذا بنيت مشاركة صريحة.

مفردات بسيطة تبقى واضحة مع النمو:

• المنظمة (المستأجر): حساب العميل وحدود البيانات الصارمة.
• المستخدم (الهوية): شخص بتسجيل دخول واحد.
• العضوية: الرابط الذي يقول إن المستخدم ينتمي لمنظمة، مع أدواره.
• الفريق (اختياري): تجمّع داخل المنظمة للعمل اليومي.
• المورد: أي شيء يجب حمايته (مشاريع، فواتير، تذاكر، مفاتيح API).

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

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

مثال: ماريا تُسجّل دخولًا مرة واحدة، ثم تنتقل بين المنظمة أ والمنظمة ب. في المنظمة أ هي في المالية ويمكنها عرض الفواتير. في المنظمة ب هي عارضة ولا تستطيع سوى قراءة المشاريع. نفس المستخدم، عضويات مختلفة، أنواع موارد متسقة، وحدود واضحة.

الأدوار والأذونات والنطاق بدون مصطلحات معقدة

تظل أذونات SaaS متعددة المستأجرين مفهومة عندما تفصل ثلاثة أشياء:

• الأدوار: تسمية توصف المسؤولية.
• الأذونات: ما يمكن للشخص فعله.
• النطاق: أين يمكنه فعله.

RBAC بلغة بسيطة

RBAC (التحكم بالوصول حسب الدور) يعني: تعطي المستخدم دورًا، والدور يمنح أفعالًا مسموحًا بها. أسماء الأدوار يجب أن تصف المسؤولية، لا الحالة. "مسؤول الفوترة" واضح. "المستخدم القوي" غالبًا ما يثير جدالًا.

عامل الأذونات كأفعال وحافظ على ثباتها عبر المنتج:

• عرض (قراءة)
• إنشاء
• تعديل
• حذف
• إدارة (دعوات، إعدادات، تصدير، وإجراءات خاصة أخرى)

ثم أضف النطاق حتى يمكن لنفس الفعل أن ينطبق في أماكن مختلفة. بهذه الطريقة تتجنب إنشاء 20 دورًا متقاربًا.

نطاقات شائعة تبقى قابلة للقراءة:

• على مستوى المنظمة
• على مستوى الفريق فقط
• العناصر الشخصية (التي يملكها المستخدم)
• المعينة (Assigned)

عندما تفوز الملكية على إضافة دور جديد

إذا وجدت نفسك تصنع أدوارًا مثل "محرر المشروع" و"محرر المشروع (الخاص)", فغالبًا هي مشكلة نطاق، لا دور.

مثال: في CRM، دع "مندوب المبيعات" ينشئ ويعدل الصفقات، لكن قيد النطاق على "العناصر الخاصة به". دع "مدير المبيعات" يحتفظ بأفعال مماثلة بنطاق "الفريق" أو "المنظمة". تحصل على أدوار أقل، قواعد أوضح، ومفاجآت أقل عند تغيير فريق شخص ما.

قانون افتراضي قوي: تمنح الأدوار الأفعال، والملكية (أو التعيين) تحدد أين تنطبق تلك الأفعال.

مجموعة قواعد بسيطة تتوسع لمئات المنظمات

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

مجموعة قواعد قابلة للتوسع:

• كل سجل (مشروع، فاتورة، تذكرة، مفتاح API) له منظمة واحدة فقط كمقر له.
• يمكن للمستخدم رؤية البيانات فقط للمنظمات التي هو عضو نشط فيها. إذا لم يكن عضوًا، يجب أن يتصرف واجهة المستخدم وواجهة برمجة التطبيقات كأن المنظمة غير موجودة.
• الأدوار تتحكم في الأفعال (إنشاء، تعديل، حذف، تصدير)، لكن فقط داخل المنظمات التي يمكن للمستخدم رؤيتها بالفعل.
• الملكية هي فاصل التعادل. يمكن أن تمنح حقوقًا إضافية داخل نطاق مسموح (تعديل المسودة الخاصة بك، إدارة مفتاح API الخاص بك) دون توسيع الوصول إلى بيانات أخرى.
• وصول المسؤول استثناء ضيق وصريح. عرّف ما الذي يستطيع "المسؤول" فعله واحتفظ بعدد أدوار المسؤولين قليلًا.

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

هذا يجعل النمو مملًا بطريقة جيدة. إضافة منظمة جديدة تعني مجرد إضافة عضويات وأدوار. القواعد الأساسية تبقى نفسها.

خطوة بخطوة: صمّم نموذج الأذونات على صفحة واحدة

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

1) اكتب المدخلات قبل القواعد

اجعل الأجزاء صغيرة عمدًا:

• اختر أربعة أنواع مستخدمين يمكنك شرحها: المالك، المسؤول، العضو، العارض.
• اذكر 3-6 موارد يلمسها الناس يوميًا (مشاريع، عملاء، تقارير، الفوترة).
• لكل مورد، اذكر 2-4 أفعال (عرض، إنشاء، تعديل، حذف، دعوة، تصدير).
• قرر ما الذي يحصل عليه العضو الجديد افتراضيًا (عادة عارض أو عضو، ليس مسؤول).
• قرر ماذا يغيّر "الفريق". اجعله يتعلق بالرؤية والتعيين والتقارير، لا بقوى مفاجِئة.

2) ضع القواعد في جدول بسيط

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

فحص بسيط: اعرض هذه الصفحة على زميل غير تقني واسأله: "هل يمكن لعضو الدعم تعديل تقرير مبيعات؟" إذا تردد، فإما نطاقاتك أو تعريف الفريق غير واضح.

قواعد ملكية الموارد والمشاركة التي تبقى معقولة

لتحافظ على وضوح الأذونات، قرر من يملك كل مورد، ثم حَدّ خيارات المشاركة. لا تفتح أدوات مشاركة معقدة مبكرًا.

نموذج الملكية الافتراضي

اجعل معظم الموارد مملوكة للمنظمة. العملاء عادةً يفكرون بمصطلح الشركة: الفواتير، المشاريع، جهات الاتصال، التذاكر، والأتمتات تنتمي للمنظمة لا للفرد.

الفرق ما تزال مفيدة، لكن اعتبر الفريق كوسم للعملية لتوجيه الرؤية والافتراضات الافتراضية، لا كمنطق أمني صارم. يمكن لوسم الفريق أن يوجه الفلاتر، لوحات البيانات، الإشعارات أو قوائم العمل، بينما يظل الوصول يأتي من الأدوار والنطاق.

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

مجموعة صغيرة من قواعد المشاركة تبقى قابلة للقراءة:

• ملكية المنظمة افتراضيًا: خزّن العناصر تحت معرف منظمة واحد.
• وسم الفريق للعملية: وسم لغاية التوجيه، لا للتحكم الصارم بالوصول.
• ملكية المستخدم للعناصر الشخصية: خاصة ما لم تُشارك صراحة.
• مستويات المشاركة فقط: خاصة (المالك)، فريق، منظمة. تجنّب قوائم تحكم وصول مخصصة لكل عنصر مبكرًا.
• فصل "المعيّن إلى" عن "من يمكنه الوصول": التعيين هو مسؤولية، ليس إذنًا.

مشاركة تبقى بسيطة

عندما يقول أحدهم "أحتاج وصولًا"، اسأل أي مستوى: عنصره الخاص، عمل فريقه، أم كل المنظمة. إن لم يتناسب مع هذه الثلاث، فعادةً علامة على أن نطاقاتك غير واضحة، لا أن تحتاج وضع مشاركة جديد.

مثال: تذكرة دعم يمكن أن تكون مملوكة للمنظمة (لكي يتمكن المديرون من إعداد تقارير عن كل التذاكر)، وموشَّمة للفريق الدعم (لتظهر في قائمة العمل الصحيحة)، ومعينة لجوردان (لتكون مسؤولًا). التعيين لا يجب أن يمنع الأدوار المصرح لها من عرضها.

الدعوات، تغييرات العضوية، والتبديل بين المنظمات

غالبًا ما تنهار الأذونات خلال "أحداث الأشخاص": دعوة شخص، نقله بين الفرق، أو إزالته. هذه التدفقات تقرر ما إذا كان نموذجك يبقى متوقعًا.

الدعوات

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

حافظ على قواعد صارمة:

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

تناسب الوصول المؤقت هنا أيضًا. بدلًا من اختراع دور "مؤقت"، اجعل منح دور له تاريخ انتهاء. عند انتهائه، يسقط الوصول تلقائيًا وسجل التدقيق يبقى نظيفًا.

الانضمام والمغادرة بدون فقدان الملكية

عندما يغادر شخص المنظمة، لا تجرِّب أن تملك الموارد نيابةً عنه. إذا كانت قاعدتك "الموارد مملوكة للمنظمة"، فالتزم بها. يمكن أن يبقى الشخص كمنشئ للتاريخ، لكن المنظمة تبقى المالكة.

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

التبديل بين المنظمات بأمان

يمكن لتسجيل دخول واحد أن ينتمي لعدة منظمات، لكن التطبيق يجب أن يكون دائمًا لديه "المنظمة الحالية" بوضوح. اجعل ذلك واضحًا في الواجهة وحدد كل فعل ضمنها.

التعطيل عادةً أفضل من الحذف. يزيل الوصول الآن بينما يحافظ على قابلية مراجعة الأفعال القديمة.

أخطاء شائعة وفخاخ يجب تجنّبها

تفشل أغلب نماذج الأذونات لأنّها تنمو أسرع من القواعد. احمِ الأساسيات (حدود المستأجر، الملكية، النطاق) وتعامل مع الباقي كتفاصيل.

انفجار الأدوار هو الفخ الكلاسيكي. يظهر حالة هامشية وتضيف دورًا جديدًا بدلًا من إذن أو نطاق أوضح. بعد أشهر، لا يعرف أحد معنى "المدير بلس". إن كان الاستثناء مطلوبًا كثيرًا، اجعله إذنًا من الدرجة الأولى. إن كان نادرًا، عالجه بمنح مؤقت ينتهي تلقائيًا.

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

الفرق كحدود أمان وهمية تسبب لبسًا مستمرًا. إذا كانت الموارد تُشترك بين فرق داخل نفس المنظمة، فقل ذلك بوضوح. إن لم تكن كذلك، نفّذ ذلك في الشيفرة، لا في التسمية.

علامات حمراء تلتقطها مبكرًا:

• "مسؤولي النظام العام" الذين يرون بيانات عبر كل منظمات العملاء افتراضيًا
• حماية في الواجهة فقط (أزرار مخفية) بدلًا من فحوصات على الخادم
• مفاتيح API وحسابات الخدمة التي تتجاوز قواعد العضوية
• أدوار معرفة بألقاب وظيفية، لا بأفعال
• استثناءات لا يمكن شرحها في جملة واحدة

إذا احتاج الدعم لمساعدة عميل، "امنحهم مسؤولًا عالميًا لمدة دقيقة" تسرب مستأجر محتمل. فضّل منح وصول صريح ومسجّل وضيق النطاق (منظمة واحدة، نافذة زمنية محددة، أفعال محددة).

فحوصات سريعة قبل الإطلاق

يجب أن تحل كل طلب بالمنظمة النشطة أولًا (من النطاق الفرعي، هيدر، الجلسة، أو المسار) ورفض أي شيء لا يتطابق معها.

بعد سياق المنظمة، احفظ الترتيب التالي للفحوص: العضوية أولًا (هل هو عضو في هذه المنظمة؟)، ثم الدور (ما الذي يسمح به هنا؟)، ثم الملكية أو المشاركة (هل لديه حق الوصول لهذا السجل؟). إن قمت بفحص الملكية قبل العضوية، قد تكشف وجود عناصر لا ينبغي كشفها.

شغل مجموعة صغيرة من اختبارات end-to-end باستخدام حسابات حقيقية، ليس فقط اختبارات وحدات:

• عضو جديد يحاول عرض، إنشاء، وتصدير بيانات
• قائد فريق يحاول إدارة فريقه فقط، لا المنظمة كلها
• مسؤول المنظمة يغيّر أدوارًا، ثم يحاول فعلًا حساسًا (حذف، تصدير)
• مستخدم مُزال يبقي تبويبًا مفتوحًا ويحاول إجراءات
• مدعو (لم يقبل) يتبع دعوة قديمة ويحاول الوصول

أضف أحداث تدقيق أساسية للأفعال التي تغيّر السلطة أو تنقل بيانات: تغييرات الأدوار، إزالات العضوية، التصديرات، الحذوفات، تحديثات الإعدادات. لا تحتاج أن تكون مثالية من اليوم الأول، لكنها يجب أن تجيب عن "من فعل ماذا، ومتى؟"

راجع الافتراضات الافتراضية. يجب أن تبدأ المنظمات الجديدة والأعضاء الجدد بأقل وصول يسمح لهم بالنجاح. تساعد أيضًا أسئلة شائعة داخلية للدعم والمبيعات، مع أمثلة مثل "هل يستطيع قائد الفريق رؤية فرق أخرى؟" و"ماذا يحدث للوصول بعد الإزالة؟"

مثال: من منظمة واحدة إلى مئات دون إعادة تصميم

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

المرحلة 1: منظمة واحدة، فريقان

اجعل الفرق تجمُّعًا وعملاً، لا مفتاح الأذونات الرئيسي. يمكنها التأثير على الافتراضات الافتراضية والتوجيه، لكنها لا يجب أن تكون البوابة الوحيدة.

المرحلة 2: أدوار ثابتة، نطاقات متوقعة

اختر مجموعة صغيرة من الأدوار وحافظ عليها مع إصدار الميزات: مسؤول، عضو، عارض. الدور يجيب على "ماذا يمكنك فعل في هذه المنظمة؟" النطاق يجيب على "أين يمكنك فعله؟"

المرحلة 3: الملكية تُسهّل قرارات التحرير

أضف قاعدة ملكية واحدة: كل مورد له منظمة ومالك (غالبًا المنشئ). يسمح التحرير إذا كنت مسؤولًا، أو إذا كنت المالك ودورك يتضمن "تعديل الخاص". يسمح العرض إذا كان دورك يتضمن "عرض" لذلك النوع من الموارد.

مثال: عضو مبيعات ينشئ عرضًا. عضو مبيعات آخر يمكنه عرضه، لكنه لا يحق له تعديله ما لم يُشارك مع الفريق أو يُعاد تعيينه. عارض من العمليات يمكنه رؤيته فقط إذا كانت قواعدك تسمح لعمليات بعرض موارد المبيعات.

المرحلة 4: 200 منظمة، نفس القواعد

عندما تستضيف 200 منظمة عميل، تعيد استخدام نفس الأدوار ونفس قواعد الملكية. تغير العضويات، لا النموذج.

طلبات الدعم مثل "هل يمكنك منح وصول إلى X؟" تصبح قائمة تحقق: تأكيد المنظمة والمورد، التحقق من دور المستخدم في تلك المنظمة، التحقق من الملكية والمشاركة، ثم تغيير الدور أو مشاركة المورد. تجنب الاستثناءات الفردية، واترك ملاحظة تدقيق.

الخطوات التالية: نفّذ، اختبر، وتكرّر بأمان

عامل نموذج الصفحة الواحدة كالعقد. نفّذ فقط القواعد التي يمكنك فرضها في كل استدعاء API وكل شاشة في الواجهة، وإلا تنحرف الأذونات إلى "يعتمد."

ابدأ صغيرًا: بعض الأدوار، نطاقات واضحة، وملكية بسيطة. عندما يأتي طلب جديد ("هل نضيف دور محرّر-مدير؟"), شدد الملكية أو النطاق أولًا. يجب أن تكون الأدوار الجديدة نادرة.

لكل مورد جديد تضيفه، اجعل الأساسيات متسقة:

• يخزن org_id (و team_id إن انطبق)
• له قاعدة رؤية (خاص، فريق، منظمة)
• يسجل أحداث تدقيق للأفعال الحساسة (دعوات، تغييرات أدوار، تصديرات)
• يُفلتر حسب النطاق في كل استعلام (ليس فقط في الواجهة)
• له افتراضات متوقعة (من يرى العنصر فور إنشائه)

اختبر السيناريوهات الحقيقية قبل تلميع الحالات الحافة: الدعوات، التبديل بين المنظمات، صفحات المسؤول، وماذا يحدث عندما يفقد شخص الوصول خلال الجلسة.

إذا كنت تبني باستخدام منشئ تطبيقات يعتمد على الدردشة، يساعد كتابة نموذج الأذونات بلغة بسيطة أولًا وإبقاؤه بجانب مواصفات المنتج. على Koder.ai (koder.ai)، يساعد وضع التخطيط (Planning Mode) مع لقطات واسترجاع التغييرات على تجربة هذه السيناريوهات والتأكد أن القواعد تتصرف نفسه عبر الويب والخلفية والهواتف المحمولة.