วิศวกรรม Webship

เชื่อมต่อเอเย่นต์ AI อย่างปลอดภัยกับเซิร์ฟเวอร์ MCP ของ Webship

ตั้งค่าแผนควบคุม MCP ที่แยกออกของ Webship ด้วย TLS 1.3 โทเค็นผู้ถือที่แข็งแรง การผูก loopback ช่องทาง SSH การตรวจสอบการกำหนดค่า และรายการตรวจสอบการตอบสนองต่อเหตุการณ์ที่ใช้ได้จริง

เผยแพร่ 10 กันยายน 2569

# เชื่อมต่อเอเย่นต์ AI อย่างปลอดภัยกับเซิร์ฟเวอร์ MCP ของ Webship

การเชื่อมต่อ MCP กับเว็บเซิร์ฟเวอร์ไม่ใช่วิดเจ็ตแชท มันคืออินเทอร์เฟซการดำเนินงานที่สามารถตรวจสอบสถานะการผลิต เปลี่ยนเส้นทางและนโยบายความปลอดภัย โหลดใบรับรองใหม่ เปิดใช้งานการปล่อยซอฟต์แวร์แบบสถิต ประสานงานการเปลี่ยนแปลงฝูง และติดตั้งการอัปเดต Webship ที่ลงนามแล้ว

ปฏิบัติตามอย่างเหมาะสม: ในฐานะ API การจัดการที่มีสิทธิพิเศษ การตั้งค่า Webship ที่ปลอดภัยที่สุดคือ การเก็บตัวฟัง MCP ไว้นอกโพรแกรมข้อมูลสาธารณะ ผูกมันกับ loopback ปกป้องมันด้วย TLS 1.3 และ token ผู้ถือที่แข็งแรง และเข้าถึงมันผ่านอุโมงค์ SSH ที่ได้รับการยืนยันตัวตน

คู่มือนี้สร้างการตั้งค่านั้น อธิบายว่าทำไมแต่ละขอบเขตถึงมีอยู่ และให้รายการตรวจสอบสำหรับการใช้งานโดยไม่ให้ความสะดวกกลายเป็นความเสี่ยง

เริ่มต้นด้วยขอบเขตความเชื่อถือ

ทราฟฟิกสาธารณะของ Webship และทราฟฟิกของ MCP ใช้ตัวฟังแยกจากกัน ระดับการควบคุม MCP ถูกปิดใช้งานโดยค่าเริ่มต้นและไม่เคยแชร์ตัวฟัง HTTP ปกติ, HTTP/2, HTTP/3, หรือ WebTransport เมื่อเปิดใช้งาน มันให้บริการ MCP ผ่านจุดติดต่อ TLS 1.3 HTTP/1.1 ที่เฉพาะเจาะจง

การปรับใช้ที่ปลอดภัยมีการควบคุมอิสระสี่ประการ:

การเข้าถึงเครือข่าย: ตัวฟัง MCP ผูกกับ 127.0.0.1 ไม่ใช่ที่อยู่สาธารณะหรือ LAN ส่วนตัว
เอกลักษณ์การขนส่ง: ลูกค้าจะตรวจสอบใบรับรองที่ออกโดย CA ที่เชื่อถือ
การตรวจสอบสิทธิ์แอปพลิเคชัน: ทุกคำขอมีโทเค็นผู้ถือที่แข็งแรงหนึ่งรายการ
สิทธิ์เข้าถึงระดับผู้ดูแลระบบ: ผู้ปฏิบัติงานเข้าถึงตัวฟัง loopback ผ่านบัญชี SSH ที่ได้รับการตรวจสอบสิทธิ์และช่องทางเชื่อมต่อ.

ไม่มีการควบคุมเหล่านี้ที่สามารถแทนที่การควบคุมอื่นได้ TLS โดยไม่มีเส้นทางเครือข่ายส่วนตัวยังคงเปิดเผยพื้นผิวการตรวจสอบสิทธิ์ อุโมงค์โดยไม่มีการตรวจสอบใบรับรองทำให้เอกลักษณ์ของปลายทางไม่ชัดเจน โทเค็นแบบผู้ถือที่อยู่ในไฟล์ที่เปิดอ่านได้ทั่วโลกไม่ใช่ความลับ

เตรียมใบรับรองและโทเค็น

ออกใบรับรอง MCP โดยเฉพาะจาก CA ภายในของคุณ สำหรับท่อข้อมูลที่แสดงด้านล่าง ให้รวม localhost และ 127.0.0.1 ในชื่อทางเลือกของหัวเรื่องของใบรับรอง จากนั้นติดตั้ง CA ที่ออกใบรับรองในคลังความน่าเชื่อถือของเครื่องไคลเอนต์ MCP อย่าแก้ไขข้อผิดพลาดความน่าเชื่อถือด้วยตัวเลือก TLS ที่ไม่ปลอดภัย

สร้างโทเค็นเฉพาะตัวที่มีอย่างน้อย 32 ไบต์ ASCII ที่พิมพ์ได้และไม่มีช่องว่าง ค่าที่สุ่ม 32 ไบต์และเข้ารหัสเป็นเลขฐานสิบหกจะให้ตัวอักษรที่ปลอดภัย 64 ตัว:

umask 077
openssl rand -hex 32

Webship กำลังอ่านโทเค็น MCP โดยตรงจากการตั้งค่า TOML ที่ได้รับการป้องกัน; token_file ไม่ได้รับการสนับสนุน เก็บผลลัพธ์ในไฟล์การตั้งค่าที่อ่านได้เฉพาะบัญชีบริการ Webship และกลุ่มผู้ดูแลระบบของมันเท่านั้น ห้ามวางโทเค็นในยูนิต systemd, ประวัติ shell, ตั๋ว, ข้อความแชท หรือพรอมต์ที่ส่งไปยังโมเดล AI

บนโฮสต์ Debian ทั่วไป:

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 ที่ว่างจะไม่เปิด endpoint ลูกค้า loopback ยังคงได้รับอนุญาตโดยค่าเริ่มต้น expose_remote = false ทำให้ขอบเขตที่ตั้งใจไว้ชัดเจน: หากมีคนเปลี่ยน listen เป็นที่อยู่ที่ไม่ใช่ loopback ในภายหลัง, Webship จะปฏิเสธการกำหนดค่านี้แทนที่จะเผยแพร่ control plane โดยไม่แจ้งให้ทราบ

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

สร้างอุโมงค์ส่วนตัว

จากเวิร์กสเตชันผู้ดูแลระบบ ส่งต่อพอร์ตท้องถิ่นไปยังตัวฟัง loopback ของ 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 บน loopback การปิดเซสชัน SSH จะลบเส้นทางนั้นทันที

ใช้การยืนยันตัวตน SSH แบบใช้คีย์ จำกัดผู้ดูแลระบบที่สามารถเปิดอุโมงค์ และใช้การควบคุมการเข้าถึงโฮสต์ตามปกติของคุณ หากต้องใช้โฮสต์กระโดด ให้เก็บตัวฟัง MCP ไว้บนอินเทอร์เฟซ loopback ของโฮสต์ Webship และขยายเส้นทาง SSH แทนที่จะขยายตัวฟัง

กำหนดค่าลูกค้า MCP

รูปแบบการกำหนดค่าของลูกค้าแตกต่างกัน แต่รายการ HTTP MCP แบบทั่วไปมีลักษณะดังนี้:

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

ใช้กลไกความลับที่ได้รับการป้องกันของลูกค้าเมื่อมี หากไม่มี ให้จำกัดการกำหนดค่าลูกค้าไปยังบัญชีระบบปฏิบัติการปัจจุบัน ตัวไคลเอนต์ HTTP—not the model—ควรแนบหัวข้อการอนุญาต อย่าเคยวางโทเค็นที่ใช้งานอยู่ลงในการสนทนา

ให้เปิดใช้งานการตรวจสอบใบรับรองอยู่เสมอ หากไคลเอนต์ปฏิเสธใบรับรอง ให้ซ่อมชื่อทดแทนของใบรับรองหรือ ติดตั้ง CA ภายในที่ถูกต้อง อย่าเพิ่มการข้ามแบบถาวร

ทำให้เซสชันแรกเป็นแบบอ่านอย่างเดียว

หลังจากอุโมงค์และลูกค้าถูกเชื่อมต่อแล้ว ให้เริ่มด้วยการค้นหาและตรวจสอบ:

ขอ tools/list; การตอบกลับของมันคือโครงร่างข้อโต้แย้งที่เป็นทางการสำหรับเวอร์ชันที่กำลังใช้งานอยู่
เรียก webship.get_config และบันทึกเวอร์ชันการกำหนดค่าปัจจุบัน
ตรวจสอบ webship.reverse_proxy.get_status, webship.security.get_status, webship.ddos.get_status และ webship.tls.get_status ตามความเหมาะสม
ใช้ webship.policy.explain หรือ webship.security.simulate ก่อนเปลี่ยนแปลงนโยบาย
ยืนยันว่าการกำหนดค่าที่ส่งกลับจะลบข้อมูลโทเค็นผู้ถือ

จากนั้นเท่านั้นให้ทดสอบการกลายพันธุ์ในสภาพแวดล้อมที่ไม่ใช่การผลิต การกลายพันธุ์การกำหนดค่า Webship ต้องใช้รหัสเวอร์ชันปัจจุบัน การเขียนที่ล้าสมัยจะถูกปฏิเสธแทนการเขียนทับการเปลี่ยนแปลงใหม่ นโยบายตัวอย่างสามารถตรวจสอบได้ด้วยการตรวจสอบแบบเงาและสถานการณ์ห้องปฏิบัติการการจราจรก่อนการเปิดใช้งาน

Webship ปฏิเสธการลดระดับความปลอดภัยสดที่เลือกแล้วด้วยเช่นกัน คำขอ MCP ไม่สามารถปิด WAF, ชั้น DDoS, API Shield, การท้าทายบอท, นโยบาย edge-auth หรือชั้น response-header ที่กำลังทำงานอยู่ได้ การเปลี่ยนแปลง listener, โปรโตคอล, worker, runtime และ MCP-authentication ที่ผูกกับกระบวนการต้องมีการรีสตาร์ทอย่างรอบคอบ

