Xây dựng MCP Server bảo mật trên AWS cho nền tảng B2B quy mô lớn

Model Context Protocol (MCP) đã giúp việc kết nối các ứng dụng khách LLM (Mô hình ngôn ngữ lớn) với các hệ thống hiện có trở nên dễ dàng hơn, nhưng hầu hết các ví dụ hiện nay vẫn chỉ dừng lại ở mức demo. Vấn đề khó khăn hơn xuất hiện khi tích hợp đó chạm đến dữ liệu kinh doanh thực, quy trình làm việc thực và các ràng buộc vận hành thực tế.

Trong trường hợp của chúng tôi, mục tiêu là mở rộng một nền tảng thông tin B2B được xây dựng dựa trên hơn một triệu hồ sơ công ty cho một ứng dụng khách LLM thông qua máy chủ MCP. Ý tưởng dành cho người dùng rất đơn giản: Thay vì mở cổng thông tin, nhập truy vấn, xem xét kết quả và xuất dữ liệu thủ công, người dùng có thể đưa ra một yêu cầu có cấu trúc như "tìm các công ty SaaS tại Đức với 50-200 nhân viên" và nhận kết quả ngay qua ứng dụng khách LLM.

Tuy nhiên, thách thức kỹ thuật lại không đơn giản: Làm thế nào để quy trình này hữu ích mà không tạo ra một cầu nối không an toàn giữa LLM và dữ liệu sản xuất? Câu hỏi này đã định hình toàn bộ quá trình triển khai từ đầu.

Kiến trúc hệ thống

Chúng tôi không coi máy chủ MCP chỉ là một lớp bao bọc tiện lợi xung quanh một API hiện có. Thay vào đó, chúng tôi coi đó là một giao diện hạng nhất với các hợp đồng, giả định bảo mật, chiến lược kiểm thử và kiểm soát vận hành riêng.

Nền tảng cơ bản đã cung cấp dữ liệu thông qua GraphQL trên AWS AppSync, mang lại cho chúng ta một ranh giới backend có cấu trúc để đọc các đối tượng kinh doanh. Ngoài ra, chúng tôi đã xây dựng một máy chủ MCP dựa trên ngôn ngữ Go để chuyển đổi các yêu cầu của người dùng thành một tập hợp các công cụ (tools) có phạm vi hẹp thay vì đẩy logic kinh doanh vào chính lớp LLM. Triển khai này sử dụng thư viện mcp-go, một ứng dụng khách GraphQL cho AppSync và một lớp công cụ bao gồm tìm kiếm, tìm kiếm hỗ trợ bởi AI và các hành động liên quan đến bộ sưu tập.

Kiến trúc này giúp ích theo hai cách. Thứ nhất, AppSync vẫn là hệ thống ghi lại (system of record) cho quyền truy cập backend thay vì để lớp MCP trở thành bề mặt tích hợp tạm thời. Thứ hai, lớp công cụ có thể được thiết kế xung quanh các trách nhiệm rõ ràng, giúp hệ thống dễ kiểm thử và dễ lý luận hơn.

Quy trình xử lý yêu cầu

Khi người dùng đưa ra yêu cầu thông qua ứng dụng khách LLM, các lớp sau sẽ xử lý nó theo trình tự:

1. Gọi công cụ: Ứng dụng khách LLM gửi một cuộc gọi công cụ qua giao tiếp stdio của MCP với tải trọng JSON.
2. Phân tích và xác thực: Mỗi trình xử lý công cụ trước tiên phân tích các đối số thô thành cấu trúc Go có kiểu. Sau đó, xác thực sẽ chạy: kiểm tra các trường bắt buộc, giới hạn giới hạn (ví dụ: tối đa 100 kết quả), và chuẩn hóa đầu vào. Đối với các công cụ thay đổi (mutation), một boolean mutationsAllowed sẽ được kiểm tra trước khi bất kỳ xử lý nào khác.
3. Thực thi GraphQL: Công cụ xây dựng bản đồ biến số và gọi client.Execute đối với điểm cuối AppSync. Ứng dụng khách GraphQL xử lý xác thực (mang token OIDC, khóa API hoặc ký AWS SigV4) và các lỗi cấp HTTP minh bạch.
4. Định hình phản hồi: Phản hồi GraphQL được giải mã thành các kiểu nội bộ và sau đó ánh xạ tới các kiểu công khai thân thiện với AI phẳng. Điều này đảm bảo LLM nhận được một bản ghi có hình dạng nhất quán mà không có các đối tượng lồng nhau phức tạp.

