Ý chính: Phần lớn sự cố lộ dữ liệu giữa khách hàng bắt nguồn từ một điều kiện bị bỏ quên, không phải từ kỹ thuật tấn công phức tạp.
Thuật ngữ trong bài: Tenant: một khách hàng dùng nền tảng; RLS: chính sách giới hạn từng dòng dữ liệu ngay tại cơ sở dữ liệu; fail closed: thiếu thông tin thì từ chối truy cập.
Bài toán thực tế
Đăng nhập thành công không có nghĩa là người dùng được phép xem mọi tài nguyên. Chỉ một truy vấn thiếu mã khách hàng cũng có thể trả nhầm dữ liệu. Vì vậy, quyền truy cập phải được kiểm tra lại ở từng lớp quan trọng.
Điểm dễ bị bỏ qua
Xác thực chỉ trả lời người gọi là ai; cô lập dữ liệu còn phải trả lời họ được phép làm gì với tài nguyên nào. Câu trả lời đó phải nhất quán ở API, tác vụ nền, cache, xuất dữ liệu và kho tệp.
Không nên đặt toàn bộ niềm tin vào một điều kiện lọc ở tầng ứng dụng. Ranh giới quan trọng cần được kiểm tra lại ở cơ sở dữ liệu và ở mọi điểm dữ liệu rời khỏi hệ thống.
Luồng xử lý
Định danh người dùng và site→Phân quyền
Thành viên và quyền hạn→Truy vấn khách hàng
RLS và bộ lọc phạm vi→Lưu trữ tệp
Khóa an toàn từ máy chủ
Thiết kế và triển khai
Suy ra ngữ cảnh khách hàng ở phía server
Xác định ngữ cảnh khách hàng (thông tin khách hàng gắn theo phiên/transaction) bằng cách đối chiếu membership (quan hệ thành viên trong tổ chức) của principal (chủ thể đã xác thực) với site được yêu cầu.
Ép phạm vi tại cơ sở dữ liệu
Thiết lập ngữ cảnh khách hàng theo từng transaction, rồi áp dụng RLS (row-level bảo mật — bảo mật ở mức từng dòng dữ liệu) hoặc một điều kiện composite bắt buộc.
Mang định danh vào luồng xử lý bất đồng bộ
Mỗi nội dung dữ liệu tác vụ cần chứa khách hàng, actor, một quyền hạn bản chụp hoặc khóa tái xác thực, và một correlation ID (mã lần chạy để truy vết).
Đi sâu vào thiết kế
Phân quyền là một đồ thị quan hệ, không phải một câu trả lời đúng/sai
Quyền truy cập có thể phụ thuộc vào membership tổ chức, role tại site, quyền sở hữu tài nguyên, delegation và subscription hiện tại. Hãy giải các quan hệ này thành một quyết định rõ ràng, kèm nguyên nhân code.
Xem mỗi ranh giới là một lớp có thể hỏng độc lập
RLS bảo vệ các dòng dữ liệu, nhưng không bảo vệ object kho lưu trữ, search chỉ mục, nhật ký hay cache entry. Hãy sinh kho lưu trữ khóa từ mã khách hàng do server quản lý, cấp signed URL (URL có chữ ký, hết hạn ngắn), và kiểm tra metadata của object tải lên trước khi publish.
Cách triển khai
- Ràng buộc site được yêu cầu với khách hàng trong phiên đăng nhập trước khi chạy nghiệp vụ.
- Thiết lập ngữ cảnh khách hàng ở cơ sở dữ liệu và từ chối truy vấn nếu ngữ cảnh bị thiếu.
- Tạo đường dẫn tệp ở phía máy chủ và chỉ cấp URL tải lên hoặc tải xuống có thời hạn ngắn.
Mã minh họa: Giới hạn ngữ cảnh khách hàng trong một giao dịch
BEGIN
SET LOCAL app.tenant_id = :tenantId
SET LOCAL app.actor_id = :actorId
SELECT * FROM documents
WHERE site_id = :siteId AND id = :documentId
-- RLS policy đồng thời yêu cầu:
tenant_id = current_setting('app.tenant_id')
COMMITDùng thiết lập chỉ tồn tại trong giao dịch để kết nối tái sử dụng không mang ngữ cảnh khách hàng sang yêu cầu kế tiếp.
Rủi ro cần tính trước
- Mã tài nguyên duy nhất trên toàn hệ thống khiến lập trình viên vô tình truy vấn chỉ bằng ID mà quên mã khách hàng.
- Khóa cache chứa ID tài nguyên nhưng thiếu mã khách hàng hoặc phiên bản quyền.
- Tác vụ xuất dữ liệu được cấp quyền lúc đưa vào hàng đợi nhưng quyền đã đổi trước khi nó chạy.
Nên theo dõi gì?
| Tín hiệu | Điều tín hiệu cho biết |
|---|---|
| Số lần bị từ chối do sai khách hàng | Tăng đột biến có thể là dò quét, liên kết hỏng hoặc ứng dụng khách giữ ngữ cảnh cũ. |
| Truy vấn thiếu ngữ cảnh khách hàng | Mọi trường hợp đều phải được xem là lỗi bảo mật, không chỉ lỗi ứng dụng. |
| Mức bao phủ kiểm thử chính sách RLS | Cho biết mỗi bảng đã có đủ kiểm thử cho truy cập hợp lệ lẫn truy cập chéo hay chưa. |
| Mức sử dụng vai trò đặc quyền | Hoạt động bỏ qua kiểm soát ngoài dự kiến cần tạo cảnh báo kiểm toán ưu tiên cao. |
Cách kiểm chứng
- Lập một ma trận quyền phủ người phụ trách, member, người được mời, người đã bị xóa và service account, trên hai khách hàng.
- Fuzz từng tài nguyên endpoint bằng cách thay khách hàng, site và object ID một cách độc lập.
- Chạy tác vụ nền và export sau khi thu hồi role của người khởi tạo, để kiểm chứng chính sách tái phân quyền đã chọn.
- Kiểm tra khóa cache, search document và object-kho lưu trữ khóa ngay trong test; chỉ cô lập ở cơ sở dữ liệu thì chưa đủ làm bằng chứng.
- Dùng stress test trên nhóm kết nối dùng lại để chứng minh ngữ cảnh khách hàng theo transaction của RLS không bao giờ rò giữa các yêu cầu đồng thời.
Đưa vào production từng bước
Trước tiên, ghi nhận những truy vấn sẽ vi phạm chính sách mới nhưng chưa chặn người dùng. Sửa từng điểm gọi, bổ sung kiểm thử chéo giữa hai khách hàng, rồi bật RLS theo từng bảng, bắt đầu từ vùng dữ liệu có lưu lượng thấp.
Checklist trước khi vận hành
- Việc kiểm tra lặp lại ở nhiều lớp là chiến lược phòng thủ chiều sâu (defense in depth) cần thiết.
- Khóa cache và các tác vụ tác vụ nền phải luôn đi kèm ngữ cảnh khách hàng tương tự HTTP yêu cầu.
- Đưa kịch bản truy cập chéo khách hàng thành bài kiểm thử bảo mật tự động bắt buộc.
Điều cần nhớ
Cô lập khách hàng là một chuỗi bảo vệ liên tục. Chỉ một mắt xích bỏ quên mã khách hàng cũng đủ tạo ra sự cố rò rỉ dữ liệu nghiêm trọng.