Ribuan permintaan berbahaya berhasil diblokir. Aturan keamanan diperbarui secara berkala. Dashboard Web Application Firewall atau WAF memperlihatkan bahwa perlindungan aplikasi berjalan setiap hari.

Namun, ada pertanyaan yang lebih mendasar daripada jumlah serangan yang dihentikan: apakah aplikasi hanya dapat diakses melalui jalur yang diperiksa WAF?

Pertanyaan ini menentukan seberapa jauh perlindungan tersebut berlaku. Jika server asal masih menerima akses langsung dari internet, sebagian permintaan dapat mencapai aplikasi tanpa melewati pemeriksaan pada lapisan depan.

Perusahaan akhirnya memiliki dua jalur menuju layanan yang sama, dengan tingkat perlindungan yang berbeda. Satu jalur diawasi secara ketat, sementara jalur lainnya mungkin tidak masuk dalam perhatian tim keamanan.

Perlindungan WAF Bergantung pada Jalur yang Dilalui Permintaan

Pada penerapan WAF berbasis cloud yang berada di depan aplikasi, domain publik diarahkan menuju layanan perantara. Permintaan pengguna diperiksa terlebih dahulu sebelum diteruskan ke server asal, yaitu infrastruktur yang menjalankan aplikasi atau menyediakan kontennya.

Alur tersebut memungkinkan WAF menyaring permintaan sesuai aturan yang diterapkan. Akan tetapi, pengalihan melalui DNS tidak otomatis membuat server asal menolak koneksi dari sumber lain.

Sebagai ilustrasi, sebuah portal pelanggan telah menggunakan WAF pada domain utamanya. Di belakang layanan tersebut, load balancer masih memiliki alamat publik dan tetap menerima permintaan langsung menuju aplikasi.

Pengguna yang mengikuti domain utama akan melewati pemeriksaan. Sementara itu, koneksi melalui alamat alternatif berpotensi mencapai aplikasi tanpa melalui WAF yang sama.

OWASP membahas kemungkinan ini dalam Web Security Testing Guide, khususnya pada pemetaan arsitektur aplikasi. Panduan tersebut menjelaskan bahwa akses langsung ke server backend dapat menjadi jalur untuk melewati WAF berbasis cloud.

Persoalannya terletak pada cakupan penerapan kontrol. WAF dapat bekerja sesuai konfigurasi, tetapi belum tentu ditempatkan pada seluruh jalur yang dapat digunakan untuk menjangkau aplikasi.

Jalur Alternatif Sering Tertinggal Setelah Perubahan Infrastruktur

Penerapan layanan keamanan biasanya berlangsung di tengah sistem yang sudah beroperasi. Sebelumnya, aplikasi mungkin diakses langsung melalui server publik. Setelah WAF dipasang, domain utama diperbarui, sedangkan konfigurasi akses lama belum seluruhnya ditinjau kembali.

Kondisi serupa dapat muncul ketika perusahaan mengganti penyedia hosting, menambah load balancer, atau memindahkan aplikasi ke lingkungan cloud.

Beberapa akses juga sengaja dipertahankan untuk keperluan operasional. Tim membutuhkan jalur pengujian, vendor memerlukan koneksi sementara, atau administrator membuka akses ketika menangani gangguan.

Kebutuhan tersebut dapat dibenarkan. Masalah muncul ketika pengecualian tidak memiliki batas waktu, pembatasan sumber koneksi, dan penanggung jawab yang jelas.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Evaluasi keamanan karena itu perlu mencakup hubungan antara konfigurasi baru dan akses yang sudah ada sebelumnya. Setiap jalur yang masih aktif harus memiliki alasan operasional serta kontrol yang dapat diperiksa.

Risiko Ini Telah Dibahas dalam Penelitian Keamanan

Keterbukaan server asal bukan sekadar kemungkinan dalam rancangan jaringan. Penelitian berjudul Maneuvering Around Clouds: Bypassing Cloud-based Security Providers, yang dipublikasikan dalam konferensi ACM CCS pada 2015, mengkaji bagaimana informasi server asal dapat terungkap dan memungkinkan akses langsung yang melewati penyedia perlindungan berbasis cloud.

