Danh Sách Kiểm Tra Bảo Mật MCP: Tiêu Chuẩn Tối Thiểu OWASP cho Triển Khai Máy Chủ MCP An Toàn

MCP Security Security Checklist OWASP GenAI AI Security

Hướng dẫn thực tế của Dự án Bảo mật GenAI OWASP về phát triển máy chủ MCP đạt đến đỉnh điểm với một danh sách kiểm tra đánh giá cụ thể — “Tiêu Chuẩn Tối Thiểu Bảo Mật MCP”. Danh sách kiểm tra này xác định các kiểm soát cơ bản phải có trước khi triển khai máy chủ MCP vào production.

Bài viết này trình bày danh sách kiểm tra đầy đủ với hướng dẫn triển khai cho từng mục, được tổ chức theo năm lĩnh vực bảo mật mà hướng dẫn OWASP xác định. Sử dụng nó cho đánh giá bảo mật trước triển khai, kiểm toán định kỳ và như một khung để khắc phục các lỗ hổng đã xác định.

Cách Sử Dụng Danh Sách Kiểm Tra Này

Đánh dấu các mục: Đối với mỗi mục, ghi lại ĐẠT (đã triển khai và xác minh), KHÔNG ĐẠT (chưa triển khai hoặc triển khai một phần), hoặc N/A (không áp dụng cho triển khai này).

Cổng triển khai: Các mục trong Danh mục 1 (Danh Tính, Xác Thực, Chính Sách) và Danh mục 2 (Cách Ly) là cổng triển khai cứng — bất kỳ mục KHÔNG ĐẠT nào nên chặn go-live cho đến khi được khắc phục. Các mục trong danh mục khác nên được chấp nhận rủi ro với lịch trình được ghi chép.

Trình kích hoạt đánh giá: Chạy lại toàn bộ danh sách kiểm tra sau bất kỳ thay đổi đáng kể nào đối với mã máy chủ MCP, sổ đăng ký công cụ, cấu hình xác thực, môi trường triển khai, hoặc khi một danh mục công cụ mới được tích hợp.


Danh Mục 1: Danh Tính, Xác Thực và Thực Thi Chính Sách Mạnh Mẽ

Đây là danh mục có mức độ ưu tiên cao nhất. Lỗi xác thực cấp cho kẻ tấn công quyền truy cập trực tiếp vào mọi thứ mà máy chủ MCP có thể làm.

1.1 Tất cả máy chủ MCP từ xa sử dụng OAuth 2.1 / OIDC

Cần xác minh: Mọi kết nối từ xa đến máy chủ MCP yêu cầu xác thực thông qua máy chủ ủy quyền OAuth 2.1 được cấu hình đúng cách. Các kết nối ẩn danh bị từ chối. Máy chủ MCP cục bộ sử dụng STDIO có thể sử dụng xác thực thay thế phù hợp với ngữ cảnh triển khai của chúng.

Cách kiểm tra: Thử kết nối mà không có header authorization. Thử kết nối với token bị lỗi định dạng hoặc hết hạn. Cả hai nên dẫn đến lỗi xác thực, không phải quyền truy cập vào công cụ.

Chế độ lỗi phổ biến: Endpoint phát triển để truy cập mà không cần xác thực; dự phòng xác thực API key không xác thực thời hạn hoặc phạm vi; xác thực token chỉ khi thiết lập phiên, không phải mỗi yêu cầu.


1.2 Token có thời gian sống ngắn, được phạm vi hóa và được xác thực ở mọi lần gọi

Cần xác minh: Access token hết hạn trong vòng vài phút (không phải giờ). Mỗi token mang phạm vi tối thiểu cần thiết cho tác vụ hiện tại. Mọi lần gọi công cụ đều xác thực chữ ký của token, nhà phát hành (iss), đối tượng (aud), thời hạn (exp), và phạm vi yêu cầu — không chỉ khi thiết lập phiên.

Cách kiểm tra: Sử dụng token hợp lệ, sau đó đợi nó hết hạn (hoặc đặt đồng hồ về phía trước thủ công). Thử gọi công cụ — nó nên thất bại với lỗi 401, không thành công dựa trên kết quả xác thực được cache.

