Keseimbangan antara perekaman dan pemblokiran di WAF

Informatec Digital » Sumber daya » Keseimbangan antara perekaman dan pemblokiran di WAF

Menemukan keseimbangan yang tepat antara pencatatan (logging) dan pemblokiran dalam WAF telah menjadi salah satu masalah umum bagi tim keamanan dan operasional. Firewall aplikasi web dapat menghentikan serangan yang sangat serius, tetapi jika dikonfigurasi terlalu agresif, ia dapat memblokir pembelian, akses, atau panggilan API yang sah. Jika dikonfigurasi terlalu longgar, ia akhirnya hampir hanya menjadi hiasan. Kuncinya adalah menyesuaikan dengan cermat kapan harus mencatat, kapan harus menghitung, kapan harus mengizinkan, dan kapan harus memblokir.

Dalam artikel ini, kita akan membahas cara mencapai keseimbangan ini menggunakan kemampuan WAF modern (daftar izin, aturan berbasis frekuensi, mode pembelajaran, integrasi SIEM, pembelajaran mesin, dll.), yang didukung oleh contoh konkret dari AWS WAF, ModSecurity, WAF berbasis cloud, dan solusi on-premises . Anda akan melihat cara membatasi false positive tanpa menurunkan tingkat perlindungan, cara mengatur kebijakan berdasarkan aplikasi, dan cara menggunakan logging sebagai sekutu, bukan sebagai sumber kebisingan yang konstan dan tidak terkendali.

Apa itu WAF dan mengapa pendaftaran sangat penting?

Firewall aplikasi web bertindak sebagai lapisan cerdas antara pengguna dan server , menganalisis lalu lintas HTTP/HTTPS secara real-time. Tidak seperti firewall jaringan tradisional yang memantau port dan IP, WAF menelusuri lebih dalam: URL, parameter, isi permintaan, header, cookie, metode HTTP, dan banyak lagi.

Misinya adalah untuk mendeteksi dan menghentikan serangan Layer 7 yang umum : injeksi SQL, XSS, LFI/RFI, serangan terhadap kontrol akses, penyalahgunaan API, scraping agresif, brute force, dan bahkan pola DDoS tingkat aplikasi tertentu. Untuk melakukan ini, ia bergantung pada serangkaian aturan, tanda tangan, dan kebijakan keamanan yang terus diperbarui.

Pencatatan log adalah sisi lain dari koin. Setiap keputusan WAF—izinkan, blokir, atau hanya hitung—dapat disertai dengan peristiwa terperinci dalam log . Log ini memungkinkan:

• Selidiki insiden: merekonstruksi apa yang terjadi dan bagaimana upaya dilakukan untuk mengeksploitasi kerentanan.
• Sesuaikan aturan: Mendeteksi false positive dengan melihat permintaan sah mana yang diblokir oleh WAF.
• Patuhi peraturan: menunjukkan bahwa kontrol aktif telah diterapkan (PCI DSS, GDPR, audit internal, dll.).
• Memberi makan SIEM: mengkorelasikan serangan aplikasi dengan peristiwa jaringan, sistem, identitas, dll.

Masalahnya adalah WAF yang disetel dengan buruk dapat memenuhi log dengan ribuan kejadian yang tidak relevan , sehingga mustahil untuk menemukan apa yang penting dan, di atas itu, menyebabkan penolakan yang tidak beralasan terhadap lalu lintas yang sah. Di situlah seni bermain-main dengan mode pencatatan, penghitungan, dan pemblokiran berperan.

Model keamanan di WAF: daftar blokir, daftar izin, dan pendekatan hibrida.

Sebagian besar WAF modern menggabungkan beberapa pendekatan penyaringan, yang secara langsung memengaruhi bagaimana permintaan dicatat dan diblokir . Secara umum, kita dapat mengidentifikasi dua filosofi klasik, ditambah model hibrida yang sangat umum.

