Cô lập tenant trong Cloudflare AI Search trở nên quan trọng ngay khi cùng một ứng dụng phục vụ nhiều tổ chức có tài liệu riêng. Kết quả truy xuất có thể làm lộ thông tin trước khi tạo câu trả lời, và trích dẫn có thể để lộ tài liệu dù câu trả lời hiển thị có vẻ vô hại. Ranh giới quyền hạn phải bao trùm toàn bộ hành trình tìm kiếm.
Suy ra phạm vi tenant từ danh tính ứng dụng đã xác thực, sau đó chọn phiên bản tìm kiếm được phép hoặc áp dụng bộ lọc bắt buộc do máy chủ kiểm soát. Giữ nạp dữ liệu, truy xuất, trích dẫn và bộ nhớ đệm trong cùng một thiết kế truy cập. Chứng minh khả năng cô lập bằng kiểm thử từ chối, bao gồm đổi tenant, phiên cũ và cố mở trực tiếp nguồn của tenant khác.
Hãy hình dung sản phẩm SaaS cho phép các nhà phân phối tải lên thỏa thuận nhà cung cấp. Mỗi nhà phân phối muốn trợ lý giải thích điều khoản giao hàng và chiết khấu của chính mình. Sản phẩm cũng có thể có sổ tay công khai dùng chung. Kết hợp các nguồn đó chỉ hữu ích nếu tài liệu riêng không bao giờ vượt ranh giới dự định.
Đây là thiết kế ứng dụng và cách nghiệm thu được đề xuất. Bài viết không khẳng định rằng chỉ một namespace hoặc bộ lọc đáp ứng mọi yêu cầu bảo mật.
Cô lập tenant trong Cloudflare AI Search bắt đầu trước truy xuất
Hướng dẫn đa tenant của Cloudflare mô tả cách dùng phiên bản riêng và phiên bản dùng chung cho tìm kiếm tenant. Lựa chọn kiến trúc trước hết cần mô hình danh tính ứng dụng. Quyết định tenant đại diện cho điều gì và người dùng nào được hành động trong đó.
Lấy tenant từ phiên đã kiểm chứng hoặc ngữ cảnh đáng tin cậy tương đương. Tham số yêu cầu có thể chỉ ra lựa chọn người dùng muốn, nhưng máy chủ phải xác lập lựa chọn đó được phép. Không bao giờ để mô hình cung cấp phạm vi tenant có thẩm quyền.
Với đồng nghiệp thuộc nhiều nhà phân phối, làm rõ tổ chức đang hoạt động. Chuyển tổ chức phải thay đổi tập nguồn được phép và mọi ngữ cảnh hội thoại liên quan. Đoạn riêng tư đã truy xuất trước khi chuyển không được âm thầm xuất hiện trong câu trả lời tiếp theo.
| Ranh giới | Đầu vào đáng tin cậy | Thay thế không đáng tin cần từ chối |
|---|---|---|
| Chọn tenant | Tư cách thành viên đã xác thực và phạm vi đang hoạt động | Mã tenant tùy ý từ trình duyệt |
| Định tuyến phiên bản | Ánh xạ do máy chủ kiểm soát | Tên phiên bản do mô hình bịa ra |
| Phạm vi tài liệu | Chủ sở hữu nguồn và quyền đã kiểm chứng | Tệp tải lên tự khai tenant của mình |
| Truy cập trích dẫn | Quyền hiện tại khi mở tài liệu | Chỉ việc có URL kết quả |
So sánh phiên bản riêng và lọc bắt buộc
Phiên bản riêng có thể giúp kiểm tra ranh giới dữ liệu dễ hơn, nhưng thêm công việc về vòng đời và cấp phát. Phiên bản dùng chung có thể giảm gánh nặng đó, nhưng mọi đường truy xuất liên quan phải áp dụng đúng phạm vi mà không có lối bỏ qua tùy chọn.
Tài liệu namespace của Cloudflare giải thích cách nhóm và truy cập phiên bản qua binding. Xem xét kỹ phạm vi của binding. Một nhóm logic không chứng minh ứng dụng định tuyến đúng mọi người gọi.
| Lựa chọn thiết kế | Lợi ích vận hành cần đánh giá | Trách nhiệm vẫn còn |
|---|---|---|
| Phiên bản tenant riêng | Tách nguồn và vòng đời rõ hơn | Định tuyến và kiểm tra thành viên đúng |
| Phiên bản chung với bộ lọc tenant | Nạp dữ liệu và quản lý chỉ mục chung | Phạm vi bắt buộc trên mọi đường truy xuất |
| Bộ sưu tập công khai riêng | Tài liệu dùng chung rõ ràng | Ngăn nạp tài liệu riêng vào đó |
| Tập con tài liệu hạn chế | Truy cập chi tiết hơn trong tenant | Quyền hiện tại ở cấp tài liệu |
Lựa chọn theo mô hình quyền và yêu cầu vận hành, không chỉ theo số tenant. Tenant có các nhóm nội bộ bị hạn chế có thể cần nhiều hơn ranh giới cấp tổ chức, bất kể bố cục phiên bản.
Áp dụng phạm vi cả khi nạp dữ liệu lẫn truy vấn
Quyền sở hữu tài liệu phải được xác lập khi nội dung vào hệ thống. Gắn mỗi nguồn với tenant và mức hiển thị dự định bằng siêu dữ liệu ứng dụng đáng tin cậy. Không chấp nhận quyền sở hữu do tệp tải lên tự khai mà chưa kiểm tra quyền của người gọi.
Giữ mã định danh nguồn ổn định qua các lần cập nhật. Thỏa thuận thay thế phải cập nhật tài liệu của đúng tenant, và việc xóa phải nhắm đúng nguồn cùng nội dung dẫn xuất. Trùng mã giữa các tenant có thể phá hỏng cô lập ngay cả trước khi tìm kiếm chạy.
Tách quyết định nạp dữ liệu công khai và riêng tư. Sổ tay dùng chung có thể được công khai có chủ đích; thỏa thuận nhà cung cấp không được vào bộ sưu tập đó chỉ vì phần mở rộng tệp hoặc tên thư mục giống sổ tay.
Ghi lại danh tính nạp dữ liệu nào có thể đọc mỗi vị trí nguồn. Ứng dụng có thể lọc đúng kết quả trong khi một bộ kết nối nguồn có quyền quá rộng vẫn nhập tài liệu mà nó không được xử lý. Xem xét phạm vi phải bao gồm cả hai đầu quy trình.
Biến bộ lọc thành chính sách ứng dụng không thể bỏ qua
Cloudflare mô tả lọc truy xuất . Chuyển quyền ứng dụng hiện tại thành hợp đồng bộ lọc đã chọn, rồi thử yêu cầu thực tế do máy chủ tạo ra.
Đừng cung cấp một đối tượng bộ lọc chung mà máy khách thông thường có thể thay thế. Tương tự, đừng thêm phương án dự phòng tiện lợi thử lại không có bộ lọc khi truy vấn có phạm vi không khớp gì. Không có kết quả là đầu ra hợp lệ và cần thiết với thông tin không được phép hoặc không tồn tại.
Tách phạm vi ứng dụng khỏi tùy chọn người dùng như loại tài liệu hay ngôn ngữ. Người dùng có thể yêu cầu tìm hẹp hơn, nhưng không được xóa điều kiện truy cập bắt buộc bằng cách thay đổi tùy chọn tìm kiếm.
Thử mọi đường dẫn đến truy xuất: kết quả tìm kiếm, câu trả lời được tạo, bản xuất, công cụ tác nhân và bản xem trước quản trị. Trang tìm kiếm an toàn không bù được điểm cuối công cụ không lọc đang truy vấn cùng bộ sưu tập.
Bảo vệ trích dẫn, bộ nhớ đệm và lịch sử hội thoại
Câu trả lời được tạo có thể bỏ đoạn riêng tư nhưng vẫn trả tiêu đề trích dẫn hoặc URL làm lộ thông tin tenant khác. Kiểm tra mọi trường trả về, không chỉ văn bản câu trả lời.
Mở trích dẫn theo quyền tài liệu hiện tại. Nếu ứng dụng của bạn phục vụ nguồn, xác minh người gọi trước khi trả nó. Nếu nguồn dùng hệ thống tài liệu bên ngoài, xác lập rằng liên kết giữ nguyên các quy tắc truy cập của hệ thống đó.
Đưa tenant và ngữ cảnh quyền liên quan vào mọi thiết kế bộ nhớ đệm ứng dụng. Câu trả lời lưu đệm phù hợp với một tổ chức không được trở thành câu trả lời dùng chung chỉ vì văn bản câu hỏi giống nhau.
Lịch sử hội thoại có thể giữ đoạn đã truy xuất sau khi người dùng đổi tổ chức hoặc mất quyền. Quyết định lịch sử nào có thể mở lại và ngữ cảnh nào có thể đưa cho mô hình. Thu hồi phải có tác động xác định đến bản sao dẫn xuất, không chỉ truy vấn tìm kiếm trực tiếp.
Xây dựng kiểm thử từ chối để phát hiện rò rỉ thực
Dùng tài liệu tenant giả lập với dấu hiệu riêng, không thể nhầm lẫn. Đặt cùng câu hỏi dưới danh tính người dùng ở các tổ chức khác nhau và xác nhận dấu hiệu của tổ chức kia không xuất hiện trong đoạn, câu trả lời, siêu dữ liệu hay trích dẫn.
| Phép thử | Kết quả dự kiến |
|---|---|
| Sửa mã tenant được yêu cầu | Máy chủ từ chối hoặc giữ phạm vi được phép |
| Truy vấn cụm từ đã biết từ tenant khác | Không trả đoạn riêng, câu trả lời hoặc trích dẫn |
| Mở URL tài liệu của tenant khác | Từ chối truy cập |
| Đổi tổ chức đang hoạt động | Truy xuất và ngữ cảnh mô hình theo phạm vi mới được phép |
| Xóa tư cách thành viên trong phiên | Truy cập tiếp theo tuân theo quyền hiện tại |
| Lặp câu hỏi lưu đệm giữa các tenant | Không dùng lại câu trả lời chéo tenant |
Đưa quản trị viên đa tenant được phép vào trường hợp riêng với người dùng thông thường. Khắc phục sự cố quản trị cần quyền và bằng chứng riêng. Đừng coi kết quả rộng của quản trị viên là chuẩn của kiểm thử nghiệm thu người dùng thông thường.
Lặp bộ kiểm thử cô lập sau thay đổi định tuyến, nạp dữ liệu, lọc và bộ nhớ đệm. Chỉ thử độ liên quan tìm kiếm sẽ không phát hiện suy giảm quyền; một kết quả rất liên quan có thể chính là tài liệu người dùng không được xem.
Dự trù vòng đời quyền hạn
Công sức phát triển phụ thuộc vào tư cách thành viên, quyền tài liệu, tích hợp nguồn và số đường truy xuất. Bản trình diễn bộ lọc tenant đơn giản loại ra phần lớn công việc vòng đời cần cho sản phẩm SaaS thực tế.
Yêu cầu đề xuất bằng GBP bao gồm cấp phát, thay đổi tenant, xóa, thu hồi quyền và nghiệm thu. Nêu rõ cô lập dừng ở ranh giới tổ chức hay bao gồm các nhóm và tài liệu riêng bên trong.
| Mảng công việc | Bằng chứng cần yêu cầu |
|---|---|
| Danh tính | Quy tắc thành viên và chuyển tenant |
| Nạp dữ liệu | Quyền sở hữu đã kiểm chứng và ánh xạ truy cập nguồn |
| Truy xuất | Phạm vi do máy chủ kiểm soát trên mọi đường |
| Nội dung dẫn xuất | Chính sách bộ nhớ đệm, trích dẫn và lịch sử |
| Vận hành | Hướng dẫn cấp phát, xóa và xử lý sự cố |
Thử nghiệm thí điểm tích hợp AI có giới hạn có thể thử các tổ chức giả lập và tài liệu đại diện trước khi đưa dữ liệu riêng vào. Yêu cầu đề xuất tìm kiếm tenant cùng mô hình thành viên và quyền nguồn của bạn. Nhờ vậy, cô lập trở thành hợp đồng kiểm thử được, thay vì nhãn trấn an trên sơ đồ kiến trúc.
Câu hỏi thường gặp
Mỗi tenant có cần một phiên bản AI Search riêng không? Không nhất thiết. Cloudflare mô tả cách dùng phiên bản riêng và dùng chung. So sánh mô hình quyền, công việc cấp phát và độ tin cậy của lọc bắt buộc trước khi chọn. Cả hai cách đều không loại bỏ phân quyền ứng dụng.
Trình duyệt có thể gửi mã tenant không? Nó có thể yêu cầu một lựa chọn, nhưng máy chủ phải kiểm chứng lựa chọn dựa trên tư cách thành viên đã xác thực. Đừng xem tham số trình duyệt tùy ý hoặc giá trị do mô hình tạo là nguồn của quyền truy cập.
Namespace có phải hệ thống phân quyền không? Namespace tổ chức truy cập phiên bản qua mô hình binding được mô tả. Ứng dụng vẫn phải xác thực người gọi và định tuyến đúng. Xem xét phạm vi binding và chứng minh ranh giới bằng kiểm thử từ chối của người dùng thông thường.
Tìm kiếm có bộ lọc không ra kết quả có nên thử lại mà bỏ lọc không? Không. Xóa phạm vi bắt buộc để có câu trả lời có thể làm lộ tài liệu của tenant khác. Trả trạng thái không có kết quả hữu ích hoặc điều tra cấu hình chỉ mục và quyền mà không mở rộng truy cập người dùng.
Trích dẫn có thể làm lộ thông tin không? Có. Tiêu đề, URL, đoạn trích và tải tài liệu có thể tiết lộ thông tin riêng dù câu trả lời được tạo đã bỏ nó. Thử toàn bộ phản hồi và yêu cầu quyền hiện tại khi mở nguồn.
Điều gì xảy ra khi người dùng mất tư cách thành viên tenant? Truy cập tiếp theo cần tuân theo quyền hiện tại. Xác định tác động đến phiên mở, câu trả lời lưu đệm, lịch sử hội thoại và bản sao dẫn xuất bên cạnh truy xuất trực tiếp. Thử thu hồi trong phiên đang hoạt động.
Thử nghiệm cô lập thí điểm cần chứng minh gì? Nó cần chứng minh người dùng thông thường không thể truy xuất, suy ra từ siêu dữ liệu trả về hoặc mở nguồn riêng của tenant khác. Bao gồm sửa phạm vi, đổi tenant, dùng lại bộ nhớ đệm, cập nhật nguồn và thu hồi quyền.