Máy chủ MCP của bạn an toàn. Nhưng sổ cái phía sau thì không.

Trong một bài viết gần đây trên Unite.AI, Gil Feig đã nêu sáu phương pháp tốt nhất để xây dựng máy chủ MCP an toàn. Những phương pháp này rất hữu ích, và bất kỳ ai triển khai máy chủ MCP đều nên làm theo. Lời khuyên của ông rằng mỗi tích hợp nên có “vai trò chi tiết riêng, được giới hạn nghiêm ngặt trong phạm vi quyền cần thiết” là hoàn toàn chính xác. Tuy nhiên, lời khuyên đó cũng giả định rằng hệ thống ở đầu bên kia có các vai trò chi tiết. Điều này cho thấy một giả định rộng hơn nhưng hiếm khi được nói rõ: các hệ thống phía sau máy chủ có thể được bảo mật theo cùng tiêu chuẩn.

Trong phần mềm doanh nghiệp, điều đó thường không thể thực hiện được. Tôi điều hành đội ngũ kỹ thuật xây dựng một lớp tích hợp kết nối với 32 hệ thống kế toán và ERP, bên trên có thể tùy chọn thêm máy chủ MCP. Chúng tôi thường thấy các tác nhân được xác thực, phân quyền theo phạm vi phù hợp và ghi nhật ký đầy đủ ở phía mình, nhưng lại ghi dữ liệu vào những hệ thống hoàn toàn không thể biết rằng có tác nhân tham gia.

Bài viết này đề cập đến nửa còn lại của vấn đề: các hệ thống thượng nguồn thực sự cung cấp những gì, bạn có thể kiểm soát điều gì từ lớp tích hợp và giới hạn của quyền kiểm soát đó nằm ở đâu.

Đặc tả MCP bàn giao quyền kiểm soát ở đâu

Bản đặc tả ủy quyền MCP nêu rõ ranh giới của chính nó. Máy chủ MCP là máy chủ tài nguyên OAuth dành cho các ứng dụng khách của nó. Khi gọi một API ở hệ thống thượng nguồn, máy chủ hoạt động như một ứng dụng khách OAuth riêng biệt, với một mã thông báo riêng do hệ thống thượng nguồn cấp. Việc chuyển tiếp mã thông báo của ứng dụng khách bị nghiêm cấm rõ ràng.

Đó là thiết kế đúng đắn. Điều đó cũng có nghĩa là mọi khía cạnh của lệnh gọi thượng nguồn, bao gồm ai được phép làm gì và hoạt động đó được ghi nhận như thế nào, hoàn toàn phụ thuộc vào hệ thống thượng nguồn. Đặc tả không thể khắc phục những gì hệ thống thượng nguồn không hỗ trợ.

Điều tương tự cũng đúng với hướng dẫn của OWASP về quyền hạn quá mức của tác nhân. Hướng dẫn khuyến nghị giới hạn quyền mà các tiện ích mở rộng của tác nhân nắm giữ trong những hệ thống khác ở mức tối thiểu cần thiết, đồng thời thực hiện hành động trong ngữ cảnh của người dùng mà tác nhân thay mặt. Cả hai đều là lời khuyên hữu ích. Cả hai đều giả định rằng hệ thống kia có cách thể hiện quyền tối thiểu và ngữ cảnh người dùng.

Các hệ thống thượng nguồn thực sự cung cấp những gì

Dưới đây là những gì chúng tôi thấy khi nhìn 32 hệ thống kế toán và ERP mà mình kết nối từ góc độ của một đơn vị tích hợp.

Một phần ba không có OAuth

21 trong số 32 hệ thống sử dụng OAuth. 11 hệ thống còn lại dựa vào thông tin xác thực tĩnh: khóa API, tên người dùng và mật khẩu hoặc một cặp mã thông báo. Một số khóa trong đó không bao giờ hết hạn. Một hệ thống được sử dụng rộng rãi ghi rõ trong tài liệu rằng mã thông báo API của họ có thời hạn không giới hạn, miễn là người dùng còn tồn tại.