WAF berbasis daftar blokir mengikuti model keamanan negatif. Prinsip intinya adalah: "Saya mengizinkan semuanya kecuali yang saya ketahui berbahaya." Cara kerjanya adalah dengan menggunakan tanda tangan serangan yang dikenal (injeksi SQL, XSS, pola bot, dll.) dan aturan yang mendefinisikan apa yang dianggap mencurigakan. Meskipun lebih mudah diterapkan pada awalnya, mengandalkan model ini saja berisiko memungkinkan vektor serangan atau varian baru lolos tanpa terdeteksi.

WAF dengan daftar izin (allowlist) bekerja sebaliknya: "memblokir semua kecuali yang secara eksplisit diizinkan." Ini didasarkan pada model keamanan positif. Hanya lalu lintas yang sesuai dengan perilaku sah yang didefinisikan—rute, metode, parameter, format, ukuran, dll.—yang diterima. Ini jauh lebih aman, tetapi membutuhkan penyesuaian yang signifikan dan dapat menghasilkan false positive pada awalnya jika tidak dipersiapkan dengan benar.

Karena kelebihan dan kekurangan dari setiap pendekatan, model hibrida yang menggabungkan daftar izin (allowlist) dan daftar blokir (blocklist) semakin umum digunakan . Dalam skenario ini, profil lalu lintas yang diharapkan didefinisikan (misalnya, apa yang dianggap sebagai permintaan login atau pembayaran normal), dan tanda tangan serta heuristik diterapkan secara bersamaan untuk mendeteksi pola berbahaya yang umum. Untuk tujuan pencatatan log, pendekatan hibrida ini memungkinkan:

• Tandai sebagai peristiwa berisiko tinggi yaitu sesuatu yang melanggar daftar barang yang diizinkan.
• Perlakukan sebagai peringatan prioritas sedang/rendah Pola daftar blokir umum.
• Gunakan mode "hitung" untuk melihat apa yang akan melanggar aturan sebelum mengaktifkan pemblokiran.

WAF di jaringan, di host, dan di cloud: dampaknya pada pencatatan dan penguncian

Model penerapan WAF sangat memengaruhi cara penanganan pencatatan dan pemblokiran lalu lintas. Pencatatan permintaan pada perangkat jaringan tidak sama dengan pencatatan permintaan pada agen di dalam server atau pada layanan cloud terkelola.

WAF berbasis jaringan biasanya diterapkan sebagai perangkat fisik atau virtual di dalam infrastruktur, antara internet dan aplikasi. Ini adalah pendekatan klasik yang digunakan oleh produsen seperti F5. Pendekatan ini menawarkan keunggulan kinerja tinggi dan kontrol yang terperinci , tetapi konfigurasi dan pengelolaannya bisa kompleks. Pencatatan biasanya dikirim ke syslog atau SIEM pusat, dan penting untuk menyaring dengan cermat apa yang disimpan untuk menghindari kelebihan beban penyimpanan dan alat analisis, serta untuk mendiagnosis masalah pada jaringan IP dan DNS.

WAF berbasis host berjalan pada server (atau kontainer) yang sama tempat aplikasi berada, biasanya sebagai modul atau agen (misalnya, ModSecurity yang terintegrasi ke dalam Nginx atau Apache; menggabungkannya dengan pengerasan Linux menggunakan SELinux meningkatkan postur keamanan). Model ini memungkinkan konteks aplikasi yang lebih luas dan aturan yang sangat spesifik per layanan, dengan mengorbankan konsumsi sumber daya lokal dan membutuhkan manajemen log yang lebih terdistribusi. Log dapat disimpan dalam file lokal dan kemudian diteruskan, atau diintegrasikan dengan layanan pencatatan terpusat.

WAF berbasis cloud (Cloudflare, Akamai, Imperva Cloud, AWS WAF, dll.) terintegrasi dengan load balancer, CDN, atau jaringan virtual. Penyedia biasanya menawarkan dasbor dan ekspor log ke S3, BigQuery, syslog jarak jauh, atau SIEM. Secara umum, WAF lebih mudah diatur, tetapi Anda harus menyesuaikan kebijakan pencatatan log Anda dengan model penyedia: jenis kejadian, periode retensi, filter tingkat keparahan, dll.

