Với một sản phẩm SaaS đa tenant, có một lời hứa quan trọng hơn gần như mọi tính năng khác: Khách hàng A không bao giờ được nhìn thấy hoặc thay đổi dữ liệu của khách hàng B.
Nghe giống một yêu cầu thuộc về backend, nhưng thực tế việc cô lập dữ liệu giữa các tenant — mỗi tenant là một tổ chức khách hàng dùng chung nền tảng — là năng lực xuyên suốt cấu trúc dữ liệu, phân quyền, API, cập nhật thời gian thực, tệp, tìm kiếm, xuất dữ liệu và giao diện.
Ngữ cảnh tenant phải rõ ràng
Kiến trúc SaaS tốt phải trả lời được cho mỗi bản ghi: Tổ chức nào sở hữu dữ liệu này?
Các công cụ phổ biến gồm:
organization_idhoặc một khóa tenant tương đương;- khóa ngoại giữ được quan hệ sở hữu;
- phân quyền phía máy chủ;
- đường dẫn lưu trữ tách theo tenant;
- tác vụ nền và webhook có phạm vi rõ ràng;
- nhật ký truy vết ghi lại người thực hiện và tổ chức.
Cách triển khai có thể khác nhau, nhưng để tenant ở dạng ngầm định là nguy hiểm. Nếu quyền sở hữu dựa vào giả định ở phía trình duyệt, chỉ một truy vấn thiếu điều kiện lọc cũng có thể làm lộ dữ liệu.
Kiểm tra vai trò trên frontend không phải là bảo mật
Ẩn nút “Quản trị” là trải nghiệm đúng, nhưng không phải là phân quyền. Người dùng vẫn có thể gọi API trực tiếp.
Một sản phẩm SaaS trưởng thành nên phân biệt:
- Chặn theo vai trò trên giao diện: người dùng nên nhìn thấy gì;
- Phân quyền phía máy chủ: người dùng được phép thực hiện gì;
- Cô lập ở cơ sở dữ liệu: mỗi yêu cầu được phép đọc/ghi những dòng nào.
Row-level security (RLS — bảo mật theo từng dòng dữ liệu) có thể rất mạnh vì đưa ranh giới tenant xuống gần dữ liệu, nhưng phải kiểm thử theo từng vai trò và từng thao tác. SELECT, INSERT, UPDATE, DELETE có thể có quy tắc khác nhau.
Super-admin cần được soi kỹ hơn
Quản trị viên nội bộ của nền tảng đôi khi cần thao tác xuyên tenant để hỗ trợ khách hàng, xử lý thanh toán hoặc quản lý tài khoản. Đây là một luồng đặc quyền và nên được giới hạn rõ ràng, hẹp nhất có thể.
Cần hỏi:
- hành động nào thực sự cần quyền xuyên tenant?
- có nhật ký truy vết không?
- nhân viên hỗ trợ có thể thao tác nhầm tenant không?
- hành động có tính phá hủy có yêu cầu xác nhận rõ tổ chức không?
- công cụ chạy nền có nhiều quyền hơn cần thiết không?
Thiết kế an toàn nên làm cho quyền ngoại lệ dễ nhận biết, thay vì ẩn nó trong hành vi bình thường.
Thời gian thực và tệp có thể phá vỡ giả định
Đội ngũ thường tập trung vào truy vấn cơ sở dữ liệu mà quên các kênh khác.
Kênh cập nhật thời gian thực cần giới hạn theo tenant. Kho lưu trữ tệp và đường dẫn có chữ ký cần kiểm tra quyền sở hữu. Chỉ mục tìm kiếm, dữ liệu xuất, thông báo và dữ liệu phân tích cũng không được trộn lẫn giữa các tenant.
Một hệ thống có RLS tốt vẫn có thể lộ dữ liệu qua thông báo hoặc đường dẫn tệp.
Trạng thái lỗi cũng là một phần của bảo mật
Giả sử truy vấn kiểm tra quyền thất bại. Nếu giao diện hiểu là “người dùng không có quyền”, màn hình có vẻ an toàn nhưng kết luận nghiệp vụ lại sai. Nếu truy vấn dữ liệu thất bại nhưng giao diện báo “không có bản ghi”, người quản lý có thể ra quyết định từ dữ liệu chưa hề được đo.
Bảo mật và sự thật của dữ liệu gặp nhau ở cách thiết kế trạng thái:
DENIED ≠ FAILED
EMPTY ≠ FAILED
ZERO ≠ UNKNOWN
Điều này đặc biệt quan trọng ở màn hình quản trị, thanh toán, tính lương, cấp phát token và khóa API.
Kiểm thử ranh giới, không chỉ kịch bản thuận lợi
Một ma trận kiểm thử đa tenant có ý nghĩa nên gồm:
- người dùng A đọc tenant A → được phép;
- người dùng A đọc tenant B → bị từ chối hoặc không nhận được dòng nào, đúng theo chính sách;
- thao tác thay đổi dữ liệu theo vai trò quản lý, quản trị và theo từng loại thao tác;
- gọi API trực tiếp, không đi qua giao diện;
- cập nhật thời gian thực xuyên tenant;
- truy cập tệp xuyên tenant;
- thiếu ngữ cảnh tổ chức;
- ngoại lệ dành cho super-admin.
Nhãn bằng chứng cũng quan trọng. Một nút bị ẩn chỉ chứng minh hành vi của giao diện. Nó không chứng minh RLS.
Niềm tin được tích lũy bằng kiến trúc
Khách hàng doanh nghiệp ngày càng đánh giá không chỉ tính năng mà cả quyền kiểm soát: ai đọc được gì, hành động có được ghi nhật ký không, và hệ thống có thể mở rộng mà không làm việc phân quyền trở nên mơ hồ hay không.
Vì vậy, bảo mật đa tenant nên là một phần cam kết của sản phẩm ngay từ đầu. Bổ sung về sau, khi sản phẩm đã lớn, khó hơn nhiều, vì các giả định về dữ liệu và quyền đã lan khắp hệ thống.
NAIT tiếp cận SaaS B2B với ranh giới tenant, sự rõ ràng về quyền và khả năng truy vết như những yêu cầu sản phẩm hàng đầu, không phải chi tiết kỹ thuật để “làm sau”.