ربط وكلاء الذكاء الاصطناعي بأمان بخادم MCP الخاص بـ Webship

# ربط وكلاء الذكاء الاصطناعي بأمان بخادم MCP الخاص بـ Webship

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

تعامل معه وفقًا لذلك: باعتباره واجهة برمجة تطبيقات إدارية مميزة. أفضل إعداد Webship يحافظ على مستمع MCP بعيدًا عن مستوى البيانات العامة، ويربطه بـ loopback، ويحميه باستخدام TLS 1.3 ورمز حامل قوي، ويتم الوصول إليه من خلال نفق SSH مصادق عليه.

يبني هذا الدليل ذلك الإعداد، ويشرح سبب وجود كل حد، ويعطيك قائمة تحقق لتشغيله دون تحويل الراحة إلى انكشاف.

ابدأ بحدود الثقة

يستخدم المرور العام لـ Webship ومرور MCP مستمعين منفصلين. يتم تعطيل مستوى التحكم MCP بشكل افتراضي ولا يشارك أبدًا مستمع HTTP العادي، HTTP/2، HTTP/3، أو WebTransport. عند التمكين، يقوم بخدمة MCP عبر نقطة نهاية TLS 1.3 HTTP/1.1 مخصصة.

يشمل النشر الآمن أربعة ضوابط مستقلة:

1. قابلية الوصول إلى الشبكة: مستمع MCP يرتبط بـ 127.0.0.1، وليس بعنوان عام أو عنوان شبكة محلية خاصة.
2. هوية النقل: يتحقق العميل من شهادة صادرة عن سلطة مصادقة يثق بها.
3. مصادقة التطبيق: كل طلب يحمل رمز حامِل قوي واحد.
4. الوصول الإداري: يصل المشغلون إلى مستمع الارتداد من خلال حساب SSH مصادق ونفق.

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

أعد الشهادة والرمز

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

أنشئ رمزًا فريدًا يحتوي على 32 بايتًا على الأقل من رموز ASCII القابلة للطباعة وبدون فراغات. يعطيك قيمة عشوائية بطول 32 بايت مشفرة كسداسية عشرية 64 حرفًا آمنًا:

umask 077
openssl rand -hex 32

Webship يقرأ حاليًا الرمز MCP مباشرة من تكوين TOML المحمي؛ token_file غير مدعوم. قم بتخزين النتيجة في ملف تكوين يمكن قراءته فقط بواسطة حساب خدمة Webship ومجموعته الإدارية. لا تضع الرمز في وحدة systemd أو سجل الأوامر shell أو تذكرة أو رسالة دردشة أو موجه يُرسل إلى نموذج ذكاء اصطناعي.

على مضيف ديبيان نموذجي:

sudo chown root:webship /etc/webship/production.toml
sudo chmod 0640 /etc/webship/production.toml
sudo chown root:webship /etc/webship/mcp-cert.pem /etc/webship/mcp-key.pem
sudo chmod 0644 /etc/webship/mcp-cert.pem
sudo chmod 0640 /etc/webship/mcp-key.pem

قم بتكييف مستخدم الخدمة والمجموعة مع التثبيت الخاص بك. يجب أن تكون المفتاح الخاص والتكوين قابلين للقراءة بواسطة Webship، لكن ليس بواسطة الحسابات غير ذات الصلة.

تمكين المستمع المعزول

أضف هذا القسم إلى تكوين Webship النشط:

[security.mcp]
enabled = true
listen = "127.0.0.1:9443"
token = "replace-with-your-generated-64-character-token"
allowed_ips = []
expose_remote = false

[security.mcp.tls]
cert = "/etc/webship/mcp-cert.pem"
key = "/etc/webship/mcp-key.pem"

قائمة allowed_ips الفارغة لا تفتح نقطة نهاية. يظل العملاء المحليون مسموحًا لهم افتراضيًا. expose_remote = false يجعل الحدود المقصودة واضحة: إذا قام شخص ما لاحقًا بتغيير listen إلى عنوان غير محلي، فإن Webship يرفض التكوين بدلاً من نشر طائرة التحكم بصمت.

Webship يرفض أيضًا مستمع MCP مفعل بدون TLS، بدون رمز، برمز قصير أو يحتوي على فراغات، أو بمسارات شهادة فارغة. يتم رفض الرموز النائبة العامة قبل التعرض عن بُعد.

تحقق قبل إعادة التشغيل

يقوم مستمع MCP وهوية TLS والتغييرات في الرموز بإعادة بناء لوحة التحكم، لذا فهي تتطلب إعادة تشغيل العملية. تحقق من التكوين الكامل أولاً:

/usr/local/bin/webship --check-config --config /etc/webship/production.toml
sudo systemctl restart webship
sudo systemctl status webship --no-pager

تأكيد أن المستمع موجود فقط على واجهة العودة المحليّة:

ss -ltn | grep '127.0.0.1:9443'

لا تضف المنفذ 9443 إلى قواعد جدار الحماية العامة للمضيف. الخطوة التالية تصل إليه عبر SSH.

أنشئ النفق الخاص

