Kỹ thuật Webship

Kết nối các tác nhân AI một cách an toàn với Máy chủ MCP của Webship

Thiết lập mặt phẳng kiểm soát MCP tách biệt của Webship với TLS 1.3, một token người mang mạnh, liên kết loopback, một đường hầm SSH, xác thực cấu hình và một danh sách kiểm tra ứng phó sự cố thực tế.

Được xuất bản ngày 10 tháng 9, 2026

# Kết nối an toàn các tác nhân AI với Máy chủ MCP của Webship

Một kết nối MCP đến máy chủ web không phải là một widget trò chuyện. Nó là một giao diện vận hành có thể kiểm tra trạng thái sản xuất, thay đổi chính sách định tuyến và bảo mật, tải lại chứng chỉ, kích hoạt các bản phát hành tĩnh, điều phối các thay đổi của đội ngũ và cài đặt bản cập nhật Webship đã ký.

Xử lý nó tương ứng: như một API hành chính đặc quyền. Cài đặt Webship an toàn nhất giữ cho trình lắng nghe MCP không hoạt động trên mạng dữ liệu công cộng, gắn nó vào loopback, bảo vệ nó bằng TLS 1.3 và một token bearer mạnh, và truy cập nó thông qua một kênh SSH đã xác thực.

Hướng dẫn này xây dựng cài đặt đó, giải thích lý do tại sao mỗi ranh giới tồn tại, và cung cấp cho bạn một danh sách kiểm tra để vận hành nó mà không biến sự tiện lợi thành rủi ro.

Bắt đầu với ranh giới tin cậy

Lưu lượng công cộng của Webship và lưu lượng của MCP sử dụng các trình lắng nghe riêng biệt. Bảng điều khiển MCP bị tắt theo mặc định và không bao giờ chia sẻ trình lắng nghe HTTP bình thường, HTTP/2, HTTP/3 hoặc WebTransport. Khi được bật, nó phục vụ MCP thông qua một điểm cuối TLS 1.3 HTTP/1.1 riêng biệt.

Một triển khai an toàn có bốn biện pháp kiểm soát độc lập:

Khả năng tiếp cận mạng: trình nghe MCP liên kết với 127.0.0.1, không phải địa chỉ công cộng hoặc LAN riêng.
Định danh vận chuyển: khách hàng xác minh một chứng chỉ do CA mà nó tin cậy phát hành.
Xác thực ứng dụng: mỗi yêu cầu đều mang theo một token bearer mạnh.
Quyền truy cập quản trị: các nhà điều hành kết nối với trình nghe loopback thông qua tài khoản SSH đã xác thực và tunnel.

Không kiểm soát nào trong số này thay thế được kiểm soát khác. TLS mà không có đường dẫn mạng riêng vẫn để lộ bề mặt xác thực. Một đường hầm mà không kiểm tra chứng chỉ làm cho danh tính điểm cuối trở nên mơ hồ. Một mã thông báo bearer trong một tập tin có thể đọc được công khai không phải là bí mật.

Chuẩn bị chứng chỉ và mã thông báo

Phát hành một chứng chỉ MCP chuyên dụng từ CA nội bộ của bạn. Đối với đường hầm được hiển thị bên dưới, bao gồm localhost và 127.0.0.1 trong tên thay thế chủ thể của chứng chỉ, sau đó cài đặt CA phát hành vào kho tin cậy của máy khách MCP. Không giải quyết lỗi tin cậy bằng tùy chọn TLS không an toàn.

Tạo một token duy nhất với ít nhất 32 byte ASCII có thể in được và không có khoảng trắng. Một giá trị ngẫu nhiên 32 byte được mã hóa dưới dạng thập lục phân sẽ cho bạn 64 ký tự an toàn:

umask 077
openssl rand -hex 32

Webship hiện đang đọc token MCP trực tiếp từ cấu hình TOML được bảo vệ; token_file không được hỗ trợ. Lưu kết quả vào một tệp cấu hình chỉ có thể đọc bởi tài khoản dịch vụ Webship và nhóm quản trị của nó. Không đặt token vào đơn vị systemd, lịch sử shell, vé, tin nhắn chat hoặc prompt gửi cho mô hình AI.

Trên một máy chủ Debian điển hình:

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

Điều chỉnh người dùng dịch vụ và nhóm cho cài đặt của bạn. Khóa riêng và cấu hình phải có thể đọc được bởi Webship, nhưng không được bởi các tài khoản không liên quan.

Bật chế độ nghe tách biệt

Thêm phần này vào cấu hình Webship đang hoạt động:

[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"

Một danh sách allowed_ips trống sẽ không mở điểm cuối. Các khách hàng loopback vẫn được phép theo mặc định. expose_remote = false làm ranh giới dự định trở nên rõ ràng: nếu ai đó sau này thay đổi listen thành một địa chỉ không phải loopback, Webship sẽ từ chối cấu hình thay vì công khai vô tình plane điều khiển.

Webship cũng từ chối một listener MCP đã bật mà không có TLS, không có token, có token ngắn hoặc chứa khoảng trắng, hoặc có đường dẫn chứng chỉ trống. Các token giữ chỗ công khai bị từ chối trước khi phơi bày từ xa.

Xác nhận trước khi khởi động lại

MCP listener, danh tính TLS và các thay đổi token sẽ xây dựng lại plane điều khiển, vì vậy chúng yêu cầu khởi động lại quy trình. Hãy xác thực cấu hình hoàn chỉnh trước:

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

Xác nhận rằng trình nghe chỉ tồn tại trên vòng lặp nội bộ:

ss -ltn | grep '127.0.0.1:9443'

Không thêm cổng 9443 vào các quy tắc tường lửa công cộng của máy chủ. Bước tiếp theo sẽ truy cập nó qua SSH.

Tạo đường hầm riêng

Từ trạm làm việc của quản trị viên, chuyển tiếp một cổng cục bộ đến trình nghe vòng lặp của Webship:

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

Khách hàng MCP hiện kết nối với https://localhost:19443/mcp. TCP kết nối đến máy chủ SSH, SSH truyền kết nối đến máy chủ, và máy chủ mở kết nối cuối cùng đến Webship trên loopback. Đóng phiên SSH sẽ loại bỏ đường dẫn đó ngay lập tức.

Sử dụng xác thực SSH dựa trên khóa, hạn chế những quản trị viên có thể mở đường hầm, và áp dụng các kiểm soát truy cập máy chủ thông thường của bạn. Nếu cần một máy chủ nhảy, hãy giữ trình lắng nghe MCP trên giao diện loopback của máy chủ Webship và mở rộng đường dẫn SSH thay vì mở rộng trình lắng nghe.

Cấu hình client MCP

Các định dạng cấu hình khách hàng khác nhau, nhưng một mục HTTP MCP điển hình trông như sau:

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

Sử dụng cơ chế bí mật được bảo vệ của khách hàng khi có. Nếu không, hãy giới hạn cấu hình khách hàng với tài khoản hệ điều hành hiện tại. Khách hàng HTTP — không phải mô hình — nên đính kèm tiêu đề ủy quyền. Không bao giờ dán token trực tiếp vào cuộc trò chuyện.

Giữ bật việc xác minh chứng chỉ. Nếu máy khách từ chối chứng chỉ, hãy sửa các tên thay thế của chủ thể trong chứng chỉ hoặc cài đặt CA nội bộ đúng. Không thêm cách bỏ qua vĩnh viễn.

Đặt phiên làm việc đầu tiên chỉ đọc

Sau khi đường hầm và khách hàng được kết nối, bắt đầu với việc khám phá và kiểm tra:

Yêu cầu tools/list; phản hồi của nó là sơ đồ lập luận chính thức cho phiên bản đang chạy.
Gọi webship.get_config và ghi lại phiên bản cấu hình hiện tại.
Kiểm tra webship.reverse_proxy.get_status, webship.security.get_status, webship.ddos.get_status và webship.tls.get_status nếu áp dụng.
Sử dụng webship.policy.explain hoặc webship.security.simulate trước khi thay đổi chính sách.
Xác nhận rằng cấu hình trả về đã che đi các token người mang.

Chỉ sau đó mới thử nghiệm một đột biến trong môi trường không phải sản xuất. Các đột biến cấu hình của Webship yêu cầu ID phiên bản hiện tại. Một lần ghi lỗi thời sẽ bị từ chối thay vì ghi đè một thay đổi mới hơn. Chính sách ứng viên có thể được kiểm tra bằng xác minh bóng và các kịch bản phòng thí nghiệm lưu lượng trước khi kích hoạt.

Webship cũng từ chối các hạ cấp bảo mật trực tiếp đã được chọn. Một yêu cầu MCP không thể tắt một WAF đang hoạt động, lớp DDoS, API Shield, thử thách bot, chính sách xác thực biên, hoặc lớp tiêu đề phản hồi. Thay đổi listener, giao thức, worker, runtime và xác thực MCP liên quan đến quy trình yêu cầu khởi động lại một cách có chủ ý.

Những vệ sĩ đó giảm thiểu sai sót; chúng không làm cho mọi hành động được ủy quyền trở nên vô hại. Mã thông báo cung cấp một bề mặt điều khiển mạnh mẽ, bao gồm các thao tác cập nhật và phát hành. Xem xét các lệnh gọi công cụ được đề xuất chính xác như cách bạn sẽ xem xét lệnh shell của quản trị viên.

Nếu việc liên kết từ xa là không thể tránh khỏi

Thiết kế được khuyến nghị là Loopback cộng với SSH. Nếu môi trường của bạn yêu cầu một trình nghe mạng riêng, hãy chỉ rõ ngoại lệ:

[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"

Giữ nguyên khối TLS từ ví dụ trước, sử dụng chứng chỉ phù hợp với tên DNS riêng, và thực thi cùng một phạm vi nguồn trên cả tường lửa máy chủ và mạng. Không bao giờ sử dụng 0.0.0.0/0 hoặc ::/0 như một danh sách cho phép thuận tiện. Hãy nhớ rằng một danh sách cho phép ứng dụng sẽ thấy địa chỉ nguồn thực sự đến Webship; kiểm tra hành vi khi một bộ cân bằng tải, cổng NAT hoặc service mesh đặt ở phía trước nó.

Tiếp xúc từ xa làm tăng giá trị của các nhật ký truy cập tập trung, các cửa sổ hoạt động ngắn và việc thay đổi nhanh chóng. Nó không bắt buộc chỉ vì khách hàng MCP chạy trên máy khác; đó chính xác là điều mà đường hầm SSH giải quyết.

Vận hành mặt phẳng điều khiển một cách có chủ ý

Sử dụng danh sách kiểm tra này cho sản xuất:

Giữ MCP ở trạng thái tắt nơi không có đại lý hoặc nhân viên nào cần nó.
Liên kết với vòng lặp quay lại và sử dụng đường hầm SSH theo mặc định.
Sử dụng một danh tính TLS riêng và giữ bật xác minh chứng chỉ.
Tạo một mã thông báo bearer độc nhất cho mỗi môi trường Webship.
Bảo vệ TOML, cấu hình client, khóa TLS và khóa SSH bằng các quyền của hệ thống tệp.
Tách biệt thông tin đăng nhập phát triển, thử nghiệm và sản xuất.
Bắt đầu các phiên với các công cụ mô phỏng trạng thái và chính sách trước khi thực hiện các biến đổi.
Lưu giữ và xem lại các sự kiện kiểm toán bảo mật của Webship.
Xoay mã thông báo và khởi động lại Webship sau khi nghi ngờ bị phơi nhiễm.
Đóng các đường hầm khi phiên quản trị kết thúc.

Đối với phản ứng sự cố, đóng các kênh đang hoạt động, hạn chế tài khoản SSH, thay thế token MCP trong TOML được bảo vệ, khởi động lại Webship, và xem xét các bản ghi kiểm toán bảo mật và phiên bản cấu hình gần đây. Nếu khóa riêng TLS có thể bị lộ, phát hành chứng chỉ và khóa mới như một phần của cùng lần khởi động lại. Sau đó, kiểm tra token cũ và xác nhận rằng nó bị từ chối.

Một mặt phẳng điều khiển nên vẫn là một mặt phẳng điều khiển

MCP hữu ích vì một đại lý có thể kiểm tra trạng thái thực và áp dụng các thay đổi đã được xác thực mà không cần định tuyến các thao tác đó qua đường dẫn yêu cầu công khai. Lợi thế đó sẽ biến mất nếu trình lắng nghe điều khiển trở thành một điểm cuối Internet khác.

Giữ ranh giới đơn giản: một trình nghe riêng, khả năng tiếp cận vòng lặp, TLS đã được xác minh, một chứng chỉ người mang được bảo vệ, một đường hầm đã xác thực, các thay đổi được kiểm tra phiên bản và quy trình đánh giá của con người cho các hoạt động mạnh. Webship cung cấp giao thức và các biện pháp bảo vệ an toàn; người điều hành quyết định ai có thể tiếp cận chúng.

Hướng dẫn này dựa trên tài liệu vận hành Webship 1.3.1, các ví dụ cấu hình đi kèm, mã xác thực và vận chuyển MCP, các cơ chế bảo vệ cấu hình khi chạy, và danh mục công cụ. Hãy xem xét tài liệu Webship hiện tại và phản hồi tools/list từ máy chủ đang chạy trước khi áp dụng nó cho bản phát hành khác.