الانتقال إلى المحتوى الرئيسي
خادم MCP المسجّل يُعلِن عن أي أدوات يريد — وسيستدعي وكيل بكل سرور أياً منها. الوضعية الآمنة هي العكس: قرّر القائمة القصيرة للأدوات التي تحتاجها فعلاً، واسمح بتلك بالضبط، وامنع البقية. ذلك هو قائمة السماح، وعلى OrcaRouter تبنيها من قواعد tool_name_glob تُقيَّم على سطح mcp. كل tools/call يعبر بوابة MCP يمرّ عبر سياسة جدار الحماية الخاصة بك قبل أن يصل إلى الخادم الحقيقي. فقائمة السماح ليست استشارية — استدعاء أداة لم تسمح بها لا يُرسَل أبداً.
تحرير السياسة إجراء وحدة التحكم. مسارات /api/workspace/firewall/* تصادق برمز جلستك / وصولك، وليس بمفتاح ترحيل sk-orca-…. كتابة القواعد تتطلب دور Developer+؛ ويستطيع أي عضو مساحة عمل (وصولاً إلى Viewer) قراءة السياسات وتغذية الأدوات المكتشَفة.

​
1. لماذا قائمة سماح بمنع افتراضي لأدوات mcp آمنة

قائمة المنع — “احجب الأدوات الخطيرة” — تفشل في اللحظة التي يضيف فيها خادم أداة جديدة، أو يعيد تسمية واحدة، أو توصّل خادماً ثانياً. مجموعة الأدوات الخطيرة مفتوحة الطرف؛ والمجموعة التي قصدت استخدامها صغيرة ومعروفة. قائمة السماح تعكس الافتراضي بحيث يُرفض المجهول، لا يُقبَل:
  • الأدوات الجديدة ممنوعة افتراضياً. الخادم الذي ينمّي أداة delete_repo بعد توصيلك له لا يمكن استدعاؤها حتى تضيفها إلى قائمة السماح.
  • النطاق لكل خادم. مساحة الأسماء <server>.<tool> تتيح لك السماح بـ github.create_issue بينما تمنع كل شيء آخر تحت github.*.
  • نقطة اختناق واحدة. نفس السياسة تحوكم الخادم المُرفَق وكل خادم خاص خلف البوابة، فهناك مكان واحد لقراءة قائمة السماح.
قائمة السماح تقترن طبيعياً مع وضع المراقبة: شغّله أولاً، ودع الحركة الحقيقية تملأ تغذية الأدوات المكتشَفة، ثم رقِّ الأدوات التي تراها إلى قواعد سماح صريحة واقلب الافتراضي إلى منع.

​
2. القطعتان

قائمة السماح هي default_verdict إضافة إلى مجموعة قواعد مرتّبة.

default_verdict: deny

احتياطي السياسة لأي tools/call لا تطابقه قاعدة. اضبطه على deny ويُحجَب كل شيء لم تسمح به صراحةً. (يقبل أيضاً allow وaudit — audit هو الافتراضي.)

قواعد allow

قاعدة واحدة لكل أداة (أو لكل glob). كل واحدة تحمل tool_name_glob وحكم allow. tools/call يطابق الـ glob يتحلّل إلى allow ويُرسَل؛ وكل شيء آخر يقع إلى افتراضي المنع.
يُطابَق الـ glob مقابل اسم الأداة ذي مساحة الأسماء — github.create_issue، وshell.exec. * يطابق أي أداة (استخدمه باعتدال؛ قاعدة سماح بـ* تُلغي قائمة السماح كلها). بادئة <server>. تحدّد نطاق الـ glob لخادم واحد.

​
3. مثال ملموس واحد

وصّلت خادم github وتريد فقط أن يقرأ الوكلاء ويفتحوا المشكلات — دون حذف أو إدارة أي شيء أبداً. في وحدة التحكم، افتح Firewall → Policies، واضبط الحكم الافتراضي للسياسة على deny، وأضِف قاعدتَي سماح:
الترتيبtool_name_globالحكم
1github.create_issueallow
2github.list_issuesallow
تلك هي قائمة السماح كلها. مع الافتراضي عند deny:
  • github.create_issue → يطابق القاعدة 1 → allow، يُرسَل.
  • github.delete_repo → لا يطابق شيئاً → deny افتراضياً.
استدعاء MCP الممنوع يعود إلى النموذج كـخطأ أداة (firewall deny: …) — نفس الشكل الذي تعيده أي أداة فاشلة — فيستطيع الوكيل التكيّف بدلاً من الانهيار. (على السطح الوارد، المنع بدلاً من ذلك HTTP 400 برمز خطأ firewall_blocked.)
القواعد مرتّبة وتُقيَّم من الأعلى للأسفل. لا تضع tool_name_glob: github.* سماح عريضاً فوق قواعد المنع المحددة — أول تطابق يفوز والحرف البدل سيقبل الأدوات نفسها التي قصدت استثناءها. عند الشك، أبقِ قائمة السماح ضيّقة واتّكئ على افتراضي المنع بدلاً من الأحرف البدلية.

​
4. التشديد بالوسائط

اسم أداة على قائمة السماح لا يزال يمكن استدعاؤه بوسائط سيئة. ضيّق أكثر بإضافة جملة args_match (JSONPath + عامل مثل eq، أو contains، أو regex، أو in، أو cidr_match) إلى القاعدة، أو بطبقة قاعدة deny فوق السماح لشكل وسيط محدد — مثلاً، اسمح بـgithub.create_issue لكن deny عندما لا يكون المستودع الهدف على قائمة معتمَدة. انظر مرجع قواعد جدار الحماية لمجموعة العوامل الكاملة.
sanitize ينقّح وسائط استدعاء أداة قبل التمرير — لا يلمس أبداً ما تعيده أداة. لتقليم المحتوى المُعاد، ذلك ضابط مختلف؛ انظر تنظيف مخرجات الأداة.

​
5. اطرحها بأمان

اقلب منعاً افتراضياً لخادم كامل في الإنتاج وتخاطر بكسر وكيل اعتمد بهدوء على أداة نسيتها. إعدادان يقلّلان المخاطرة:
علم لكل سياسة يخفّض الأحكام الفارضة إلى audit. افتراضي منعك وقواعد منعك تسجّل [shadow] would deny … بدلاً من الحجب، فتستطيع التحقق من قائمة السماح مقابل الحركة الحقيقية قبل أن تعضّ. اقرأ أكثر في أوضاع الفرض.
إعداد مساحة عمل يسجّل كل استدعاء غير مغطّى كفجوة في تغذية الأدوات المكتشَفة. شغّله قبل كتابة قائمة السماح لتعلّم بالضبط أي الأدوات يستدعيها وكلاؤك، ثم رقِّ كلاً منها إلى قاعدة سماح صريحة.
بمجرد أن يصير سجل الظل نظيفاً — ما كان أي استدعاء مشروع ليُمنَع — امسح shadow_mode وتفرض قائمة السماح.

​
6. تحقّق من أنها تعمل

بعد الفرض، أكّد أن الأدوات الممنوعة تُرفَض فعلاً:
  • شغّل تجريبياً tools/call مقابل السياسة (Developer+) لرؤية الحكم وأي قاعدة — أو الافتراضي — أنتجته، دون إرسال حركة حقيقية. مرِّر اسم أداة، وسطحاً، ووسائط عيّنة؛ يقيّمها المحرك ويعيد أثر الحكم دون تسجيل حدث.
  • راقب الأحداث. كل استدعاء محجوب يسجّل حدث جدار حماية يستطيع Developer+ قراءته في وحدة التحكم؛ صفحة أحداث التدقيق تغطي التغذية وحقولها.
تفضّل عدم تأليف كل قاعدة يدوياً؟ مُعَدّ الاستقلالية tight يكتب سياسة منع افتراضي لك (إضافة إلى قواعد منع لأدوات shell المدمّرة وأسماء أدوات بشكل جلب)، ثم تضيف الأدوات المحددة التي تحتاجها. انظر أوضاع الفرض لما يثبّته كل مستوى استقلالية.

​
ذات صلة

توصيل خادم MCP

سجّل خادماً قبل أن تتمكن من وضع قائمة سماح لأدواته.

جدار الحماية: خوادم MCP

سلوك البوابة وقت التشغيل والأحكام لكل استدعاء.

مرجع قواعد جدار الحماية

لغة القواعد الكاملة — الـ globs، وargs_match، والخروج، وsanitize.

استدعاءات الأدوات الخطيرة

التهديد الذي بُنيت قائمة السماح لاحتوائه.

حدود الخروج

حوكِم أين يجوز لأداة مسموح بها الوصول.

حواجز الحماية مقابل جدار الحماية

متى تلجأ إلى سياسة المحتوى مقابل سياسة الأداة.