Trên cùng một nền tảng SaaS, khách hàng này đăng nhập bình thường nhưng cả một văn phòng của khách hàng khác lại bị giới hạn tốc độ. Trang tĩnh tải nhanh, còn thông báo thời gian thực liên tục mất kết nối. Khi bật bộ nhớ đệm, lại xuất hiện câu hỏi: liệu tenant này có thể nhìn thấy dữ liệu của tenant khác không?

Với SaaS, xác nhận “website mở được” mới chỉ là bước đầu của quá trình kiểm thử tích hợp.

Khi chọn CDN tích hợp bảo vệ DDoS cho SaaS, hãy kiểm tra trước việc cô lập dữ liệu giữa các tenant, khả năng tương thích của luồng đăng nhập và API, cùng độ ổn định của kết nối duy trì lâu. Sau đó mới so sánh tuyến mạng, năng lực giảm thiểu DDoS và chi phí.

Dữ liệu lẫn giữa các tenant, luồng xác thực bị gián đoạn hoặc kết nối không ổn định đều có thể khiến lợi ích từ việc trang chủ tải nhanh hơn trở nên không còn đáng kể.

Vì sao SaaS không thể dùng cùng tiêu chí chọn CDN như website thông thường?

Mô hình đa tenant cho phép nhiều doanh nghiệp hoặc tổ chức sử dụng chung một nền tảng, trong khi mỗi bên có tài khoản, dữ liệu và quyền truy cập riêng. Họ có thể dùng chung máy chủ, cơ sở dữ liệu và điểm truy cập, nhưng ranh giới dữ liệu và quyền hạn phải rõ ràng.

Vì vậy, đối tượng cần đánh giá không chỉ là một tên miền mà là một nhóm điểm truy cập liên quan đến nhau: website chính, tên miền phụ theo tenant, tên miền riêng của khách hàng, đăng nhập, API, tải tệp và kết nối thời gian thực.

Ví dụ, mười tenant dùng chung một IP đầu ra công cộng không có nghĩa họ là cùng một người dùng. Một tenant xuất hàng loạt báo cáo trong thời gian ngắn cũng không nên tự động dùng hết năng lực xử lý API của cả nền tảng. Cấu hình CDN cần phối hợp với cơ chế định danh, hạn mức và quản lý tài nguyên của ứng dụng.

Trong môi trường đa tenant, trước tiên hãy kiểm tra liệu bộ nhớ đệm có bị dùng chung vượt ranh giới hay không

Tên miền, đường dẫn và header yêu cầu ảnh hưởng thế nào tới nội dung?

Các cách truy cập tenant thường gặp gồm:

• Tên miền phụ: tenant-a.example.com và tenant-b.example.com.
• Đường dẫn: example.com/tenant-a/ và example.com/tenant-b/.
• API dùng chung: Đường dẫn yêu cầu giống nhau, tenant được xác định bằng phiên hoặc token.
• Tên miền riêng: Mỗi khách hàng sử dụng tên miền mang thương hiệu của mình.

CDN thường dùng cache key để phân biệt các nội dung đã lưu. Có thể hiểu đây là thông tin xác định hai yêu cầu có được dùng chung một phản hồi hay không. Khi chọn dịch vụ, hãy kiểm tra quy tắc thực tế có phân biệt tên miền, đường dẫn và tham số ảnh hưởng tới nội dung hay không. Đặc biệt chú ý cache key tùy chỉnh, việc bỏ qua tham số truy vấn và viết lại đường dẫn.

Ví dụ, hai doanh nghiệp truy cập cùng đường dẫn /api/report nhưng nhận báo cáo kinh doanh riêng của từng bên. Nếu chỉ lưu theo đường dẫn, CDN có thể dùng lại sai phản hồi. Ngay cả khi cache key chứa mã tenant, quản trị viên và nhân viên thông thường trong cùng tenant vẫn có thể có quyền xem dữ liệu khác nhau.

Lưu các bản cache riêng không có nghĩa yêu cầu đã vượt qua bước kiểm tra quyền truy cập.

