Giới thiệu

Bảo mật MCP trong môi trường production phụ thuộc vào ba quyết định riêng biệt: ai đang gọi, caller đó được phép thực hiện những gì, và thông tin xác thực được lưu trữ cũng như sử dụng ra sao. Xác thực thiết lập một danh tính, ủy quyền đánh giá danh tính đó dựa trên một hành động và tài nguyên, còn quản lý bí mật bảo vệ thông tin xác thực cần thiết để truy cập các hệ thống phụ thuộc. Coi đây là một vấn đề duy nhất thường dẫn đến quyền hạn quá rộng, bản ghi kiểm tra không rõ ràng và thông tin xác thực khó xoay vòng.

MCP server nên đưa ra quyết định ủy quyền tại ranh giới của server, ngay trước khi thực thi một thao tác trên tool hoặc tài nguyên. Không được giả định rằng giao diện client, chỉ dẫn của model hay một request trước đó đã thực hiện thành công là bằng chứng đầy đủ về quyền. Mỗi request phải mang đủ ngữ cảnh đáng tin cậy để đánh giá danh tính hiện tại, tenant, hành động, tài nguyên và các ràng buộc liên quan. Khi thiếu một thuộc tính bắt buộc, kết quả an toàn là từ chối, không phải tự suy diễn quyền.

Bài học này sử dụng một ví dụ Python nhỏ, độc lập với giao thức truyền tải, để làm rõ quy trình ra quyết định. Ví dụ này không phải là một MCP SDK và không thay thế các tính năng xác thực hoặc ủy quyền của một môi trường triển khai cụ thể. Ví dụ minh họa logic chính sách mà MCP server có thể áp dụng sau khi lớp truyền tải đã xác thực request và thiết lập các claim danh tính đáng tin cậy.

Ngữ cảnh xác thực và danh tính

Xác thực trả lời câu hỏi liệu một danh tính được cung cấp có thể được tin cậy hay không. Trong môi trường production, một MCP deployment có thể nhận danh tính từ session đã được xác thực, identity provider của doanh nghiệp, cơ chế workload identity hoặc gateway xác minh token trước khi chuyển tiếp các claim đáng tin cậy. Cơ chế cụ thể phụ thuộc vào môi trường triển khai, nhưng server phải xác định thành phần nào xác thực thông tin đăng nhập, claim nào được tin cậy, thời hạn được kiểm tra như thế nào và danh tính được biểu diễn nội bộ ra sao.

Một bản ghi danh tính nội bộ hữu ích thường chứa mã định danh subject ổn định, mã định danh tenant, loại actor và các quyền hoặc role liên quan đến quyết định chính sách. Khi có thể, hãy tách token bên ngoài ban đầu khỏi ngữ cảnh nội bộ này. Các triển khai tool thường cần claim danh tính chứ không cần bearer token. Việc truyền token thô vào các đối số mà model có thể nhìn thấy, kết quả của tool, log hoặc các dịch vụ downstream không liên quan sẽ làm tăng mức độ phơi lộ mà không cải thiện khả năng ủy quyền.

Xác thực cũng cần các cơ chế kiểm soát vòng đời. Từ chối thông tin xác thực đã hết hạn, không đúng định dạng hoặc có phạm vi không chính xác. Phân biệt người dùng cuối với tài khoản dịch vụ, vì tài khoản dịch vụ không nên tự động kế thừa quyền của người dùng. Ghi lại phương thức xác thực và mã định danh danh tính trong các sự kiện kiểm tra, đồng thời tránh ghi giá trị token và các dữ liệu bí mật khác. Một sự kiện xác thực thành công không được xem là quyền ủy quyền tổng quát.

Ủy quyền theo nguyên tắc đặc quyền tối thiểu

Việc ủy quyền nên đánh giá một yêu cầu cụ thể, không chỉ đơn thuần dựa trên tên vai trò chung. Một mô hình ra quyết định thực tế bao gồm chủ thể, tenant, hành động, tài nguyên, môi trường và các ràng buộc như chế độ chỉ đọc hoặc trạng thái phê duyệt. Ví dụ, việc đọc một báo cáo của tenant alpha khác với việc xuất tất cả báo cáo, xóa một báo cáo hoặc đọc một báo cáo thuộc tenant beta. Chính sách nên nêu riêng từng thao tác này để quyền được cấp cho thao tác này không ngầm cho phép các thao tác khác.

Chính sách mặc định phải là từ chối. Chỉ cho phép khi yêu cầu có hành động đã biết, phạm vi tài nguyên đã biết, tenant khớp hợp lệ và quyền được cấp rõ ràng. Tránh sử dụng quyền dạng wildcard cho các tài khoản dịch vụ production, trừ khi yêu cầu vận hành đã được lập tài liệu, giới hạn chặt chẽ và được giám sát. Tách các thao tác rủi ro cao như xóa, xoay vòng thông tin xác thực, xuất hàng loạt và thay đổi cấu hình khỏi các thao tác đọc thông thường.