เจ้าหน้าที่รักษาความปลอดภัยเหล่านั้นช่วยลดความผิดพลาด; พวกเขาไม่ได้ทำให้การกระทำที่ได้รับอนุญาตทุกอย่างไม่เป็นอันตราย โทเค็นให้พื้นผิวการควบคุมที่มีประสิทธิภาพ รวมถึงการอัปเดตและการปล่อยการทำงาน ตรวจสอบการเรียกเครื่องมือที่เสนออย่างตรงไปตรงมาเหมือนกับที่คุณตรวจสอบคำสั่งเชลล์ของผู้ดูแลระบบ

หากการผูกระยะไกลหลีกเลี่ยงไม่ได้

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 tunnel แก้ไขได้พอดี

ควบคุมแผงควบคุมอย่างรอบคอบ

ใช้รายการตรวจสอบนี้สำหรับการผลิต:

เก็บ MCP ไว้ในสถานะปิดใช้งานเมื่อไม่มีตัวแทนหรืิอผู้ปฏิบัติงานใดต้องการมัน
เชื่อมต่อกับ loopback และใช้ SSH tunnel เป็นค่าเริ่มต้น
ใช้ตัวตน TLS เฉพาะและเปิดใช้งานการตรวจสอบใบรับรองไว้
สร้างโทเค็นผู้ถือเอกลักษณ์สำหรับแต่ละสภาพแวดล้อม Webship
ปกป้อง TOML, การกำหนดค่าลูกค้า, กุญแจ TLS, และกุญแจ SSH ด้วยสิทธิ์ไฟล์ระบบ
แยกข้อมูลประจำตัวสำหรับการพัฒนา การทดสอบ และการผลิต
เริ่มเซสชันด้วยเครื่องมือจำลองสถานะและนโยบายก่อนการเปลี่ยนแปลง
เก็บรักษาและตรวจสอบเหตุการณ์ตรวจสอบความปลอดภัยของ Webship
หมุนโทเค็นและรีสตาร์ท Webship หลังสงสัยว่ามีการสัมผัส
ปิดอุโมงค์เมื่อเซสชันผู้ดูแลระบบสิ้นสุดลง

สำหรับการตอบสนองต่อเหตุการณ์ ให้ปิดอุโมงค์ที่กำลังใช้งานอยู่ จำกัดบัญชี SSH แทนที่โทเค็น MCP ใน TOML ที่ได้รับการป้องกัน รีสตาร์ท Webship และตรวจสอบบันทึกการตรวจสอบความปลอดภัยล่าสุดและเวอร์ชันการกำหนดค่า หากคีย์ส่วนตัว TLS อาจถูกเปิดเผย ให้ออกใบรับรองและคีย์ใหม่เป็นส่วนหนึ่งของการรีสตาร์ทเดียวกัน ทดสอบโทเค็นเก่าหลังจากนั้นและยืนยันว่าถูกปฏิเสธแล้ว

ระนาบควบคุมควรคงเป็นระนาบควบคุม

MCP มีประโยชน์เพราะตัวแทนสามารถตรวจสอบสถานะจริงและนำการเปลี่ยนแปลงที่ได้รับการยืนยันมาใช้โดยไม่ต้องส่งการดำเนินการเหล่านั้นผ่านเส้นทางคำขอสาธารณะ แต่ข้อได้เปรียบนั้นจะหายไปหากตัวฟังการควบคุมกลายเป็นจุดเชื่อมต่ออินเทอร์เน็ตอีกจุดหนึ่ง

รักษาขอบเขตให้เรียบง่าย: ตัวฟังแยกต่างหาก, การเข้าถึงแบบ loopback, TLS ที่ตรวจสอบแล้ว, ข้อมูลประจำตัวของผู้ถือที่ป้องกันหนึ่งรายการ, ช่องทางที่ตรวจสอบแล้ว, การเปลี่ยนแปลงที่ตรวจสอบเวอร์ชัน, และกระบวนการตรวจสอบโดยมนุษย์สำหรับการดำเนินการที่มีอำนาจ Webship จัดให้มีโปรโตคอลและมาตรการป้องกันความปลอดภัย; ผู้ปฏิบัติการตัดสินใจว่าใครสามารถเข้าถึงได้

คู่มือนี้อิงตามเอกสารผู้ปฏิบัติงาน Webship 1.3.1 ตัวอย่างการกำหนดค่าที่จัดส่ง MCP โค้ดการตรวจสอบและการขนส่ง การป้องกันการกำหนดค่าเวลารัน และแคตตาล็อกเครื่องมือ โปรดทบทวน เอกสารWebship ปัจจุบันและการตอบสนอง tools/list ของเซิร์ฟเวอร์ที่กำลังทำงานก่อนนำไปใช้กับเวอร์ชันอื่น