حساب Administrator هو نقطة عالية الحساسية في أي موقع WordPress. والهدف من هذا الدليل ليس الاعتماد على إجراء واحد، بل بناء طبقات متتابعة: حماية بيانات الدخول، إضافة عامل تحقق مستقل، تقليل الصلاحيات المستخدمة يومياً، والمحافظة على البرمجيات وبيئة الاستضافة محدثة. ما يلي يجمع إرشادات WordPress وCISA وNIST، مع تمييز الاقتراحات التحريرية عن الحقائق الموثقة.
1. ابدأ بهوية دخول يصعب تخمينها
استخدم كلمة مرور طويلة وفريدة لحساب المدير. توصي إرشادات WordPress باستخدام كلمات مرور قوية وتجنب أسماء المستخدمين المتوقعة مثل admin، كما تذكر أن مدير كلمات المرور يمكنه إنشاء كلمات مرور مناسبة وحفظها بدلاً من إعادة استخدام كلمة قديمة. المصدر: إرشادات WordPress لأفضل ممارسات كلمات المرور
عملياً، اجعل كلمة مرور هذا الحساب مختلفة عن كلمات مرور البريد الإلكتروني والاستضافة وخدمات العمل. هذه توصية تصميمية في هذا الدليل، وليست ادعاءً بأن تغيير الاسم أو كلمة المرور وحده يحل جميع مخاطر الحساب. إذا كان الموقع يستخدم بالفعل اسم مستخدم سهل التخمين، فضع خطة انتقال آمنة بدلاً من حذف الحساب عشوائياً: أنشئ حساباً إدارياً بديلاً، اختبره، ثم راجع الحساب القديم وفق إجراءات الاستعادة المتاحة لديك.
لا تحفظ كلمة المرور في ملف نصي غير محمي أو في رسالة بريد. هذا اقتراح تحريري لتقليل مخاطر التعرض العرضي؛ أما النقطة الموثقة فهي أن إرشادات WordPress تصف كلمات المرور المنشأة بأنها طويلة ومعقدة ومناسبة للاستخدام بدلاً من كلمات المرور المعاد استخدامها. المصدر: إرشادات WordPress لأفضل ممارسات كلمات المرور
2. أضف المصادقة متعددة العوامل
توصي WordPress بتفعيل المصادقة الثنائية من خلال إضافة من طرف ثالث. المصدر: إرشادات WordPress لأفضل ممارسات كلمات المرور ويقترح هذا الدليل اختيار إضافة maintained ومدعومة ومتوافقة مع إصدار موقعك، ثم فحص حالة دعمها وتوافقها قبل النشر؛ هذه توصية عملية، وليست شهادة بأن إضافة بعينها آمنة أو مناسبة لكل موقع.
عند توفرها، أعطِ الأولوية لمفاتيح الأمان أو مفاتيح المرور (passkeys) التي تستخدم FIDO/WebAuthn. تصف CISA تقنية FIDO/WebAuthn بأنها وسيلة مصادقة مقاومة للتصيد ومتاحة على نطاق واسع، وتوصي بوسائل MFA الأقوى على البدائل الأضعف. المصدر: ورقة CISA حول MFA المقاوم للتصيد
يوضح NIST أن رموز OTP التي يكتبها المستخدم يدوياً ليست مقاومة للتصيد، بينما توفر WebAuthn مقاومة للتصيد من خلال الارتباط باسم الجهة الموثِّقة (verifier-name binding). المصدر: NIST SP 800-63B-4 لذلك يمكن استخدام تطبيق رموز المصادقة كخيار بديل عملي إذا لم تتوفر مفاتيح FIDO/WebAuthn، أما SMS فتعامل معه كخيار أخير في تصميم هذا الدليل، لا كخيار مساوٍ للمصادقة المقاومة للتصيد. احتفظ برمز الاستعادة بطريقة آمنة، واختبر مسار الاستعادة قبل الحاجة إليه؛ وهذه نقطة اختبار تشغيلية وليست ضماناً لاستعادة الحساب.
3. افصل العمل اليومي عن الصلاحية القصوى
يستطيع دور Administrator الوصول إلى جميع ميزات الإدارة لموقع واحد، بينما يمتلك دور Editor مجموعة أضيق من القدرات. المصدر: توثيق WordPress للأدوار والقدرات وبناءً على ذلك، يوصي هذا الدليل باستخدام Administrator عند الحاجة فقط، وإسناد النشر والتحرير اليومي إلى Editor أو دور أقل صلاحية عندما تكون قدراته كافية. هذا تقليل مقترح لنطاق الضرر المحتمل، وليس دليلاً على نتيجة أمنية مضمونة.
أنشئ لكل شخص حساباً مناسباً لدوره بدلاً من مشاركة حساب المدير. افحص القدرات المطلوبة فعلاً: قد يحتاج المحرر إلى إنشاء المحتوى ومراجعته، لكنه قد لا يحتاج إلى تغيير إعدادات الموقع أو إدارة الإضافات. هذه طريقة تصميمية للمراجعة وليست قائمة شاملة بقدرات كل دور. راجع أيضاً الحسابات القديمة والمتعاونين الذين لم يعودوا يعملون على الموقع، وفق سياسة وصول مؤسستك.
4. حدّث المكونات وخذ نسخة قبل التحديثات الكبيرة
توصي WordPress بالحفاظ على البرنامج الأساسي محدثاً، وتذكر أن التحديثات الصغيرة والأمنية يمكن تطبيقها تلقائياً عادةً، كما توصي بأخذ نسخ احتياطية قبل التحديث. المصدر: Hardening WordPress وطبّق هذه المراجعة على نواة WordPress والإضافات والقوالب وPHP وبيئة الاستضافة، مع التحقق من أن الإصدارات ما زالت مدعومة؛ وهذه النطاقات واردة في متطلبات هذا الدليل، بينما لا يحدد المصدر هنا جدول دعم أو رقم إصدار بعينه.
قبل تحديث رئيسي، تحقّق من وجود نسخة احتياطية قابلة للاستعادة، لا مجرد ملف لم تختبره. هذه توصية تحريرية عملية. سجّل وقت النسخة، ومكانها، وطريقة الاستعادة، ومن يملك صلاحية تنفيذها. جرّب التحديث على نسخة اختبار إن كانت متاحة لديك، ثم راقب تسجيل الدخول والنماذج والوظائف الأساسية. لا تحوّل هذه الخطوات إلى ادعاء بأنها تمنع التعطل؛ إنها عناصر اختبار واستعداد.
5. احمِ قناة الإدارة واختبر طبقة الخادم
يحمي HTTPS الاتصالات الإدارية، ويمكن للحماية على مستوى الخادم حول المسار /wp-admin/ أن تضيف طبقة ثانية، لكن WordPress تحذر من أن هذه الحماية قد تتداخل مع وظائف مثل admin-ajax.php. المصدر: Hardening WordPress لذلك اجعل الوصول الإداري عبر HTTPS، وإذا أضفت تقييداً على مستوى الخادم فاختبر تسجيل الدخول، وحفظ المقالات، ورفع الملفات، وأي إضافة تعتمد على طلبات AJAX قبل اعتماده.
هذه ليست دعوة إلى تطبيق قاعدة خادم جاهزة دون مراجعة. اعتبر احتمال تعارض admin-ajax.php خطر تصميم يجب اختباره، وحدد طريقة رجوع سريعة إذا أدت القاعدة إلى فقدان وظيفة إدارية. لا يثبت هذا الدليل أن تقييد المسار مناسب لكل استضافة أو شبكة؛ القرار يعتمد على بيئتك واختباراتك.
قائمة تنفيذ مختصرة
- أنشئ كلمة مرور طويلة وفريدة باستخدام مدير كلمات مرور، ولا تعِد استخدامها.
- استبدل اسم المستخدم المتوقع مثل
adminبخطة انتقال مختبرة. - فعّل إضافة مصادقة ثنائية مناسبة، وافحص توافقها ودعمها قبل النشر.
- فضّل passkeys أو مفاتيح FIDO/WebAuthn عندما يدعمها موقعك.
- استخدم تطبيق رموز المصادقة كبديل عند عدم توفر الخيار الأقوى، وتعامل مع SMS كخيار أخير.
- خصص Administrator للمهام التي تحتاجه، واستخدم Editor للعمل التحريري اليومي عندما يكفي.
- حدّث WordPress والإضافات والقوالب وPHP وبيئة الاستضافة ضمن إصدارات مدعومة.
- خذ نسخة احتياطية قبل التحديثات الرئيسية وسجّل طريقة استعادتها.
- تأكد من استخدام HTTPS للإدارة.
- اختبر أي حماية خادمية لمسار
/wp-admin/، خصوصاً الوظائف التي تعتمد علىadmin-ajax.php.
الخلاصة
الترتيب المقترح هنا هو: ابدأ بحساب فريد ومحمي، أضف MFA مع تفضيل FIDO/WebAuthn، قلل استخدام Administrator، ثم حافظ على التحديثات والنسخ القابلة للاستعادة واختبر أي طبقة خادم إضافية. هذه بنية عمل عملية وليست ضماناً أمنياً أو بديلاً عن مراجعة إعدادات موقعك وإضافاته وبيئة استضافته.