التصحيح جزء ممّا تستعيدونه
في منتج SaaS يكون تحديث الأمان غير مرئي: يطرحه الناشر على أسطوله الخاص، أحيانًا قبل الإعلان العلني. أما الثغرة ذاتها على نسخة تستضيفونها بأنفسكم فتظل مفتوحة حتى يطبّق أحدهم الإصلاح. توضّح CVE-2026-63077 هذه الفجوة: أتاحت الثغرة تنفيذ أوامر النظام دون مصادقة على TeamCity On-Premises، وصُحّحت في الإصدارين 2025.11.7 و2026.1.3، بينما لم تتطلّب نشرات الناشر السحابية أي إجراء من عملائها. الفجوة ليست تقنية، بل تنظيمية.
ما الذي ينكسر حين لا يتولّاه أحد
- يصبح الإصدار المثبَّت غير معروف — بلا جرد لا يعرف أحد أي مكوّن يعمل على أي جهاز، ولا يمكن حتى فرز نشرة أمنية.
- تصل النشرة إلى عنوان ميت — تذهب إشعارات الناشر إلى بريد مزوّد غادر، أو إلى اسم مستعار لم يعد أحد يقرأه.
- يتراكم التأخّر حتى الطريق المسدود — التأخّر بثلاثة إصدارات رئيسية يحوّل تصحيحًا من عشر دقائق إلى ترحيل من يومين.
- يجري التحديث بلا شبكة أمان — بلا نسخة احتياطية متحقَّق منها، لا يمكن التراجع عن ترحيل مخطَّط قاعدة البيانات بعد تطبيقه.
- لا يتحقّق أحد بعد ذلك — تُعاد الخدمة، وتستجيب الصفحة الرئيسية، ويبقى مستهلك طابور المهام ميتًا أسابيع دون أي إشارة.
المتطلبات الأربعة لروتين قابل للاستمرار
لا يقوم روتين التصحيحات على حسن النية، بل على أربعة أمور مكتوبة. جرد: كل تطبيق وإصداره ومضيفه والمسؤول عنه. مصادر نشرات محصورة في المكوّنات المثبَّتة فعلًا، لأن التغذية العامة تُغرق الإشارة. نافذة معلنة: موعد متكرر يُقبل فيه الانقطاع، وإلا انتظر التصحيح لحظة هدوء لا تأتي أبدًا. نسخة احتياطية قابلة للاستعادة، مجرَّبة قبل الحاجة إليها. بدون هذه الأربعة، يعود كل تحديث مشروعًا يُتفاوض عليه.
الروتين في خمس خطوات
جرد ما يعمل فعلًا
أدرجوا كل تطبيق مكشوف وإصداره الدقيق ومضيفه والمسؤول عنه. يعطي docker compose ls ثم docker image inspect الحالة الحقيقية للحاويات، ويعطي dpkg -l أو rpm -qa حالة حزم النظام. ضعوا هذا الملف تحت إدارة الإصدارات إلى جانب إعداداتكم: الجرد الذي يعيش في ذاكرة بشرية فقط غير موجود.
الاشتراك في نشرات المكوّنات المثبَّتة، لا في الإنترنت كله
لكل سطر في الجرد افتحوا اشتراكًا مسمّى: تغذية Atom لإصدارات المستودع (https://github.com/org/repo/releases.atom)، أو قائمة الأمان البريدية للناشر، أو استعلام NVD مرشَّحًا على المنتج. اشتراك واحد لكل مكوّن يبقى قابلًا للفرز. وجّهوها إلى بريد مشترك، لا إلى عنوان شخصي.
تحديد نافذة تصحيح ومسار سريع
احجزوا موعدًا متكررًا يُقبل فيه الانقطاع ويُعلن عنه. تكفي فئتان: التصحيحات العادية تنتظر النافذة، والثغرة الحرجة المستغَلة فعليًا تستوجب تطبيقًا فوريًا خارج النافذة. كتابة هذه القاعدة قبل الحادثة تعفيكم من التفاوض عليها أثناءها.
النسخ الاحتياطي قبل التطبيق مباشرة، وإثبات الاستعادة
قبل التطبيق خذوا تصديرًا لقاعدة البيانات (mysqldump، pg_dump) ونسخة مؤرَّخة من وحدة تخزين البيانات، وسجّلوا الإصدار الذي تغادرونه. لقطة على مستوى المُشرف الافتراضي ونسخة احتياطية على مستوى التطبيق (restic، borg) لا تغطّيان الخطر ذاته: احتفظوا بالاثنتين، واختبروا استعادة ما دامت غير عاجلة.
التحقق من السلوك بعد التطبيق، ثم تسليمه إلى مِجَسّ
المنفذ المفتوح لا يثبت شيئًا. بعد كل تصحيح تحقّقوا ممّا يفعله التطبيق فعلًا: استجابة نقطة الصحة (curl -fsS https://your-domain.com/health)، واستهلاك الطوابير، وإرسال بريد اختباري، وغياب أخطاء جديدة في السجلات. ثم أدرجوا هذه الفحوص في مراقبة دائمة، مع Uptime Kuma مثلًا، تعيد تشغيلها دونكم.
تقليص سطح الهجوم بدل الجري خلف التصحيحات
لوحة إدارة أو بروتوكول وكيل مكشوف على الإنترنت العام يحوّل كل ثغرة غير مصادَق عليها إلى حادثة فورية. ضعوا هذه الواجهات خلف شبكة خاصة أو VPN أو قائمة عناوين مسموح بها. يبقى التحديث إلزاميًا، لكن المهلة بين نشر النشرة وتصحيحكم تتوقّف عن كونها نافذة انكشاف مفتوحة للجميع.
من يحدّث ماذا، بالضبط
على خادم تديرونه بأنفسكم يجب أن يبقى التقسيم واضحًا. يوفّر المستضيف الأساس ويصونه: الجهاز والشبكة والتخزين وتوافر المُشرف الافتراضي. أما التطبيقات التي تثبّتونها فوقه — إصداراتها وتصحيحاتها وإعداداتها — فتبقى تحت إدارتكم. لن يحدّثها أحد نيابة عنكم، وذلك ثمن التحكّم الذي اخترتموه. الروتين الموصوف هنا هو ما يجعل هذا التقسيم قابلًا للاستمرار: يحوّل عبئًا منتشرًا إلى موعد قصير ومتوقَّع.
