صلاحيات المستخدمين في التطبيق: دليل الإدارة العملي

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

ما هي صلاحيات المستخدمين في التطبيق؟

صلاحيات المستخدمين في التطبيق هي مجموعة القواعد التي تحدد من يرى بيانات معينة، ومن يستطيع تعديلها أو حذفها أو الموافقة عليها أو تصديرها. تُمنح هذه القواعد عادةً عبر «أدوار» جاهزة مثل مالك ومدير ومحرر وعميل. المبدأ واحد: أقل قدر من الوصول يكفي لإنجاز المهمة، لا أكثر.

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

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

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

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

الأدوار التي يحتاجها أي تطبيق تجاري فعلًا

لا تصنع خمسة عشر دورًا في البداية. جرّبت ذلك مع عميل يدير سلسلة مقاهٍ، وانتهى الأمر بأدوار لا أحد يتذكر ما تفعله. أربعة إلى ستة أدوار تكفي 90% من التطبيقات:

• المالك (Owner): يملك الاشتراك والفاتورة، ويستطيع حذف الحساب أو نقل الملكية. شخص واحد، أو اثنان بحد أقصى.
• المدير (Admin): يدير المستخدمين والإعدادات، لكنه لا يمسّ بيانات الفواتير ولا يحذف المشروع.
• المشرف التشغيلي (Manager): يرى فرعه أو فريقه فقط. مدير فرع جدة لا يرى أرقام فرع الدمام.
• الموظف (Member): ينشئ ويعدّل ما يخصه، ولا يرى سجلات زملائه.
• القارئ (Viewer): مثالي للمستثمر أو المحاسب الخارجي أو مدقق الحسابات.
• العميل النهائي (Customer): يرى طلباته وبياناته الشخصية حصرًا.

الدور ليس مسمى وظيفيًا، بل حزمة أفعال. لهذا أنصح بتسمية الأدوار بما تفعله لا بالمنصب: «معتمد الطلبات» أوضح من «مدير أول». الموظف قد يترقى، والدور يبقى.

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

كيف تحدد الصلاحيات قبل نشر التطبيق؟

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

خطوات التنفيذ التي أتبعها مع كل مشروع:

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

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

RBAC أم ABAC؟ النموذج الذي أنصح به

نموذجان يتنافسان. RBAC يمنح الصلاحية حسب الدور: «كل مدير يستطيع الاعتماد». ABAC يمنحها حسب الخصائص: «يستطيع الاعتماد إن كان في الفرع نفسه، والمبلغ أقل من حد معين، والوقت داخل ساعات العمل».

رأيي صريح: ابدأ بـ RBAC، وأضف إليه شرط الملكية فقط. أي «الدور + هل هذا السجل يخصك أو يخص فرعك؟». هذا المزيج البسيط يغطي المتاجر والعيادات والمدارس وتطبيقات الخدمات الميدانية بلا تعقيد.

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

هناك عنصر ثالث لا يُناقش كفاية: عزل المستأجرين (Multi-tenancy). إن كان تطبيقك يخدم عدة شركات على النظام نفسه، فكل استعلام يجب أن يحمل معرّف الشركة. غياب هذا الحقل هو السبب الأول لحوادث «عميل يرى بيانات عميل آخر»، وهي أسوأ رسالة يمكن أن تصل إلى صندوق بريدك.

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

مقارنة خيارات إدارة الصلاحيات: ما تشتريه فعلًا

السوق مزدحم، والأسماء تبدو متشابهة. هذه الخيارات الرئيسية وما يناسب كل منها:

• منصات البناء بالذكاء الاصطناعي: تولّد لك الأدوار وقواعدها مع التطبيق نفسه، وتديرها من لوحة تحكم عربية بلا كود. الأسرع لغير التقنيين، والأنسب إن أردت الإطلاق خلال أسبوع بدل أشهر. راجع خطط الأسعار لتعرف ما يشمله كل مستوى من عدد المستخدمين والأدوار.
• Supabase مع Row Level Security: قواعد تُفرض داخل قاعدة البيانات ذاتها، وهو الأسلوب الأقوى تقنيًا. خطته المدفوعة Pro تبدأ من 25 دولارًا شهريًا، لكن كتابة القواعد بلغة SQL تحتاج مطورًا.
• Firebase Security Rules: مريح لتطبيقات الجوال البسيطة، وتعقيده يرتفع سريعًا مع تشابك البيانات.
• Auth0 و Clerk: ممتازان في تسجيل الدخول وإدارة الهوية، وطبقاتهما المجانية تغطي آلاف المستخدمين النشطين. لكن التصريح التفصيلي يبقى مسؤوليتك في الطبقة الخلفية.
• Keycloak: مفتوح المصدر ومجاني، ويحتاج خبرة تشغيل حقيقية. مناسب للجهات التي تطلب استضافة داخلية.
• محرّكات متخصصة مثل Permit.io و Cerbos: منطقية عند قواعد معقدة ومتعددة، ومبالغ فيها لمشروع في مرحلة التحقق من السوق.

معايير الشراء التي أوصي بها: هل يمكن تعديل الأدوار من لوحة التحكم بلا تعديل كود؟ هل هناك سجل تدقيق جاهز؟ هل تستطيع تسجيل الخروج القسري لمستخدم معيّن؟ وهل التكلفة تُحسب بعدد المستخدمين النشطين أم بعدد المقاعد؟ الفرق بين الطريقتين قد يضاعف فاتورتك السنوية.

ستة أخطاء شائعة وما لا يخبرك به أحد

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

• حساب المالك على بريد شخصي لموظف: يغادر الموظف، ويغادر معه مفتاح المشروع. اربط الملكية ببريد مؤسسي دائم مثل owner@شركتك.
• مدير واحد فقط: إن سافر أو فقد هاتفه، تجمّد الإدارة بالكامل. اجعلهم اثنين، لا أكثر.
• إخفاء الزر بدل منع العملية: الواجهة نظيفة، والـ API مفتوحة. اطلب الفحص من حساب موظف عادي.
• صلاحية التصدير المنسية: قد تمنع التعديل وتترك زر «تنزيل Excel» مفتوحًا للجميع. اعتبر التصدير صلاحية منفصلة دائمًا.
• حساب مشترك بين ثلاثة موظفين: يوفّر رسوم مقعد واحد، ويلغي أي إمكانية للمساءلة. لا تقبله.
• عدم وجود إجراء لمغادرة الموظف: إيقاف الحساب يجب أن يحدث في اليوم نفسه، مع نقل سجلاته لا حذفها.

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

الامتثال وسجل التدقيق في السوق الخليجي

إن كان تطبيقك يتعامل مع بيانات أشخاص في السعودية، فأنت تحت مظلة نظام حماية البيانات الشخصية الذي تشرف عليه الهيئة السعودية للبيانات والذكاء الاصطناعي (سدايا). الإمارات لديها القانون الاتحادي رقم 45 لسنة 2021 بشأن حماية البيانات الشخصية، ولدول الخليج الأخرى أطر مشابهة تتوسع سنويًا.

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

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

قائمة تحقق سريعة قبل النشر:

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

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

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

الأسئلة الشائعة

كم عدد الأدوار المناسب لتطبيق ناشئ في بدايته؟

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

هل أحتاج مطورًا لتعديل الصلاحيات بعد نشر التطبيق؟

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

ما الفرق بين إيقاف حساب الموظف وحذفه؟

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

كيف أمنع مدير فرع من رؤية أرقام الفروع الأخرى؟

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