خادم MCP قد يسرّب أسرارك: 10 ضوابط قبل توصيل أي وكيل

قد يسرّب خادم MCP أسرارك إذا استطاع الوكيل تحويل محتوى خبيث إلى استدعاء أداة بصلاحيات حقيقية. لتقليل الخطر، لا تعتمد على تعليمات النموذج وحدها؛ قيّد الهوية والصلاحيات، واعزل التنفيذ، واحمِ الرموز، وافحص الأدوات ومدخلاتها ومخرجاتها.

قبل توصيل أي وكيل، طبّق الضوابط العشرة التالية واجعل الأفعال الحساسة متوقفة على موافقة لا يستطيع النموذج تجاوزها. هذه قائمة نشر عملية، وليست بديلًا عن نمذجة التهديدات وفق بياناتك وبنية شبكتك والأنظمة التي يستطيع الخادم تغييرها.

افهم كيف يتحول المحتوى إلى تسريب أو إجراء

لا يقتصر سطح الهجوم على منفذ الخادم. قد تختبئ تعليمات ضارة في طلب المستخدم، أو مستند مسترجع، أو وصف أداة، أو نتيجة يعيدها خادم آخر؛ ثم يختار النموذج أداة مشروعة لكنه يمرر إليها موردًا أو وجهة أو معلمات خطرة.

توضح قائمة OWASP لأمان MCP أن هذا السطح يجمع حقن التعليمات وتسميم الأدوات وهجمات سلسلة التوريد ومشكلة الوكيل المربك، كما يتيح تسريب البيانات عبر استدعاءات تبدو طبيعية. لذلك يجب أن يفرض كل حاجز قرارًا تقنيًا مستقلًا عن امتثال النموذج.

1 و2: افصل الهوية وقلّص نطاق التفويض

1. أنشئ هوية مستقلة لكل وكيل وخادم وبيئة. لا تشغّل التطوير والإنتاج بالحساب الخدمي نفسه، ولا تشارك رمز وصول بين خوادم متعددة. اربط الطلب بالمستخدم أو المستأجر، ثم افحص التفويض عند كل أداة ومورد بدل الاكتفاء بنجاح تسجيل الدخول.
2. ابدأ بأضيق نطاق ثم ارفع الامتياز عند الحاجة. افصل القراءة عن الإنشاء والحذف وتغيير الصلاحيات. إذا احتاجت عملية إلى امتياز أعلى، اطلب نطاقها المحدد في وقت التنفيذ ولا تمنح صلاحيات مستقبلية احتياطًا.

تنص إرشادات الأمان الرسمية لـMCP على قراءة توصياتها مع مواصفة التفويض وأفضل ممارسات OAuth، وتعد تمرير الرمز إلى خدمة خلفية دون التحقق من جمهوره نمطًا غير آمن. يجب أن يرفض خادم MCP أي رمز لم يصدر له تحديدًا، وأن يستخدم للخدمة اللاحقة رمزًا منفصلًا صادرًا عنها.

3 و4: اعزل الخادم وأبقِ الأسرار خارج متناول النموذج

3. شغّل الخادم داخل حد احتواء مستقل. استخدم حاوية أو صندوقًا معزولًا بهوية نظام غير مميزة، واقصر الملفات المركبة على المسارات المطلوبة. امنع الاتصال الشبكي افتراضيًا ثم اسمح بالوجهات والمنافذ الضرورية، وافصل خوادم المدفوعات والهوية والبيانات الشخصية عن الخوادم العامة.
4. لا تضع الرموز في الشيفرة أو الإعدادات المكشوفة أو السجلات. احفظها في مخزن أسرار، ومرّرها وقت التشغيل إلى العملية المخولة فقط، وفضّل رموز الوصول قصيرة العمر مع تدوير قابل للاختبار. نقّح رسائل الخطأ ونتائج الأدوات وسجلات التدقيق من رموز OAuth ومفاتيح API وملفات تعريف الارتباط.

اختبر العزل بمحاولة قراءة ملف خارج المسار المسموح، والاتصال بعنوان داخلي محظور، واستدعاء أداة بهوية مستأجر آخر. معيار النجاح هو رفض نظام الملفات أو الشبكة أو طبقة التفويض للطلب، لا اختيار الوكيل الامتناع عنه.

5 و6 و7: تحقّق من الأداة والمدخل والمخرج

