Một nền tảng SaaS xử lý tác vụ kết nối cho nhiều khách hàng có thể cần tuyến mạng khác nhau theo từng tổ chức. Nếu tất cả worker dùng chung một biến cấu hình proxy, một lần đổi tuyến có thể tác động ngoài phạm vi dự kiến. Giải pháp phù hợp là ràng buộc từng tác vụ với tenant và chính sách mạng đã được máy chủ xác minh.
Khi nào nên tách tuyến theo tenant?
Cách tổ chức này hữu ích khi khách hàng có yêu cầu vị trí kết nối, hạn mức hoặc danh sách đích được phép khác nhau. Lợi ích chính là xác định rõ ai sử dụng tuyến nào và khoanh vùng sự cố. Nó không mặc nhiên tạo IP riêng, cũng không đảm bảo hai tuyến có hạ tầng vật lý độc lập. Cần xác nhận khả năng thực tế của gói proxy và hệ thống.
Kiến trúc: xác thực trước, chọn tuyến sau
Luồng đề xuất là: người dùng được xác thực → kiểm tra quyền trong tenant → tạo tác vụ có ngữ cảnh tin cậy → worker lấy chính sách → mở kết nối. Tenant do người dùng gửi lên chỉ là lựa chọn cần kiểm tra, không phải chứng cứ về quyền. OWASP Multi Tenant Security nhấn mạnh việc gắn ngữ cảnh tenant với danh tính đã xác minh và kiểm soát quyền hiện hành.
Dùng khóa cấu hình dạng môi trường, tenant, mục đích, phiên bản. Cấu hình lưu mã tuyến và tham chiếu bí mật, không nhúng mật khẩu vào hàng đợi. Khi xử lý chậm, worker phải kiểm tra tenant vẫn còn quyền thực hiện tác vụ. Thiếu cấu hình thì báo lỗi có kiểm soát, không lấy tuyến của khách hàng khác làm mặc định.
Phân quyền và hạn mức không dựa vào IP
IP đầu ra là thuộc tính mạng, không chứng minh danh tính khách hàng. Nếu một tenant đổi IP, quyền truy cập dữ liệu vẫn phải do ứng dụng quyết định. OWASP Authorization khuyến nghị quyền tối thiểu, từ chối mặc định và kiểm tra quyền trên từng yêu cầu. Chính sách chọn tuyến cần đi cùng kiểm soát đối tượng dữ liệu.
Giới hạn đồng thời và dung lượng nên có cả tầng tenant lẫn tầng toàn hệ thống. Một khách hàng hết hạn mức không được đẩy công việc sang tuyến chung để tiếp tục chạy. Với tác vụ hợp lệ, hàng đợi có thể chờ hoặc trả lỗi hạn mức rõ ràng. Chỉ cho phép kết nối tới những dịch vụ đã được chủ hệ thống phê duyệt.
Kế hoạch triển khai theo phạm vi nhỏ
- Liệt kê tác vụ, môi trường và đích được phép của từng tenant.
- Tách kho cấu hình khỏi bí mật; phân quyền đọc theo danh tính worker.
- Chọn connection pool theo tenant và phiên bản tuyến, tránh tái sử dụng nhầm cấu hình.
- Chạy thử hai tenant giả trong staging, mỗi bên dùng dữ liệu riêng.
- Đối chiếu nhật ký và kết quả trước khi mở rộng có phê duyệt.
Tên endpoint không nhất thiết là IP mà dịch vụ đích nhìn thấy. Đọc phân biệt endpoint với IP đầu ra trước khi thiết kế tiêu chí nghiệm thu. Bí mật cần được quản lý theo vòng đời, tham khảo quản lý proxy bằng API an toàn.
Ví dụ giả định: hai nhóm tác vụ độc lập
Giả sử tenant A kiểm thử API nội bộ được cấp phép ở một khu vực; tenant B kiểm thử website của chính họ ở khu vực khác. Mỗi tenant có mã tuyến, giới hạn hai tác vụ đồng thời và tài khoản thử riêng. Đây là ví dụ thiết kế, không phải mô tả tính năng sẵn có của ProxySmart.
Khi A bị thu hồi quyền, tác vụ đang chờ của A phải bị từ chối tại bước kiểm tra quyền. B vẫn chạy theo hạn mức của B. Nếu nhà cung cấp báo lỗi xác thực proxy, ghi mã lỗi và mã tuyến đã che thông tin; không in chuỗi kết nối chứa mật khẩu vào thông báo hỗ trợ.
Nghiệm thu khả năng cách ly
- Đổi tenant trên yêu cầu thử không đọc được cấu hình hay dữ liệu của tenant khác.
- Ngữ cảnh tenant thiếu hoặc đã hết quyền không tạo kết nối mới.
- Đổi cấu hình A không đổi mã tuyến và hạn mức B.
- Nhật ký đối chiếu được tác vụ, tenant và phiên bản chính sách mà không lộ bí mật.
Kiểm thử cả đường thành công, lỗi, hàng đợi và tái chạy. Tuyến mạng tách biệt chỉ là một lớp; cơ sở dữ liệu, cache và lưu trữ cũng cần kiểm soát tenant phù hợp.
Câu hỏi thường gặp
Có cần mỗi tenant một IP riêng?
Không nhất thiết. Cần xác định yêu cầu nghiệp vụ trước, rồi kiểm tra khả năng dịch vụ. Tách chính sách không đồng nghĩa có IP độc quyền.
Cho tenant tự nhập proxy có an toàn không?
Chỉ nên làm khi có xác minh đích, quản lý bí mật và bảo vệ kết nối tới mạng nội bộ. Áp chính sách tại điểm egress, kiểm tra kết quả DNS và chỉ kết nối tới địa chỉ đã được xác nhận; chặn loopback, private và link-local ngoài phạm vi được duyệt ở cả IPv4 lẫn IPv6. Mặc định tắt tự theo redirect; nếu nghiệp vụ cần, xác minh lại từng bước. Đối chiếu hướng dẫn phòng SSRF của OWASP, không chỉ kiểm tra chuỗi URL rồi chuyển thẳng cho worker.
Kết luận
Giải pháp proxy cho SaaS nhiều tenant nên bắt đầu từ phân quyền và ngữ cảnh tin cậy, sau đó mới chọn tuyến. Cấu hình có phiên bản, hạn mức và kiểm thử cách ly giúp thay đổi mạng trong phạm vi kiểm soát được.