إنشاء مستخدم قاعدة بيانات محدود لووردبريس واختبار عزله

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

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

ما الصلاحيات التي منحناها في الاختبار؟

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

GRANT SELECT, INSERT, UPDATE, DELETE,
CREATE, DROP, INDEX, ALTER
ON your_wordpress_database.*
TO 'your_wordpress_user'@'127.0.0.1';

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

أخطاء شائعة

• منح صلاحيات بيانات أو إدارة واسعة على *.* بدل قاعدة الموقع فقط؛ أما USAGE وحدها فلا تمنح هذه الصلاحيات.
• كتابة كلمة المرور داخل لقطة شاشة أو أمر منشور.
• سحب ALTER وCREATE قبل تحديث رئيسي ثم استغراب فشل الترقية.
• استخدام المستخدم نفسه لكل مواقع الحساب مع توفر إمكانية الفصل.

خطوات التنفيذ والتحقق

1. أنشئ قاعدة ومستخدما باسمين مختلفين، واستخدم كلمة مرور مولدة لا تظهر في اسم الموقع.
2. امنح الصلاحيات على database_name.* فقط، ثم استخدم SHOW GRANTS لعرض الصلاحيات وتأكد أن اسم قاعدة موقعك هو النطاق المسموح، وليس كل القواعد.
3. اتصل بالمستخدم الجديد ونفذ SELECT بسيطا على قاعدة ووردبريس.
4. اختبر عملية كتابة داخل بيئة التجربة أو دع ووردبريس ينشئ جدول تحديث تجريبيا.
5. في بيئة تملكها أو لديك إذن لاختبارها، حاول فتح قاعدة اختبار أخرى لم تمنح المستخدم صلاحية لها. نجاح المحاولة هنا يعني أن العزل غير صحيح.
6. ضع بيانات الحساب في wp-config عبر قناة آمنة، ثم احذفها من سجل الأوامر أو لقطة الدعم.

ماذا عن التحديثات؟

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

تفاصيل التجربة ونتيجتها

تاريخ التجربة: 18 أغسطس 2026؛ ووردبريس: نسخة استعادة مع 19 جدولا؛ مكان التنفيذ وأدواته: MySQL محلي على 3308.

تمكن المستخدم المحدود من قراءة قاعدة gzkhabar_restore_test، وأعاد الخادم الخطأ 1044 عندما حاول المستخدم نفسه فتح قاعدة gzkhabar_local الخاصة بالمشروع الجديد.

تحقق إضافي، 19 أغسطس 2026: قرأنا schema_privileges للمستخدم التجريبي وقارنّا منح قاعدة الاستعادة بقاعدة المشروع. عد الصلاحيات الممنوحة ليس اختبار اتصال مكافئا لكل عملية. اختبر الوصول المسموح ورفض الوصول إلى القاعدة الأخرى بحساب مخصص، دون كشف بيانات الدخول.

SELECT CURRENT_USER();
SHOW GRANTS;

GRANT USAGE ON *.* TO `gz_fixture_20260921`@`127.0.0.1`
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER
ON `gz_grants_allowed_20260921`.*
TO `gz_fixture_20260921`@`127.0.0.1`

runAt: 2026-09-21T11:29:06+00:00
engine: MySQL 8.4.3; client: PHP 8.3.30 / mysqli
same limited connection: true
CREATE: pass; INSERT: pass; SELECT: pass; UPDATE: pass
ALTER: pass; INDEX: pass; DELETE: pass; DROP: pass
select other database: denied (1044 / SQLSTATE 42000)
qualified read from other database: denied (1142 / SQLSTATE 42000)

المصادر الرسمية

• WordPress: تقوية الموقع وصلاحيات قاعدة البيانات.
• WordPress: إنشاء قاعدة ومستخدم خاصين بالموقع.