Memilih salah satu model bukanlah sekadar keputusan teknis, tetapi juga soal bagaimana Anda ingin menyeimbangkan pencatatan dan penguncian: layanan yang dikelola cloud menyederhanakan banyak aspek, tetapi Anda mungkin menginginkan kendali mutlak atas tempat penyimpanan log karena kebijakan kepatuhan atau kerahasiaan, yang mendorong Anda ke arah model on-premise atau hybrid.

Syarat, aturan, dan ACL web: bagaimana WAF memutuskan apakah akan memblokir, mengizinkan, atau hanya mendaftarkan

Terlepas dari pabrikannya, semua WAF modern didasarkan pada konsep kondisi akses, aturan, dan kebijakan . Memahami hal ini sangat penting untuk berhasil menggunakan mode penghitungan, pencatatan, dan penguncian dalam lingkungan produksi.

Kondisi tersebut menjelaskan bagian mana dari permintaan yang diperiksa: IP sumber, header HTTP tertentu (Host, User-Agent, Accept, Content-Type…), parameter kueri, isi permintaan, cookie, metode HTTP, negara asal, dll. Misalnya, di AWS WAF Classic Anda dapat menentukan kondisi IP dengan hingga 10.000 alamat atau rentang, atau kondisi pencocokan string pada sebagian URL.

Aturan menggabungkan satu atau lebih kondisi dan menetapkan tujuan: untuk mengizinkan, untuk memblokir, atau untuk menghitung. Ketika suatu aturan memiliki beberapa kondisi, kondisi tersebut biasanya dievaluasi dengan operator logika AND : semua kondisi harus terpenuhi agar aturan tersebut dipicu. Aturan normal tanpa kondisi, dalam praktiknya, tidak cocok dengan apa pun, dan tindakannya tidak pernah dipicu.

Banyak WAF, termasuk AWS WAF, juga memiliki aturan berbasis laju . Aturan ini menghitung permintaan yang datang dari alamat IP (atau sekumpulan alamat IP yang memenuhi kondisi tertentu) selama jangka waktu tertentu, misalnya, lima menit. Jika ambang batas terlampaui—misalnya, 1.000 permintaan dalam lima menit—aturan tersebut akan berlaku: memblokir atau hanya menghitung. Ini sangat berguna untuk:

• Kontrol serangan brute force pada formulir login.
• Batasi pengambilan data secara agresif atau bot yang tidak sopan.
• Meredakan jenis serangan DDoS tertentu pada tingkat aplikasi.

Level selanjutnya adalah Web ACL (Access Control List) . Di sini, aturan-aturan dikelompokkan, dan urutan evaluasi serta tindakan default (IZINKAN atau BLOKIR) ditentukan. Sebuah permintaan melewati aturan-aturan secara berurutan; jika cocok dengan salah satu aturan, tindakannya diterapkan, dan evaluasi aturan lainnya dihentikan. Jika tidak cocok dengan aturan apa pun, tindakan default yang ditentukan dalam ACL diterapkan.

Dalam hal menyeimbangkan pencatatan dan pemblokiran, ACL adalah tempat Anda memutuskan apakah Anda ingin sistem bersifat permisif secara default (IZINKAN dan pemblokiran hanya berdasarkan aturan tertentu) atau sangat ketat (BLOKIR kecuali dalam kasus-kasus luar biasa). Selain itu, banyak solusi memungkinkan Anda untuk mengatur aturan dalam mode "hitung" di dalam ACL, sehingga aturan tersebut mencatat kecocokan tetapi tidak memblokir lalu lintas—ideal untuk fase penyetelan.

Daftar putih dan pengurangan kebisingan dalam log

Allowlist adalah alat fundamental untuk mengurangi false positive dan noise dalam log . Idenya sederhana: dalam konteks tertentu, Anda memberi tahu WAF untuk tidak menerapkan arahan atau serangkaian aturan pada lalu lintas tertentu yang telah Anda kategorikan sebagai tepercaya atau yang Anda ketahui berada di luar norma tetapi sah.

