حادثة تذاكر دعم Virtualizor: لماذا لا يجوز تخزين كلمات مرور root أبدًا
سلّطت حادثة أمنية في فبراير 2026 طالت نظام دعم لدى Virtualizor الضوء على واحدة من أقدم مشكلات الأمن في قطاع الاستضافة: منصات الدعم تتحول دون قصد إلى مخازن لبيانات اعتماد العملاء.
فبحسب التحديث الأمني الصادر عن Virtualizor نفسها، أدى وصول غير مصرّح به إلى نظام تذاكر الدعم لديها إلى كشف نحو 1500 تذكرة قديمة. وأفادت الشركة بأن بعض تلك التذاكر تضمّن معلومات حساسة، منها بيانات اعتماد root بنص صريح كان العملاء قد شاركوها سابقًا أثناء طلب المساعدة. وأوضحت الشركة أن الحادثة تتعلق بنظام الدعم ولم تنشأ عن ثغرة في برنامج Virtualizor ذاته. 1
والدرس المهم لا يقتصر على منصة واحدة أو مزود واحد.
فالمشكلة أن أنظمة الدعم تحتوي غالبًا على سنوات من بيانات العملاء، وهي بيانات لم يُقصد يومًا أن تتحول إلى سجل أمني دائم.
مكاتب الدعم أنظمة أمنية مُهمَلة
كثير من مزودي الاستضافة يراكم النوع نفسه من المعلومات مع الوقت.
كلمات مرور root تُلصق أثناء تشخيص عطل. مفاتيح SSH تُرفق أثناء ترحيل. رموز API داخل رسائل الأخطاء. نسخ من قواعد بيانات تُرفع لإعادة إنتاج مشكلة.
تُغلق التذكرة. تُحل المشكلة. ويمضي العميل إلى شأنه.
لكن البيانات تبقى في الغالب مخزّنة في قواعد بيانات التذاكر والنسخ الاحتياطية والمرفقات والأرشيفات الداخلية.
ويرتبط حجم التعرّض الأمني لنظام الدعم ارتباطًا مباشرًا بكل سرّ مرّ عبره. ولدى كثير من المزودين، يحتوي ذلك التاريخ على معلومات حساسة أكثر مما يدركون.
لا ترسل بيانات اعتماد دائمة إلى الدعم أبدًا
ينبغي للعميل أن يعتبر أي بيانات اعتماد أرسلها عبر تذكرة دعم مكشوفة احتمالًا.
ويشمل ذلك:
- كلمات مرور root
- كلمات مرور المسؤول
- مفاتيح API
- المفاتيح الخاصة
- بيانات اعتماد قواعد البيانات
- كلمات مرور لوحة التحكم
- كلمات المرور المؤقتة المنشأة لأغراض التشخيص
وإن سبق أن شاركت بيانات اعتماد، فغيّرها.
والنهج الأكثر أمانًا هو الوصول المؤقت:
- أنشئ حسابًا مؤقتًا للدعم
- امنحه صلاحيات محدودة
- اسحب الوصول بعد الانتهاء
- استخدم الوصول عبر الكونسول حين لا يتوفر SSH
ينبغي أن يكون المزود قادرًا على تشخيص خدمتك دون الحاجة إلى بيانات دخولك الدائمة.
ما ينبغي أن يغيّره مزودو الاستضافة
المسؤولية لا تقع على العملاء وحدهم.
فعلى المزودين أن يفترضوا وجود معلومات حساسة داخل التذاكر القديمة، وأن يتخذوا خطوات للحد من الأثر.
ومن الممارسات الجيدة:
- فحص التذاكر القديمة بحثًا عن بيانات تشبه بيانات الاعتماد
- حذف المرفقات غير الضرورية بعد انتهاء مدد الاحتفاظ
- حماية أنظمة الدعم بضوابط مصادقة قوية
- تقييد وصول الموظفين إلى بيانات العملاء
- توثيق سياسات التعامل مع بيانات الاعتماد
ينبغي التعامل مع منصة الدعم بوصفها نظامًا أمنيًا في بيئة الإنتاج. فهي تحتوي على معلومات العملاء وتفاصيل تشغيلية وربما مواد مصادقة.
وصول بلا بيانات اعتماد
في AVS ISP لا نطلب من العملاء إرسال كلمات مرور root.
فخدمات VPS وVDS لدينا تشمل وصولًا إلى كونسول noVNC عبر المتصفح من داخل منطقة العملاء. وإذا تعذّر الوصول عبر SSH بسبب خطأ في جدار الحماية أو إعداد معطوب أو تحديث فاشل أو أي مشكلة أخرى في النظام، يستطيع العميل الدخول إلى الجهاز مباشرة دون مشاركة أي بيانات اعتماد دائمة.
وحين تلزم مساعدة الدعم، فالهدف مساعدة العميل على تشخيص المشكلة دون إنشاء نسخة أخرى من أسراره.
وتعتمد بنيتنا التحتية لخدمات VPS على محاكاة قائمة على KVM، بحيث تفرض حدودَ العزل محاكاةٌ مدعومة بالعتاد على مستوى مشرف الأجهزة الافتراضية، لا العزل على مستوى نظام التشغيل وحده.
ينبغي أن تحتوي محادثات الدعم على معلومات تشخيصية، لا على كلمات مرور.
وإن سبق أن أرسلت بيانات اعتماد إلى أي مزود استضافة، بما فينا، فالإجراء الأسلم واحد: غيّرها.
برامج الفدية تحوّل سوء تصميم النسخ الاحتياطية إلى خسارة دائمة
أشد ما يضر في حوادث برامج الفدية ليس الاختراق الأولي في الغالب.
بل فقدان خيارات الاستعادة.
فإذا وصل المهاجمون إلى أنظمة الإنتاج وإلى النسخ الاحتياطية المتاحة منها، يتحول الانقطاع إلى فقدان دائم للبيانات.
واستراتيجية النسخ الاحتياطي الحقيقية تتطلب فصلًا:
- بيانات اعتماد منفصلة
- أنظمة منفصلة
- نطاقات فشل منفصلة
- ويُفضَّل مواقع مادية منفصلة
فالنسخة الاحتياطية المخزَّنة في البيئة نفسها والمحمية ببيانات الاعتماد نفسها التي تحمي الإنتاج ليست نسخة استعادة مستقلة.
تشغّل AVS ISP بنية تحتية في عدة مواقع، وتوفر مواقع VPS إضافية لمن يريد فصلًا جغرافيًا. غير أن المبدأ ينطبق في كل مكان: ينبغي أن يحتفظ العميل بنسخ يتحكم فيها بنفسه، لا بنسخ موجودة داخل بيئة مزود استضافته فحسب.
الدرس الأوسع للاستضافة
الدرس المستفاد من حوادث كهذه بسيط:
الأمن ليس جدران حماية ومشرفي أجهزة افتراضية وحماية شبكات فحسب.
إنه كذلك عادات عمل يومية عادية.
فكلمة مرور تُنسخ اليوم داخل تذكرة دعم قد تتحول بعد سنوات إلى حادثة أمنية.
على مزودي الاستضافة أن يصمّموا أنظمتهم على افتراض أن العملاء سيخطئون. وعلى العملاء أن يختاروا مزودين تكون تلك الأخطاء لديهم أقل خطورة.
وأفضل تذكرة دعم هي التي تحل المشكلة دون أن تحتوي سرًا قط.
أسئلة متكررة
هل أعطي مزود VPS كلمة مرور root الخاصة بي؟
لا. لا ينبغي لمزود الاستضافة أن يطلب بيانات اعتماد دائمة. فطرق الوصول المؤقت أو الكونسول أو الحسابات المحدودة الصلاحيات أكثر أمانًا.
هل تذاكر الدعم خطر أمني؟
نعم. فالتذاكر تحتوي غالبًا على سجلات وتفاصيل إعداد وبيانات اعتماد ومعلومات عن العملاء، وقد تبقى مخزنة سنوات.
ماذا أفعل إن أرسلت كلمة مروري إلى دعم الاستضافة؟
غيّرها فورًا. وغيّر كذلك أي مفاتيح أو رموز أو بيانات اعتماد مرتبطة ربما وردت في الرسالة نفسها.
المصادر
- Security Update: Transparency Regarding a Recent Support Ticket Incident، Virtualizor (3 فبراير 2026) — المصدر الأساسي
- Mass VPS Provider Ransomware Attack Linked to Stolen Credentials from Virtualizor Support Breach، Cyber Kendra (فبراير 2026) — تقرير مستقل