Ý 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.
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.
Thiết kế và 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. |
Đư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.
Đ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.