أتفق مع الآخرين هنا أن نموذج التحكم في الوصول سيتحسن بإضافة طبقة إضافية من تفصيل التحكم في الوصول القائم على الأدوار (RBAC) تحدد ما يمكن لـ staff وadmin الوصول إليه (لوظائف معينة، وليس جميعها).
على سبيل المثال، قد يرغب موقع ما في إضافة المزيد من المدراء؛ لكنهم يفضلون منح مجموعة أصغر من امتيازات RBAC للمدراء؛ مثل منح أو عدم منح القدرة على تنزيل نسخة احتياطية كاملة للموقع أو الوصول إلى ملفات سجل إجراءات معينة للموظفين. بالإضافة إلى ذلك، قد يرغب الموقع في التأكد من أن بعض الموظفين ليس لديهم أذونات RBAC لعرض إجراءات المدراء أو المطورين، أو فقط إجراءات معينة تعتبر أكثر “خصوصية”.
يتم تعليم جميع خبراء الأمن السيبراني (ويعرفون من خلال الخبرة المباشرة) أن أكبر تهديد لأي منظمة هو “الموظف غير الراضي” وليس المتسللين أو المهاجمين الخارجيين. لا شك في هذا الخطر الأساسي لأمن تكنولوجيا المعلومات، وهو معرفة راسخة للمحترفين المدربين أو ذوي الخبرة في مجال أمن تكنولوجيا المعلومات. لذلك، فإن تجاهل تهديد الداخل بـ “ثق فقط في مدير الموقع” أو “يجب أن تثق بموظفيك” ليس حلاً تقنيًا للمحترفين في مجال تكنولوجيا المعلومات. حتى أكثر الموظفين موثوقية، المخلصين لسنوات عديدة، قد يبدأون في مواجهة مشاكل حياتية قد تجعلهم يتحولون إلى “موظف غير راضٍ”. بالإضافة إلى ذلك، فإن الموظفين الأكثر امتيازًا هم من يرتكبون معظم الأخطاء؛ ونحن جميعًا نعلم أن أخطاء الموظفين/المدراء ذات النوايا الحسنة عادة ما تسبب توقفًا عن العمل أكثر من أي متسلل، بشكل عام.
منذ فترة، فكرت في تعديل class Guardian في Discourse لموقعنا، ولكن بعد فحص أعمق لتلك الفئة، لم يكن واضحًا بالنسبة لي وجود “حل سريع” يسمح لي بكتابة كمية قليلة من كود التصحيح (monkey patch) لتعزيز RBAC في Discourse. وبما أنني كسول بطبعي وأفضل إنشاء حلول بسيطة كلما أمكن، فقد وضعت الفكرة جانبًا وانتقلت إلى مشاريع أخرى “مدفوعة الأجر جيدًا”.
بعد ذلك، فكرت في النزول مستوىً آخر في الكود ونقل بعض وظائف staff وadmin إلى ```developer``، لكن هذا النهج تطلب عددًا كبيرًا من التصحيحات (monkey patches)، وهو ما اعتقدت أنه ليس فكرة جيدة في ذلك الوقت. بعد كل شيء، إذا كان بإمكاننا تحقيق شيء ما بتصحيح واحد مقابل عشرة، فمن الواضح أن التصحيح الواحد أفضل.
لم أجد بعد الوقت أو “الضرورة الملحة” للنظر بعمق في هذا الجزء من نواة Discourse لتحديد ما إذا كان هناك تحسين RBAC “سهل” يمكنني كتابته عبر ملحق “نسبيًا بسيط”.
بصراحة، أعتقد أن المشكلة هي أنني لست بعد خبيرًا في Ruby، ومعظم الوقت أعتبر نفسي مجرد “طامح” لكتابة كود Ruby، LOL. أنا واثق من أنه، على الأرجح، يوجد حل بسيط لملحق RBAC، لكن شخصيًا، لم أجد بعد، وربما يمكن لشخص Ruby أكثر خبرة بكثير النظر في الكود بسرعة ورؤية كيفية التعامل مع هذا الأمر.
فكرتي هي وجود بعض إعدادات الموقع الجديدة من نوع boolean التي إما أن تحد أو تمنح أذونات RBAC محددة بناءً على الدور، ثم إضافة هذه القيم boolean إلى الجزء المناسب من الكود عبر تصحيح (monkey patch) في الملحق. ومع ذلك، وكما ذكرت، أفضل تصحيح ملف واحد، وليس “العديد”، ليكون الأمر نظيفًا وبسيطًا وسهل الصيانة.
عندما أجد الوقت، سأبحث في هذا التحسين RBAC بشكل أعمق لأنه مثير للاهتمام بالتأكيد.