Với phản hồi nhạy cảm yêu cầu đăng nhập hoặc phụ thuộc vào quyền người dùng, cấu hình ban đầu nên ưu tiên bỏ qua bộ nhớ đệm dùng chung. Nếu thực sự cần cache, hãy thiết kế trước cơ chế xác minh danh tính đáng tin cậy, phạm vi cô lập và cách vô hiệu hóa dữ liệu đã lưu.

Như OWASP nhấn mạnh trong hướng dẫn bảo mật đa tenant, mã tenant do client gửi chỉ có thể dùng để chọn đối tượng đích; phía server vẫn phải xác minh người dùng hiện tại có quyền truy cập tenant đó hay không. Việc yêu cầu chứa header X-Tenant-ID không chứng minh người gửi có quyền tương ứng.

Có Cookie hoặc Set-Cookie không có nghĩa phản hồi chắc chắn sẽ không bị cache

Một ngộ nhận phổ biến là: “API mang Cookie đăng nhập thì CDN đương nhiên không cache.” Cách xử lý còn tùy sản phẩm, quy tắc và cấu hình ghi đè. Không thể lấy hành vi mặc định làm ranh giới bảo mật.

Trong chuẩn bộ nhớ đệm HTTP RFC 9111, IETF nêu rõ rằng riêng Set-Cookie không ngăn phản hồi được cache. Cần dùng chỉ thị cache phù hợp để kiểm soát việc lưu phản hồi, đồng thời kiểm tra xem CDN có quy tắc ghi đè như ép cache hay không.

Với phản hồi nhạy cảm không được lưu, ứng dụng có thể trả về header sau. Hãy xác minh hành vi thực tế sau khi tích hợp:

Cache-Control: no-store

Đây là ví dụ về header phản hồi HTTP, không phải lệnh terminal hay cấu hình áp dụng đồng loạt cho mọi API. Tài liệu trợ giúp công khai, script có phiên bản và hình ảnh có thể dùng chính sách cache khác tùy tính chất nội dung.

Ít nhất hãy kiểm tra hai tenant, các vai trò khác nhau trong cùng tenant và truy cập khi chưa đăng nhập. Dùng các phiên trình duyệt tách biệt để lần lượt vào cùng đường dẫn nghiệp vụ, rồi xác minh dữ liệu trả về thuộc về ai. Sau khi đăng xuất, xóa thành viên hoặc giảm quyền, cũng cần xác nhận dữ liệu từng được phép xem không còn truy cập được.

Cho tenant A gửi yêu cầu trước, sau đó tenant B truy cập địa chỉ tương ứng; rồi đảo thứ tự và lặp lại. Kiểm tra cả trường hợp cache hit lẫn yêu cầu về máy chủ gốc. Dùng dữ liệu thử nghiệm riêng, dễ nhận biết cho mỗi tenant để các giá trị mẫu giống nhau không che khuất lỗi dùng lại phản hồi.

Tên miền riêng cũng cần quy trình thêm và gỡ bỏ

Với SaaS phục vụ khách hàng doanh nghiệp, quản lý tên miền là công việc liên tục. Thêm khách hàng, gia hạn chứng chỉ, ngắt liên kết tên miền và khách hàng chấm dứt dịch vụ đều cần quy trình tương ứng.

Khi đánh giá nhà cung cấp, hãy hỏi có thể kết nối bao nhiêu tên miền riêng, xác minh quyền sở hữu thế nào, quản lý chứng chỉ ra sao, có thể áp dụng quy tắc hàng loạt không và cách xóa ánh xạ giữa tên miền với tenant sau khi ngắt liên kết. Chứng chỉ wildcard không bao phủ mọi tên miền độc lập do khách hàng sở hữu.

Không thể suy ra các khả năng đó chỉ từ tuyên bố “hỗ trợ nhiều tên miền”. Khi nền tảng mở rộng, thời gian cấu hình thủ công từng tên miền cũng phải được tính vào chi phí vận hành.

Bảo vệ đăng nhập thế nào để không chặn nhầm cả một công ty?

Giới hạn tốc độ theo IP phải tính đến mạng đầu ra dùng chung của doanh nghiệp

Văn phòng, trường học và mạng di động có thể đặt nhiều người dùng hợp lệ sau một IP công cộng. Nếu chỉ đặt ngưỡng đơn giản theo IP, đợt đăng nhập tập trung buổi sáng, tải lại nhiều trang hoặc đồng bộ client có thể gây chặn nhầm.

