Tách biệt việc xuất bản HTTP khỏi thực thi ứng dụng và dữ liệu lâu dài. Reverse proxy có thể tổ chức định tuyến và giới hạn, nhưng quyền truy cập origin, ủy quyền ứng dụng, dung lượng upstream và khôi phục đều cần các kiểm soát riêng.
Một yêu cầu web đi qua nhiều trách nhiệm
Máy chủ web nhận các yêu cầu HTTP và có thể phục vụ tệp tĩnh. Tiến trình ứng dụng thực thi hành vi động của dự án, chẳng hạn như kiểm tra tài khoản hoặc truy vấn cơ sở dữ liệu. Reverse proxy nhận yêu cầu thay cho tiến trình đó và chuyển tiếp chúng đến upstream. Một chương trình có thể đảm nhận nhiều vai trò, nhưng việc tách biệt trách nhiệm giúp dễ lý giải cấu hình và khôi phục hơn.
Theo dõi một yêu cầu từ phân giải tên máy chủ đến phản hồi. Ghi lại nơi TLS kết thúc, tiến trình nào chọn tuyến và thành phần nào có thể đọc dữ liệu ứng dụng. Làm tương tự cho một yêu cầu quản trị. Bài tập này thường phát hiện một listener hoặc tên máy chủ được tạo để thử nghiệm và vô tình vẫn có thể truy cập được. Sơ đồ nên mô tả đường đã triển khai thay vì kiến trúc bạn hy vọng xây dựng.
Sử dụng biên để tổ chức hành vi HTTP
NGINX ghi lại cả việc phục vụ nội dung tĩnh và chuyển tiếp yêu cầu đến upstream. Kiến trúc worker và các mô-đun HTTP của nó cung cấp cơ chế cấu hình, nhưng một cấu hình cụ thể vẫn quyết định hành vi. Xác định tên máy chủ, upstream và thư mục gốc hệ thống tệp một cách có chủ đích. Hạn chế các tệp có thể được phục vụ để cấu hình, thông tin xác thực và siêu dữ liệu kho lưu trữ không bao giờ trở thành tệp có thể tải xuống chỉ vì chúng nằm gần ứng dụng.
Đặt giới hạn phù hợp cho phần thân yêu cầu, thời gian chờ và kết nối theo ứng dụng. Coi bộ nhớ đệm là một quyết định dữ liệu: nội dung gắn với người dùng hoặc quyền không thể kế thừa quy tắc lưu đệm chung một cách an toàn nếu không xem xét. Kiểm tra xác thực và hành vi bộ nhớ đệm cùng nhau. Giữ cấu hình có thể tái tạo và xác thực thay đổi trước khi tải lại dịch vụ, với đường quay về phiên bản hoạt động trước đó đã biết.
| Lớp | Trách nhiệm hữu ích | Kiểm tra trước khi khởi chạy |
|---|---|---|
| Biên web công khai | TLS, định tuyến tên máy chủ và giới hạn HTTP | Chứng chỉ, thư mục gốc và tên máy chủ dự định |
| Tiến trình ứng dụng | Logic nghiệp vụ và ủy quyền | Xác thực, kiểm tra đầu vào và lỗi phụ thuộc |
| Dịch vụ dữ liệu nội bộ | Trạng thái ứng dụng lâu dài | Truy cập bị hạn chế và khôi phục đã được kiểm tra |
| Mạng nhà cung cấp upstream | Dịch vụ mạng theo hợp đồng | Phạm vi bảo vệ và đường leo thang |
Reverse proxy không loại bỏ mức độ phơi bày của origin
Nếu origin vẫn có thể truy cập công khai, máy khách có thể truy cập nó mà không dùng tuyến proxy dự định. Hạn chế quyền truy cập origin thông qua thiết kế mạng và cấu hình ứng dụng khi triển khai yêu cầu ranh giới đó. Trên một máy, backend thường có thể lắng nghe trên loopback hoặc socket cục bộ. Giữa các máy, hãy dùng các tuyến bị hạn chế rõ ràng và bảo vệ phù hợp cho kết nối upstream.
Header chuyển tiếp cũng cần quy tắc tin cậy. Chỉ chấp nhận thông tin về máy khách gốc từ các trung gian đáng tin cậy và ngăn người gọi tùy ý cung cấp giá trị mà ứng dụng coi là có thẩm quyền. Quyết định nội dung xuất hiện trong nhật ký truy cập và báo cáo lỗi. Proxy có thể thay đổi thông tin sẵn có ở mỗi lớp; nó không xóa mã định danh tài khoản hoặc làm cho ứng dụng trở nên ẩn danh với chính nhà vận hành.
Áp dụng quyết định truy cập bên trong ứng dụng
Kiến trúc Zero Trust của NIST tập trung vào quyết định truy cập cho tài nguyên thay vì tin cậy ngầm chỉ dựa trên vị trí mạng. Áp dụng nguyên tắc đó một cách cụ thể: xác thực người gọi, ủy quyền thao tác được yêu cầu và chỉ cấp cho tài khoản dịch vụ phạm vi cần thiết. Một yêu cầu đến từ mạng con nội bộ không nên tự động trở thành yêu cầu quản trị viên.
Tách biệt chức năng công khai và quản trị khi thực tế cho phép. Kiểm tra lại quyền khi người dùng truy cập một bản ghi thay vì chỉ dựa vào lần đăng nhập ban đầu. Giữ thông tin xác thực cho proxy, ứng dụng và cơ sở dữ liệu riêng biệt. Đưa thay đổi vào theo từng giai đoạn có thể kiểm tra, bắt đầu với một đường nhạy cảm hẹp. Gọi một triển khai là Zero Trust ít hữu ích hơn việc chứng minh rằng một hành động bị cấm thực sự bị từ chối tại thành phần chịu trách nhiệm.
Lập kế hoạch từ chối dịch vụ ở nhiều hơn một lớp
Một liên kết mạng bị bão hòa và một yêu cầu ứng dụng tốn kém thất bại ở những nơi khác nhau. Giới hạn tốc độ ở biên web có thể giúp hạn chế các mẫu yêu cầu, trong khi giới hạn ứng dụng có thể giới hạn công việc như tìm kiếm, tải lên hoặc xuất. Mô-đun giới hạn yêu cầu của NGINX cung cấp một cơ chế; khóa và ngưỡng phải phù hợp với người dùng thực và được kiểm tra để tránh từ chối lưu lượng hợp lệ.
Hướng dẫn về từ chối dịch vụ của OWASP cũng đề cập đến việc cạn kiệt tài nguyên trong hành vi ứng dụng. Đặt giới hạn thời gian và kích thước cho công việc tốn kém, dùng hàng đợi có giới hạn và giám sát tín hiệu lỗi. Kiểm soát cục bộ không thể tạo dung lượng trong một liên kết upstream đã bão hòa. Xác nhận bảo vệ mạng cụ thể có trong ưu đãi đã chọn và chuẩn bị đường leo thang. Không bao giờ giả định rằng bảo vệ Layer 3–4 của một danh mục cũng chứng minh bảo vệ cho mọi khối lượng công việc HTTP.
Đưa khôi phục thành một phần của việc xuất bản
Kiểm tra trang từ máy khách bên ngoài bằng tên máy chủ dự định. Xác minh HTTPS, chuyển hướng, tài nguyên tĩnh, đăng nhập và một giao dịch ứng dụng đại diện. Xác nhận rằng listener quản trị và tệp riêng tư vẫn không thể truy cập. Mô phỏng upstream đã dừng và kiểm tra rằng biên trả về lỗi được kiểm soát thay vì tiết lộ chi tiết nội bộ hoặc chờ đợi không giới hạn.
Đối với Canvas, hãy đọc các kiểm soát có sẵn trong tài khoản lưu trữ. Đối với VPS, duy trì biên web và ứng dụng như một phần trong kế hoạch vận hành của riêng bạn. Cổng mạng lớn là một thông số dung lượng, không phải bằng chứng rằng ứng dụng có thể duy trì thông lượng đó. Giữ giám sát, khôi phục và liên hệ nhà cung cấp trong runbook. Chỉ xuất bản sau khi đường yêu cầu thực tế và đường khôi phục thực tế đã được xác minh.
Danh sách kiểm tra thực tế của bạn.
- Theo dõi một yêu cầu công khai và một yêu cầu quản trị.
- Xác định thư mục gốc được phục vụ và listener upstream.
- Chỉ tin cậy header chuyển tiếp từ các trung gian được phê duyệt.
- Kiểm tra ủy quyền và ranh giới bộ nhớ đệm.
- Chuẩn bị giới hạn và leo thang cho lỗi mạng và ứng dụng.
Những chi tiết quan trọng.
Máy chủ web có thể đồng thời hoạt động như reverse proxy không?+
Có. NGINX là một ví dụ được ghi lại. Vai trò của nó phụ thuộc vào cấu hình và ứng dụng vẫn cần ủy quyền và bảo trì riêng.
Reverse proxy có tự động ẩn origin không?+
Không. Origin có thể vẫn truy cập được trừ khi định tuyến, tường lửa và cài đặt listener thực thi ranh giới dự định.
Giới hạn yêu cầu có ngăn chặn mọi cuộc tấn công DDoS không?+
Không. Nó giải quyết các mẫu yêu cầu HTTP được chọn. Bão hòa mạng và các lỗi tài nguyên khác yêu cầu kiểm soát upstream và ứng dụng phù hợp.
Đến nguồn.
Các tài liệu tham khảo này hỗ trợ các khái niệm kỹ thuật trong hướng dẫn này. Hãy theo dõi tài liệu hiện hành trước khi thay đổi hệ thống sản xuất.
- NGINX: Hướng dẫn cho người mới bắt đầu nginx.org
- NGINX: Giới hạn yêu cầu HTTP nginx.org
- NIST SP 800-207: Kiến trúc Zero Trust nvlpubs.nist.gov
- OWASP: Ngăn chặn từ chối dịch vụ cheatsheetseries.owasp.org
Hướng dẫn biên tập bởi SwissOctet. Các ví dụ chỉ mang tính minh họa. Thông số dịch vụ, tùy chọn có sẵn và điều kiện hợp đồng phải được xác minh riêng.