Sebagai contoh, di AWS WAF Anda dapat membuat aturan daftar izin (allowlist) sehingga jika permintaan berasal dari alamat IP atau rentang tertentu , atau jika cocok dengan pola URL dan metode HTTP yang dikenal, pemeriksaan tanda tangan tertentu tidak diterapkan. Hal ini membantu untuk:

• Mencegah API internal yang menggunakan pola "aneh" menghasilkan positif palsu secara terus-menerus.
• Kurangi latensi yang ditimbulkan oleh inspeksi mendalam pada lalu lintas yang sudah Anda anggap tepercaya.
• Kurangi jumlah catatan yang tidak perlu dalam log WAF.

Pada platform seperti ModSecurity, pendekatan yang disarankan bukanlah memodifikasi aturan standar (misalnya, OWASP Core Rule Set), melainkan membuat pengecualian khusus berdasarkan ID aturan untuk parameter, jalur, atau pengguna tertentu. Hal ini memungkinkan Anda untuk mempertahankan perlindungan secara keseluruhan tanpa menciptakan kerentanan besar dengan menonaktifkan seluruh aturan di seluruh situs.

Kuncinya adalah membuat daftar yang diizinkan (allowlist) secara spesifik , bukan pendekatan menyeluruh. Jauh lebih baik untuk mengecualikan kombinasi tertentu (aturan X + parameter Y di URL Z) daripada menonaktifkan aturan X secara global. Dengan begitu, pencatatan (logging) tetap bermanfaat dan Anda tidak menciptakan titik buta yang tidak perlu.

Aturan dan batasan protokol: kapan harus memblokir, kapan harus memperingatkan

Banyak WAF (Web Application Firewall) menggabungkan serangkaian aturan sanitasi protokol HTTP yang bertindak sebagai filter pertama untuk lalu lintas yang salah format atau mencurigakan . Aturan-aturan ini memeriksa header, metode, ukuran argumen yang diperlukan, dll., dan sering menjadi sumber perlindungan yang baik sekaligus positif palsu jika tidak dipahami dengan benar.

Beberapa contoh yang sangat umum:

• Header Accept Hilang (Header Accept hilang): Ini bukan pelanggaran RFC secara ketat, tetapi banyak permintaan tanpa header ini berasal dari alat otomatis atau skrip yang ditulis dengan buruk. Hal ini dapat memengaruhi API kustom atau klien yang tidak mengirimkannya. Di banyak lingkungan, pencatatan dan penghitungan lebih disukai daripada pemblokiran langsung.
• Header Host HilangMenurut standar HTTP/1.1, header Host bersifat wajib. WAF juga membutuhkannya untuk menentukan kebijakan mana yang akan diterapkan. Pemblokiran di sini biasanya wajar, tetapi dapat menghasilkan false positive selama pengujian atau karena kesalahan konfigurasi lalu lintas internal; disarankan untuk memantau log sebelum mengaktifkan pemblokiran ketat.
• Header User-Agent HilangAturan ini bertujuan untuk mengekang bot-bot sederhana dan lalu lintas yang tidak teridentifikasi. Masalahnya adalah banyak API yang sah mungkin tidak mengirimkan User-Agent. Pendekatan yang paling masuk akal biasanya adalah dengan melakukan pencatatan (log) dan, jika API yang konsisten dan sah terdeteksi, tambahkan IP atau pola mereka ke daftar yang diizinkan.
• Validasi GET/HEAD dengan isiMeskipun RFC tidak secara tegas melarang pengiriman isi permintaan (body) dengan permintaan GET atau HEAD, hal ini bukan praktik umum dan dapat mengindikasikan upaya penghindaran. Dalam banyak kasus, langkah pertama adalah mencatat semua permintaan ini dan, jika ditemukan sebagai anomali yang mencurigakan, lanjutkan untuk memblokirnya.
• Content-Type dengan body hilangJika terdapat isi permintaan tetapi tidak ada Content-Type, itu merupakan indikasi jelas penggunaan protokol yang tidak tepat atau upaya untuk menghindari analisis. Dalam kasus ini, pendekatan pemblokiran yang lebih agresif biasanya masuk akal, terutama di lingkungan yang terhubung langsung ke internet.