Ở chiều ngược lại, tấn công thử thông tin đăng nhập bị lộ có thể phân tán yêu cầu qua nhiều IP. Từng nguồn có vẻ không gửi quá thường xuyên, nhưng một tài khoản vẫn liên tục phải chịu các lần thử mật khẩu.

Trong hướng dẫn bảo mật xác thực, OWASP khuyến nghị gắn số lần thất bại với tài khoản, đồng thời lưu ý cơ chế khóa tài khoản cũng có thể bị lợi dụng để chặn người dùng hợp lệ. Khi chọn dịch vụ, hãy xét cùng lúc nguồn yêu cầu, tài khoản và hành vi ứng dụng, thay vì chỉ tăng hoặc giảm một ngưỡng IP.

Có thể phân chia trách nhiệm: CDN xử lý lưu lượng bất thường ở điểm truy cập và các đặc điểm yêu cầu mà nó nhận diện được; ứng dụng chịu trách nhiệm về trạng thái tài khoản, xác thực, quyền tenant và hạn mức đòi hỏi danh tính đáng tin cậy. Cần kiểm tra gói dịch vụ cụ thể có hỗ trợ quy tắc theo các chiều tương ứng hay không, thay vì mặc định CDN hiểu hệ thống tenant và tài khoản của bạn.

Kiểm tra riêng trang đăng nhập, yêu cầu đăng nhập và callback định danh

Luồng đăng nhập SaaS có thể gồm đăng nhập một lần (SSO), xác thực đa yếu tố, chuyển hướng tới nhà cung cấp danh tính, callback và làm mới token. Trang đăng nhập mở được mới chỉ xác nhận một khâu.

Ít nhất hãy liệt kê các đường dẫn sau:

Không nên bắt mọi API phục vụ hệ thống phải qua bước xác minh dành cho trình duyệt. Client chờ JSON nhưng nhận trang xác minh HTML có thể báo lỗi ngay cả khi mã trạng thái là 200. Ngược lại, tắt bảo vệ toàn website chỉ để callback hoạt động sẽ mở rộng phạm vi phơi lộ.

Để phân loại API và phối hợp quy tắc, có thể tham khảo cách bảo vệ API trước lượng yêu cầu lạm dụng, rồi xử lý đăng nhập, truy vấn, xuất dữ liệu và lệnh gọi từ bên thứ ba theo từng nhóm. Về vai trò của các cơ chế bảo mật khác nhau, hãy xem cách phối hợp WAF, quản lý bot và bảo vệ DDoS.

Cần kiểm tra gì với kết nối WebSocket và SSE duy trì lâu?

Xác định loại kết nối trước khi hỏi về giới hạn

Thông báo thời gian thực, cộng tác trực tuyến và kết quả do AI tạo có thể dùng WebSocket hoặc SSE. Hai cơ chế này không thay thế được cho nhau.

WebSocket phù hợp với giao tiếp hai chiều liên tục. Theo giao thức WebSocket trong RFC 6455, dữ liệu tiếp tục được trao đổi sau khi thiết lập kết nối, nên chỉ kiểm tra bước bắt tay là chưa đủ.

Với SSE, server liên tục gửi sự kiện tới client qua HTTP. Trong tài liệu sử dụng SSE, MDN giải thích luồng sự kiện dùng kiểu nội dung text/event-stream và ngăn cách các thông điệp bằng dòng trống. Sau khi tích hợp, cần xác nhận sự kiện đến dần theo thời gian, thay vì bị giữ lại rồi trả một lần ở cuối.

Một sản phẩm hỗ trợ WebSocket không có nghĩa SSE hoặc giao thức truyền dữ liệu dạng luồng khác sẽ hoạt động đúng như ứng dụng cần. Hãy hỏi riêng về thời gian chờ khi không hoạt động và giới hạn tổng thời lượng kết nối; heartbeat không ngăn được mọi trường hợp đứt kết nối.

Kiểm tra SSE có trả sự kiện dần theo thời gian không

Trên terminal Linux hoặc macOS đã cài curl, bạn có thể dùng lệnh sau để kiểm tra luồng sự kiện thử nghiệm. Thay URL ví dụ bằng API SSE thực tế. Nếu API cần xác thực, hãy dùng phiên thử nghiệm riêng; không mở API production chỉ để phục vụ phép thử.