Penelitian tersebut menjadi landasan historis untuk memahami kelemahan pengalihan lalu lintas yang hanya bergantung pada perubahan DNS. Temuannya tidak dapat digunakan untuk menyimpulkan kondisi seluruh layanan WAF saat ini, tetapi prinsip risikonya tetap relevan untuk pemeriksaan arsitektur.

Dokumentasi resmi AWS dan Cloudflare juga menyediakan mekanisme khusus untuk membatasi akses menuju origin. Keberadaan panduan tersebut memperjelas bahwa perlindungan server asal merupakan pekerjaan konfigurasi tersendiri.

Mengaktifkan layanan di lapisan depan perlu disertai kebijakan yang menentukan koneksi mana yang boleh diterima di belakangnya.

Akses Langsung Dapat Mengurangi Perlindungan dan Visibilitas

Server asal yang dapat diakses langsung tidak otomatis berarti data perusahaan telah bocor. Aplikasi masih mungkin memiliki autentikasi, otorisasi, validasi masukan, dan kontrol keamanan lainnya.

Namun, organisasi perlu memeriksa perlindungan apa saja yang hanya diterapkan pada WAF atau layanan perantara.

Jika pembatasan frekuensi permintaan berada di lapisan depan, akses langsung belum tentu mengikuti batas yang sama. Jika pengendalian bot diterapkan melalui layanan tersebut, koneksi menuju origin mungkin tidak menjalani pemeriksaan serupa.

Dampaknya juga menyentuh pemantauan. Dashboard WAF mencatat lalu lintas yang diterimanya. Permintaan melalui jalur lain perlu ditelusuri melalui log server, load balancer, atau perangkat jaringan terkait.

Karena itu, rendahnya aktivitas mencurigakan pada dashboard WAF belum cukup untuk menggambarkan seluruh aktivitas menuju aplikasi.

Dari sisi ketersediaan, akses langsung juga dapat membuat permintaan mencapai server tanpa memperoleh manfaat cache di lapisan depan. Besarnya dampak bergantung pada jenis permintaan, kapasitas infrastruktur, dan perlindungan lain yang tersedia.

Alamat IP yang Dirahasiakan Tetap Memerlukan Pembatasan Akses

Membatasi penyebaran informasi infrastruktur merupakan langkah yang berguna. Meski demikian, keamanan server asal sebaiknya tetap bertahan ketika alamatnya diketahui pihak lain.

Ukuran keberhasilannya adalah apakah koneksi yang tidak diizinkan akan ditolak.

Mengganti alamat IP tanpa memperbaiki kebijakan akses hanya mempertahankan ketergantungan pada kerahasiaan alamat baru. Apabila alamat tersebut kembali diketahui, persoalan yang sama dapat muncul.

Penggunaan HTTPS juga perlu dipahami sesuai fungsinya. Enkripsi melindungi komunikasi, tetapi tidak dengan sendirinya memastikan bahwa koneksi berasal dari perantara yang disetujui perusahaan.

Dengan kata lain, ada tiga kebutuhan yang perlu dibedakan: melindungi informasi infrastruktur, mengenkripsi komunikasi, dan memverifikasi pihak yang boleh terhubung. Ketiganya saling mendukung, tetapi tidak saling menggantikan.

Pembatasan Origin Perlu Memeriksa Sumber dan Identitas Koneksi

Perbaikan dapat dimulai dengan membatasi sumber koneksi pada firewall atau security group. Server asal hanya menerima lalu lintas dari perantara yang diperlukan serta jalur administrasi yang telah disetujui.

Namun, pembatasan berdasarkan jaringan penyedia perlu ditinjau cakupannya. Pada infrastruktur bersama, koneksi dari jaringan penyedia belum tentu membuktikan bahwa permintaan berasal dari konfigurasi milik perusahaan sendiri.

Karena itu, verifikasi tambahan dapat diperlukan.

