بازگشت به وبلاگ Webship

مهندسی Webship

اتصال ایمن عوامل هوش مصنوعی به سرور MCP در Webship

راه‌اندازی صفحه کنترل جدا شده MCP برای Webship با TLS 1.3، یک توکن حامل قوی، اتصال لوپ‌بک، تونل SSH، اعتبارسنجی پیکربندی، و فهرست بررسی عملی پاسخ به حادثه.

# اتصال امن عامل‌های هوش مصنوعی به WebshipِMCP سرور

یکMCP اتصال به یک سرور وب یک ویجت چت نیست. این یک رابط عملیاتی است که می‌تواند وضعیت تولید را بررسی کند، سیاست مسیر‌یابی و امنیت را تغییر دهد، گواهی‌ها را مجدداً بارگذاری کند، نسخه‌های ایستا را فعال کند، تغییرات ناوگان را هماهنگ کند و یک برنامه امضا شده را نصب کند.Webship به‌روزرسانی.

با آن مطابق عمل کنید: به عنوان یک API مدیریتی ممتاز. ایمن‌ترینWebship راه‌اندازی نگه می‌داردMCP گوش‌دهنده از صفحه داده عمومی، آن را به حلقه بازمی‌گرداند، با ... محافظت می‌کند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، نه یک آدرس LAN عمومی یا خصوصی.
  2. هویت حمل و نقل: مشتری یک گواهی صادرشده توسط یک CA که به آن اعتماد دارد را تأیید می‌کند.
  3. احراز هویت برنامه: هر درخواست یک توکن معتبر قوی دارد.
  4. دسترسی مدیریتی: اپراتورها از طریق یک حساب SSH احراز هویت شده و تونل به شنونده لوپ‌بک دسترسی پیدا می‌کنند.

هیچ یک از این کنترل‌ها جایگزین دیگری نمی‌شود. TLS بدون مسیر شبکه خصوصی همچنان سطح احراز هویت را در معرض قرار می‌دهد. تونل بدون تایید گواهی، هویت نقطه پایانی را مبهم می‌کند. یک توکن حامل در یک فایل قابل خواندن توسط دنیا، یک راز نیست.

گواهی و توکن را آماده کنید

صدور یک اختصاصیMCP گواهی از CA داخلی شما. برای تونلی که در زیر نشان داده شده است، شامل کنیدlocalhost و127.0.0.1 در نام‌های جایگزین موضوع گواهی، سپس CA صادرکننده را نصب کنید درMCP فهرست اعتماد دستگاه مشتری. خطای اعتماد را با گزینه TLS ناامن حل نکنید.

یک توکن منحصر به فرد با حداقل ۳۲ بایت قابل چاپ ASCII و بدون فاصله ایجاد کنید. یک مقدار تصادفی ۳۲ بایتی که به صورت هگزادسیمال رمزگذاری شده باشد، ۶۴ کاراکتر ایمن به شما می‌دهد:

umask 077
openssl rand -hex 32

Webship فعلاً به‌صورتMCP توکن مستقیماً از محافظت‌شدهTOML پیکربندیtoken_file پشتیبانی نمی‌شود. نتیجه را در یک فایل پیکربندی ذخیره کنید که فقط توسط Webship حساب سرویس و گروه مدیریتی آن. توکن را در یک واحد systemd، تاریخچه شل، بلیط، پیام چت یا درخواست ارسالی به یک مدل هوش مصنوعی قرار ندهید.

در یک میزبان معمولی دبیان:

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'

پورت ۹۴۴۳ را به قوانین فایروال عمومی میزبان اضافه نکنید. مرحله بعدی از طریق 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—نه مدل—باید هدر مجوز را الصاق کند. هرگز توکن زنده را در یک مکالمه جای‌گذاری نکنید.

تأیید گواهی را فعال نگه دارید. اگر کلاینت گواهی را قبول نکند، نام‌های جایگزین موضوع گواهی را تعمیر کنید یا CA داخلی صحیح را نصب کنید. از اضافه کردن یک گذرگاه دائمی خودداری کنید.

جلسه اول فقط برای خواندن باشد

پس از اتصال تونل و مشتری، با کشف و بازرسی شروع کنید:

  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 Shield، چالش بات، سیاست تأیید هویت لبه، یا لایه هدر پاسخ را خاموش کند. Listener، پروتکل، worker، زمان اجرا و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 ۱.۳.۱ مستندات اپراتور، نمونه‌های پیکربندی ارائه شده،MCP کد اعتبارسنجی و حمل و نقل، محافظ‌های پیکربندی زمان اجرا و فهرست ابزار. بررسی فعلی Webship مستندسازی و سرور در حال اجرا tools/list پاسخ قبل از اعمال آن به نسخه دیگر.