استخدام root داخل wp-config يجعل الموقع يملك صلاحيات أوسع من حاجته. أنشأنا مستخدم MySQL خاصًا بنسخة الاستعادة، ومنحناه صلاحيات على قاعدة واحدة فقط، ثم اختبرنا الوصول المسموح والمرفوض بدل الاكتفاء بقراءة أمر GRANT.
الصلاحيات المستخدمة في التجربة
GRANT SELECT, INSERT, UPDATE, DELETE,
CREATE, DROP, INDEX, ALTER
ON your_wordpress_database.*
TO 'your_wordpress_user'@'127.0.0.1';استبدل الأسماء والقيمة السرية ولا تنسخ بيانات تجربتنا. الصلاحيات الأربع الأولى تكفي للعمليات اليومية عادة. أضفنا صلاحيات بنيوية لأن التثبيت والتحديثات وبعض الإضافات قد تنشئ جداول أو تعدلها. يمكن تشديدها لاحقًا إذا كانت لديك خطة نسخ واستعادة واختبار للتحديثات.
أخطاء شائعة
- منح الصلاحيات على
*.*بدل قاعدة الموقع فقط. - كتابة كلمة المرور داخل لقطة شاشة أو أمر منشور.
- سحب ALTER وCREATE قبل تحديث رئيسي ثم استغراب فشل الترقية.
- استخدام المستخدم نفسه لكل مواقع الحساب مع توفر إمكانية الفصل.
خطوات التنفيذ والتحقق
- أنشئ قاعدة ومستخدمًا باسمين مختلفين، واستخدم كلمة مرور مولدة لا تظهر في اسم الموقع.
- امنح الصلاحيات على
database_name.*فقط، ثم اعرض SHOW GRANTS واقرأ النطاق حرفيًا. - اتصل بالمستخدم الجديد ونفذ SELECT بسيطًا على قاعدة ووردبريس.
- اختبر عملية كتابة داخل بيئة التجربة أو دع ووردبريس ينشئ جدول تحديث تجريبيًا.
- حاول فتح قاعدة أخرى لا تخص المستخدم. نجاح المحاولة هنا يعني أن العزل غير صحيح.
- ضع بيانات الحساب في wp-config عبر قناة آمنة، ثم احذفها من سجل الأوامر أو لقطة الدعم.
ماذا عن التحديثات؟
التقوية ليست قرارًا ثابتًا لكل الاستضافات. إذا سمحت بأربع صلاحيات قراءة وكتابة فقط فقد يعمل النشر اليومي، بينما يفشل تحديث يحتاج ALTER أو CREATE. لذلك افصل بين حساب تشغيل شديد التقييد وحساب صيانة مؤقت إن كانت خبرتك والاستضافة تسمحان، أو استخدم مجموعة الصلاحيات التي توصي بها الاستضافة مع نسخ احتياطي مجرب. الأهم ألا يكون مستخدم الموقع مديرًا لكل قواعد الخادم.