5. ثبّت مصدر الخادم وتعريفات أدواته. راجع الناشر والشيفرة والتبعيات، وثبّت إصدار الحزمة وتحقق من سلامتها. احتفظ ببصمة معتمدة لأسماء الأدوات وأوصافها ومخططات معلماتها، وأوقف الاتصال أو أعد المراجعة عند ظهور تغيير غير متوقع.
6. طبّق مخطط إدخال مغلقًا لكل أداة. ارفض الحقول غير المعلنة وحدد الأنواع والأطوال والأنماط والقيم المقبولة. لا تمرر أمر shell أو استعلام SQL أو مسار ملف خامًا، واستخدم قائمة سماح للوجهات التي تستطيع أدوات جلب الروابط الاتصال بها لمنع SSRF والوصول إلى خدمات داخلية.
7. عامل المخرجات كبيانات غير موثوقة. أعد حقولًا منظمة وضرورية فقط، وانزع الأسرار والمحتوى التنفيذي. لا تسمح لنص مسترجع بأن يصبح تعليمات نظام أو معلمات لأداة ثانية من دون تحقق جديد، وافصل قناة البيانات عن قناة التعليمات.

شغّل اختبارات حقن تتضمن أمرًا مخفيًا في مستند، ووصف أداة يحاول التأثير في أداة أخرى، ونتيجة تطلب إرسال البيانات إلى نطاق خارجي. النجاح لا يعني اكتشاف العبارة فحسب، بل منع انتقالها إلى فعل يتجاوز السياسة.

8 و9: أوقف الأفعال الحساسة عند بوابة مستقلة

8. صنّف الأدوات وفق أثرها قبل إتاحتها. يمكن تنفيذ قراءة منخفضة الحساسية تلقائيًا داخل حدود محددة، بينما يتطلب الحذف والنشر والتحويل المالي وتغيير الصلاحيات ومشاركة البيانات موافقة صريحة. ضع قواعد المنع والتنفيذ في بوابة خارج النموذج.
9. اعرض الفعل الفعلي للمراجع. يجب أن يرى المستخدم المورد المستهدف، والحقول التي ستتغير، والجهة المستلمة، والقيمة أو النطاق. اربط الموافقة ببصمة هذه المعلمات وباستخدام واحد؛ فإذا تغيّرت بعد العرض، ألغِ الموافقة واطلب قرارًا جديدًا.

تميّز وثائق أمان Google Cloud MCP بين تشغيل يوافق فيه الإنسان على كل فعل وتشغيل يتصرف فيه الوكيل منفردًا؛ وفي الحالة الثانية تعتمد الحماية بالكامل على برمجة الوكيل، مع بقاء التعرض لحقن التعليمات وتسلسل الأدوات غير الآمن. أما الموافقة البشرية فتقلل الخطر لكنها لا تلغيه إذا كان العرض مبهمًا أو اعتمد المستخدم اقتراح الوكيل بلا تحقق.

10: اربط الاستمرار بسجل قابل للتحقيق واختبارات متكررة

10. سجّل القرار والتنفيذ من دون تسجيل الأسرار. احتفظ بهوية المستخدم والوكيل والخادم، واسم الأداة وإصدار تعريفها، ووقت الطلب ومعرف الارتباط، ونتائج التفويض والموافقة والتنفيذ. أنشئ تنبيهات عند استدعاء أداة جديدة، أو تكرار الرفض، أو طلب امتياز مرتفع، أو انتقال بيانات غير متوقع بين خادمين.

قبل النشر، اختبر رمزًا منتهيًا ورمزًا مخصصًا لخدمة أخرى، ومحاولة عبور المستأجرين، وتغيير تعريف أداة بعد اعتماده، وإعادة إرسال طلب حساس، ومسار ملف ملتف، ورابطًا إلى عنوان داخلي، وتسلسلًا يبدأ بالقراءة وينتهي بالإرسال. أعد الاختبارات بعد تحديث الخادم أو العميل أو أدوات الوكيل، وراجع الصلاحيات كلما أضيفت أداة أو وجهة جديدة.

يصبح الاتصال مقبول المخاطر عندما تستطيع إثبات أن سقوط طبقة واحدة لا يمنح المهاجم السر أو الإجراء النهائي: الرمز محدود ومربوط بجمهوره، والخادم معزول، والمدخل والمخرج مفحوصان، والفعل الحساس متوقف على موافقة مرتبطة بمعلماته، والمحاولات قابلة للتتبع.