كيف يتم اختبار صلاحيات المستخدمين؟
اختبار صلاحيات المستخدمين هو عملية منهجية للتحقق من أن كل مستخدم في النظام يستطيع الوصول فقط إلى البيانات والوظائف المسموح له بها حسب دوره، لا أكثر ولا أقل. يشمل ذلك اختبار الأدوار (مثل المدير والموظف والمحاسب)، ومحاولات الوصول غير المصرح بها، ومراجعة صلاحيات الواجهات البرمجية (API). في السوق السعودي يُعد هذا الاختبار ضرورياً لأي نظام يتعامل مع بيانات عملاء أو مالية، خصوصاً مع متطلبات حماية البيانات الشخصية.
ما المقصود باختبار صلاحيات المستخدمين؟
صلاحيات المستخدمين تعني تحديد من يستطيع رؤية أو تعديل أو حذف أي جزء من النظام. في نظام إدارة عيادة مثلاً، يجب أن يرى الطبيب سجلات المرضى الطبية، بينما يرى موظف الاستقبال فقط بيانات الحجز والدفع. اختبار الصلاحيات هو التأكد بشكل عملي من أن هذا التقسيم يعمل فعلاً، وليس فقط مكتوباً في وثيقة التصميم.
كثير من الشركات في الرياض وجدة والدمام تكتشف ثغرات في الصلاحيات بعد إطلاق النظام بفترة، عندما يلاحظ أحد الموظفين أنه يستطيع الوصول إلى شاشة لا تخصه. هذا النوع من الأخطاء يمكن تفاديه بالكامل عبر اختبار منظم قبل التسليم.
لماذا يُعد اختبار الصلاحيات خطوة حرجة؟
الخطأ في الصلاحيات ليس مجرد عيب تقني بسيط، بل قد يؤدي إلى تسريب بيانات عملاء، أو تعديل غير مصرح به في الفواتير، أو حتى مخالفة نظامية. في متجر إلكتروني مثلاً، يجب ألا يستطيع موظف خدمة العملاء رؤية أرقام بطاقات الدفع، وفي نظام موارد بشرية يجب ألا يطّلع موظف عادي على رواتب زملائه.
مع تزايد اعتماد المنشآت السعودية على الأنظمة الرقمية في القطاعات المالية والصحية والتعليمية، أصبح اختبار الصلاحيات جزءاً أساسياً من ضمان الجودة، وليس خطوة اختيارية تُضاف في آخر المشروع.
إهمال اختبار الصلاحيات قد يعني أن أي موظف بحساب عادي يستطيع الوصول إلى تقارير مالية حساسة أو بيانات عملاء أخرى دون أن يلاحظ أحد ذلك لأشهر.
أنواع الصلاحيات الشائعة في الأنظمة الحديثة
معظم الأنظمة الاحترافية اليوم تعتمد أسلوباً يُسمى RBAC، وهو اختصار لـ Role-Based Access Control أي "التحكم بالوصول حسب الدور"، بمعنى أن الصلاحيات تُمنح لدور وظيفي (مثل مدير مبيعات) وليس لكل مستخدم على حدة، مما يسهّل الإدارة والاختبار.
| نوع الدور | أمثلة على الصلاحيات | مثال قطاعي |
|---|---|---|
| مدير النظام | إدارة المستخدمين، إعدادات عامة، تقارير كاملة | صاحب المنشأة أو مدير تقني |
| موظف تشغيلي | إدخال بيانات، عرض محدود، بدون حذف | موظف استقبال في عيادة |
| محاسب | الفواتير والتقارير المالية فقط | قسم المحاسبة في متجر إلكتروني |
| عميل نهائي | بياناته الشخصية وطلباته فقط | مستخدم تطبيق جوال أو موقع |
خطوات اختبار الصلاحيات عملياً
عملية الاختبار الجيدة تمر بمراحل واضحة، سواء كان النظام موقعاً إلكترونياً أو تطبيق جوال أو نظاماً مخصصاً للشركة.
- حصر الأدوار والصلاحيات: إعداد قائمة كاملة بكل دور وما يُسمح له به وما يُمنع عنه، بالتنسيق مع صاحب العمل.
- اختبار الوصول الإيجابي: التأكد من أن كل دور يستطيع فعلاً تنفيذ المهام المسموح له بها دون عوائق.
- اختبار الوصول السلبي: محاولة الوصول إلى شاشات أو بيانات غير مصرح بها لكل دور، والتأكد من رفض النظام لها.
- اختبار الواجهات البرمجية: فحص أن نقاط الاتصال البرمجية API (وهي الطريقة التي يتواصل بها التطبيق مع الخادم) تطبّق نفس قواعد الصلاحيات، لأن كثيراً من الثغرات تحدث هنا وليس في الواجهة المرئية فقط.
- اختبار تغيير الأدوار: التأكد من أن ترقية أو تخفيض دور المستخدم ينعكس فوراً على صلاحياته دون تأخير.
- اختبار القبول من المستخدم: إشراك فريق العميل الفعلي في مرحلة تسمى UAT، أي اختبار قبول المستخدم (User Acceptance Testing)، للتأكد من أن الصلاحيات تطابق واقع العمل اليومي.
يُفضّل توثيق مصفوفة الصلاحيات في جدول واضح قبل بدء البرمجة، فهذا يسرّع الاختبار لاحقاً ويقلل النقاشات بعد التسليم.
أدوات وأساليب الاختبار المستخدمة
يجمع فريق الجودة عادة بين الاختبار اليدوي، حيث يقوم مختبر بتسجيل الدخول بحسابات مختلفة ومحاولة الوصول لكل شاشة، والاختبار الآلي عبر سيناريوهات مبرمجة تُكرَّر تلقائياً عند كل تحديث للنظام. في المشاريع الأكبر مثل أنظمة نقاط البيع أو الأرشفة الإلكترونية، يُضاف أحياناً اختبار اختراق مبسّط لمحاكاة محاولة تجاوز الصلاحيات من مستخدم خبيث.
الأنظمة الجاهزة القابلة للتخصيص، مثل حلول إدارة علاقات العملاء CRM أو أنظمة الموارد البشرية، تأتي غالباً بصلاحيات مُختبرة مسبقاً، لكنها تحتاج إعادة اختبار عند أي تخصيص إضافي يناسب طبيعة عمل المنشأة.
الصلاحيات وعلاقتها بحماية البيانات الشخصية
في السعودية، تخضع المنشآت التي تجمع بيانات العملاء لأحكام نظام حماية البيانات الشخصية الذي تشرف عليه الهيئة السعودية للبيانات والذكاء الاصطناعي SDAIA والمعروف اختصاراً بـ PDPL. جزء أساسي من الالتزام بهذا النظام هو التأكد من أن الوصول إلى البيانات الشخصية مقصور على من يحتاجها فعلاً لأداء عمله، وهذا ما يجعل اختبار الصلاحيات ليس فقط ممارسة جودة، بل ركيزة امتثال نظامي أيضاً.
الأنظمة المرتبطة بالفوترة الإلكترونية والمتاجر يجب أيضاً أن تراعي متطلبات هيئة الزكاة والضريبة والجمارك ZATCA فيما يخص من يحق له إصدار أو تعديل الفواتير الضريبية، وهو ما يُختبر ضمن سيناريوهات الصلاحيات الخاصة بالمحاسبين.
الالتزام بالتشفير الجيد للصلاحيات لا يغني عن المراجعة الدورية؛ يُنصح بإعادة اختبار الصلاحيات كل مرة يُضاف فيها دور جديد أو ميزة جديدة للنظام.
كيف تضمن جودة الصلاحيات في مشروعك؟
عند التعاقد مع مزود خدمة لبناء نظام مخصص، من الأفضل أن تسأل صراحة عن منهجية اختبار الصلاحيات المتّبعة، وأن تطلب نسخة من مصفوفة الأدوار قبل الإطلاق النهائي. فريق برمجة الأنظمة المخصصة الجيد يخصص مرحلة كاملة لهذا النوع من الاختبار ضمن دورة تطوير المشروع، سواء كان النظام موقعاً أو تطبيق جوال أو منصة تجارة إلكترونية.
بعد الإطلاق، تستمر أهمية المراقبة عبر خدمات الدعم الفني التي تتابع أي تنبيهات مرتبطة بمحاولات وصول غير معتادة، خصوصاً في الأنظمة المستضافة على بيئات استضافة مخصصة تحتاج مراقبة أمنية مستمرة.
- اختبار الصلاحيات يتحقق من أن كل مستخدم يصل فقط لما يخصه من بيانات ووظائف.
- أسلوب RBAC (التحكم بالوصول حسب الدور) هو الأكثر شيوعاً في الأنظمة الحديثة.
- الاختبار يشمل الوصول الإيجابي والسلبي والواجهات البرمجية API وليس الشاشة فقط.
- إشراك فريق العميل عبر اختبار قبول المستخدم UAT يضمن مطابقة الصلاحيات لواقع العمل.
- الصلاحيات مرتبطة مباشرة بالامتثال لنظام حماية البيانات الشخصية PDPL ومتطلبات الفوترة الإلكترونية.
أسئلة شائعة
اختبار الصلاحيات جزء من الاختبار الأمني الأوسع، لكنه يركّز تحديداً على تحديد من يستطيع فعل ماذا داخل النظام، بينما يشمل الاختبار الأمني العام أيضاً حماية البيانات من الاختراق الخارجي والتشفير وغيرها من الجوانب.
نعم، حتى لو كان النظام يخدم دورين فقط مثل المدير والموظف، فإن اختبار الصلاحيات بشكل بسيط يمنع مفاجآت لاحقة، ويُفضّل تضمينه منذ مرحلة تصميم النموذج الأولي MVP، وهو اختصار Minimum Viable Product أي النسخة الأولى القابلة للاستخدام من المنتج.
يعتمد على عدد الأدوار وتعقيد الشاشات، لكنه عادة يُدمج ضمن دورة الاختبار العامة للمشروع، ويُضاف له وقت إضافي بسيط عند وجود أدوار متعددة مثل الأنظمة التي تخدم فروعاً متعددة في مدن مختلفة كالرياض وجدة والدمام.
غالباً نعم من حيث الصلاحيات الأساسية، لكن عند إضافة أدوار مخصصة لطبيعة عملك، يجب إعادة اختبارها، وهذا ينطبق على منتجات مثل نقاط البيع والمواعيد والأرشفة الإلكترونية.
إذا كنت تخطط لبناء نظام جديد أو تشك في وجود ثغرات صلاحيات في نظامك الحالي، يسعد فريق بوابة الحلول التقنية بمراجعة الوضع معك وتقديم خطة اختبار واضحة. اطلب عرض سعر أو استشارة مجانية الآن لنبدأ بتقييم صلاحيات نظامك.