Phân tích xác thực và phân quyền để tìm lỗ hổng

Khi một agent đọc dữ liệu và gọi tool thay cho người dùng, câu hỏi bảo mật không còn đơn giản là "đăng nhập chưa". Phải hỏi: agent đang hành động thay cho ai, người đó được thấy gì, và token nào đang đi tới đâu. Phần lớn lỗ hổng nằm ở chỗ trả lời sai một trong ba câu đó.

Bài này giúp bạn trả lời: đọc một bản thiết kế, làm sao nhận ra lỗ hổng xác thực (authentication) và phân quyền (authorization), và sửa ở đâu?

Ví dụ xuyên suốt: trợ lý nội bộ của một công ty bất động sản

Một công ty bất động sản làm trợ lý dùng Claude cho hai nhóm người:

• Nhân viên kinh doanh của công ty: xem giá sàn, hợp đồng, thông tin khách trong CRM.
• Môi giới bên ngoài (đối tác): chỉ xem bảng giá công khai và tình trạng căn hộ của dự án mình được phân phối.

Trợ lý truy xuất tài liệu từ kho hợp đồng, và gọi CRM qua một MCP server chạy trên HTTP. Bản thiết kế đầu tiên có những dòng sau:

1. Mọi người dùng chung một API key để gọi CRM.
2. Key CRM được đặt trong system prompt "để Claude tự gọi".
3. Trợ lý truy xuất mọi tài liệu khớp câu hỏi, rồi lọc bỏ nội dung môi giới không được xem ở bước hiển thị câu trả lời.
4. Log gọi tool ghi tên tool và tham số, không ghi ai yêu cầu.

Hai câu hỏi: ai đang gọi, và được làm gì

Xác thực trả lời "ai". Phân quyền trả lời "được làm gì". Dòng 1 và dòng 4 làm hỏng câu "ai":

• Key dùng chung nghĩa là CRM chỉ thấy một danh tính duy nhất cho mọi người. Không phân quyền theo người được, không thu hồi quyền của một người được.
• Log không ghi người khởi tạo thì khi có sự cố, không truy được ai đã yêu cầu hành động đó.

Kiểm quyền trước khi dữ liệu tới model

Dòng 3 là lỗi thứ tự. Khi tài liệu môi giới không được xem đã được truy xuất, nó đã nằm trong context của Claude: có thể lộ qua câu trả lời, qua suy luận, hay bị một prompt injection moi ra. Lọc ở bước hiển thị là quá muộn.

Chỗ đúng để áp kiểm soát truy cập theo vai trò (RBAC) là tầng truy xuất: truy vấn chỉ trả về tài liệu mà vai trò của người hỏi được xem, trước khi bất cứ thứ gì được đưa vào prompt.

Credential không được nằm trong prompt

Dòng 2 là lỗ hổng rõ nhất: credential trong context của model có thể lọt vào log, trace, hay bị lộ qua câu trả lời. Docs của Anthropic về chống prompt injection cũng khuyên giới hạn quyền truy cập dữ liệu và hành động của Claude.

Cách làm đúng: Claude chỉ đưa ra yêu cầu gọi tool; code của bạn chạy lời gọi đó ở phía server, lấy credential từ kho bí mật, dưới một danh tính có quyền tối thiểu cho đúng hành động, hoặc bằng token của chính người dùng. Với MCP connector của Messages API, bạn truyền authorization_token cho server; docs nói bạn phải tự xử lý luồng OAuth và lấy access token trước khi gọi API.

Uỷ quyền cho MCP server chạy trên HTTP

MCP server của CRM chạy qua HTTP, nên áp phần uỷ quyền của đặc tả MCP. Server chạy cục bộ qua STDIO thì không theo phần này; đặc tả nói chúng lấy credential từ môi trường.

Những điểm chính của đặc tả (bản 2026-07-28):

1. Dựa trên OAuth 2.1. Client gọi server chưa có token thì nhận 401 kèm header WWW-Authenticate chỉ tới tài liệu metadata của server, từ đó tìm ra authorization server.
2. PKCE bắt buộc, dùng phương thức S256; authorization server không công bố hỗ trợ PKCE thì client phải dừng.
3. Đăng ký client theo thứ tự ưu tiên: thông tin đăng ký sẵn, rồi Client ID Metadata Document, rồi Dynamic Client Registration (đã bị đánh dấu lỗi thời), cuối cùng mới hỏi người dùng nhập.
4. Token gắn với đúng một server. Client gửi tham số resource là URI chuẩn của MCP server khi xin token; server phải kiểm token được cấp cho chính nó.
5. Không chuyển tiếp token (token passthrough). MCP server không được lấy token nhận từ client đem gọi API phía sau. Gọi API phía sau phải dùng một token riêng do authorization server của API đó cấp. Tài liệu bảo mật của MCP giải thích: chuyển tiếp token làm vô hiệu các kiểm soát an ninh, làm hỏng việc kiểm toán (không phân biệt được client nào gọi), và phá ranh giới tin cậy.
6. 401 khác 403. 401 là chưa xác thực hoặc token hỏng, phải xác thực lại. 403 với insufficient_scope là token hợp lệ nhưng thiếu quyền; client xin thêm quyền (step-up) với tập scope gộp cả cũ và mới, có giới hạn số lần thử. Đăng nhập lại y như cũ sẽ chỉ nhận lại đúng tập quyền cũ.
7. Scope tối thiểu. Tài liệu bảo mật khuyên mô hình quyền tăng dần theo nhu cầu, tránh scope "bao trùm mọi thứ".

Trong Claude Code, server từ xa cần đăng nhập thì xác thực qua lệnh /mcp; tổ chức có thể quản lý tập trung danh sách MCP server được phép bằng cấu hình managed.