Selain aturan protokol ini, batasan argumen sering ditemukan untuk melindungi dari luapan data tingkat aplikasi dan serangan DoS. Misalnya:

• Jumlah maksimum argumen per permintaan (secara default, 255 di beberapa WAF).
• Panjang maksimum untuk setiap argumen (misalnya, 400 karakter).
• Ukuran total gabungan dari semua argumen (misalnya, 64.000 byte).

Nilai-nilai ini wajar untuk banyak aplikasi, tetapi ada kasus-kasus tertentu—pengunggahan formulir yang kompleks, filter tingkat lanjut, pemuatan JSON besar—di mana terjadi kesalahan positif. Dalam skenario tersebut, pendekatan yang paling bijaksana adalah memulai dengan mencatat dan menghitung , meninjau titik akhir mana yang melanggar batas, dan menyesuaikan hanya untuk rute-rute tersebut, daripada menghapus semua batasan untuk seluruh situs.

Hasil positif palsu: bagaimana mendeteksinya dan menghindari kegagalan dalam upaya tersebut

False positive adalah permintaan sah yang diidentifikasi oleh WAF sebagai berbahaya dan diblokir atau ditandai sebagai serangan. Hal ini tidak dapat dihindari, terutama jika Anda memiliki aturan yang komprehensif seperti OWASP CRS yang diaktifkan, tetapi dapat dikelola secara profesional sehingga tidak menjadi masalah sehari-hari.

Mendeteksi false positive dimulai dengan peninjauan log yang cermat . Ini melibatkan pemeriksaan permintaan mana yang diblokir, aturan mana yang memicunya, dan konteks terjadinya (URL, parameter, pengguna, asal, dll.). Alat visual dan dasbor dapat membantu mengidentifikasi lonjakan kesalahan 403 atau pola yang tidak biasa.

Pendekatan yang sangat direkomendasikan, baik oleh penyedia cloud maupun komunitas ModSecurity, adalah menggunakan mode simulasi atau penghitungan . Dalam mode ini, aturan yang ingin Anda uji mencatat setiap kecocokan tetapi tidak memblokir. Ini memungkinkan Anda untuk melihat, misalnya, berapa banyak permintaan sah yang akan diblokir oleh aturan SQLi baru sebelum Anda berani mengaktifkannya di lingkungan produksi.

Sebaiknya juga menguji aturan tersebut di lingkungan staging atau pra-produksi yang menerima lalu lintas nyata atau simulasi. Alat seperti OWASP ZAP atau skrip pemutaran ulang lalu lintas dapat membantu Anda mensimulasikan pola yang sah dan serangan yang dikenal untuk menguji perilaku WAF.

Selain itu, sangat penting untuk mempertimbangkan dampak operasional dan reputasi dari false positive: gangguan pembayaran, kegagalan pendaftaran pengguna, panggilan API penting yang gagal tanpa penjelasan—semuanya dapat berdampak langsung pada pendapatan dan citra merek. Terlalu banyak false positive juga akan membebani tim keamanan dengan peringatan yang tidak memberikan nilai tambah, sehingga sulit untuk mengidentifikasi insiden yang sebenarnya.

Strategi untuk menyesuaikan aturan dan penggunaan registri secara cerdas.

Mengelola false positive bukan tentang menonaktifkan aturan sampai "semuanya berfungsi," tetapi tentang menyempurnakan WAF dengan presisi yang sangat tinggi . Di sinilah praktik-praktik baik seperti berikut ini berperan:

Pertama, hindari menonaktifkan aturan secara global. Lebih baik membuat pengecualian yang sangat spesifik : kecualikan ID aturan hanya untuk rute tertentu, untuk parameter tertentu, atau untuk lalu lintas internal. Dengan cara ini, Anda tetap terlindungi di bagian aplikasi lainnya dan tetap memiliki log yang bermanfaat.