curl -N -sS --connect-timeout 5 --max-time 30 \
  -H 'Accept: text/event-stream' \
  -D - \
  'https://example.com/events'

Theo tài liệu chính thức của curl, -N chỉ tắt bộ đệm đầu ra của chính curl. Nó không tắt bộ đệm tại CDN, gateway hoặc máy chủ gốc. --max-time 30 giới hạn toàn bộ phép thử trong 30 giây.

Quan sát loại phản hồi, nội dung sự kiện và nhịp sự kiện đến. Nếu máy chủ gốc thử nghiệm đã gửi theo khoảng thời gian cố định nhưng client lại nhận thành từng lô, hãy đối chiếu nhật ký gửi tại máy chủ gốc với thời điểm client nhận để tìm lớp đang giữ bộ đệm. Chỉ riêng hiện tượng đó không chứng minh CDN là nguyên nhân.

Mã 401 hoặc 403 có thể do chưa đăng nhập hoặc do chính sách truy cập; trước tiên cần có danh tính thử nghiệm hợp lệ. Lệnh chủ động dừng sau 30 giây và có thể báo hết thời gian chờ, nhưng điều đó không tự chứng minh dịch vụ gặp sự cố. Đây chỉ là phép kiểm tra ngắn về kết nối và đầu ra. Nghiệm thu chính thức còn phải bao quát thời lượng kết nối ứng dụng cần, các giai đoạn không có dữ liệu và khả năng khôi phục khi mất mạng.

Đừng dồn toàn bộ tải khi kết nối lại vào dịch vụ đăng nhập

Sau khi đổi điểm biên, mạng của client thay đổi hoặc dịch vụ được triển khai phiên bản mới, rất nhiều kết nối có thể được thiết lập lại trong thời gian ngắn. Nếu mọi kết nối cùng lúc làm mới token, kiểm tra quyền và đăng ký nhận dữ liệu lại, dịch vụ xác thực và đăng ký có thể trở thành nút thắt mới.

Hãy kiểm tra cơ chế lùi thời gian thử lại và độ trễ ngẫu nhiên ở client, xác thực lại, khôi phục đăng ký nhận dữ liệu, loại bỏ thông điệp trùng và phát lại dữ liệu khi cần. Client SSE tự kết nối lại không có nghĩa ứng dụng tự có khả năng gửi bù các sự kiện đã lỡ. WebSocket kết nối lại cũng không tự khôi phục trạng thái phiên.

Sau khi kết nối dài được thiết lập, ứng dụng vẫn phải thực thi quyền truy cập theo tenant, kênh và thông điệp. Khi chọn CDN, hãy phân biệt khả năng kiểm tra yêu cầu bắt tay với khả năng kiểm tra thông điệp trong kết nối; đây là hai năng lực riêng.

Nếu một tenant bị tấn công, các tenant khác có tiếp tục sử dụng bình thường được không?

Tính sẵn sàng của môi trường đa tenant không chỉ phụ thuộc vào CDN. Lượng yêu cầu lớn nhắm vào một tenant có thể tiêu thụ luồng xử lý ứng dụng, kết nối cơ sở dữ liệu, hàng đợi xuất dữ liệu hoặc tài nguyên xử lý tệp dùng chung.

Vì vậy, cần đánh giá hai lớp: điểm truy cập có thể thu hẹp phạm vi ảnh hưởng của lưu lượng bất thường không; phía ứng dụng có đặt giới hạn hợp lý cho số tác vụ đồng thời, công việc và tài nguyên mỗi tenant sử dụng không.

Danh tính dùng để giới hạn tốc độ theo tenant phải đáng tin cậy. Client không được phép sửa tùy ý một header để vượt hạn mức hoặc tính mức sử dụng sang tenant khác. Các yêu cầu trước đăng nhập chưa có danh tính tenant đáng tin cậy cũng cần chính sách bảo vệ điểm truy cập riêng.