Thời hạn dài, khả năng thu hồi hạn chế

OAuth không giúp được nhiều như bạn mong đợi. Một nhà cung cấp cấp mã làm mới có thời hạn khoảng 20 năm. Đây là thông tin xác thực được thiết kế để tồn tại lâu hơn tác nhân sử dụng nó, khuôn khổ dùng để xây dựng tác nhân và rất có thể cả người đã nhấp vào “cho phép”. Trong một hệ thống khác, ngay cả mã thông báo truy cập cũng không hết hạn.

Khi thông tin xác thực đã được cấp, câu hỏi đặt ra là ai có thể vô hiệu hóa nó. Tiêu chuẩn về việc này, thu hồi mã thông báo OAuth (RFC 7009), đã tồn tại từ năm 2013. Tuy vậy, khoảng bốn trong mười hệ thống không cung cấp cho đơn vị tích hợp cách kỹ thuật nào để thu hồi thông tin xác thực. Tất cả các hệ thống dùng khóa API đều thuộc nhóm này. Biện pháp kiểm soát duy nhất còn lại là yêu cầu khách hàng tự xóa quyền truy cập.

Phạm vi quyền hạn chung chung, không có danh tính tác nhân

Hầu hết khóa tĩnh chỉ kế thừa toàn bộ quyền của người dùng đã tạo ra chúng; chỉ một số ít hệ thống cho phép giới hạn khóa ở từng điểm cuối riêng lẻ. Nhiều hệ thống OAuth có phạm vi quyền hạn, nhưng phạm vi thường khá chung chung, chẳng hạn như “kế toán, đọc và ghi”. Và trong số 32 hệ thống, chúng tôi không tìm thấy hệ thống nào có cách ghi nhận qua API cả tác nhân lẫn người mà tác nhân thay mặt trên cùng một giao dịch. Các tác nhân bên ngoài xuất hiện dưới danh nghĩa người dùng đã kết nối chúng hoặc một người dùng hệ thống chung. Đáng chú ý, khi một nhà cung cấp tích hợp tác nhân vào chính sản phẩm của mình, như Microsoft đã làm trong Business Central, nhà cung cấp đó cấp cho chúng tài khoản người dùng riêng. Đó cũng chính là cách tiếp cận tôi đề xuất dưới đây, nhưng hiện chỉ dành cho các tác nhân của nhà cung cấp.

Lớp tích hợp có thể thực thi những gì

Không điều nào trong số này có nghĩa là phải bỏ cuộc. Giữa tác nhân và hệ thống kế toán, bạn có thể kiểm soát gần như mọi thứ:

• thông tin xác thực riêng cho từng tác nhân khi truy cập lớp tích hợp của bạn
• phạm vi quyền hạn riêng, chẳng hạn như quyền chỉ đọc hóa đơn
• nhật ký kiểm tra mọi lệnh gọi của tác nhân, kèm theo thông tin về người mà tác nhân thay mặt
• khóa bảo đảm tính lũy đẳng để tác nhân thử lại không ghi nhận cùng một hóa đơn hai lần
• giới hạn tốc độ cho từng tác nhân
• bước phê duyệt trước mọi thao tác ghi

Không điều nào trong số đó phụ thuộc vào những gì hệ thống đích hỗ trợ. Ngày nay, có thể xây dựng một lớp kiểm soát truy cập mạnh mẽ ở tầng tích hợp; nếu triển khai tác nhân ở bất kỳ nơi nào gần dữ liệu tài chính, bạn nên xây dựng lớp này.

Giới hạn nằm ở đâu

Điều bạn không thể làm là mở rộng lớp đó vượt ra ngoài ranh giới của hệ thống. Có ba vấn đề phát sinh ở đó.

Khả năng truy nguyên