Kedua, manfaatkan mode penghitungan sebelum memblokir. Mengaktifkan aturan baru awalnya hanya dalam mode pencatatan memungkinkan Anda mengukur berapa banyak permintaan sah yang akan terpengaruh. Anda dapat melengkapi ini dengan peringatan di SIEM untuk mendeteksi dengan cepat jika suatu aturan menghasilkan volume kecocokan yang abnormal.

Ketiga, integrasikan WAF dengan SIEM atau platform pencatatan terpusat . Hal ini mempermudah korelasi antara peristiwa WAF dengan indikator lain: aktivitas sistem yang tidak biasa, kegagalan otentikasi massal, perubahan konfigurasi yang mencurigakan, dll. Ini juga membantu memprioritaskan aturan mana yang harus disesuaikan terlebih dahulu berdasarkan tingkat keparahan dan frekuensi peristiwa.

Keempat, dokumentasikan setiap perubahan: aturan mana yang disempurnakan, untuk titik akhir mana, dengan alasan apa, dan dengan bukti apa. Melihat manual server dapat membantu dalam hal ini. Dokumentasi ini tidak hanya membantu menjaga kontrol internal, tetapi juga sangat berharga dalam audit dan tinjauan keamanan, di mana Anda ingin menunjukkan bahwa kontrol tidak dinonaktifkan begitu saja.

Otomatisasi, pembelajaran mesin, dan aturan adaptif di WAF

Seiring berkembangnya aplikasi dan semakin kompleksnya lalu lintas, mengelola WAF secara manual menjadi tidak realistis. Di sinilah otomatisasi, analisis log tingkat lanjut, dan, dalam beberapa kasus, pembelajaran mesin berperan.

Pertama, integrasi dengan SIEM memungkinkan Anda untuk membangun aturan korelasi dan respons otomatis : misalnya, jika sekumpulan IP berulang kali memicu aturan injeksi atau XSS, Anda dapat menghasilkan tindakan otomatis untuk menambahkan IP tersebut ke daftar blokir sementara atau memperkuat tingkat inspeksi.

Kedua, beberapa WAF menggabungkan mode pembelajaran mesin yang mengamati lalu lintas yang sah selama periode waktu tertentu. Berdasarkan data ini, mereka mengusulkan atau menyesuaikan ambang batas, pola, dan profil perilaku normal. Hal ini membantu mengurangi kesalahan positif ketika aturan dialihkan ke mode pemblokiran dan mendeteksi penyimpangan lalu lintas selanjutnya.

Dalam lingkungan penelitian dan laboratorium, teknik pembelajaran terawasi telah digunakan untuk melatih model yang membedakan antara lalu lintas yang sah dan berbahaya, menyempurnakan kebijakan yang kemudian digunakan dalam produksi. Meskipun bukan solusi ajaib, pendekatan ini dapat membantu mengungkap pola-pola halus yang tidak mudah dideteksi oleh aturan berbasis tanda tangan klasik.

Terakhir, pengujian otomatis berkelanjutan (menggunakan alat seperti OWASP ZAP, skrip khusus, atau pipeline CI/CD) memungkinkan Anda untuk memvalidasi bahwa perubahan pada WAF tidak merusak fungsionalitas penting atau meninggalkan kerentanan yang jelas. Mengintegrasikan pengujian ini ke dalam siklus penerapan menjadikan keamanan sebagai bagian alami dari alur pengembangan, bukan sekadar perbaikan di menit-menit terakhir.

Desain kebijakan per aplikasi dan daftar hitam per layanan

Dalam lingkungan yang kompleks—misalnya, penyedia hosting atau ISP—satu kebijakan WAF saja tidak cukup, terutama jika melibatkan shadow IT . Seringkali terdapat beberapa domain atau aplikasi di belakang load balancer yang sama, masing-masing dengan kebutuhan keamanan dan profil lalu lintas yang berbeda . Di sinilah perancangan kebijakan dan daftar khusus layanan menjadi sangat penting.