من محطة عمل المسؤول، قم بتحويل منفذ محلي إلى مستمع الحلقة الداخلية لـ Webship:

ssh -N \
  -L 127.0.0.1:19443:127.0.0.1:9443 \
  webship-admin@edge.example.com

العميل MCP يتصل الآن بـ https://localhost:19443/mcp. تصل TCP إلى خادم SSH، وSSH ينقل الاتصال إلى المضيف، ويفتح المضيف الاتصال النهائي بـ Webship على الحلقة الرجعية. إغلاق جلسة SSH يزيل هذا المسار فورًا.

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

قم بتكوين العميل MCP

تختلف صيغ تكوين العميل، لكن إدخال HTTP MCP النموذجي يبدو هكذا:

{
  "mcpServers": {
    "webship-production": {
      "url": "https://localhost:19443/mcp",
      "headers": {
        "Authorization": "Bearer <your-token>"
      }
    }
  }
}

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

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

اجعل الجلسة الأولى للقراءة فقط

بعد أن يتم اتصال النفق والعميل، ابدأ بالاكتشاف والفحص:

1. اطلب tools/list; استجابته هي مخطط الحجج الموثوق للإصدار الجاري.
2. اتصل بـ webship.get_config وسجل نسخة التكوين الحالية.
3. افحص webship.reverse_proxy.get_status، webship.security.get_status، webship.ddos.get_status، و webship.tls.get_status حسب الاقتضاء.
4. استخدم webship.policy.explain أو webship.security.simulate قبل تغيير السياسة.
5. تأكيد أن التكوين المُعاد يحجب رموز الحامل.

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

Webship يرفض أيضًا تخفيضات الأمان الحية المحددة. لا يمكن لطلب MCP إيقاف WAF نشط، أو طبقة DDoS، أو درع API، أو تحدي الروبوت، أو سياسة المصادقة الطرفية، أو طبقة رؤوس الاستجابة. التغييرات المتعلقة بالمستمع المرتبط بالعملية، البروتوكول، العامل، وقت التشغيل، وMCP-المصادقة تتطلب إعادة تشغيل متعمدة.

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

إذا كان الربط عن بُعد لا مفر منه

يُوصى بالتصميم باستخدام Loopback بالإضافة إلى SSH. إذا كان بيئتك تتطلب مستمعًا لشبكة خاصة، اجعل الاستثناء واضحًا:

[security.mcp]
enabled = true
listen = "10.20.0.15:9443"
expose_remote = true
allowed_ips = ["10.20.10.0/24"]
token = "replace-with-your-generated-64-character-token"

احتفظ بالكتلة TLS من المثال السابق، واستخدم شهادة تتوافق مع اسم DNS الخاص، وفرض نفس نطاق المصدر في جدران الحماية للمضيف والشبكة. لا تستخدم أبدًا 0.0.0.0/0 أو ::/0 كقائمة سماح تسهيلية. تذكر أن قائمة السماح للتطبيق ترى عنوان المصدر الذي يصل فعليًا إلى Webship؛ تحقق من السلوك عند وجود موزع تحميل، أو بوابة NAT، أو شبكة خدمات أمامه.

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

تشغيل مستوى التحكم بوعي

استخدم قائمة التحقق هذه للإنتاج:

• احتفظ بـ MCP معطلاً حيث لا يحتاج أي وكيل أو مشغل إليه.
• الارتباط بالحلقة المحلية واستخدام نفق SSH بشكل افتراضي.
• استخدم هوية TLS مخصصة وحافظ على تمكين التحقق من الشهادة.
• قم بإنشاء رمز حامل فريد لكل بيئة Webship.
• احمِ TOML، وتكوين العميل، ومفتاح TLS، ومفاتيح SSH باستخدام أذونات نظام الملفات.
• فصل بيانات الاعتماد للتطوير والاختبار والإنتاج.
• ابدأ الجلسات باستخدام أدوات محاكاة الحالة والسياسة قبل الطفرات.
• الحفاظ على أحداث تدقيق الأمان الخاصة بـ Webship ومراجعتها.
• قم بتدوير الرمز وأعد تشغيل Webship بعد الاشتباه في التعرض.
• أغلق الأنفاق عند انتهاء الجلسة الإدارية.

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

يجب أن تظل طبقة التحكم طبقة تحكم

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

احتفظ بالحدود بسيطة: مستمع منفصل، إمكانية الوصول عبر الحلقة العكسية، TLS مُتحقق منه، اعتماد ناقل واحد محمي، نفق مصادق عليه، تغييرات تم التحقق من الإصدار لها، وعملية مراجعة بشرية للعمليات القوية. Webship يوفر البروتوكول وحواجز الأمان؛ يقرر المشغل من يمكنه الوصول إليها.

هذا الدليل يستند إلى وثائق المشغل Webship 1.3.1، وأمثلة التهيئة المرفقة، وكود التحقق والنقل MCP، وحراس تهيئة وقت التشغيل، وفهرس الأدوات. راجع الوثائق الحالية Webship documentation واستجابة tools/list للخادم العامل قبل تطبيقه على إصدار آخر.