AWS mendokumentasikan penggunaan header rahasia yang ditambahkan CloudFront dan diperiksa oleh Application Load Balancer. Nilai tersebut harus dijaga sebagai kredensial karena pihak yang mengetahuinya dapat mencoba mengirimkan nilai yang sama.

Pendekatan lain menggunakan mutual TLS atau mTLS untuk memverifikasi identitas koneksi melalui sertifikat. Pada mekanisme ini, pengelolaan sertifikat dan cakupan kepercayaannya harus disesuaikan dengan kebutuhan organisasi.

Jika infrastrukturnya mendukung, server asal juga dapat ditempatkan pada jaringan privat dan dihubungkan melalui mekanisme yang sesuai. Pilihan ini mengurangi kebutuhan membuka layanan origin secara langsung ke internet.

Tidak ada satu konfigurasi yang tepat untuk semua sistem. Integrasi pihak ketiga, pemeriksaan kesehatan layanan, serta kebutuhan pemulihan harus diperhitungkan agar kontrol keamanan dapat dipertahankan dalam operasional sehari-hari.

Pengujian Harus Membuktikan Penolakan pada Jalur yang Tidak Diizinkan

Pemeriksaan keamanan WAF perlu menghasilkan bukti perilaku sistem. Status aktif dan daftar aturan belum cukup untuk memastikan akses langsung telah dibatasi.

Dalam ruang lingkup pengujian yang disepakati, perusahaan perlu memeriksa apakah:

• Jalur resmi melalui WAF tetap berfungsi untuk pengguna dan integrasi yang sah.
• Akses langsung yang tidak diizinkan gagal mencapai fungsi aplikasi yang dilindungi.
• Hostname alternatif dan alamat layanan bawaan mengikuti kebijakan yang sesuai.
• Pembatasan diterapkan secara konsisten pada IPv4, IPv6, dan port yang relevan.
• Jalur pemeliharaan memiliki autentikasi, pembatasan akses, dan pencatatan yang memadai.

Hasil pengujian juga harus dijelaskan secara proporsional. Server yang memberikan respons belum tentu menyajikan aplikasi yang sama. Aplikasi yang dapat dijangkau langsung juga belum otomatis terbukti memiliki kerentanan yang dapat dieksploitasi.

Laporan yang baik membedakan keterbukaan akses, kontrol yang dapat dilewati, dan dampak yang berhasil diverifikasi. Pembedaan ini membantu tim menentukan prioritas perbaikan berdasarkan bukti.

Pastikan Investasi WAF Melindungi Jalur yang Sebenarnya

Keberhasilan penerapan WAF perlu dinilai dari cakupan perlindungannya. Jumlah permintaan yang diblokir tetap berguna, tetapi perusahaan juga membutuhkan kepastian bahwa jalur alternatif tidak menghilangkan manfaat kontrol tersebut.

Langkah yang dapat dilakukan adalah memetakan seluruh pintu masuk aplikasi, meninjau pengecualian akses, membatasi koneksi menuju origin, dan menguji kembali hasil perbaikannya.

Pemeriksaan ini perlu diulang setelah perubahan infrastruktur yang relevan. Penambahan server, migrasi hosting, atau kebutuhan integrasi baru dapat mengubah jalur akses yang sebelumnya sudah terkendali.

Evaluasi Keamanan Aplikasi Bersama Fourtrezz

Fourtrezz menyediakan layanan Penetration Testing dan Vulnerability Assessment untuk aplikasi web, API, jaringan, serta server.

Melalui kerja sama pengujian dengan ruang lingkup yang disepakati, perusahaan dapat mengevaluasi keterpaparan server asal, jalur akses aplikasi, dan kelemahan keamanan yang memerlukan perbaikan. Hasilnya menjadi dasar bagi tim untuk menyusun langkah penanganan serta memverifikasi efektivitas kontrol yang diterapkan.

Diskusikan kebutuhan pengujian keamanan perusahaan Anda bersama Fourtrezz agar investasi perlindungan aplikasi didukung oleh hasil evaluasi yang terukur.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]