أدلة

صلاحيات تصمد حين يحاول أحدهم فتح الباب

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

فريق Rocket ERP

Rocket ERPمدة القراءة: 3 دقيقة

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

الواجهة للتيسير، والخادم هو الضابط

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

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

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

ثلاثة أسئلة لا سؤال واحد

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

  • ماذا يحق لهذا الشخص أن يفعل؟ أن يُنشئ فاتورة، أو يعتمد أمر شراء، أو يشغّل الرواتب.

  • وأي السجلات يحق له أن يرى؟ سجلات فرعه، أو فريقه، أو عملائه هو. هذا هو تحديد النطاق، وهو الجزء الذي يغيب أكثر من غيره.

  • وأي الحقول يحق له أن يعدّل؟ قد يعدّل مندوب المبيعات الكمية دون السعر، وقد يرى أمين المستودع التكلفة أو لا يراها.

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

النطاق واحد في كل اتجاه

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

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

أدوار للحالات المعتادة، واستثناءات موثّقة

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

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

ما الذي تراجعه الآن

  1. استخرج قائمة بالمستخدمين القادرين على ترحيل القيود، أو حذف المستندات، أو تغيير الأسعار. ثم قارنها بمن ينبغي أن يملك هذه الصلاحيات.

  2. اختر مستخدماً مقيَّداً، وجرّب إجراءً ممنوعاً عليه من تطبيق الهاتف بدلاً من واجهة الويب. فإما أن تخضع التطبيقات وواجهة API لضوابط الخادم نفسها، وإما لا.

  3. صدّر تقريراً مقيّداً بالنطاق بصفتك مستخدماً مقيَّداً، ثم عُدّ الأسطر.