احمِ بيانات شركتك بالصلاحيات الصحيحة: دليل Roles وPermissions في ‎.NET

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

سؤالان مختلفان: من أنت؟ وماذا يحق لك أن تفعل؟

المصادقة (Authentication) تتحقق من الهوية: يثبت المستخدم من هو بكلمة مرور أو مفتاح مرور أو رمز لمرة واحدة أو تسجيل دخول عبر حساب الشركة. أما التفويض (Authorization) فيحدد ما يحق لهذا المستخدم الوصول إليه أو تعديله. قد يمتلك النظام تسجيل دخول ممتازًا ومع ذلك تتسرب بياناته إذا كان التفويض ضعيفًا. ويكفي أن تعرف أن "خلل التحكم في الوصول" يتصدر قائمة OWASP Top 10 لأخطر مخاطر تطبيقات الويب.

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

المستخدمون والأدوار والصلاحيات

• المستخدم (User): شخص حقيقي واحد له حسابه الخاص. لا تشارك الحسابات أبدًا؛ فبدون مستخدمين منفصلين لا توجد مساءلة.
• الصلاحية (Permission): إجراء محدد على نوع محدد من البيانات، مثل "عرض الفواتير" أو "اعتماد المرتجعات" أو "تصدير العملاء".
• الدور (Role): مجموعة صلاحيات تحمل اسمًا يطابق وظيفة، مثل كاشير أو مدير فرع أو محاسب. المستخدم يحصل على أدوار، والأدوار تحصل على صلاحيات.

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

أقل صلاحية ممكنة كقاعدة افتراضية

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

هيكل أدوار عملي

كل شركة مختلفة، لكن معظم الأنظمة تبدأ من هيكل قريب من التالي ثم تطوّره:

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

متى لا تكفي الأدوار وحدها؟

نطاق الإدارة أو الفرع

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

الصلاحية على مستوى السجل

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

الاعتمادات وفصل المهام

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

الحقول الحساسة والتصدير

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

التطبيق الفعلي: أين يحدث الأمان حقًا؟

إخفاء الزر ليس حماية

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

واجهات API تحتاج القواعد نفسها

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

تطبيق الصلاحيات في ‎.NET

يوفر ASP.NET Core إطار تفويض ناضجًا يدعم أكثر من أسلوب:

• الفحص بالأدوار: مثل قصر نقطة معينة على دور المدير. أسلوب بسيط، لكن توزيع أسماء الأدوار في الكود يجعل التعديل لاحقًا مرهقًا.
• التفويض بالسياسات (Policy-based): سياسات مسماة تعتمد على متطلبات ومعالِجات. يسأل الكود: "هل يحقق المستخدم سياسة Invoices.Approve؟" والسياسة هي التي تقرر كيف.
• التفويض على مستوى المورد عبر IAuthorizationService، الذي يقيّم سياسة مقابل سجل محدد، مثل "من الفرع نفسه" أو "صاحب هذا العميل المحتمل".

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

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("Invoices.Approve", policy =>
        policy.RequireClaim("permission", "invoices.approve"));
});

app.MapPost("/invoices/{id}/approve", ApproveInvoice)
   .RequireAuthorization("Invoices.Approve");

هنا تُحمَّل صلاحيات المستخدم من أدواره وتُصدر كـ Claims عند تسجيل الدخول أو تُحسب مع كل طلب، ويُفحص شرط مستوى السجل (الفرع نفسه، وليس طلبك الشخصي) داخل المعالِج باستخدام IAuthorizationService. وعندما تحتاج الشركة دورًا جديدًا، يجمع مدير النظام صلاحيات موجودة من شاشة الإدارة دون أي تعديل في الكود. ويمكن أن تأتي الهوية من ASP.NET Core Identity في الأنظمة المستقلة أو من مزود هوية مؤسسي مثل Microsoft Entra ID، بينما يبقى تصميم التفويض كما هو.

قرارات معمارية تتحمل النمو

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

السجلات الرقابية ودورة حياة الصلاحيات

ماذا تسجّل؟

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

التعيين والنقل وانتهاء الخدمة

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

مثال: شركة توزيع

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

أخطاء شائعة

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

صمّم الصلاحيات قبل البرمجة

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

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

كم دورًا نحتاج؟

أقل عدد يعكس وظائف مختلفة فعلًا. وإذا كان عدد الأدوار يقترب من عدد المستخدمين، فالصلاحيات غالبًا تُمنح لكل شخص على حدة بدلًا من الوظيفة.

هل يستطيع مدير النظام إنشاء أدوار جديدة دون مبرمج؟

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

هل تكفي المصادقة متعددة العوامل لحماية بياناتنا؟

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

هل يمكن إضافة الصلاحيات إلى نظام موجود؟

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

هل يجب أن يملك صاحب الشركة صلاحيات كاملة؟

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

الخلاصة

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

خطط لنظام صلاحيات يناسب شركتك

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