Cách ly tenant SaaS nghĩa là khách hàng chỉ truy cập hồ sơ và thao tác mà tổ chức của họ có quyền sử dụng. Bộ chọn tenant trong giao diện không đủ. Ranh giới phải được giữ khi yêu cầu, tác vụ nền, cache và tải tệp đi tới hệ thống bên dưới.
Kiểm thử cách ly tenant bằng tổ chức tách biệt, vai trò người dùng thông thường và cố ý thử vượt ranh giới. Xác minh đọc, ghi, tệp, phản hồi cache và công việc nền theo cùng quy tắc truy cập. Yêu cầu bằng chứng từ ranh giới backend được thực thi trước khi tiếp nhận khách hàng có hồ sơ nhạy cảm hoặc quan trọng thương mại.
Hãy hình dung cổng khách hàng nơi mỗi tổ chức thấy đơn mua hàng của mình. Màn hình danh sách trông đúng nhưng bản xuất tải xuống chứa dòng của tổ chức khác. Đó là lỗi cách ly dù đăng nhập và đường trang thông thường hoạt động đúng ý định.
Hướng dẫn giúp người phụ trách xác định phạm vi xác minh và khắc phục. Nó không khẳng định một kiểu cơ sở dữ liệu bảo đảm bảo mật hoặc danh sách kiểm tra thay thế đánh giá ứng dụng đầy đủ.
Xác định cách ly tenant SaaS trước khi chọn lưu trữ
Xác định tenant nghĩa là gì trong sản phẩm. Có thể là tổ chức khách hàng, pháp nhân hoặc không gian làm việc. Ghi cách người dùng tham gia, rời và chuyển giữa tenant, cùng vai trò hỗ trợ có thể hoạt động xuyên tenant. Quy tắc mơ hồ trở thành kiểm thử mơ hồ.
Hướng dẫn bảo mật đa tenant của OWASP mô tả cách ly qua ranh giới cơ sở dữ liệu, cache, lưu trữ và tính toán. Nó còn phân biệt bộ chọn tenant do client cung cấp với quyền được server xác minh. Dùng phân biệt này khi đánh giá đường yêu cầu thực tế của sản phẩm.
Xác định rõ quyền sở hữu dữ liệu. Danh mục sản phẩm chung có thể chủ động hiển thị cho nhiều khách hàng, trong khi ghi chú đơn hàng thuộc tenant. Kiểm thử cần biết khác biệt để phát hiện rò rỉ mà không xem thông tin chủ động chia sẻ là lỗi.
Lập bản đồ ngoại lệ quản trị. Nếu nhân viên hỗ trợ có thể xem hồ sơ khách hàng, giải thích ai cấp quyền, phạm vi giới hạn thế nào và việc dùng được ghi lại ra sao. Đường hỗ trợ mạnh cần kiểm thử như năng lực chủ định thay vì giấu ngoài mô hình tenant thông thường.
Theo ngữ cảnh tenant qua yêu cầu
Bắt đầu với người dùng đã xác thực và xác minh tư cách thành viên hiện tại hoặc quyền dịch vụ. Theo tenant đã chọn vào logic nghiệp vụ và truy cập dữ liệu. Kiểm tra đổi header, giá trị đường dẫn hoặc thân yêu cầu không thể thay quyền của tổ chức khác vào.
Mã định danh trông ngẫu nhiên có thể khó đoán hơn nhưng không xác lập quyền. Hướng dẫn phân quyền của OWASP khuyến nghị kiểm tra truy cập trên mọi yêu cầu. Kiểm thử mã có được hợp lệ từ tenant khác thay vì dựa vào việc người kiểm thử có đoán được hay không.
| Ranh giới | Thay đổi thử minh họa | Kết quả chấp nhận |
|---|---|---|
| Tra cứu hồ sơ | Yêu cầu mã đơn hàng đã biết của tenant khác | Từ chối không tiết lộ hồ sơ |
| Cập nhật | Gửi mã tenant khác trong payload hợp lệ | Không sửa trái phép |
| Đổi tenant | Chọn tổ chức không có tư cách thành viên | Server từ chối phạm vi yêu cầu |
| Endpoint hàng loạt | Đưa vào mã từ nhiều tenant | Từ chối đã định nghĩa không rò rỉ một phần |
| Hành động hỗ trợ | Dùng vai trò thường trên đường quyền cao | Từ chối và bằng chứng điều tra hữu ích |
Lặp lập luận với tìm kiếm, xuất dữ liệu và API khác. Màn hình chi tiết đầu tiên đúng không chứng minh báo cáo hàng loạt, endpoint di động hay đường tương thích cũ thực thi cùng ranh giới.
So sánh phương án dữ liệu theo kiểm soát thực tế
Cơ sở dữ liệu riêng, schema riêng và bảng chung tạo đánh đổi vận hành khác nhau. Không phương án nào bỏ nhu cầu xác minh thông tin xác thực, vai trò, truy vấn và đường quản trị. Đề xuất cần xác định ranh giới được thực thi ở đâu và điều gì xảy ra nếu mã ứng dụng bỏ bộ lọc.
| Phương án | Ranh giới cần kiểm tra | Công việc vận hành cần gồm |
|---|---|---|
| Cơ sở dữ liệu riêng | Quyền kết nối và thông tin xác thực | Cấp phát, di chuyển và tách sao lưu |
| Schema riêng | Vai trò dữ liệu và lựa chọn namespace | Cấp quyền, kỷ luật di chuyển và truy cập quản trị |
| Bảng chung | Quyền sở hữu tenant và chính sách truy cập được thực thi | Bao phủ truy vấn, vai trò yêu cầu và kiểm thử âm |
| Kết hợp | Quy tắc ghi lại cho mỗi nhóm dữ liệu | Định tuyến rõ và điều tra sự cố nhất quán |
Tránh xem chuyển sang cơ sở dữ liệu riêng là cách sửa mặc định mọi lỗi. Lỗi phân quyền có giới hạn có thể sửa có mục tiêu. Tương tự, thêm bộ lọc ở một controller không đủ nếu xuất dữ liệu, tác vụ và công cụ hỗ trợ vẫn dùng truy cập không giới hạn.
Kiểm thử vai trò yêu cầu sản xuất thực sự dùng
Tài liệu bảo mật hàng của PostgreSQL giải thích ngoại lệ quan trọng, gồm vai trò đặc quyền và chủ bảng. Khi sản phẩm dựa vào chính sách hàng, xác minh bằng vai trò yêu cầu hạn chế thực tế. Kiểm thử chạy với quản trị viên dữ liệu không đại diện ranh giới ứng dụng thông thường.
Đưa tài khoản triển khai và di chuyển vào danh mục. Chúng có thể hợp lệ cần quyền rộng hơn nhưng không nên thành danh tính thường dùng cho yêu cầu khách hàng. Ghi cách môi trường chạy lấy quyền dự kiến và cách kiểm tra sau triển khai.
Kiểm tra cache, tệp và đầu ra dẫn xuất
Kiểm tra khóa cache và phạm vi kết quả được cache. Mục tạo cho tổ chức này không được thành câu trả lời cho tổ chức khác vì yêu cầu dùng chung đường hoặc bộ lọc tiện lợi. Kiểm thử tenant thứ hai sau khi tenant đầu đã điền cache.
Tệp cần bằng chứng chấp nhận riêng. Xác minh quyền sở hữu tải lên, truy cập xem trước, tải xuống và báo cáo tạo ra. Trang có thể từ chối truy cập đúng trong khi URL đính kèm vẫn khả dụng qua đường không liên quan. Đưa liên kết cũ và đã cấp trước đây vào phạm vi kiểm thử thống nhất.
Kiểm tra dữ liệu dẫn xuất như chỉ mục tìm kiếm, gợi ý và bản xuất phân tích. Xác định hệ thống thực thi hạn chế tenant khi lấy dữ liệu, không chỉ lúc chèn. Thông tin có thể vượt ranh giới qua tóm tắt dù endpoint hồ sơ nguồn được bảo vệ.
Dùng dữ liệu kiểm thử kiểm soát thuộc các tổ chức riêng. Cho mỗi bên đủ nội dung nhận biết để phát hiện lẫn dữ liệu mà không chép tài liệu khách hàng thật vào đánh giá. Điều này giúp chẩn đoán cache hit bất ngờ hoặc bản xuất trộn dễ hơn.
Thử tác vụ nền và thay đổi thành viên
Công việc nền cần mang ngữ cảnh tenant đã xác minh qua hàng đợi vào thao tác. Kiểm tra điều gì xảy ra nếu tác vụ chậm, thử lại hoặc được worker khác lấy. Phạm vi tenant hợp lệ trong yêu cầu web không chứng minh tác vụ sau giữ nguyên.
Kiểm thử thay đổi tư cách thành viên. Người bị loại khỏi tổ chức không nên giữ truy cập thông thường qua phiên cache, bản xuất lưu hoặc thao tác chờ trái chính sách thống nhất. Xác định hành vi dự kiến cho công việc đã chấp nhận trước thu hồi.
Giả danh hỗ trợ và xóa tenant cũng cần chủ động bao phủ. Giải thích cách người vận hành rời phiên quyền cao và xử lý tệp, tác vụ và tham chiếu còn lại. Chính sách xóa đúng tùy nghĩa vụ lưu giữ của sản phẩm; đánh giá cần xác minh chính sách đã chọn thay vì tự tạo.
Hướng dẫn tiếp quản dự án phần mềm của chúng tôi phù hợp khi nhóm hiện tại không giải thích được các đường này. Khôi phục trách nhiệm triển khai, truy cập dữ liệu và tài liệu vận hành có thể góp phần làm ranh giới dễ bảo trì.
Chỉ định báo cáo xác minh hữu ích
Yêu cầu phát hiện cho thấy chủ thể, tenant, thao tác và tác động quan sát. Bao gồm yêu cầu liên quan và bằng chứng đích với giá trị nhạy cảm kiểm soát phù hợp. Phát hiện mang nhãn kiểm soát truy cập mà thiếu đường tái hiện khó sửa và khó kiểm thử lại.
OWASP ASVS có thể hỗ trợ yêu cầu bảo mật ứng dụng rộng hơn. Giữ ma trận chấp nhận riêng tenant cùng công việc đó để người rà soát thấy tổ chức, vai trò và loại tài nguyên nào đã thử.
Tách lỗi xác nhận khỏi đường chưa thử. Nếu người đánh giá không xem được dịch vụ lưu trữ riêng hoặc bản xuất quản trị, nói rõ. Giới hạn phạm vi trung thực hữu ích hơn kết luận thiếu căn cứ rằng mọi dữ liệu tenant đều cách ly.
Sau khắc phục, lặp ca lỗi ban đầu và ca hợp lệ lân cận. Bản sửa chặn mọi tải xuống có thể dừng rò rỉ nhưng làm hỏng sản phẩm. Chấp nhận cần cả từ chối truy cập trái phép lẫn tiếp tục công việc khách hàng được phép.
Dự trù ngân sách theo ranh giới thật của sản phẩm
Xác định phạm vi đánh giá theo loại tài nguyên, vai trò và đường vận hành thay vì chỉ số trang. Gồm tệp ngoài, cache, tác vụ nền và hỗ trợ khi chúng có thể lộ thông tin thuộc tenant. Cổng nhỏ có thể có ranh giới rộng hơn giao diện gợi ý.
| Gói công việc | Sản phẩm | Giả định cần làm rõ |
|---|---|---|
| Lập bản đồ ranh giới | Mô hình tenant và vai trò | Mức sẵn có của kiến thức kiến trúc |
| Xác minh | Bằng chứng truy cập dương và âm | Tài khoản và môi trường kiểm soát |
| Khắc phục | Thực thi đã sửa và kiểm tra hồi quy | Có cần thay đổi cấu trúc hay không |
| Bàn giao | Kiểm thử lặp lại và loại trừ đã biết | Người phụ trách sau tiếp nhận |
Yêu cầu đề xuất GBP phân biệt đánh giá và khắc phục. Tránh chấp nhận bảo đảm chung chỉ dựa trên kiểm thử đăng nhập hoặc quét tự động. Sản phẩm giá trị là bằng chứng về ranh giới truy cập khách hàng sẽ phụ thuộc.
Dịch vụ bảo mật ứng dụng của chúng tôi cung cấp khởi đầu cho phạm vi đó. Gửi chúng tôi mô hình tenant của sản phẩm và quyết định tiếp nhận để trao đổi xác minh, sửa có mục tiêu và bằng chứng cần trước khi mở tài khoản khách hàng tiếp theo.
Câu hỏi thường gặp
Cách ly tenant SaaS là gì? Đó là sự tách biệt được thực thi giữa dữ liệu tổ chức khách hàng và thao tác được phép. Ranh giới cần giữ qua yêu cầu ứng dụng, lưu trữ, cache, tệp và công việc nền, gồm ngoại lệ quản trị sản phẩm định nghĩa.
Cơ sở dữ liệu riêng có bảo đảm cách ly không? Không. Thông tin xác thực, định tuyến, công cụ hỗ trợ, bản xuất và sao lưu vẫn có thể vượt ranh giới. Cơ sở dữ liệu riêng có thể là phần thiết kế, nhưng đường truy cập thực tế cần kiểm thử.
Mã hồ sơ ngẫu nhiên có đủ không? Không. Chúng giảm việc liệt kê dễ nhưng không phải kiểm tra quyền. Kiểm thử truy cập bằng mã thật từ tenant kiểm soát khác và xác nhận server từ chối.
Nên kiểm thử truy cập được phép cùng từ chối không? Có. Khắc phục từ chối mọi yêu cầu có thể che sản phẩm hỏng. Xác minh người dùng thường giữ thao tác dự kiến trong khi thử xuyên tenant bị từ chối.
Vì sao cache cần kiểm thử riêng? Chúng có thể trả dữ liệu không lặp đường truy cập ban đầu. Điền cache dưới tenant này và kiểm tra kết quả dưới tenant khác. Xác nhận phạm vi cache giữ quyền dự kiến thay vì chỉ dùng chung khóa tiện lợi.
Truy cập hỗ trợ nên hoạt động thế nào? Xác định ai được nhận, phạm vi quyền, thời lượng và cách ghi hành động. Kiểm thử vào, dùng và thoát ngữ cảnh quyền cao. Thiết kế cần làm ngoại lệ rõ ràng và rà soát được.
Nếu dùng bảo mật mức hàng thì sao? Kiểm thử bằng vai trò yêu cầu thật của ứng dụng và gồm thao tác bỏ qua controller thường. Vai trò dữ liệu đặc quyền và đường khác có thể hành xử khác. Chính sách hàng là kiểm soát cần xác minh, không phải lý do bỏ đánh giá.
Nhà cung cấp cần nhận gì trước khi báo giá? Mô tả tenant và vai trò, loại tài nguyên, lưu trữ ngoài và thao tác nền. Xác định môi trường, tài khoản kiểm soát có sẵn để kiểm thử và quyết định đánh giá cần hỗ trợ.