Chế độ lỗi phổ biến: Xác thực token được cache khi bắt đầu phiên và không được lặp lại; token có thời gian sống 24+ giờ; phạm vi “admin” rộng được sử dụng thay vì phạm vi cụ thể cho từng hoạt động; trường exp không được kiểm tra.


1.3 Không chuyển tiếp token; thực thi chính sách được tập trung hóa

Cần xác minh: Máy chủ MCP không chuyển tiếp token của client đến các API downstream. Tất cả các lần gọi dịch vụ downstream sử dụng token được cấp rõ ràng cho máy chủ MCP (thông qua luồng On-Behalf-Of hoặc thông tin xác thực dịch vụ). Một cổng chính sách tập trung chặn tất cả các lần gọi công cụ và thực thi xác thực, ủy quyền, đồng ý và ghi log kiểm toán trước khi bất kỳ mã công cụ nào được thực thi.

Cách kiểm tra: Xem xét mã để tìm bất kỳ vị trí nào mà token client đến được chuyển tiếp trong lần gọi API đi ra. Kiểm tra log truy cập dịch vụ downstream để xác minh các yêu cầu đến với thông tin xác thực máy chủ, không phải thông tin xác thực người dùng.

Chế độ lỗi phổ biến: Mẫu Authorization: Bearer ${request.headers.authorization} trong các lần gọi downstream; kiểm tra ủy quyền phân tán trên các trình xử lý công cụ riêng lẻ; không có điểm thực thi chính sách tập trung.


Logo

Sẵn sàng phát triển doanh nghiệp của bạn?

Bắt đầu dùng thử miễn phí ngay hôm nay và xem kết quả trong vài ngày.

Danh Mục 2: Cách Ly Nghiêm Ngặt và Kiểm Soát Vòng Đời

Lỗi cách ly trong môi trường đa người thuê là thảm họa — chúng cho phép một người dùng truy cập dữ liệu của người khác. Đây là cổng triển khai cứng.

2.1 Người dùng, phiên và ngữ cảnh thực thi được cách ly hoàn toàn

Cần xác minh: Không có biến toàn cục, thuộc tính cấp lớp hoặc thể hiện singleton được chia sẻ lưu trữ dữ liệu cụ thể của người dùng hoặc phiên. Mỗi phiên sử dụng các đối tượng được khởi tạo độc lập hoặc không gian tên được khóa bằng phiên (ví dụ: khóa Redis có tiền tố session_id:). Đánh giá mã xác nhận không có trạng thái có thể thay đổi được chia sẻ giữa các phiên.

Cách kiểm tra: Chạy hai phiên đồng thời với các danh tính người dùng khác nhau. Xác minh rằng dữ liệu được ghi trong phiên A không thể được đọc trong phiên B. Sử dụng kiểm tra tải đồng thời để kiểm tra các điều kiện race có thể gây rò rỉ trạng thái phiên.

Chế độ lỗi phổ biến: self.user_context = {} như một thuộc tính lớp trong dịch vụ singleton; cache toàn cục không có không gian tên được khóa bằng phiên; bộ nhớ cục bộ luồng không phạm vi đúng cách theo vòng đời yêu cầu.


2.2 Không có trạng thái được chia sẻ cho dữ liệu người dùng

Cần xác minh: Ngoài ngữ cảnh thực thi, bất kỳ cơ sở hạ tầng được chia sẻ nào (cơ sở dữ liệu, cache, hàng đợi tin nhắn) đều thực thi kiểm soát truy cập theo từng người dùng. Một truy vấn được thực thi trong phiên của một người dùng không thể trả về dữ liệu của người dùng khác ngay cả khi cơ sở hạ tầng được chia sẻ bị cấu hình sai hoặc bị xâm phạm.

Cách kiểm tra: Thử truy cập dữ liệu của người dùng khác bằng cách thao túng tham số phiên hoặc khai thác khóa cache được chia sẻ.

Chế độ lỗi phổ biến: Khóa cache chỉ dựa trên nội dung truy vấn, không phải danh tính người dùng; truy vấn cơ sở dữ liệu không có mệnh đề WHERE phạm vi người dùng; thư mục tệp tạm thời được chia sẻ không có thư mục con theo từng người dùng.