Điểm mấu chốt ở đây là xác thực, thực thi và định hình được xử lý bởi các lớp riêng biệt. Máy chủ MCP không bao giờ chuyển đầu vào thô của người dùng trực tiếp đến GraphQL và không bao giờ trả về phản hồi GraphQL thô cho ứng dụng khách.

Tách biệt quyền đọc và ghi

Quyết định triển khai quan trọng nhất là tách biệt các thao tác đọc và ghi ngay từ đầu. Trong nhiều ví dụ MCP sớm, các công cụ được thiết kế rộng rãi: chúng tìm kiếm, cập nhật và điều phối hành động thông qua một giao diện linh hoạt. Cách tiếp cận đó có thể chấp nhận được trong nguyên mẫu, nhưng nó tạo ra sự mơ hồ không cần thiết khi giao diện hướng tới các hệ thống thực.

Khi một mô hình có thể tiếp cận dữ liệu kinh doanh, "truy vấn" và "thay đổi" không nên được tách biệt chỉ theo quy ước. Chúng nên được tách biệt trong chính thiết kế công cụ. Trong triển khai của chúng tôi, các đường dẫn đọc chỉ đọc, và các hành động có khả năng thay đổi bị chặn theo mặc định.

Cách tiếp cận này không chỉ làm cho hệ thống an toàn hơn mà còn dễ bảo trì hơn. Một công cụ chỉ đọc đơn giản hơn để xem xét, kiểm thử và quan sát vì nó chỉ biểu thị một loại ý định thay vì nhiều loại.

Cơ chế từ chối mặc định cho các thay đổi

Chúng tôi đã giới thiệu một cờ rõ ràng --allow-mutations trước khi bất kỳ hành vi nào có khả năng thay đổi có thể chạy. Đó không phải là một mô hình ủy quyền đầy đủ, nhưng nó là một điểm kiểm soát hiệu quả. Nó buộc các nhóm phải đưa ra quyết định có chủ đích về việc liệu các đường dẫn ghi có sẵn trong một môi trường nhất định hay không.

Cờ này cũng tạo ra ranh giới thực tế giữa việc sử dụng khám phá và các môi trường mà sự an toàn quan trọng hơn sự tiện lợi. Trong tệp cấu hình ứng dụng khách MCP (.mcp.json), cờ này được chuyển dưới dạng đối số dòng lệnh, giúp bất kỳ ai xem xét thiết lập tích hợp đều có thể nhìn thấy.

Xác thực và kiểm thử

Máy chủ MCP xác thực với AppSync bằng các mã mang (bearer tokens) OIDC được cấp bởi nhà cung cấp danh tính của nền tảng. Mỗi mã được gắn với một người dùng được xác thực, có thời hạn ngắn và được giới hạn ở các hoạt động mà người dùng đó được ủy quyền thực hiện. Điều này quan trọng vì ứng dụng khách LLM đang thay mặt cho một người dùng cụ thể, không phải như một dịch vụ chung.

Về kiểm thử, việc sử dụng MCP Inspector để xác thực ngoài ứng dụng khách LLM là một lựa chọn dựa trên độ tin cậy. Nếu các kỹ sư chỉ có thể xác thực máy chủ MCP thông qua ứng dụng khách cuối cùng, việc gỡ lỗi sẽ chậm hơn và giao diện trở nên ít minh bạch hơn. Một đường dẫn kiểm tra cục bộ giúp dễ dàng kiểm tra cấu trúc yêu cầu và phản hồi, xác nhận hành vi của công cụ và cô lập lỗi trước khi LLM can thiệp.

Bài học kinh nghiệm

Một bài học rút ra từ việc triển khai là số lượng công cụ ít quan trọng hơn hình dạng của công cụ đó. Chín công cụ có phạm vi hẹp có thể an toàn hơn hai công cụ chung mục đích nếu mỗi công cụ có mô hình đầu vào rõ ràng, cấu trúc đầu ra bị giới hạn và bề mặt vận hành nhỏ.

Hợp đồng công cụ hẹp giúp bù đắp cho sự không chắc chắn của mô hình xác suất (LLM). Nó làm cho việc chẩn đoán lỗi dễ dàng hơn, xác thực kết quả dễ dàng hơn và quản lý thay đổi trong tương lai dễ dàng hơn. Ở quy mô hơn một triệu hồ sơ công ty, việc giữ cho các đường dẫn đọc chỉ đọc giúp giảm thiểu rủi ro và đảm bảo hệ thống hoạt động ổn định khi chuyển từ thử nghiệm sang sản xuất thực tế.