Pisahkan publikasi HTTP dari eksekusi aplikasi dan data persisten. Reverse proxy dapat mengatur perutean dan batasan, tetapi akses origin, otorisasi aplikasi, kapasitas upstream dan pemulihan masing-masing memerlukan kontrolnya sendiri.
Permintaan web melewati beberapa tanggung jawab
Server web menerima permintaan HTTP dan dapat menyajikan file statis. Proses aplikasi menjalankan perilaku dinamis proyek, seperti memeriksa akun atau melakukan kueri basis data. Reverse proxy menerima permintaan atas nama proses tersebut dan meneruskannya ke upstream. Satu program dapat memenuhi beberapa peran, tetapi memisahkan tanggung jawab memudahkan penalaran tentang konfigurasi dan pemulihan.
Lacak satu permintaan dari resolusi hostname hingga respons. Catat di mana TLS berakhir, proses mana yang memilih rute dan komponen mana yang dapat membaca data aplikasi. Lakukan hal yang sama untuk permintaan administratif. Latihan ini sering mengungkap listener atau hostname yang dibuat untuk pengujian dan secara tidak sengaja tetap dapat dijangkau. Diagram harus menggambarkan jalur yang diterapkan, bukan arsitektur yang Anda harapkan.
Gunakan tepi untuk mengatur perilaku HTTP
NGINX mendokumentasikan penyajian konten statis dan penerusan permintaan ke upstream. Arsitektur worker dan modul HTTP-nya menyediakan mekanisme konfigurasi, tetapi konfigurasi tertentu tetap menentukan perilakunya. Tentukan hostname, upstream dan root filesystem secara sengaja. Batasi file yang dapat disajikan agar konfigurasi, kredensial dan metadata repositori tidak pernah dapat diunduh karena kebetulan berada di dekat aplikasi.
Tetapkan batas yang sesuai untuk body permintaan, timeout dan koneksi sesuai aplikasi. Perlakukan cache sebagai keputusan data: konten yang terkait dengan pengguna atau izin tidak dapat dengan aman mewarisi aturan cache bersama tanpa peninjauan. Uji autentikasi dan perilaku cache secara bersamaan. Simpan konfigurasi yang dapat direproduksi dan validasi perubahan sebelum memuat ulang layanan, dengan jalur kembali ke versi yang berfungsi sebelumnya yang diketahui.
| Lapisan | Tanggung jawab yang berguna | Periksa sebelum peluncuran |
|---|---|---|
| Tepi web publik | TLS, perutean hostname dan batas HTTP | Sertifikat, root dan hostname yang dimaksudkan |
| Proses aplikasi | Logika bisnis dan otorisasi | Autentikasi, pemeriksaan input dan kegagalan dependensi |
| Layanan data internal | Status aplikasi persisten | Akses terbatas dan pemulihan yang teruji |
| Jaringan penyedia upstream | Layanan jaringan yang dikontrak | Cakupan perlindungan dan jalur eskalasi |
Reverse proxy tidak menghilangkan paparan origin
Jika origin tetap dapat diakses publik, klien dapat mencapainya tanpa menggunakan rute proxy yang dimaksudkan. Batasi akses origin melalui desain jaringan dan konfigurasi aplikasi ketika penerapan memerlukan batas tersebut. Pada satu mesin, backend sering kali dapat mendengarkan pada loopback atau soket lokal. Di seluruh mesin, gunakan rute terbatas yang eksplisit dan perlindungan yang sesuai untuk koneksi upstream.
Header yang diteruskan juga memerlukan aturan kepercayaan. Terima informasi tentang klien asli hanya dari perantara tepercaya, dan cegah pemanggil arbitrer memasok nilai yang dianggap otoritatif oleh aplikasi. Tentukan apa yang muncul dalam log akses dan laporan kesalahan. Proxy dapat mengubah informasi yang tersedia di setiap lapisan; proxy tidak menghapus pengenal akun atau membuat aplikasi anonim bagi operatornya sendiri.
Terapkan keputusan akses di dalam aplikasi
Arsitektur Zero Trust NIST berfokus pada keputusan akses untuk sumber daya daripada kepercayaan implisit yang hanya berdasarkan lokasi jaringan. Terapkan prinsip itu secara konkret: autentikasi pemanggil, otorisasi operasi yang diminta dan beri akun layanan hanya cakupan yang diperlukan. Permintaan yang datang dari subnet internal tidak boleh otomatis menjadi permintaan administrator.
Pisahkan fungsi publik dan administratif jika memungkinkan. Periksa ulang izin saat pengguna mengakses catatan daripada hanya mengandalkan login awal. Jaga agar kredensial untuk proxy, aplikasi dan basis data tetap berbeda. Perkenalkan perubahan secara bertahap yang dapat diuji, dimulai dengan jalur sensitif yang sempit. Menyebut penerapan sebagai Zero Trust kurang berguna daripada menunjukkan bahwa tindakan terlarang benar-benar ditolak pada komponen yang bertanggung jawab.
Rencanakan penolakan layanan di lebih dari satu lapisan
Tautan jaringan yang jenuh dan permintaan aplikasi yang mahal gagal di tempat yang berbeda. Pembatasan laju di tepi web dapat membantu membatasi pola permintaan, sementara batas aplikasi dapat membatasi pekerjaan seperti pencarian, unggahan atau ekspor. Modul pembatasan permintaan NGINX menyediakan salah satu mekanisme; kunci dan ambang batas harus sesuai dengan pengguna nyata dan diuji untuk menghindari penolakan lalu lintas yang sah.
Panduan penolakan layanan OWASP juga membahas kehabisan sumber daya dalam perilaku aplikasi. Tetapkan batas waktu dan ukuran untuk pekerjaan yang mahal, gunakan antrean terbatas dan pantau sinyal kegagalan. Kontrol lokal tidak dapat menciptakan kapasitas pada tautan upstream yang sudah jenuh. Konfirmasi perlindungan jaringan spesifik yang termasuk dalam penawaran yang dipilih dan siapkan jalur eskalasi. Jangan pernah menganggap perlindungan Layer 3–4 dalam katalog juga membuktikan perlindungan untuk setiap beban kerja HTTP.
Jadikan pemulihan bagian dari publikasi
Periksa situs dari klien eksternal menggunakan hostname yang dimaksudkan. Verifikasi HTTPS, pengalihan, sumber daya statis, login dan transaksi aplikasi yang representatif. Konfirmasi bahwa listener administratif dan file privat tetap tidak dapat diakses. Simulasikan upstream yang berhenti dan periksa bahwa tepi mengembalikan kegagalan terkendali daripada mengekspos detail internal atau menunggu tanpa batas.
Untuk Canvas, baca kontrol yang tersedia dalam akun hosting. Untuk VPS, pelihara tepi web dan aplikasi sebagai bagian dari rencana operasi Anda sendiri. Port jaringan yang besar adalah spesifikasi kapasitas, bukan bukti bahwa aplikasi dapat mempertahankan throughput tersebut. Simpan pemantauan, pemulihan dan kontak penyedia dalam runbook. Publikasikan hanya setelah jalur permintaan yang sebenarnya dan jalur pemulihan yang praktis telah diverifikasi.
Daftar periksa praktis Anda.
- Lacak permintaan publik dan administratif.
- Tentukan root yang disajikan dan listener upstream.
- Percayai header yang diteruskan hanya dari perantara yang disetujui.
- Uji otorisasi dan batas cache.
- Siapkan batas dan eskalasi untuk kegagalan jaringan dan aplikasi.
Detail yang penting.
Dapatkah server web juga bertindak sebagai reverse proxy?+
Ya. NGINX adalah salah satu contoh yang terdokumentasi. Perannya bergantung pada konfigurasi, dan aplikasi tetap memerlukan otorisasi dan pemeliharaannya sendiri.
Apakah reverse proxy otomatis menyembunyikan origin?+
Tidak. Origin dapat tetap dapat dijangkau kecuali pengaturan perutean, firewall dan listener menegakkan batas yang dimaksudkan.
Apakah pembatasan permintaan akan menghentikan setiap serangan DDoS?+
Tidak. Ini mengatasi pola permintaan HTTP tertentu. Kejenuhan jaringan dan kegagalan sumber daya lainnya memerlukan kontrol upstream dan aplikasi yang sesuai.
Kunjungi sumbernya.
Referensi ini mendukung konsep teknis dalam panduan ini. Ikuti dokumentasi terkini sebelum mengubah sistem produksi.
- NGINX: Panduan pemula nginx.org
- NGINX: Pembatasan permintaan HTTP nginx.org
- NIST SP 800-207: Arsitektur Zero Trust nvlpubs.nist.gov
- OWASP: Pencegahan Denial of Service cheatsheetseries.owasp.org
Panduan editorial oleh SwissOctet. Contoh bersifat ilustratif. Spesifikasi layanan, opsi yang tersedia, dan ketentuan kontraktual harus diverifikasi secara terpisah.