أمان Drupal واحد من المجالات القليلة في عالم أنظمة إدارة المحتوى مفتوحة المصدر التي تكون فيها العملية المنشورة أفضل من سمعة المنصة. يعمل فريق أمان Drupal وفق جدول إفصاح ثابت، ويمنح كل تنبيه درجة على مقياس رقمي موثق، وينسق الإصلاحات عبر النواة وعشرات الآلاف من المشاريع المساهَم بها.
السجل في الواقع أسوأ مما تستحقه تلك العملية. مواقع Drupal تتعرض للاختراق فعلاً، والسبب لا يكون تقريباً أن أحداً لم يعلم. فقد نُشر التنبيه في موعده، يوم أربعاء. ووصل الترقيع إلى بيئة الإنتاج في الأسبوع التالي. تلك الفجوة هي موضوع هذا المقال، والتحصين وجدران الحماية وصلاحيات الملفات كلها موجودة لجعلها قابلة للنجاة منها أو لتقصيرها.
مخاطرك تحددها سرعة الترقيع لديك، لا الوحدات التي تصادف أنك تشغلها. تنبيهات النواة تصل في نافذة شهرية يوم الأربعاء، وتنبيهات المشاريع المساهَم بها كل أربعاء، ولكل منها درجة من 0 إلى 25 على مقياس منشور. ثغرات النواة البالغة الخطورة استُغلت خلال ساعات من الإفصاح: بعد تنبيه حقن SQL لعام 2014 كانت التوجيهات الرسمية هي اعتبار أي موقع لم يُرقَّع خلال سبع ساعات مخترقاً بالفعل. الموقع الذي لا يستطيع نشر ترقيع للنواة خلال يوم عمل واحد يحمل تقريباً كل المخاطر الموجودة.
كيف تعمل عملية تنبيهات أمان Drupal فعلياً
معظم من يديرون موقع Drupal لم يقرأوا وثائق العملية قط، وهذا مؤسف: فهي تخبرك بالضبط بحجم الإنذار الذي تحصل عليه، وبأي شكل، وفي أي أيام.
نوافذ الإصدار
ينشر فريق الأمان وفق تقويم. تنبيهات المشاريع المساهَم بها تخرج كل أربعاء. وللنواة نافذة لإصلاح العلل وإضافة الميزات في أول أربعاء من الشهر، ونافذة إصدار أمني في الأربعاء الثالث، كما توضح وثيقة توقيت الإصدارات الأمنية. النافذة ليست وعداً بصدور شيء؛ وجودها كي يعرف المسؤولون أي الأيام يراقبون.
أحياناً يوجد إنذار مسبق. قبل إصدار نواة بالغ الخطورة قد ينشر الفريق إعلان خدمة عامة، عادة يوم الاثنين. وقد فعل PSA-2026-05-18 ذلك تماماً قبل إصدار 20 مايو 2026، فحدد نافذة من 17:00 إلى 21:00 بالتوقيت العالمي، وطلب من أصحاب المواقع الترقية أولاً إلى أحدث إصدار ترقيعي على فرعهم كي تظهر مشكلات الترقية مبكراً. يومان هما أقصى إنذار ستحصل عليه.
تنبيهات النواة وتنبيهات المشاريع المساهَم بها
هذان نظامان بضمانات مختلفة. تنبيهات النواة تغطي الفروع الفرعية المدعومة، اثنين في الوقت نفسه، الأحدث والذي يسبقه. وعملياً يعني جدول إصدارات النواة الفرعين 11.4.x و11.3.x، مع بقاء 10.6.x مغطى ما دام Drupal 10 مستمراً حتى نهاية عمره في 9 ديسمبر 2026. ومع مطلع سبتمبر 2026 فإن الإصدارات الحالية هي 11.4.5 و11.3.16 و10.6.15. ومن المقرر صدور Drupal 12.0.0 و11.5.0 في أسبوع 7 ديسمبر 2026، وعندها ينتهي دعم 11.3.x و10.6.x.
تغطية المشاريع المساهَم بها اختيارية ومشروطة. فالتنبيهات لا تصدر إلا للإصدارات المستقرة في الفروع الرئيسية المدعومة للمشاريع التي تقدم مشرفوها بطلب التغطية وحصلوا عليها، بموجب سياسة عملية التنبيهات الأمنية والصلاحيات. والوحدة التي تقف عند إصدار ألفا أو بيتا أو مرشح للإصدار تقع خارج النظام، وكذلك الوحدة التي لم يسجل مشرفها فيه قط. وأي من هاتين الحقيقتين لا يظهر في واجهة الإدارة ما دام الموقع يعمل بشكل طبيعي.
الحجم هو عبء العمل الحقيقي. ففي الأربعاء 26 أغسطس 2026 نشر الفريق عشرة تنبيهات لمشاريع مساهَم بها في يوم واحد، جميعها متوسطة الخطورة. والموقع الذي يشغل ستين وحدة سيُذكر عدة مرات في السنة، وهذا التدفق يكلف مع الوقت أكثر من حالات الطوارئ في النواة.
درجة الخطورة، ولماذا ليست CVSS
كل تنبيه يحمل رقماً من 25. والمقياس مبني على نظام NIST Common Misuse Scoring System، أي NISTIR 7864، وهو موثق في صفحة مستويات المخاطر الأمنية. ستة مقاييس تغذيه: تعقيد الوصول، والمصادقة المطلوبة، وأثر السرية، وأثر السلامة، ووجود استغلال معروف من عدمه، ومدى انتشار الأهداف. وتمتد النطاقات من غير خطير عند 0 إلى 4، وقليل الخطورة عند 5 إلى 9، ومتوسط الخطورة عند 10 إلى 14، وخطير عند 15 إلى 19، وبالغ الخطورة عند 20 إلى 25.
ولأن انتشار الأهداف جزء من الدرجة، فإن الثغرة التي لا تعض إلا في إعداد غير شائع تحصل على درجة أدنى مما كانت ستحصل عليه بمقياس CVSS. فتنبيه SA-CORE-2026-005 الصادر في 17 يونيو 2026، وهو مشكلة حقن كائنات PHP مُتتبعة برقم CVE-2026-55803، حصل على 18 وصُنف خطيراً لا بالغ الخطورة لهذا السبب بالضبط.
عندما يصبح مشروع مساهَم به غير مدعوم
لا يستطيع فريق الأمان إجبار مشرف متطوع على إصلاح أي شيء. وعندما يتوقف المشرف عن الرد، تقضي الإجراءات الموثقة بوسم المشروع بأنه غير مدعوم بعد محاولات اتصال متكررة. وعندئذ تحذر صفحة المشروع أصحاب المواقع من اختيار بديل تجري صيانته بنشاط، أو دفع أجر لشخص يصلح العلة كي يعاد نشر الوحدة.
تلك النصيحة صحيحة ومكلفة، لأن الوحدة حين تُوسم بأنها غير مدعومة تكون عادة حاملة للبنية، واستبدالها يعني ترحيل بيانات وتغييرات في القوالب واختبار انحدار كاملاً. واللحظة الرخيصة للتصرف هي الإصدار السابق للهجر، حين يكون المشرف قد صمت ولم يتعطل شيء بعد، وفي تلك اللحظة لا ينظر أحد تقريباً.
Drupal 7 انتهى عمره الافتراضي، والدعم الممتد ليس مثل الأمان
بلغ Drupal 7 نهاية عمره في 5 يناير 2025، وهو ما أكده PSA-2025-01-06. وبعد ذلك التاريخ توقف فريق الأمان عن تقديم الدعم والتنبيهات لنواة Drupal 7 ولوحداته وقوالبه المساهَم بها. وكان الإعلان صريحاً في أن مشكلات أمان Drupal 7 قد يُفصح عنها علناً الآن دون تنسيق، وأن ثغرات اليوم صفر واردة الحدوث.
ثمة سوق تجارية للدعم الممتد. فقد اعتمدت جمعية Drupal مزودين، منهم HeroDevs وTag1 Consulting، ضمن برنامج Extended Security Support Provider Program، وهم ينتجون ترقيعات بالفعل. هذا أفضل من لا شيء، لكنه ليس مثل أن تكون مدعوماً. فالمزود يرقّع النواة ومجموعة محددة من الوحدات اختار تغطيتها، وفق جدوله الخاص، للعملاء الذين يدفعون. أما بقية المنظومة التي يعتمد عليها موقعك فخارج النطاق.
كما يصعب الدفاع عن نظام إدارة محتوى غير مدعوم في استبيان ضمان الموردين أو أمام شركة تأمين بعد الحادث. ودليلنا حول تكاليف ترحيل Drupal وخياراته ومواعيده يوضح تكلفة الخروج.
النمط التاريخي: Drupalgeddon وما تلاه
ثلاثة حوادث شكلت طريقة تفكير المجتمع في سرعة الترقيع. كل منها كان ثغرة حقن أو تنفيذ شيفرة عن بُعد في النواة، وكل منها شهد استغلالاً آلياً واسعاً خلال ساعات أو أيام.
نافذة السبع ساعات في أكتوبر 2014
كان Drupalgeddon الأصلي هو SA-CORE-2014-005، المنشور في 15 أكتوبر 2014. وكان CVE-2014-3704 ثغرة حقن SQL في طبقة تجريد قاعدة البيانات في Drupal 7، قابلة للاستغلال من مستخدمين مجهولين، وحصلت على الدرجة الكاملة 25 من 25. وكان كل موقع Drupal 7 دون 7.32 متأثراً.
المتابعة هي التي جعلته علامة فارقة. فقد أبلغ PSA-2014-003 أصحاب المواقع بأن الهجمات الآلية بدأت باختراق المواقع غير المرقعة خلال ساعات من الإعلان، وبأن عليهم افتراض أن أي موقع لم يُرقَّع بحلول الساعة 23:00 بالتوقيت العالمي في ذلك اليوم، أي بعد سبع ساعات من النشر، قد اختُرق. لا أنه ربما اختُرق. بل اختُرق. وحذر من أن المهاجمين ربما أخذوا كل البيانات وثبتوا أبواباً خلفية، وهذا ما يحول مشكلة ترقيع إلى مشكلة استجابة للحوادث.
Drupalgeddon 2 و3
SA-CORE-2018-002، المنشور في 28 مارس 2018، كان CVE-2018-7600: ثغرة تنفيذ شيفرة عن بُعد عبر أنظمة فرعية متعددة في Drupal 7 وDrupal 8، بدرجة 24 من 25. وقد أثرت في Drupal من 7.0 حتى 7.57 وفي فروع 8.x حتى 8.5.0، وتبعتها استغلالات علنية خلال أسبوعين تقريباً.
وبعد أربعة أسابيع وصل SA-CORE-2018-004 في 25 أبريل 2018. وكان CVE-2018-7602 ثغرة تنفيذ شيفرة عن بُعد أخرى في شيفرة قريبة، بدرجة 20 من 25، وذكر التنبيه أنها كانت تُستغل بالفعل في الميدان. والفاصل الزمني هو الدرس: فالمواقع التي رقّعت في مارس ثم توقفت عن الانتباه عادت لتكون مكشوفة في أبريل.
مايو 2026، وما الذي لم يتغير
النمط ليس تاريخاً. فقد نُشر SA-CORE-2026-004 في 20 مايو 2026: وهو CVE-2026-9082، ثغرة حقن SQL تصيب المواقع العاملة على PostgreSQL، صُنفت بالغة الخطورة بدرجة 23 من 25، وتغطي كل الفروع من 8.9 حتى 11.3.9. وفي 22 مايو الساعة 04:30 بالتوقيت العالمي عُدل التنبيه لتسجيل محاولات استغلال رُصدت في الميدان، أي أقل من 48 ساعة من النشر إلى الهجمات المرصودة.
لا شيء من ذلك ينتقد فريق الأمان. فقد منح يومين من الإنذار، وشحن داخل النافذة المعلنة، وحدّث التنبيه عندما تغيرت الصورة. أما نمط الفشل فيقع على جانب المشغل: لا مسار مُتمرَّن عليه من التنبيه إلى موقع إنتاج مرقّع.
أين يفشل أمان Drupal فعلياً في الواقع
النواة تحصد العناوين وهي أقل الأمور شأناً. ففي المواقع التي ندققها نادراً ما تكون النتيجة المهمة إصدار نواة غير مرقّع، لأن تحديثات النواة تظهر في واجهة الإدارة ويلاحظها أحدهم. الانكشاف يقع في مكان آخر.
جرد الوحدات الذي لا يملكه أحد
الموقع النموذجي متوسط الحجم على Drupal يشغل ما بين أربعين وثمانين وحدة مساهَم بها، لكل منها مشرف منفصل وإيقاع منفصل. والسؤال الذي لا يكاد أحد يجيب عنه فوراً هو: أي منها ما زال له مشرف نشط، وأيها مغطى بسياسة التنبيهات، وأيها لم يتلق أي تعديل منذ عامين. إعداد تلك القائمة يستغرق بعد ظهر واحد.
الوحدة المخصصة التي لا يملكها أحد
أكثر النتائج الخطيرة شيوعاً وحدة مخصصة كتبها متعاقد رحل. وهي عادة تفعل شيئاً ذا طابع تكاملي: تغذية لنظام إدارة علاقات العملاء، أو معالج نموذج مفصل، أو استدعاء دفع. كُتبت مقابل واجهة برمجية أقدم، وليس لها اختبارات، ولا أحد في الفريق يستطيع القول ما الذي تتحقق منه. والشيفرة المخصصة تقع خارج نظام التنبيهات بحكم التعريف: فلن تخبرك أي رسالة يوم أربعاء بأنها تحوي حقن SQL، وسيعرض تقرير الحالة كل شيء محدثاً. وهي تحتاج إلى انضباط المراجعة نفسه الذي يحتاجه أي عمل آخر في تطوير البرمجيات.
الطبقة التي تعمل تحت Drupal
Drupal هو PHP، وإصدارات PHP تبلغ نهاية عمرها وفق جدولها الخاص. وقد يكون الموقع مرقعاً بالكامل على مستوى نظام إدارة المحتوى ويعمل مع ذلك على إصدار PHP توقف عن تلقي الإصلاحات الأمنية قبل عام، لأن الاستضافة لم تكن يوماً جزءاً من حديث الصيانة. والتوجيهات الخاصة بـصلاحيات الملفات وملكيتها تقوم على مبدأ أن خادم الويب يجب ألا يكون قادراً على الكتابة في الملفات التي ينفذها، ومع ذلك تعمل مواقع كثيرة بدليل شيفرة قابل للكتابة لأن ذلك بسّط سكربت نشر.
كيف ينبغي ترقيع موقع Drupal فعلياً
الإجابة مملة، ولهذا تبقى بلا تنفيذ. فلا أداة تلغي الحاجة إلى مسار مُتمرَّن عليه من التنبيه إلى الإنتاج، وبناؤه مرة واحدة يكلف أقل من أول حالة طوارئ.
سير العمل مع Composer
كل شيء ابتداءً من Drupal 8 هو مشروع Composer. حدّث حزم النواة مع اعتمادياتها، ثم طبّق تحديثات قاعدة البيانات وأعد بناء الذاكرة المؤقتة:
1composer update "drupal/core-*" --with-all-dependencies
2drush updatedb
3drush cache:rebuild
يمكن استبدال Drush بـ update.php. راجع تقرير الحالة قبل وبعد. والمهم ليس الأوامر، بل أن تعمل أولاً في مكان غير بيئة الإنتاج.
بيئة تجريبية تكون نسخة حقيقية
البيئة التجريبية لا تنفع إلا إذا عكست الإنتاج: مجموعة الوحدات نفسها، وإصدار PHP نفسه، وقاعدة بيانات حديثة منقّاة. والبيئة التجريبية القديمة تنتج نتيجة خضراء لا تعني شيئاً، وهذا أسوأ من غياب البيئة التجريبية أصلاً لأنها تصنع ثقة زائفة.
التسلسل هو سحب الإنتاج إلى البيئة التجريبية، وتطبيق التحديث، وتشغيل تحديثات قاعدة البيانات، والمرور على الصفحات والنماذج التي تجعل الموقع مفيداً تجارياً، ثم النشر. ومع خط أنابيب يعمل يستغرق ذلك 45 إلى 90 دقيقة. ومن دونه يوم ونصف.
الأتمتة وحدودها
تحديثات الاعتماديات الآلية تساعد أكثر ما تساعد في تدفق الوحدات المساهَم بها، أي الطرف عالي الحجم منخفض الخطورة. فالروبوت الذي يفتح طلب دمج واحداً لكل تحديث وحدة، مع تشغيل الاختبارات على كل منها، يحول جولة يدوية شهرية إلى طابور مراجعة. والنواة تسير في الاتجاه نفسه: فعمل Automatic Updates مبني على وحدة Package Manager التي تُشحن ضمن النواة لكنها ما زالت تجريبية.
ميزانية الوقت الواقعية
موقع Drupal المصان يكلف نحو نصف يوم شهرياً في تحديثات الوحدات الروتينية، إضافة إلى ساعة إلى ثلاث ساعات لكل إصدار أمني للنواة ينطبق عليه. وأضف احتياطياً للإصدارين البالغي الخطورة أو الإصدار الواحد في السنة الذي يجب إنجازه في المساء نفسه. هذا هو الرقم الذي لم تضعه معظم الفرق الداخلية في الميزانية قط، ولهذا يتأخر العمل.
التحصين إلى ما بعد الترقيع
التحصين لا يحل محل الترقيع. فهو يقلل عدد الثغرات المنشورة القابلة للاستغلال على تثبيتك، ويكسب وقتاً حين يتعذر إخراج ترقيع فوراً. والبنود الخاصة بـ Drupal رخيصة ودائمة.
المضيفات الموثوقة ونظام الملفات
اضبط أنماط المضيفات الموثوقة. يستخدم Drupal آلية المضيف الموثوق من Symfony، وتُضبط عبر إعداد trusted_host_patterns في settings.php بصيغة تعبيرات نمطية تطابق النطاقات التي يجيب عليها موقعك. والطلبات التي تحمل أي ترويسة Host أخرى تُرفض بالرمز 400. ومن دون ذلك يستطيع مهاجم تسميم روابط إعادة تعيين كلمة المرور وعناوين URL المطلقة المخزنة مؤقتاً عبر ترويسة مزورة.
استخدم نظام الملفات الخاص لكل ما لا ينبغي أن يكون قابلاً للقراءة علناً، وتأكد من أن PHP لا يمكن أن تُنفَّذ داخل دليل الملفات العام. يشحن Drupal ملف .htaccess يمنع التنفيذ تحت Apache، لكن nginx ليس له ملف مكافئ يُوضع مباشرة، ويجب كتابة القاعدة يدوياً في إعدادات الخادم. والمواقع التي انتقلت من Apache إلى nginx قبل سنوات فقدت تلك الحماية بصمت في كثير من الأحيان.
ثم طبّق نموذج الملكية: الأدلة عند 750، وملفات الشيفرة عند 640، ودليل الملفات قابل للكتابة من خادم الويب فقط لا غير، وsettings.php قابل للقراءة من مالكه وحده.
الصلاحيات ومسارات الإدارة وجولة المراجعة
قيّد المسارات الإدارية. لا يوجد سبب لأن تكون مسارات تسجيل الدخول والإدارة في موقع يعمل محرروه من ثلاثة مكاتب قابلة للوصول من الإنترنت كله، وقائمة عناوين IP المسموح بها أو وكيل يفرض المصادقة يزيلان صنفاً كاملاً من هجمات بيانات الاعتماد.
ثم دقّق شبكة الصلاحيات. فهي تكبر مع كل وحدة تُثبَّت، والنتيجة تأخذ الشكل نفسه دائماً تقريباً: دور محرر يستطيع إدارة مرشحات النص، أو دور يستطيع تنفيذ شيفرة PHP اعتباطية. وكلاهما يحول كلمة مرور محرر مسروقة إلى تنفيذ شيفرة عن بُعد، فتصير رسالة تصيد اختراقاً للخادم.
شغّل وحدة Security Review قبل أن تجادل في أي شيء آخر. فهي تؤتمت الفحوص المرهقة يدوياً: صلاحيات نظام الملفات، وصيغ النص غير الآمنة، ووجود PHP أو JavaScript في المحتوى، وكشف تقارير الأخطاء، وامتدادات الرفع، ومحاولات الدخول الفاشلة، والصلاحيات الخطرة، وإعداد المضيفات الموثوقة. والإصدار 3.1.3، الصادر في يناير 2026، يدعم Drupal 10.3 وما فوق إلى جانب Drupal 11.
ما الذي يمنحه جدار الحماية وما لا يمنحه
جدار حماية تطبيقات الويب ترقيع افتراضي، وهكذا تضع جمعية Drupal خدمة Drupal Steward، وهي الخدمة المدفوعة التي تديرها مع فريق الأمان. فهي تطبق تخفيفاً على مستوى الشبكة لبعض ثغرات النواة البالغة الخطورة، وتحمي الموقع خلال الفجوة بين التنبيه والنشر. والسعر المنشور أقل من 20 دولاراً أمريكياً شهرياً لموقع يخدم مليون طلب HTTP، وأقل من 100 دولار أمريكي فوق عشرة ملايين.
الحدود يعلنها المشروع نفسه: ليست كل مشكلة قابلة للتخفيف بهذه الطريقة، والآلية لا تغطي إلا الثغرات التي تُستغل عبر طلب موجه إلى خادم الويب. وجدار الحماية لا يفعل شيئاً حيال كلمة مرور مدير مخترقة، أو تحديث وحدة خبيث، أو خلل في شيفرتك أنت. عامله بوصفه تأميناً لنافذة الترقيع، لا سبباً لتوسيعها، وهو الرأي الذي نتبناه في قائمة تعزيز أمان WordPress لدينا.
ما تكلفة الاختراق وكيف تبدو عملية التعافي
التعافي من اختراق Drupal ليس ترقيعاً. فبمجرد أن يحقق المهاجم تنفيذ شيفرة، يصبح الافتراض العملي أن ملفات كُتبت، وبيانات اعتماد أُخذت، وآلية بقاء ثُبتت، وهذا ما قاله فريق الأمان لأصحاب مواقع Drupal 7 في 2014. وتنظيف موقع مخترق في مكانه تخمين يرتدي ثوب المعالجة.
النهج القابل للدفاع عنه هو إعادة بناء قاعدة الشيفرة من نظام إدارة الإصدارات على مضيف جديد، واستعادة المحتوى والملفات المرفوعة فقط بعد الفحص، وتدوير كل بيانات الاعتماد التي كان الموقع يحملها، والاحتفاظ بصورة القرص المخترق بدل حذفها. وهذه الخطوة الأخيرة هي التي يتخطاها الناس تحت الضغط، وهي الدليل الوحيد على ما جرى.
التكلفة التجارية نادراً ما تكون إعادة البناء. بل هي التوقف عن العمل، والعمل الجنائي الرقمي، والتواصل مع العملاء، والإجراء التنظيمي. وإعادة البناء في ظروف الحادث تعادل عادة 5,000 إلى 20,000 جنيه إسترليني من العمل الهندسي، وهي عادة أصغر بند في الإجمالي.
التزامات حماية البيانات في المملكة المتحدة
إذا جرى الوصول إلى بيانات شخصية أو احتمل ذلك، فإن ساعة اللائحة العامة لحماية البيانات في المملكة المتحدة تبدأ عند علمك، لا عند انتهائك من التحقيق. وتشترط إرشادات مكتب مفوض المعلومات بشأن الخروقات الإبلاغ عن أي خرق واجب الإبلاغ دون تأخير لا مبرر له وفي موعد لا يتجاوز 72 ساعة من العلم به، وإذا استغرقت وقتاً أطول وجب عليك بيان الأسباب. وحيثما رجح أن يؤدي الخرق إلى خطر مرتفع على حقوق الأفراد وحرياتهم، وجب عليك أيضاً إبلاغ أولئك الأفراد دون تأخير لا مبرر له.
ومكتب مفوض المعلومات واضح في أن نقص الصورة ليس سبباً لتفويت الموعد: أبلغ بما تعرفه ثم استكمل لاحقاً. والتقصير في الإبلاغ عند وجوبه قد يستوجب غرامة تصل إلى 8.7 مليون جنيه إسترليني أو 2 بالمئة من الإيرادات العالمية.
تلك الساعة هي سبب أهمية السؤال الجنائي الرقمي. فالموقع الذي لا سجلات لديه ولا قيد لأي إصدار كان يعمل لا يستطيع أن يقول أي بيانات جرى الوصول إليها، فينتهي به الأمر إلى الإبلاغ عن أسوأ الحالات. وهذه هي الحجة لإجراء تدقيق أمان الموقع قبل الحادث لا بعده.
ما الذي ينبغي أن يشمله عقد صيانة أمان Drupal
العقد الذي يعد بتطبيق التحديثات فقط لا يستحق الشراء، لأن تطبيق التحديثات هو النصف السهل. فما تدفع مقابله هو مسار الاستجابة في اليوم الذي يصدر فيه تنبيه بالغ الخطورة، والمخرج الذي يثبت أنه يعمل هو التمرين.
النطاق الجدير بالدفع يغطي مراقبة تدفقات التنبيهات لمجموعة وحداتك بالتحديد، ودورة ترقيع شهرية مع بيئة تجريبية واختبار وخطة تراجع، ونافذة استجابة متفقاً عليها خارج ساعات العمل لإصدارات النواة البالغة الخطورة، ومراجعة فصلية للوحدات المهجورة مع تسعير البدائل، وتتبع إصدارات PHP والمنصة، ومراجعة سنوية للإعدادات.
في المملكة المتحدة تقع ترتيبات المراقبة وحدها عند نحو 250 إلى 450 جنيهاً إسترلينياً شهرياً. أما العقد الذي يشمل البيئة التجريبية والاختبار والنشر لموقع متوسط الحجم فهو أقرب إلى 600 إلى 1,500 جنيه إسترليني شهرياً، ويتدرج مع عدد الوحدات وحجم الشيفرة المخصصة، لأن كليهما يحدد قدر اختبار الانحدار المطلوب في كل دورة. وأمام أسعار الوكالات اليومية البالغة 600 إلى 900 جنيه إسترليني، فإن أعلى ذلك النطاق يشتري نحو يومي مهندس. وملاحظتنا حول أسعار مطوري Drupal وتقييمهم تحوي الأرقام.
إغلاق النافذة
يمنحك Drupal إنذاراً وبنية أكثر مما تمنحه أي منصة مماثلة تقريباً. فالتنبيهات تسير وفق جدول، والإصدارات البالغة الخطورة تصل بإنذار مدته يومان. لكن شيئاً من ذلك لا ينفع موقعاً يستغرق أسبوعين لنشر ترقيع من سطر واحد.
تتولى Mecanik ترقيع Drupal وتحصينه ضمن تدقيق أمان الموقع وأعمال تطوير البرمجيات المستمرة لدينا. وأول ارتباط يكون عادة جرداً لا إصلاحاً، لأن معظم المواقع لا تستطيع أن تقول أي وحداتها ما زالت مدعومة. وإذا كنت توازن بين المنصات نفسها، فإن دليلنا لعام 2026 حول تطوير مواقع Drupal يغطي ذلك.
الأسئلة الشائعة
كم مرة يصدر Drupal تحديثات أمنية؟ تنبيهات المشاريع المساهَم بها تُنشر كل أربعاء، ولنواة Drupal نافذة إصدار أمني في الأربعاء الثالث من كل شهر، وإن كانت النافذة لا تضمن صدور إصدار. وإصدارات النواة البالغة الخطورة يسبقها عادة إعلان خدمة عامة قبل نحو يومين، يحدد التاريخ والنافذة الزمنية.
ماذا تعني درجة خطورة Drupal البالغة 20 من 25؟ يمنح Drupal كل تنبيه درجة من 0 إلى 25 بنظام مبني على NIST Common Misuse Scoring System، يجمع بين تعقيد الوصول والمصادقة المطلوبة وأثر السرية والسلامة ووجود استغلال معروف وعدد المواقع المتأثرة. وأي درجة من 20 إلى 25 تعد بالغة الخطورة، ومعناها الترقيع في اليوم نفسه.
هل ما زال تشغيل Drupal 7 آمناً في 2026؟ لا. فقد بلغ Drupal 7 نهاية عمره في 5 يناير 2025، ولم يعد فريق أمان Drupal يصدر تنبيهات لنواته أو وحداته المساهَم بها أو قوالبه، ولذلك يمكن الإفصاح عن الثغرات علناً دون إصلاح منسق. والدعم الممتد التجاري يغطي مجموعة محددة من الشيفرة بشروط المزود، وهو يساعد أثناء الترحيل لكنه ليس مثل أن تكون مدعوماً.
ما مدى سرعة استغلال المهاجمين لثغرة في Drupal؟ خلال ساعات في أسوأ الحالات. فبعد تنبيه حقن SQL في أكتوبر 2014 طلب فريق أمان Drupal من أصحاب المواقع افتراض أن أي موقع لم يُرقَّع خلال سبع ساعات قد اختُرق بالفعل. وفي مايو 2026 رُصدت محاولات استغلال في الميدان ضد ثغرة حقن SQL بالغة الخطورة في النواة بعد أقل من يومين من النشر.
هل يغني جدار حماية تطبيقات الويب عن ترقيع Drupal؟ لا. جدار حماية مثل Drupal Steward يوفر ترقيعاً افتراضياً لبعض ثغرات النواة البالغة الخطورة التي تُستغل عبر طلب ويب، وهو ما يكسب وقتاً خلال نافذة النشر. لكنه لا يجدي مع كلمة مرور مدير مسروقة أو وحدة مخترقة أو خلل في شيفرتك أنت، فهو يقلل خطر الفجوة بدل أن يغلقها.
التعليقات