Trong hệ thống kế toán, giao dịch do tác nhân thực hiện được ghi nhận dưới tên người đã ủy quyền kết nối hoặc dưới tên một người dùng kỹ thuật. Bất kỳ ai kiểm tra hệ thống đó cũng sẽ thấy giao dịch được ghi nhận bởi người dùng ấy. Họ không thể biết giao dịch do một người hay một tác nhân thực hiện. Đối với sổ cái, một tác nhân ghi nhận 400 hóa đơn lúc 3 giờ sáng trông chẳng khác nào một quản lý tài chính cực kỳ cần mẫn. Muốn dựng lại quá trình đó, phải dựa vào nhật ký của bên tích hợp — một chuỗi tin cậy khác với chuỗi của hệ thống lưu trữ hồ sơ chính thức. Đây là một vị thế yếu khi cần điều tra pháp chứng hoặc kiểm toán.

Phần lớn các tổ chức cũng chưa giải quyết được vấn đề này. Trong khảo sát của Cloud Security Alliance, chỉ 28% số người trả lời cho biết họ có thể truy vết đáng tin cậy các hành động của tác nhân đến một cá nhân hoặc hệ thống trên mọi môi trường, và 44% đang sử dụng hoặc có kế hoạch sử dụng khóa API tĩnh cho các tác nhân của mình.

Đặc quyền tối thiểu

Bạn có thể buộc tác nhân chỉ đọc hóa đơn. Nhưng nếu hệ thống đích không có phạm vi quyền, thông tin xác thực phía sau lớp của bạn vẫn có toàn quyền truy cập. Bất kỳ ai lấy được thông tin xác thực đó đều có thể hoàn toàn bỏ qua lớp của bạn và mọi quy tắc bạn thiết lập bằng lớp này.

Thu hồi

Bạn có thể lập tức ngắt quyền truy cập của chính tác nhân mình. Nhưng việc đó không giúp ích nếu thông tin xác thực của chính hệ thống đích bị xâm phạm. Còn với bốn trong mười hệ thống không có điểm cuối thu hồi, công tắc ngắt khẩn cấp chỉ là một email gửi cho khách hàng.

Giải pháp thực tế: Tạo tài khoản người dùng riêng cho tác nhân

Việc hữu ích nhất bạn có thể làm ngay hôm nay chẳng có gì hào nhoáng: tạo một tài khoản người dùng riêng cho tác nhân trong hệ thống đích và chỉ kết nối tác nhân thông qua tài khoản đó.

Cách này hoạt động trên mọi hệ thống cho phép tạo tài khoản người dùng và mang lại ba lợi ích mà lớp tích hợp không thể cung cấp:

• Truy nguyên trong hệ thống lưu trữ hồ sơ chính thức. Các giao dịch sẽ được ghi nhận dưới tên “AP agent”, chứ không phải tên người quản lý tài chính đã nhấp vào “kết nối” sáu tháng trước.
• Có cách thu hồi, ngay cả khi không có API hỗ trợ. Khách hàng có thể vô hiệu hóa tài khoản người dùng trong giao diện, kể cả trên những hệ thống không có điểm cuối thu hồi.
• Áp dụng một phần nguyên tắc đặc quyền tối thiểu. Nếu hệ thống có bất kỳ mô hình vai trò nào, tài khoản người dùng của tác nhân thường có thể bị giới hạn chỉ ở những mô-đun mà nó thực sự cần.

Chi phí là có thật. Trong quá trình làm quen và thiết lập ban đầu, phải có người tự tạo tài khoản, làm phát sinh trở ngại đúng vào thời điểm bất tiện nhất. Khoảng một nửa số hệ thống tính phí cho mỗi tài khoản người dùng bổ sung, từ vài euro mỗi tháng đối với các công cụ dành cho doanh nghiệp nhỏ đến hơn một trăm euro mỗi tháng đối với một hệ thống ERP đầy đủ. Một số hệ thống khác giới hạn số người dùng theo gói dịch vụ, nên chỉ cần thêm một tài khoản cũng có thể khiến cả công ty phải dùng gói đắt hơn. Và tài khoản dịch vụ không có ai chịu trách nhiệm sẽ tự trở thành một rủi ro, góp phần làm tình trạng phân tán danh tính phi con người mà Unite.AI từng đề cập thêm nghiêm trọng. Tài khoản đó cần có người phụ trách và ngày rà soát, như mọi tài khoản khác.

