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