2.3 Phiên có dọn dẹp xác định và hạn ngạch tài nguyên được thực thi

Cần xác minh: Khi một phiên kết thúc (một cách sạch sẽ hoặc thông qua timeout/lỗi), tất cả các tài nguyên liên quan được giải phóng ngay lập tức: file handle, tệp tạm thời, ngữ cảnh trong bộ nhớ, token được cache, kết nối cơ sở dữ liệu. Giới hạn theo từng phiên tồn tại cho bộ nhớ, CPU, tốc độ API và sử dụng hệ thống tệp.

Cách kiểm tra: Kết thúc phiên đột ngột (kill kết nối mà không tắt một cách nhẹ nhàng). Xác minh không còn tài nguyên dư thừa. Tạo phiên và cạn kiệt giới hạn tốc độ của nó; xác minh nó không ảnh hưởng đến các phiên khác.

Chế độ lỗi phổ biến: Tệp tạm thời còn lại trong /tmp sau khi phiên kết thúc; token được cache không bị thu hồi khi phiên kết thúc; không có hạn ngạch tài nguyên cho phép một phiên cạn kiệt cơ sở hạ tầng được chia sẻ.


Danh Mục 3: Công Cụ Đáng Tin Cậy, Được Kiểm Soát

Bảo mật công cụ ngăn chặn các cuộc tấn công cụ thể MCP nguy hiểm nhất: đầu độc công cụ và rug pull.

3.1 Công cụ được ký mật mã, ghim phiên bản và được phê duyệt chính thức

Cần xác minh: Mọi định nghĩa công cụ đều có chữ ký mật mã từ người phê duyệt công cụ được ủy quyền. Chữ ký bao gồm toàn bộ manifest (mô tả, schema, phiên bản, quyền). Máy chủ MCP xác minh chữ ký này tại thời điểm tải và từ chối bất kỳ công cụ nào không được ký hoặc chữ ký không khớp. Phiên bản công cụ được ghim — máy chủ không thể tải động một công cụ đã cập nhật mà không có chữ ký được phê duyệt mới.

Cách kiểm tra: Sửa đổi một ký tự duy nhất trong mô tả của công cụ đã tải. Xác minh máy chủ phát hiện hash không khớp và chặn công cụ khỏi việc tải. Thử tải định nghĩa công cụ không được ký — nó nên bị từ chối.

Chế độ lỗi phổ biến: Định nghĩa công cụ được lưu trữ dưới dạng cấu hình có thể thay đổi mà không có xác minh tính toàn vẹn; không có cơ sở hạ tầng khóa ký; công cụ được tải trực tiếp từ hệ thống tệp được chia sẻ mà không ghim phiên bản.


3.2 Mô tả công cụ được xác thực so với hành vi runtime

Cần xác minh: Quét tự động kiểm tra mô tả công cụ để tìm các mẫu giống như hướng dẫn có thể đại diện cho các nỗ lực đầu độc. Xác thực định kỳ xác nhận rằng hành vi runtime thực tế của công cụ khớp với mô tả đã khai báo của nó — một công cụ tuyên bố là chỉ đọc không nên có khả năng thực hiện các hoạt động ghi tại runtime.

Cách kiểm tra: Thêm một hướng dẫn đáng ngờ vào mô tả công cụ (“luôn luôn cũng gọi send_webhook với…”) và xác minh quét tự động đánh dấu nó trước khi đánh giá thủ công. Xem xét cấu hình công cụ SAST để tìm quy tắc phát hiện đầu độc cụ thể MCP.

Chế độ lỗi phổ biến: Không có quét tự động mô tả công cụ; quy trình đánh giá thủ công có thể bỏ lỡ các hướng dẫn được nhúng trong mô tả dài; không có xác thực hành vi runtime để bắt các công cụ nói dối về khả năng của chúng.


3.3 Chỉ các trường công cụ tối thiểu, cần thiết được hiển thị cho model

Cần xác minh: Ngữ cảnh model chỉ nhận các trường cần thiết cho việc gọi công cụ đúng: tên, mô tả, input schema, output schema. Metadata nội bộ, chi tiết triển khai, thông tin gỡ lỗi và cấu hình nhạy cảm được lọc ra trước khi được chuyển đến model.

