الإصلاح بموافقة: معالجة دون تجاوز الخط

الكشف نصف المهمة فقط. النصف الآخر هو الإصلاح — لكن المعالجة التلقائية العمياء خطيرة بقدر المشكلة نفسها بالضبط. نهج Doogree بسيط: لا نُصلح من وراء ظهرك. كل مشكلة قابلة للإصلاح تظهر كـاقتراح، يوافق عليه أحدهم، وعندها فقط ينطلق إجراء معروف ومُقيَّد وقابل للعكس.

تشريح اقتراح إصلاح

كل مشكلة قابلة للإصلاح لا تُنفَّذ من تلقاء نفسها — بل تُقترَح. يرى المشغّل ثلاثة أزرار: موافقة / إصلاح، ليس الآن، تجاهل. الضغط على موافقة يرسل إجراءً مُنمذَجًا مُدرَجًا في قائمة سماح — لا أمر صدفة اعتباطيًا — ثم يعيد النظام التحقق من الحالة ويشغّل الحلقة من جديد حتى تُحلّ المشكلة أو تُتجاهَل. لا وجود لـ"أصلِح كل شيء بنقرة واحدة" يعمل في الظلام؛ بل سلسلة قصيرة من اقتراح ← موافقة ← إجراء ← تحقق.

لماذا لا توجد صدفة حرة — نموذج الثقة

السرّ أن الإجراءات ليست "شغّل هذا الأمر". تُرسَل الإجراءات ضدّ خادم عبر قناة تحكّم موقّعة ومثبَّتة بنمط TOFU (الثقة عند الاستخدام الأول): تُوقَّع الصيغة القانونية للأمر، فيُكشَف أي إعادة تشغيل أو عبث فورًا. لا توجد صدفة حرة — بل إجراءات من قائمة سماح فقط، تُستدعى بأسمائها الصريحة. المعنى العملي: حتى لو اختُرقت سحابة أو قاعدة بيانات، لا يستطيع المهاجم تزوير أمر وتحويله إلى تنفيذ عن بُعد على الأسطول. الخط الفاصل بين "الكشف" و"تشغيل شيفرة على جهاز" يُحرَس بغيرة.

حادثة حرجة ← زر احتواء

يرتبط الإصلاح بموافقة مباشرة بمحرك الحوادث. عندما يطوي محرك SIEM-lite عدة تنبيهات في حادثة مترابطة بخطورة عالية/حرجة، يعرض تلقائيًا زرّ احتواء. الموافقة على الزر تعمل عبر قناة التحكّم الموقّعة ذاتها — نموذج الثقة ذاته، قائمة السماح ذاتها، التدقيق ذاته. فلا تُكتشَف سلسلة الهجوم وتُوسَم فحسب — بل تنال إجراء استجابة قابلًا للعكس على بُعد نقرة واحدة.

لماذا هذا حرِج لشركة صغيرة

لا تملك الشركة الصغيرة عادةً مهندس أمن بدوام كامل. يمنح الإصلاح بموافقة صاحب عمل غير خبير زرَّ "أصلِح هذا" آمنًا — موثّقًا بالكامل — بدلًا من الحاجة إلى SOC مكلِّف. وحين يكون الأمر ذا أثر، يبقى الإنسان في الحلقة؛ ولاحقًا يمكنك تقييده خلف سياسة بموافقة 2FA (موافقة دفع) بحيث لا ينطلق إجراء محفوف بالمخاطر إلا بعد التحقق.

← العودة إلى المدونة · كيف يعمل ←