عندما نُشرت تفاصيل حملة Deadbugz في أغسطس 2026، كان أول سؤال طرحته معظم الفرق: «هل تأثرنا؟». ولم يستطع معظمها الإجابة. فقد تصرّف خادم MCP الخبيث كأداة لتنسيق النصوص في أول ثلاث استدعاءات، ثم غيّر التعليمات التي يرسلها إلى الوكيل. والفريق الذي لم يسجّل إلا «اتصل الخادم» لم يكن لديه أي سجل لما قاله الخادم، ولا لما فعله الوكيل بعد ذلك، ولا للملفات التي لمسها. هذا الدليل هو إعداد التسجيل الذي تمنينا لو كان لدينا قبل تدقيق MCP الذي أجريناه: ماذا نسجّل، وأين، وإلى متى نحتفظ به.
ماذا يجب أن يتضمن سجل تدقيق MCP؟
يجب أن يسجّل سجل تدقيق MCP كل تشغيل لخادم مع أمره الدقيق وإصداره، وكل تعريف أدوات يرسله الخادم وأي تغيير فيه، وكل استدعاء أداة مع معاملاته وحجم نتيجته، وهوية المستخدم ونطاقات الرمز خلف كل استدعاء، والطلبات الصادرة إلى الشبكة. وتتيح هذه معاً إعادة بناء ما فعله الوكيل ولمصلحة من تصرّف.
لماذا تفوّت سجلات التطبيقات العادية هجمات MCP
لخادم MCP قناتان إلى أنظمتك: فهو يشغّل شيفرة، ويرسل إلى الوكيل نصوصاً مثل أسماء الأدوات وأوصافها وقوالب الأوامر يعاملها النموذج كتعليمات. ومعظم التسجيل يغطي القناة الأولى فقط، إن غطاها. وقد وصلت حمولة Deadbugz عبر القناة الثانية: تعليمات جديدة في ردود tools/list وprompts/get اللاحقة بعد أن بلغ العدّاد ثلاثة استدعاءات. لم يبدُ أي شيء خاطئاً عند التثبيت. وحده السجل الذي يحفظ ما قاله الخادم ومتى تغيّر كان سيُظهر ذلك.
وتشير أفضل الممارسات الأمنية للبروتوكول نفسه إلى الاتجاه ذاته في عدة مواضع: يجب على خدمات الوكيل التي تشغّل خوادم محلية تسجيل كل استخدام لنقل stdio لأغراض المراقبة الأمنية، ويجب على الخوادم تسجيل أحداث رفع النطاق مع معرّفات ربط، ويجب على العملاء تسجيل روابط التفويض المشبوهة. كما يحذّر المستند من أن تمرير الرموز كما هي يُفسد سجل التدقيق، لأن الخادم لا يعود قادراً على التمييز بين العملاء وتُظهر السجلات اللاحقة هوية خاطئة.
الأحداث التي تستحق التسجيل
| الحدث | الحقول المطلوب تسجيلها | ما الذي يكشفه |
|---|---|---|
| تشغيل الخادم | الأمر الكامل ومعاملاته، وإصدار الحزمة أو بصمة commit، وملف الإعداد الذي جاء منه، والمستخدم الذي يعمل باسمه | التشغيل دون تثبيت الإصدار، والخوادم المضافة عبر طلب سحب، والأمر المتغيّر |
| تعريفات الأدوات | بصمة النص الكامل لكل رد tools/list وprompts/list ونصه، لكل جلسة مع الوقت | الأوصاف التي تتغير بعد الموافقة أو بعد عدة استدعاءات |
| استدعاء الأداة | اسم الأداة والخادم والمعاملات (مع حجب الأسرار) وحجم النتيجة والمدة والخطأ | أداة تنسيق تبدأ فجأة بقراءة الملفات، وأنماط المعاملات غير المعتادة |
| الهوية والنطاقات | المستخدم البشري، ومعرّف جلسة الوكيل، وجمهور الرمز ونطاقاته، ومعرّف الربط | الرموز واسعة الصلاحيات، وتمرير الرموز، والاستدعاءات التي لا يمكن نسبتها لأحد |
| رفع النطاق | النطاق المطلوب، والجزء الممنوح، والأداة التي أطلقته | تصاعد الصلاحيات خلال الجلسة |
| الطلبات الصادرة | المضيف الوجهة والمنفذ والبايتات المرسلة والخادم أو الأداة التي أرسلتها | التسريب الصامت، والاتصال بعناوين البيانات الوصفية مثل 169.254.169.254 |
| الوصول إلى ملفات خارج المشروع | المسار، والقراءة أو الكتابة، والعملية | قراءة ~/.ssh وملفات بيانات الاعتماد السحابية وسجل الأوامر |
سجّل تعريفات الأدوات لا استدعاءاتها فقط
هذا ما تتجاهله معظم الفرق. احفظ المخرجات الكاملة لـ tools/list وprompts/list في بداية كل جلسة ثم بعد عدة استدعاءات، وقارن البصمات. يجب أن يطلق تغيير الوصف في خادم وافقت عليه سابقاً تنبيهاً وأن يحتاج إلى موافقة بشرية من جديد، وهذه هي التوصية التي قدّمتها Pillar Security لمطوري عملاء MCP بعد Deadbugz. وحفظ النص الكامل لا البصمة فقط مهم للتحقيق لاحقاً، لأن الوصف المتغيّر هو الدليل.
أين يجب أن تُحفظ السجلات
ليس على الجهاز نفسه الذي يعمل عليه الوكيل، ولا في أي مكان يستطيع الوكيل الكتابة فيه. فإذا أمكن توجيه الوكيل لحذف ملفات، أمكن توجيهه لحذف سجله. أرسل الأحداث خارج المضيف لحظة وقوعها. ومن الأنماط العملية أن يكتب عميل MCP أو وكيل محلي صغير سطر JSON واحداً لكل حدث إلى stdout، وأن تجمعه أداة شحن السجلات الموجودة لديك، تماماً كما يجب أن تُكتب سجلات الحاويات إلى stdout لا إلى ملفات. وأحداث الشبكة أوثق حين تأتي من وكيل خروج (egress proxy) لا من الوكيل نفسه، لأن العملية المخترقة لن تبلّغ عن تسريبها.
احجب الأسرار قبل الحفظ
تحمل معاملات الأدوات ونتائجها بالضبط ما يريده المهاجم: الرموز ومحتويات الملفات وسجلات العملاء. احجب أنماط الأسرار المعروفة قبل الكتابة، واحفظ حجم النتيجة بدلاً من النتيجة كاملة افتراضياً، واحتفظ بالحمولات الكاملة فقط للأدوات التي صنّفتها حساسة وفي مخزن بصلاحيات وصول أضيق. فسجل التدقيق الذي يسرّب بيانات الاعتماد يصبح الحادثة التالية.
كم من الوقت نحتفظ بسجلات MCP
احتفظ بها مدة لا تقل عن سجلاتك الأمنية الأخرى، وطويلة بما يكفي لتغطية الفجوة بين الهجوم والكشف العلني عنه. فُتحت طلبات سحب Deadbugz في 10 أغسطس ونُشر التقرير في 12 أغسطس، بينما تظهر حملات أخرى بعد أشهر. وإذا كانت سياسة الاستجابة للحوادث لديك تحدد مدة احتفاظ لسجلات المصادقة والأجهزة الطرفية، فاستخدم المدة نفسها بدلاً من اختراع مدة أقصر لأدوات الذكاء الاصطناعي.
إعداد أدنى لفريق صغير
- اجرد كل خوادم MCP وثبّت إصداراتها، كما في قائمة التدقيق لدينا.
- غلّف عمليات التشغيل بحيث يُسجَّل الأمر الدقيق والإصدار والمستخدم مرة في كل جلسة.
- التقط لقطة من tools/list وprompts/list عند بدء الجلسة وبعد الاستدعاء الثالث، ونبّه عند أي تغيّر في البصمة.
- سجّل كل استدعاء أداة بمعاملات محجوبة الأسرار وحجم النتيجة، موسوماً بالمستخدم البشري ومعرّف الجلسة.
- مرّر حركة الوكيل عبر وكيل خروج بقائمة سماح، واحفظ سجلاته خارج المضيف.
المبدأ نفسه يحكم طريقة بنائنا للمساعدين الداخليين: لا يجوز أن يملك المساعد صلاحيات أكثر من الشخص الذي يعمل له، ويجب أن تكون كل إجابة قابلة للتتبع إلى مصدر. تناولنا جانب الوصول في تقييد المساعد الذكي الداخلي بصلاحيات السائل. وفي FanMind، مساعد المستندات لدينا، تمر الاتصالات الصادرة عبر نفق واحد بقائمة سماح وتُستبعد المستندات السرية من فهرسة الذكاء الاصطناعي افتراضياً، ما يُبقي سطح الهجوم وحجم السجلات صغيرين.
الأسئلة الشائعة
ماذا يجب أن أسجّل لخوادم MCP؟
سجّل كل تشغيل للخادم مع أمره الدقيق وإصداره والمستخدم، والنص الكامل وبصمة كل رد tools/list وprompts/list، وكل استدعاء أداة بمعاملات محجوبة الأسرار وحجم النتيجة، والمستخدم البشري ومعرّف الجلسة ونطاقات الرمز خلف كل استدعاء، وأحداث رفع النطاق، والطلبات الصادرة إلى الشبكة من الخادم أو الوكيل.
لماذا نسجّل تعريفات أدوات MCP؟
لأن أسماء الأدوات وأوصافها وقوالب الأوامر تعليمات يتبعها النموذج، ويمكن أن تتغير بعد موافقتك على الخادم. لم يغيّر خادم Deadbugz ما يرسله إلا بعد ثلاث استدعاءات. ومقارنة لقطات tools/list وprompts/list خلال الجلسة هي الطريقة الوحيدة لرؤية هذا التغيير وإثبات ما قيل للوكيل.
هل تشترط مواصفات MCP سجل تدقيق؟
لا تحدد صيغة موحدة لسجل التدقيق، لكن أفضل ممارساتها الأمنية توصي بالتسجيل في عدة مواضع: تسجيل الوكلاء لكل استخدام لنقل stdio للمراقبة الأمنية، وتسجيل الخوادم لأحداث رفع النطاق مع معرّفات ربط، وتسجيل العملاء لروابط التفويض المشبوهة. كما تحذّر من أن تمرير الرموز يضر بسجل التدقيق.
أين يجب أن تُحفظ سجلات تدقيق MCP؟
خارج المضيف الذي يعمل عليه الوكيل وبعيداً عن صلاحية الكتابة لديه، حتى لا يستطيع وكيل موجَّه حذفها. أصدر الأحداث كأسطر JSON إلى stdout واشحنها عبر مسار السجلات الحالي، وخذ أحداث الشبكة من وكيل خروج، لأن العملية المخترقة لن تبلّغ بشكل موثوق عن حركتها الصادرة.