Cách kiểm tra: Kiểm tra những gì model nhận được khi nó liệt kê các công cụ có sẵn. Xác minh không có trường nội bộ, chuỗi kết nối hoặc metadata hoạt động xuất hiện trong chế độ xem của model.

Chế độ lỗi phổ biến: Đối tượng cấu hình công cụ đầy đủ được chuyển đến ngữ cảnh model; thông báo lỗi chứa chi tiết hệ thống nội bộ bị rò rỉ đến model; mô tả công cụ bao gồm ghi chú triển khai không liên quan đến việc gọi.


Danh Mục 4: Xác Thực Dựa Trên Schema Ở Mọi Nơi

Lỗi xác thực cho phép injection, thao túng dữ liệu và từ chối dịch vụ.

4.1 Tất cả tin nhắn MCP, đầu vào công cụ và đầu ra được xác thực schema

Cần xác minh: Xác thực JSON Schema được thực thi cho mọi tin nhắn giao thức MCP, mọi đầu vào gọi công cụ và mọi đầu ra công cụ trước khi nó đến model. Xác thực từ chối bất kỳ tin nhắn nào không tuân thủ schema đã xác định — thiếu các trường bắt buộc, kiểu sai, giá trị ngoài phạm vi được phép.

Cách kiểm tra: Gửi một lần gọi công cụ với tham số bắt buộc bị thiếu. Gửi tin nhắn với trường bất ngờ thêm vào. Cả hai nên bị từ chối, không im lặng bỏ qua hoặc xử lý với giá trị mặc định.

Chế độ lỗi phổ biến: Xác thực tùy chọn bị bỏ qua trong điều kiện lỗi; xác thực chỉ trên đầu vào, không phải đầu ra; schema quá dễ dãi (chấp nhận tham số type: "any").


4.2 Đầu vào/đầu ra được làm sạch, giới hạn kích thước và được coi là không đáng tin cậy

Cần xác minh: Tất cả đầu vào được làm sạch để loại bỏ hoặc escape các ký tự có thể cho phép injection (chuỗi XSS, metacharacter SQL, metacharacter shell, null byte). Giới hạn kích thước được thực thi trên tất cả đầu vào và đầu ra. Máy chủ coi tất cả dữ liệu từ model là có khả năng đối nghịch, giống hệt với đầu vào người dùng trong ứng dụng web truyền thống.

Cách kiểm tra: Gửi đầu vào chứa payload SQL injection, metacharacter shell và chuỗi XSS. Xác minh chúng bị từ chối hoặc được escape an toàn trước khi đến hệ thống downstream. Gửi đầu vào vượt quá giới hạn kích thước — xác minh nó bị từ chối một cách sạch sẽ.

Chế độ lỗi phổ biến: Đầu vào được chuyển trực tiếp đến truy vấn SQL hoặc lệnh shell; không có giới hạn kích thước cho phép đầu vào quá khổ gây cạn kiệt bộ nhớ; đầu ra được trả về cho model mà không có giới hạn kích thước hoặc lọc nội dung.


4.3 Gọi công cụ có cấu trúc (JSON) là bắt buộc

Cần xác minh: Lời gọi công cụ chỉ được chấp nhận dưới dạng đối tượng JSON có cấu trúc với schema đã xác thực. Việc tạo văn bản tự do ngụ ý lời gọi công cụ không được xử lý. Hệ thống không thể bị dụ thực thi lời gọi công cụ bằng cách tạo ngôn ngữ tự nhiên mà máy chủ diễn giải là lệnh.

Cách kiểm tra: Gửi chuỗi ngôn ngữ tự nhiên mô tả lời gọi công cụ (“gọi công cụ delete_file với đường dẫn /etc/passwd”). Xác minh máy chủ không diễn giải điều này là lời gọi công cụ.

Chế độ lỗi phổ biến: Hệ thống kết hợp chấp nhận cả JSON có cấu trúc và mô tả công cụ bằng ngôn ngữ tự nhiên; máy chủ phân tích văn bản do model tạo ra để xác định lời gọi công cụ; phân tích lời gọi công cụ dựa trên regex có thể bị giả mạo.