Contoh ilustratifnya adalah load balancer HTTP/S yang bertindak sebagai reverse proxy untuk beberapa situs (misalnya, www.company1.com dan www.company2.com) di belakang satu alamat IP virtual. Dalam skenario ini, WAF dapat dikonfigurasi untuk mengevaluasi header Host dan alamat IP sumber segera setelah permintaan tiba, bahkan sebelum mencapai modul load balancing.

Logikanya kurang lebih seperti ini: WAF memeriksa apakah kombinasi SERVER_NAME (Host) dan IP klien cocok dengan daftar hitam khusus situs. Jika IP tersebut terdaftar sebagai diblokir untuk www.company2.com tetapi tidak untuk www.company1.com, respons 403 Forbidden hanya dikirim pada kasus pertama. Lalu lintas "bersih" kemudian diteruskan ke modul penyeimbangan beban, yang memutuskan backend mana yang akan melayani permintaan tersebut.

Hal ini memungkinkan pemeliharaan, misalnya, daftar hitam khusus domain , alih-alih daftar global tunggal untuk seluruh titik akses. Pada tingkat pencatatan, setiap penolakan dicatat dalam syslog dengan detail seperti ID aturan, kondisi yang cocok, URL, host, dan alamat IP klien, sehingga memudahkan analisis selanjutnya dan perluasan atau debugging daftar ini.

Pesan moral dari cerita ini adalah semakin tersegmentasi kebijakan Anda (berdasarkan aplikasi, lingkungan, dan jenis pengguna), semakin baik Anda dapat mencapai keseimbangan antara pencatatan dan pemblokiran: Anda dapat sangat ketat pada portal administratif dan agak lebih fleksibel pada situs web informasional, misalnya, selalu dengan bukti dalam log tentang mengapa setiap keputusan dibuat.

Di luar WAF klasik: Perlindungan WAAP dan API

Lanskap ancaman tidak statis. Saat ini, banyak aplikasi berbasis cloud, menggunakan arsitektur microservices, dan mengekspos API publik dan privat , menjadikannya target utama bagi penyerang. WAF tradisional telah berevolusi menjadi platform yang lebih luas yang dikenal sebagai WAAP (Web Application and API Protection) atau WAAS (Web Application & API Security).

Solusi-solusi ini tidak hanya secara otomatis menemukan aplikasi web, tetapi juga mengidentifikasi titik akhir API , menerima spesifikasi seperti OpenAPI atau Swagger, dan menggunakan definisi tersebut untuk memeriksa kepatuhan permintaan: tipe data yang diharapkan, parameter yang diizinkan, batasan ukuran, dll. Tergantung pada titik akhirnya (misalnya, yang menangani data yang sangat sensitif), tingkat pengawasan dan pemblokiran yang jauh lebih tinggi dapat diterapkan.

Pada tingkat pencatatan log, WAAP cenderung menghasilkan peristiwa yang kaya konteks : titik akhir API mana yang diserang, operasi apa (GET, POST, PUT…), pengguna atau token mana yang terlibat, bagian spesifikasi mana yang dilanggar, dan lain sebagainya. Hal ini memungkinkan pengambilan keputusan pemblokiran yang lebih tepat, daripada hanya mengandalkan pola muatan generik.

Selain itu, banyak alat WAAP menyertakan perlindungan DoS khusus aplikasi dan API, pemfilteran geolokasi, manajemen reputasi IP, deteksi bot dan scraping, serta opsi untuk menyesuaikan tingkat peringatan per layanan. Sekali lagi, ini tentang memiliki fleksibilitas untuk memutuskan di mana Anda menginginkan pendekatan yang lebih kuat dan di mana Anda ingin memprioritaskan kelancaran operasi , tanpa mengorbankan basis data log yang solid untuk menyelidiki insiden apa pun.

Secara keseluruhan, WAF yang disetel dengan baik—baik klasik, berbasis WAAP, atau terintegrasi ke dalam ekosistem cloud—menjadi komponen penting dari pertahanan aplikasi dan API modern, yang mampu menggabungkan pencatatan log terperinci, pemblokiran cerdas, dan adaptasi berkelanjutan terhadap lanskap ancaman yang terus berubah.