Ví dụ có thể chạy sau đây đánh giá một chính sách nhỏ. Đầu vào là một yêu cầu JSON chứa danh tính và các thuộc tính của yêu cầu. Đầu ra là một quyết định và lý do ở dạng JSON. Ví dụ này cố ý từ chối các yêu cầu thiếu ngữ cảnh tenant, truy cập xuyên tenant, hành động không xác định và các quyền không được cấp rõ ràng.

import json
import sys


def authorize(request):
    identity = request.get("identity") or {}
    subject = identity.get("subject")
    tenant = identity.get("tenant")
    permissions = set(identity.get("permissions") or [])
    action = request.get("action")
    resource_tenant = request.get("resource_tenant")

    if not subject or not tenant:
        return {"allow": False, "reason": "missing_identity_context"}
    if not action or not resource_tenant:
        return {"allow": False, "reason": "missing_request_scope"}
    if tenant != resource_tenant:
        return {"allow": False, "reason": "cross_tenant_access"}
    if action not in {"report:read", "report:export"}:
        return {"allow": False, "reason": "unknown_action"}
    if action not in permissions:
        return {"allow": False, "reason": "permission_not_granted"}
    return {"allow": True, "reason": "explicit_permission"}


if __name__ == "__main__":
    request = json.load(sys.stdin)
    print(json.dumps(authorize(request), sort_keys=True))

Ví dụ, cung cấp cho chương trình một yêu cầu trong đó tenant của danh tính là alpha, tenant của tài nguyên là alpha và các quyền chứa report:read. Kết quả là quyết định cho phép. Khi đổi tenant của tài nguyên thành beta, hệ thống sẽ từ chối vì truy cập xuyên tenant, ngay cả khi danh tính có report:read. Một tài liệu JSON không hợp lệ khiến trình phân tích cú pháp JSON tiêu chuẩn kết thúc với lỗi; các trường bị thiếu sẽ tạo ra một phản hồi từ chối có cấu trúc thay vì một ngoại lệ hoặc một lần cho phép ngoài ý muốn.

Cô lập tenant và truy cập theo phạm vi

Cô lập tenant không chỉ đơn giản là thêm một trường tenant vào thông báo log. Ranh giới tenant phải được thực thi trong quyết định ủy quyền và trong lớp truy cập dữ liệu. Một tool nên lấy tenant hiệu lực từ ngữ cảnh danh tính đáng tin cậy, so sánh tenant đó với phạm vi tài nguyên được yêu cầu, rồi truyền phạm vi đã được phê duyệt đến repository hoặc service downstream. Không được để một tham số do model tạo ra thay thế mã định danh tenant đáng tin cậy.

Phạm vi tài nguyên phải hẹp nhất có thể theo yêu cầu của tác vụ. Một yêu cầu đọc một báo cáo nên tạo ra truy vấn được giới hạn ở đúng báo cáo và tenant đó. Một yêu cầu xuất dataset phải cần một quyền riêng, phạm vi xuất rõ ràng và các giới hạn phù hợp về khối lượng cũng như tần suất. Đối với các thao tác quản trị, hãy yêu cầu danh tính quản trị được xác minh độc lập và, khi phù hợp, một tín hiệu phê duyệt hoặc xác thực nâng cấp.

Hãy cẩn thận với các đường dẫn truy cập gián tiếp. Các tool tìm kiếm, phân tích, tệp và thông báo lỗi có thể làm lộ dữ liệu ngay cả khi thao tác đọc chính đã được bảo vệ. Áp dụng bộ lọc tenant cho kết quả tìm kiếm, dữ liệu tổng hợp, tên tệp, metadata, nội dung ngoại lệ, cache và các job bất đồng bộ. Kiểm thử cả đường dẫn trực tiếp lẫn gián tiếp, bao gồm trường hợp một danh tính được ủy quyền cố truy cập tenant lân cận và một yêu cầu chưa xác thực cố suy luận xem một tài nguyên có tồn tại hay không.

Quản lý secret và thực thi tool

Secret là bất kỳ giá trị nào mà việc tiết lộ hoặc sử dụng trái phép có thể cấp quyền truy cập, bao gồm API key, client secret, mật khẩu cơ sở dữ liệu, signing key và access token ngắn hạn. Lưu trữ secret production trong secret manager được phê duyệt hoặc cơ sở hạ tầng tương đương của nền tảng, với quyền truy cập được kiểm soát bằng workload identity. Không đưa chúng vào mã nguồn, cấu hình được commit vào hệ thống quản lý phiên bản, prompt, tham số tool, ngữ cảnh của model, thông báo ngoại lệ hoặc log ứng dụng thông thường.