Cách này cũng không bổ sung phạm vi quyền cho những hệ thống vốn không có phạm vi quyền. Nhưng nó đưa khả năng truy nguyên và thu hồi trở lại hệ thống mà kiểm toán viên thực sự kiểm tra.

Giải pháp mang tính nền tảng: Danh tính được ủy quyền

Về lý thuyết, giải pháp đúng đã có sẵn. Cơ chế trao đổi mã thông báo OAuth 2.0 (RFC 8693) phân biệt việc mạo danh với việc ủy quyền. Khi được ủy quyền, tác nhân vẫn giữ danh tính riêng, còn mã thông báo ghi nhận rằng tác nhân đang hành động thay mặt một người thông qua xác nhận “act”.

Áp dụng vào kế toán, điều đó có nghĩa là:

• sổ cái ghi nhận rằng tác nhân này đã thực hiện giao dịch thay mặt cho người này
• phạm vi quyền được cấp theo từng lần ủy quyền, chứ không phải theo từng người dùng
• có thể thu hồi một lần ủy quyền riêng lẻ mà không ảnh hưởng đến tài khoản của người đó

Theo những gì tôi tìm hiểu được, không hệ thống nào trong số 32 hệ thống hỗ trợ cơ chế tương tự. Vì vậy, hiện tại đây vẫn chỉ là định hướng, chưa phải lựa chọn khả thi. Điều đó khiến đây trở thành yêu cầu dành cho các nhà cung cấp phần mềm kế toán và ERP, chứ không phải nhiệm vụ của các bên tích hợp: các tác nhân đã ghi dữ liệu vào sổ cái của bạn, và API của bạn cần có khả năng thể hiện điều đó.

Cần làm gì trước khi để tác nhân truy cập sổ cái

Nếu bạn đang kết nối tác nhân với hệ thống kế toán hoặc ERP, hãy dùng danh sách kiểm tra ngắn sau:

1. Kiểm tra mô hình thông tin xác thực của từng hệ thống đích. Hệ thống dùng OAuth hay khóa tĩnh? Thông tin xác thực có hiệu lực trong bao lâu, có phạm vi quyền hay không và bạn có thể thu hồi nó không?
2. Dù sao cũng hãy xây dựng lớp kiểm soát truy cập của riêng bạn. Danh tính riêng cho từng tác nhân, phạm vi quyền, tính bất biến khi thực hiện lại yêu cầu và cơ chế phê duyệt đều cần được triển khai ở phía bạn, bất kể hệ thống đích hỗ trợ những gì.
3. Dùng tài khoản người dùng riêng cho tác nhân ở mọi nơi hệ thống cho phép. Chấp nhận công sức thiết lập ban đầu và chi phí giấy phép như khoản phải trả để có thể truy nguyên.
4. Đảm bảo nhật ký kiểm toán của riêng bạn có thể chứng minh là không bị sửa đổi. Với nhiều hệ thống, đó sẽ là hồ sơ duy nhất cho thấy có tác nhân tham gia.
5. Ghi lại rủi ro còn tồn đọng. Nếu hệ thống không có phạm vi quyền hạn và không hỗ trợ thu hồi quyền, hãy nói rõ điều đó với khách hàng và ghi vào sổ đăng ký rủi ro nội bộ.

Ranh giới mới là mấu chốt

Bảo mật máy chủ MCP là điều cần thiết, nhưng chưa đủ. Mức độ an toàn của một tác nhân ghi dữ liệu vào sổ cái được quyết định ở ranh giới giữa lớp của bạn và hệ thống lưu trữ dữ liệu chính thức; hiện nay, ranh giới đó do các hệ thống quyết định chứ không phải bạn.

Tin tốt là khoảng trống này đã được xác định rõ. Các tiêu chuẩn đã có. Điều còn thiếu là sự hỗ trợ dành cho chúng trong các hệ thống lưu trữ sổ sách.