Đội ngũ vận hành không nên chỉ nhìn số liệu trung bình toàn nền tảng. Tối thiểu phải liên kết được tên miền, đường dẫn, quy tắc và khoảng thời gian bị ảnh hưởng với dữ liệu ứng dụng, rồi mới phân biệt lỗi do CDN chặn, kết nối về máy chủ gốc thất bại hay xử lý ứng dụng. Nhật ký ứng dụng đáng tin cậy có thể bổ sung thông tin theo tenant; không nên mặc định mọi CDN đều trực tiếp cung cấp chiều dữ liệu này.

Tránh ghi trực tiếp mật khẩu, token đầy đủ hoặc nội dung nghiệp vụ nhạy cảm vào nhật ký. ID yêu cầu và mã tenant dùng để đối chiếu cũng cần có nguồn rõ ràng và quyền truy cập được kiểm soát.

Đưa chi phí và tuyến mạng vào bảng so sánh CDN cho SaaS như thế nào?

API SaaS trả phản hồi nhỏ có thể tiêu thụ ít băng thông nhưng nhận yêu cầu với tần suất cao. Nền tảng cộng tác thời gian thực có thể truyền không nhiều dữ liệu nhưng duy trì số lượng lớn kết nối lâu dài. Ước tính toàn bộ chi phí chỉ theo lưu lượng hằng tháng rất dễ bỏ sót các khoản quan trọng.

Khi yêu cầu báo giá, hãy liệt kê riêng số tên miền, lưu lượng hằng tháng, lượng yêu cầu cao điểm, số kết nối đồng thời, tốc độ thiết lập kết nối mới, nhu cầu ghi log và các tính năng bảo mật cần thiết. Xác nhận từng mục có tính phí hay không, được đo thế nào và đã gồm trong gói chưa.

Số tên miền riêng của khách hàng lớn tăng, thời hạn lưu log dài hơn hoặc một đợt kết nối lại đồng loạt đều có thể làm thay đổi nhu cầu tài nguyên. Có thể tham khảo cách tính gói CDN tích hợp bảo vệ DDoS, lưu lượng thông thường và phí bổ sung để ước tính riêng cho tháng bình thường và thời điểm cao điểm.

Việc thử tuyến mạng cũng phải tách theo dịch vụ: tài nguyên tĩnh cần đánh giá phân phối nội dung, đăng nhập và truy vấn cần đánh giá kết nối động về máy chủ gốc, còn dịch vụ thời gian thực cần đánh giá truyền liên tục và khôi phục. Nếu máy chủ gốc đặt ngoài Trung Quốc đại lục nhưng chủ yếu phục vụ doanh nghiệp tại đó, có thể tham khảo hướng dẫn về tốc độ và bảo vệ khi người dùng Trung Quốc đại lục truy cập máy chủ gốc ở nước ngoài để đo tại các khu vực, nhà mạng và giờ làm việc chính.

Khi sàng lọc dịch vụ, bạn có thể đưa dịch vụ CDN tích hợp bảo vệ DDoS của CDN07 vào thử nghiệm. Dịch vụ kết hợp phân phối nội dung với bảo vệ DDoS, có liệt kê khả năng hỗ trợ WebSocket và các tùy chọn điều chỉnh điểm biên, băng thông, chính sách bảo mật. Đây là cơ sở để trao đổi thêm về mức độ phù hợp với SaaS; quy tắc cache theo tenant, khả năng tương thích SSO, hành vi SSE và quản lý hạn mức vẫn cần kiểm chứng từng mục, không thể suy ra chỉ từ tên sản phẩm.

Nghiệm thu thử nghiệm: Những hạng mục nào phải đạt trước khi triển khai rộng?

Trong môi trường thử nghiệm được cho phép, hãy chuẩn bị hai tenant, các tài khoản có vai trò khác nhau và client thực tế. Kiểm tra tính đúng đắn trước rồi mới đánh giá hiệu năng và bảo vệ. Không tự mô phỏng tấn công thử thông tin đăng nhập trên production hoặc chạy kiểm thử tải khi chưa thống nhất phạm vi.

Nếu việc cô lập tenant thất bại, luồng định danh cốt lõi không hoàn tất hoặc giao tiếp liên tục mà ứng dụng cần không tương thích, hãy xử lý trước khi mở rộng triển khai. Năng lực giảm thiểu tấn công lớn hơn hay kết quả đo tài nguyên tĩnh nhanh hơn đều không bù được các vấn đề này.