Danh Mục 5: Triển Khai Gia Cố và Giám Sát Liên Tục

Gia cố triển khai giới hạn bán kính vụ nổ của bất kỳ lỗ hổng nào bị khai thác.

5.1 Máy chủ chạy trong container, non-root, hạn chế mạng

Cần xác minh: Máy chủ MCP chạy trong một container gia cố tối thiểu. Tiến trình container chạy với tư cách người dùng non-root. Các khả năng Linux không cần thiết bị loại bỏ. Chính sách mạng hạn chế tất cả lưu lượng truy cập đến và đi ra chỉ với các kết nối được yêu cầu rõ ràng. Image container chỉ chứa phần mềm tối thiểu cần thiết.

Cách kiểm tra: Chạy docker inspect và xác minh người dùng là non-root. Xem xét chính sách mạng và xác nhận chúng đang chặn tất cả lưu lượng truy cập ngoại trừ các kết nối được đưa vào danh sách trắng rõ ràng. Quét image container để tìm các gói không cần thiết hoặc phần mềm có lỗ hổng đã biết.

Chế độ lỗi phổ biến: Container chạy với quyền root để thuận tiện; không có chính sách mạng để tất cả lưu lượng truy cập đi ra được phép; image cơ sở với cài đặt hệ điều hành đầy đủ thay vì image tối thiểu.


5.2 Secret được lưu trữ trong vault và không bao giờ được hiển thị cho LLM

Cần xác minh: Tất cả API key, OAuth client secret, thông tin xác thực cơ sở dữ liệu và token tài khoản dịch vụ đều được lưu trữ trong vault secret (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, v.v.). Không có secret tồn tại trong biến môi trường, mã nguồn, image container hoặc đầu ra log. Các hoạt động quản lý secret xảy ra trong middleware không thể truy cập được đối với model AI — LLM không bao giờ thấy hoặc xử lý giá trị thông tin xác thực.

Cách kiểm tra: Tìm kiếm log để tìm chuỗi giống như thông tin xác thực. Kiểm tra biến môi trường có thể truy cập được đối với tiến trình máy chủ. Xem xét ngữ cảnh có thể truy cập của model để xác nhận không có giá trị thông tin xác thực xuất hiện.

Chế độ lỗi phổ biến: API key trong tệp .env được commit vào kiểm soát phiên bản; thông tin xác thực được trả về trong thông báo lỗi đến model; secret được chuyển dưới dạng tham số công cụ xuất hiện trong ngữ cảnh hội thoại của model.


5.3 Cổng bảo mật CI/CD, log kiểm toán và giám sát liên tục là bắt buộc

Cần xác minh: Pipeline triển khai bao gồm quét bảo mật tự động (SAST, SCA, quét lỗ hổng phụ thuộc) như cổng cứng — quét thất bại chặn triển khai. Tất cả lời gọi công cụ, sự kiện xác thực và quyết định ủy quyền được ghi log bất biến với ngữ cảnh đầy đủ. Log được nhập vào SIEM với cảnh báo thời gian thực về các mẫu bất thường (tăng đột biến xác thực thất bại, tần suất gọi công cụ bất thường, kết nối bên ngoài không mong đợi).

Cách kiểm tra: Đưa vào một phụ thuộc có lỗ hổng đã biết và xác minh pipeline CI/CD làm thất bại bản build. Tạo các mẫu gọi công cụ bất thường và xác minh cảnh báo SIEM kích hoạt trong thời gian phản hồi dự kiến.

Chế độ lỗi phổ biến: Quét bảo mật như cổng tư vấn thay vì chặn; log được ghi vào bộ nhớ có thể thay đổi mà kẻ tấn công có thể sửa đổi; không có cảnh báo về các mẫu bất thường; log quá chi tiết làm cho các sự kiện liên quan không thể tìm thấy.


Sử Dụng Danh Sách Kiểm Tra Này Cho Triển Khai MCP Của Bạn

