# Pisahkan tepi web publik Anda dari aplikasi | SwissOctet Insights https://swissoctet.com/id/insights/separate-the-web-edge-from-the-app/ SwissOctet / Wawasan / Web & onion Web & onion Terapan · 4 menit baca Pisahkan tepi web publik Anda dari aplikasi Beri server web, reverse proxy, dan aplikasi tanggung jawab yang berbeda, dengan akses origin yang disengaja, TLS, batas permintaan, dan jalur insiden. Oleh SwissOctet Editorial Simpan panduan Salin tautan DI HALAMAN INI 01 Permintaan web melewati beberapa tanggung jawab 02 Gunakan tepi untuk mengatur perilaku HTTP 03 Reverse proxy tidak menghilangkan paparan origin 04 Terapkan keputusan akses di dalam aplikasi 05 Rencanakan penolakan layanan di lebih dari satu lapisan 06 Jadikan pemulihan bagian dari publikasi Daftar periksa praktis Anda Sumber & bacaan lanjutan Kembali ke pustaka JAWABAN LANGSUNG 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. 01 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. 02 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 03 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. 04 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. 05 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. 06 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. UBAH MENJADI TINDAKAN 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. Unduh daftar periksa PERTANYAAN UMUM 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. REFERENSI UTAMA 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. HUBUNGKAN PENGETAHUAN Infrastruktur terkait. Canvas Web Swiss Vector VPS Swiss Pulse NVMe Swiss Transit 40 Swiss JAGA BENANGNYA Catatan lapangan Anda berikutnya. Jelajahi semua panduan CATATAN LAPANGAN / 01 + Operasi hari kedua Terapan Baseline pengerasan Linux VPS yang dapat Anda pertahankan Amankan administrasi, ekspos hanya layanan yang diperlukan, dan tetapkan pembaruan serta pemulihan tanpa mengunci diri Anda sendiri. 6 menit baca Baca panduannya CATATAN LAPANGAN / 02 + Web & onion Fondasi Web hosting atau VPS: pilih pekerjaan yang ingin Anda miliki Bandingkan persyaratan aplikasi, kendali, dan tanggung jawab pemeliharaan alih-alih memperlakukan VPS sebagai langkah berikutnya yang otomatis untuk setiap situs web. 6 menit baca Baca panduannya CATATAN LAPANGAN / 03 + Web & onion Terapan Runbook cutover domain, DNS, dan TLS untuk server baru Siapkan perutean hostname, sertifikat, dan rollback secara bersamaan agar migrasi mengubah server tanpa merusak identitas situs atau koneksi aman. 4 menit baca Baca panduannya