Việc truy xuất secret phải diễn ra sau khi ủy quyền và gần với thao tác downstream nhất trong phạm vi thực tế. MCP server chỉ nên yêu cầu đúng secret cụ thể cần cho hành động đã được phê duyệt, sử dụng secret đó trong khoảng thời gian thực tế ngắn nhất và tránh trả secret về cho bên gọi. Ưu tiên thông tin xác thực có thời hạn ngắn và tự động xoay vòng khi dependency hỗ trợ. Việc xoay vòng phải được kiểm thử như một workflow vận hành, vì một policy chỉ hoạt động cho đến lần xoay vòng đầu tiên thì chưa sẵn sàng cho production.

Có thể mở rộng ví dụ về ủy quyền bằng cách thêm một secret provider, nhưng bản thân provider phải thực thi workload identity và policy ở cấp secret. Tool không được chấp nhận một tên secret tùy ý từ argument do model tạo ra rồi truy xuất secret đó. Hãy ánh xạ nội bộ một thao tác đã được phê duyệt tới dependency được phép sử dụng và từ chối các ánh xạ ngoài dự kiến. Redact các giá trị nhạy cảm trước khi ghi log chi tiết request, kết quả tool, header hoặc stack trace.

Một lỗi phổ biến là ủy quyền cho request trước, sau đó ghi log toàn bộ request object, bao gồm access token hoặc credential do client cung cấp. Một lỗi khác là sử dụng cùng một service credential có quyền hạn lớn cho mọi tenant và mọi tool. Các thiết kế này khiến việc khoanh vùng sự cố khi bị xâm phạm trở nên khó khăn hơn. Hãy sử dụng các identity hoặc secret path riêng cho những service và môi trường khác nhau, giới hạn quyền truy cập theo tenant hoặc thao tác khi được hỗ trợ, đồng thời giám sát các lần đọc secret như những security event.

Các thao tác và lỗi phổ biến

Authorization là một cơ chế kiểm soát trong vận hành, vì vậy cần giám sát các quyết định ủy quyền. Một audit event nên xác định subject, tenant, action, resource classification, decision, reason, policy version và correlation identifier. Event này không được chứa giá trị secret hoặc payload nhạy cảm không bị giới hạn. Hãy cảnh báo khi có các lần từ chối lặp lại, nỗ lực truy cập xuyên tenant, khối lượng export bất thường, các lần đọc secret ngoài dự kiến và service account thực hiện những thao tác tương tác hoặc quản trị.

Các lỗi triển khai phổ biến bao gồm tin cậy tenant identifier do client cung cấp, kiểm tra role nhưng không kiểm tra resource được yêu cầu, coi authentication là authorization, mặc định cho phép các action không xác định và trả về lỗi downstream chi tiết cho client hướng tới model. Một lỗi khác là chỉ kiểm thử happy path. Các bài kiểm thử nên bao quát identity hết hạn, claim bị thiếu, sai tenant, action không xác định, quyền không đủ, secret store gặp lỗi, xoay vòng và redact audit.

Sự cố ngừng hoạt động của secret store phải khiến các thao tác cần credential không khả dụng bị từ chối theo cơ chế fail closed. Không được âm thầm sử dụng credential dự phòng có quyền truy cập rộng hơn. Lỗi cấu hình policy cũng phải tạo ra một lần từ chối và cảnh báo mà operator có thể nhìn thấy. Hãy phân biệt việc user bị từ chối với lỗi dependency nội bộ trong log và metric, đồng thời chỉ trả về cho bên gọi lượng thông tin an toàn tối thiểu.

Trước khi phát hành lên production, hãy review từng MCP tool bằng bốn câu hỏi: tool tin cậy identity nào, cho phép chính xác những action nào, thực thi tenant và phạm vi resource nào, và có thể truy cập những secret nào? Hãy ghi lại các câu trả lời, tự động kiểm thử chúng và review lại khi tool, dependency, mô hình tenant hoặc vòng đời credential thay đổi.

Tóm tắt

Authentication cung cấp một identity đã được xác minh, nhưng không quyết định identity đó được phép làm gì. Authorization phải đánh giá mọi thao tác nhạy cảm bằng permission rõ ràng cho action và resource, tenant context đáng tin cậy và policy mặc định từ chối. Tenant isolation phải được thực thi cả ở ranh giới MCP lẫn trong việc truy cập dữ liệu downstream, để search, metadata, export và error không thể vượt qua ranh giới này.

Chỉ được truy xuất secret sau khi authorization, thông qua một hệ thống secret management đã được phê duyệt, sử dụng identity có phạm vi hẹp nhất hiện có và thời hạn ngắn nhất trong thực tế. Giữ secret ngoài model context, tool response, log và source code. Production readiness cũng đòi hỏi khả năng audit, xoay vòng, hành vi an toàn khi xảy ra lỗi và kiểm thử các negative path, vì những lỗi authorization gây thiệt hại lớn nhất thường xảy ra khi các giả định vẫn chưa được làm rõ.

Quy tắc triển khai cốt lõi rất đơn giản: xác thực bên gọi, ủy quyền cho đúng action đối với đúng phạm vi, chỉ truy xuất secret cần thiết, thực thi trong phạm vi đó và ghi lại một decision đã được redact để có thể điều tra về sau.