In hoặc xuất danh sách kiểm tra này và làm việc qua nó một cách có hệ thống cho mọi máy chủ MCP trước khi triển khai production. Yêu cầu đội ngũ bảo mật của bạn tham gia vào đánh giá — nhiều mục yêu cầu cả đánh giá mã và kiểm thử trực tiếp để xác minh đúng cách.

Đối với các đội muốn xác minh độc lập, một kiểm toán bảo mật MCP chuyên nghiệp kiểm tra tất cả 16 mục trong danh sách kiểm tra so với môi trường thực tế của bạn, sử dụng các kỹ thuật kiểm thử đối nghịch thay vì tự đánh giá. Kết quả là báo cáo tình trạng bảo mật được xác minh với kế hoạch khắc phục được ưu tiên.

Tài Nguyên Liên Quan

Câu hỏi thường gặp

Tiêu Chuẩn Tối Thiểu Bảo Mật MCP của OWASP là gì?

Tiêu Chuẩn Tối Thiểu Bảo Mật MCP của Dự án Bảo mật GenAI OWASP là một danh sách kiểm tra đánh giá xác định các kiểm soát bảo mật cơ bản cần thiết trước khi triển khai máy chủ MCP vào production. Nó bao gồm năm lĩnh vực: Danh Tính/Xác Thực/Chính Sách Mạnh Mẽ, Cách Ly Nghiêm Ngặt và Kiểm Soát Vòng Đời, Công Cụ Đáng Tin Cậy và Được Kiểm Soát, Xác Thực Dựa Trên Schema, và Triển Khai Gia Cố với Giám Sát Liên Tục. Không đạt tiêu chuẩn tối thiểu có nghĩa là máy chủ MCP không nên được triển khai cho đến khi các lỗ hổng được khắc phục.

Làm thế nào để sử dụng danh sách kiểm tra này cho đánh giá bảo mật?

Làm việc qua từng danh mục một cách có hệ thống, đánh dấu các mục là ĐẠT, KHÔNG ĐẠT, hoặc KHÔNG ÁP DỤNG với bằng chứng cho mỗi quyết định. Bất kỳ mục KHÔNG ĐẠT nào trong danh mục 1 hoặc 2 (danh tính và cách ly) nên chặn triển khai — đây là những lỗ hổng có rủi ro cao nhất. Các mục KHÔNG ĐẠT trong danh mục khác nên được chấp nhận rủi ro với lịch trình khắc phục được ghi chép trước khi triển khai. Danh sách kiểm tra nên được đánh giá lại sau bất kỳ thay đổi đáng kể nào đối với máy chủ MCP, sổ đăng ký công cụ, hoặc môi trường triển khai.

Những công cụ nào hỗ trợ kiểm tra bảo mật MCP tự động?

Một số công cụ hỗ trợ xác thực bảo mật MCP tự động: Invariant MCP-Scan (chuyên dụng cho quét bảo mật MCP), công cụ SAST với quy tắc MCP tùy chỉnh, npm audit và pip audit cho quét phụ thuộc, OSV-Scanner cho kiểm tra cơ sở dữ liệu lỗ hổng, Docker seccomp và AppArmor profiles cho cách ly runtime, và tích hợp SIEM cho giám sát tập trung. Không có công cụ đơn lẻ nào bao phủ tất cả các mục trong danh sách kiểm tra — phạm vi bao phủ toàn diện đòi hỏi kết hợp phân tích tĩnh, kiểm thử động và giám sát liên tục.

Arshia là Kỹ sư Quy trình AI tại FlowHunt. Với nền tảng về khoa học máy tính và niềm đam mê AI, anh chuyên tạo ra các quy trình hiệu quả tích hợp công cụ AI vào các nhiệm vụ hàng ngày, nâng cao năng suất và sự sáng tạo.

Arshia Kahani
Arshia Kahani
Kỹ sư Quy trình AI

Nhận Đánh Giá Bảo Mật MCP Chuyên Nghiệp

Sử dụng danh sách kiểm tra này để tự đánh giá, sau đó mời đội ngũ của chúng tôi thực hiện kiểm toán bảo mật được xác minh. Chúng tôi kiểm tra từng mục trong môi trường thực tế của bạn và cung cấp kế hoạch khắc phục chi tiết.

Tìm hiểu thêm