Câu hỏi thường gặp

Sau khi SaaS tích hợp CDN, tenant này có thể nhìn thấy dữ liệu của tenant khác không?

Cấu hình sai bộ nhớ đệm dùng chung hoặc quyền truy cập có thể tạo ra rủi ro đó, nhưng đây không phải hệ quả tất yếu của việc dùng CDN. Hãy phân biệt nội dung công khai, nội dung theo tenant và theo người dùng; kiểm tra hành vi khi cache hit, đăng xuất và thay đổi quyền.

Mỗi tenant có tên miền phụ riêng là đủ để cô lập dữ liệu chưa?

Chưa. Cần kiểm tra cache key, ánh xạ về máy chủ gốc, quyền do ứng dụng cấp và truy cập dữ liệu. Nếu quy tắc tùy chỉnh gộp các tên miền khác nhau hoặc ứng dụng không xác minh quyền tenant, ranh giới vẫn có thể bị vượt qua.

Nhân viên cùng đăng nhập thì bị giới hạn tốc độ. Có phải bảo vệ quá nghiêm ngặt?

Có thể quy tắc chưa phù hợp với mạng đầu ra dùng chung và hành vi đăng nhập tập trung, nhưng cũng có thể do nguyên nhân khác. Hãy xem quy tắc đã kích hoạt, hành vi tài khoản và nhật ký ứng dụng; không nên chỉ nâng ngưỡng IP hoặc tắt hẳn bảo vệ.

CDN tích hợp bảo vệ DDoS hỗ trợ WebSocket thì có chắc hỗ trợ SSE không?

Không thể suy ra như vậy. Với SSE, cần kiểm tra riêng phản hồi HTTP liên tục, bộ đệm, cache và thời gian chờ; với WebSocket, cần kiểm tra kết nối và xử lý thông điệp. Đưa cả hai vào quy trình nghiệm thu.

SSE chỉ trả toàn bộ nội dung ở cuối là do CDN cache phải không?

Không nhất thiết. Ứng dụng, reverse proxy, xử lý nén, CDN hoặc client đều có thể ảnh hưởng tới nhịp xuất dữ liệu. Đối chiếu thời điểm gửi và nhận ở từng lớp để xác định bộ đệm và cách đẩy dữ liệu ra.

CDN tích hợp bảo vệ DDoS có thể thay hệ thống tài khoản và phân quyền tenant của SaaS không?

Không. CDN có thể đảm nhận phần bảo vệ phù hợp tại điểm truy cập, nhưng trạng thái tài khoản, quan hệ thành viên tenant, quyền theo từng đối tượng và hạn mức nghiệp vụ vẫn phải do logic ứng dụng đáng tin cậy thực thi.

Đưa luồng sử dụng thực tế vào phép thử chọn dịch vụ

Khi chọn CDN tích hợp bảo vệ DDoS cho SaaS, hãy tập trung vào bốn kết quả:

• Sau cache hit, quyền theo tenant và người dùng vẫn đúng.
• Đăng nhập, SSO và API phục vụ hệ thống vẫn hoàn tất khi bật bảo vệ.
• Kết nối duy trì lâu không chỉ thiết lập được mà còn tiếp tục truyền dữ liệu và khôi phục hợp lý.
• Bất thường ở một tenant, việc điều tra sự cố và mức tăng chi phí đều nằm trong phạm vi có thể quản lý.

Tiếp theo, hãy tổng hợp cách các tenant truy cập, quy mô tên miền, luồng đăng nhập, loại kết nối duy trì lâu, mức sử dụng cao điểm và các khu vực người dùng chính. Chọn một nhóm tenant tiêu biểu để kiểm chứng.

Nếu chuẩn bị thử CDN07, bạn có thể gửi các yêu cầu này qua kênh tư vấn tích hợp CDN bảo vệ DDoS và lựa chọn phương án, đồng thời ghi các điều kiện bắt buộc vào danh sách thử nghiệm. Kết quả cô lập tenant, đăng nhập thành công và truyền dữ liệu liên tục phản ánh mức độ phù hợp với SaaS sát hơn việc chỉ so sánh năng lực giảm thiểu DDoS.