Praktik terbaik Google Cloud Armor

Halaman ini memberikan praktik terbaik untuk mengoptimalkan dan menyesuaikan deployment Google Cloud Armor.

Google Cloud Armor di-deploy dengan Load Balancer Aplikasi eksternal global, Load Balancer Aplikasi klasik, atau Load Balancer Jaringan proxy eksternal. Saat men-deploy Google Cloud Armor, Anda harus melampirkan kebijakan keamanan ke layanan backend load balancer yang ingin dilindungi. Kebijakan keamanan terdiri dari kumpulan aturan khusus dan yang telah dikonfigurasi sebelumnya yang Anda tentukan.

Pembuatan aturan dan kebijakan keamanan

Bagian berikut berisi praktik terbaik dan rekomendasi untuk aturan dan kebijakan keamanan baru.

Berikan deskripsi aturan

Gunakan deskripsi aturan untuk memberikan konteks tambahan tentang alasan setiap aturan dibuat dan fungsi aturan yang dimaksud. Kolom description dibatasi hingga 64 karakter, sehingga referensi ke database pengelolaan konfigurasi atau repositori lainnya adalah cara yang paling efisien untuk menangkap konteks.

Mempertimbangkan spasi prioritas

Saat pertama kali mengonfigurasi aturan, sisakan interval minimal 10 di antara setiap nilai prioritas aturan. Misalnya, dua aturan pertama dalam kebijakan keamanan dapat memiliki prioritas 20 dan 30. Dengan cara ini, Anda dapat menyisipkan lebih banyak aturan saat membutuhkannya. Selain itu, sebaiknya Anda mengelompokkan aturan serupa ke dalam blok, dengan memberikan interval yang lebih besar di antara grup.

Menggunakan mode pratinjau

Aturan kebijakan keamanan, termasuk tanda tangan Open Web Application Security Project (OWASP), dapat memiliki efek yang tidak dapat diprediksi pada aplikasi Anda. Gunakan mode pratinjau untuk mengevaluasi apakah penerapan aturan akan berdampak negatif terhadap traffic produksi.

Aktifkan Perlindungan Adaptif Google Cloud Armor

Aktifkan Perlindungan Adaptif untuk perlindungan tambahan aplikasi Anda. Perlindungan Adaptif memantau traffic dan (jika perlu) merekomendasikan aturan baru untuk kebijakan keamanan Anda. Selain itu, sebaiknya Anda menerapkan kebijakan pemberitahuan untuk memastikan bahwa orang yang tepat diberi tahu tentang potensi serangan. Perlindungan Adaptif paling cocok untuk perlindungan volumetrik. Serangan yang tidak volumetrik mungkin tidak memicu Perlindungan Adaptif.

Mengaktifkan penguraian JSON

Jika aplikasi Anda mengirim konten JSON dalam isi permintaan POST, pastikan Anda mengaktifkan penguraian JSON. Jika Anda tidak mengaktifkan penguraian JSON, Google Cloud Armor tidak akan mengurai konten JSON dari isi POST untuk aturan WAF yang telah dikonfigurasi sebelumnya, dan hasilnya dapat menjadi berisik serta menghasilkan positif palsu. Untuk informasi tambahan, lihat penguraian JSON.

Menguji logika Anda

Aturan dipicu saat kondisi kecocokannya bernilai benar; misalnya, kondisi pencocokan origin.region_code == 'AU' bernilai benar jika kode wilayah yang diminta adalah AU. Jika aturan prioritas yang lebih tinggi bernilai benar (true), tindakan dalam aturan prioritas yang lebih rendah akan diabaikan. Pada contoh berikut, bayangkan Anda ingin membuat kebijakan keamanan untuk memblokir pengguna dari region AU, kecuali untuk traffic dalam rentang alamat IP 10.10.10.0/24. Pertimbangkan kebijakan keamanan berikut dengan dua aturan:

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: allow
priority: 1
Rule2
expr: origin.region_code == 'AU'
action: deny(403)
priority: 2

Dalam contoh ini, Rule1 mengizinkan traffic yang berasal dari rentang alamat IP 10.10.10.0/24. Karena Rule1 adalah aturan berprioritas lebih tinggi, traffic tersebut diizinkan sebelum dievaluasi terhadap Rule2, yang berarti bahwa Google Cloud Armor tidak mengevaluasinya berdasarkan Rule2 (atau aturan lainnya).

Saat Anda membuat kebijakan Google Cloud Armor, uji logika aturan untuk memastikan bahwa Anda mencapai perilaku yang diinginkan. Untuk melakukannya, sebaiknya buat traffic sintetis untuk memahami aturan mana yang memblokir traffic, dan verifikasi bahwa hasil Anda konsisten dengan keputusan desain aturan Anda. Jika tidak yakin tentang bagaimana permintaan dapat mengalir melalui sistem, gunakan mode pratinjau untuk melihat aturan mana yang cocok dengan permintaan tersebut.

Mengidentifikasi alamat IP sumber pemindai

Pemindai keamanan Anda dapat ditemukan di dalam atau di luar Google. Jika menginginkan penilaian aplikasi di luar dan tanpa filter, Anda dapat secara eksplisit mengizinkan traffic berdasarkan alamat IP (atau token lainnya) sebelum mengevaluasinya berdasarkan aturan lain.

Aturan grup dan pengurutan dalam kebijakan keamanan Anda

Aplikasi Anda mungkin melayani subkumpulan pelanggan yang berbeda. Dalam contoh berikut, Anda ingin menolak traffic dari area geografis atau rentang IP tertentu. Oleh karena itu, Anda perlu mengonfigurasi aturan pertama dalam kebijakan untuk menolak traffic tersebut. Selain itu, Anda ingin mengizinkan beberapa traffic ke dalam aplikasi secara eksplisit tanpa memprosesnya oleh kebijakan keamanan. Untuk contoh ini, kami merekomendasikan struktur prioritas aturan berikut, dari prioritas terbesar hingga prioritas terendah:

1. Aturan penolakan eksplisit (ASN, region, rentang IP)
2. Aturan izinkan eksplisit tepercaya (pemindai, sistem tepercaya - gunakan dengan sangat hati-hati)
3. Aturan keamanan (OWASP, aturan kustom)
4. Aturan izinkan eksplisit (ASN, keberadaan nilai header, rentang IP)
5. Aturan penolakan default

Menggunakan reCAPTCHA Enterprise untuk pengelolaan bot

Google Cloud Armor terintegrasi dengan reCAPTCHA Enterprise Google untuk deteksi bot di lapisan WAF. Dalam integrasi ini, reCAPTCHA Enterprise membuat token reCAPTCHA, dan Google Cloud Armor yang melakukan proses penilaian token, bukan reCAPTCHA Enterprise. Hal ini akan mengurangi beban origin, sehingga berpotensi mengurangi biaya Anda, dan menempatkan kontrol keamanan lebih dekat ke pengguna akhir daripada backend Anda. Untuk mengetahui informasi selengkapnya, baca ringkasan pengelolaan bot.

Menetapkan batas pembatasan kapasitas

Pembatasan kapasitas adalah kemampuan fleksibel dan berharga untuk mencegah penyalahgunaan dan memitigasi ancaman bervolume tinggi seperti credential stuffing atau serangan DDoS L7. Saat men-deploy pembatasan kapasitas untuk pertama kalinya, penting untuk memilih batas yang masuk akal untuk aplikasi Anda. Sebaiknya Anda memulai dengan penerapan dalam mode pratinjau. Saat menganalisis dan memahami profil traffic, Anda dapat menyesuaikan parameter pembatasan kapasitas. Selain itu, penting untuk mempertimbangkan prioritas yang Anda tetapkan untuk aturan pembatasan kapasitas. Traffic mungkin secara eksplisit diizinkan atau ditolak oleh aturan prioritas yang lebih tinggi sebelum dievaluasi terhadap aturan pembatasan kapasitas.

Penyesuaian aturan

Aplikasi web dapat mengizinkan permintaan yang tampak seperti serangan, dan mungkin mengizinkan, atau bahkan mengharuskan, pengguna untuk mengirim permintaan yang cocok dengan tanda tangan dalam aturan WAF yang telah dikonfigurasi sebelumnya. Anda harus memvalidasi aturan Google Cloud Armor terhadap aplikasi Anda, dan menangani temuan apa pun yang mungkin tidak relevan dengan aplikasi Anda sebelum mempromosikan aturan tersebut dengan menonaktifkan mode pratinjau di aplikasi produksi. Bagian berikut berisi praktik terbaik dan rekomendasi untuk menyesuaikan aturan WAF yang telah dikonfigurasi sebelumnya.

Pilih tingkat sensitivitas aturan WAF yang telah dikonfigurasi sebelumnya

Saat menerapkan salah satu aturan WAF yang telah dikonfigurasi sebelumnya, Anda dapat memilih tingkat sensitivitas yang sesuai berdasarkan linimasa dan persyaratan keamanan Anda. Sebaiknya Anda memulai dengan tingkat sensitivitas 1 untuk sebagian besar aplikasi yang harus memenuhi persyaratan keamanan organisasi Anda. Aturan yang dikonfigurasi untuk sensitivitas 1 menggunakan tanda tangan high fidelity dan mengurangi potensi derau dari aturan. Tanda tangan yang terkait dengan sensitivitas tinggi dapat mendeteksi dan mencegah serangkaian upaya eksploitasi yang lebih besar, dengan mengorbankan potensi derau untuk beberapa aplikasi yang dilindungi. Namun, beban kerja yang tunduk pada persyaratan keamanan yang lebih ketat mungkin memilih tingkat sensitivitas tertinggi. Untuk kasus penggunaan ini, mungkin ada banyak derau atau temuan yang tidak relevan, yang harus Anda atasi menggunakan penyesuaian sebelum kebijakan keamanan mulai diproduksi.

Aktifkan logging panjang

Jika Anda memerlukan informasi tambahan tentang atribut dan payload permintaan mana yang memicu aturan WAF tertentu, aktifkan logging panjang. Logging panjang memberikan detail dari permintaan yang memicu aturan tertentu, termasuk cuplikan bagian permintaan yang melanggar, yang berguna untuk memecahkan masalah dan menyesuaikan Google Cloud Armor. Karena logging panjang dapat menyebabkan konten permintaan pengguna akhir dicatat ke dalam log di Cloud Logging, ada kemungkinan Anda mengakumulasi PII pengguna akhir di log Anda. Oleh karena itu, sebaiknya jangan jalankan workload produksi dengan logging panjang yang diaktifkan untuk jangka waktu lama.

Menggunakan aturan stabil atau canary

Ada dua jenis aturan WAF Google Cloud Armor yang telah dikonfigurasi sebelumnya, yaitu stabil dan canary. Saat aturan baru ditambahkan ke Set Aturan Inti ModSecurity (CRS) saat ini, kami memublikasikannya ke build aturan canary sebelum memublikasikannya secara otomatis ke dalam build aturan stabil. Sebaiknya deploy aturan canary di lingkungan pengujian sehingga Anda dapat melihat efek dari setiap perubahan dan penambahan di lingkungan Anda. Anda dapat memeriksa nama aturan di halaman aturan WAF Tuning Google Cloud Armor untuk memverifikasi apakah build canary sinkron dengan build stabil.

Logging dan pemantauan

Bagian berikut berisi praktik terbaik dan rekomendasi untuk mengonfigurasi logging dan pemantauan.

Menggunakan Security Command Center

Google Cloud Armor terintegrasi secara otomatis dengan Security Command Center. Google Cloud Armor mengekspor berbagai temuan ke Security Command Center:

• Lonjakan Traffic yang Diizinkan
• Meningkatkan Rasio Penolakan

Pastikan staf keamanan web Anda memeriksa temuan ini.

Memilih frekuensi sampling Cloud Logging

Log per permintaan Google Cloud Armor menggunakan Load Balancer Aplikasi eksternal global atau infrastruktur logging Load Balancer Aplikasi klasik. Oleh karena itu, pembuatan log Google Cloud Armor bergantung pada frekuensi pengambilan sampel log yang dikonfigurasi di load balancer. Sebaiknya pertahankan frekuensi sampling ke 1 saat Anda secara aktif meningkatkan dan menerapkan Google Cloud Armor. Setelah Anda menyelesaikan penyesuaian dan penerapan Google Cloud Armor, sebaiknya tetap aktifkan logging permintaan penuh. Namun, Anda dapat memilih untuk menggunakan down-sample dengan tarif yang lebih rendah. Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik tidak mengaktifkan log secara default, jadi penting bagi Anda untuk mengaktifkan logging secara manual.

Catatan: Log Perlindungan Adaptif ditampilkan di Google Cloud Console di bagian resource network_security_policy, bukan di bagian Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik.

Menggunakan dasbor Cloud Monitoring

Sangat penting untuk memiliki gambaran yang jelas tentang apa yang terjadi dalam konfigurasi Google Cloud Armor Anda. Untuk mempermudah, Anda dapat menggunakan dasbor keamanan. Selain itu, Anda dapat mengekspor log Google Cloud Armor langsung dari Logging ke platform Anda. Jika Anda menggunakan Perlindungan Adaptif, Anda harus memiliki jalur eskalasi untuk setiap pemberitahuan Perlindungan Adaptif yang dipicu.

Pengelolaan umum

Berikut ini adalah rekomendasi dan praktik terbaik tambahan untuk mengonfigurasi Google Cloud Armor.

Menyiapkan kontrol akses Identity and Access Management

Sesuai dengan praktik terbaik umum Google Cloud IAM, pastikan orang yang tepat memiliki akses ke Google Cloud Armor. Peran Compute Security Admin diperlukan untuk mengonfigurasi, mengubah, memperbarui, dan menghapus kebijakan keamanan Google Cloud Armor. Selain itu, peran Admin Jaringan Compute atau izin compute.backendServices.setSecurityPolicy diperlukan untuk melampirkan kebijakan keamanan Google Cloud Armor ke layanan backend.

Meminimalkan jumlah kebijakan

Kebijakan Google Cloud Armor dapat digunakan kembali di berbagai layanan backend. Sebaiknya Anda memiliki serangkaian kebijakan keamanan yang dapat digunakan kembali dengan konsisten.

Menggunakan Terraform

Untuk memastikan bahwa konfigurasi dapat dengan mudah di-roll back, serta direproduksi di seluruh project, sebaiknya gunakan Terraform. Google Cloud Armor memiliki integrasi Terraform lengkap untuk fitur GA.

Mengonfigurasi Google Cloud Armor dengan Google Kubernetes Engine

Jika menggunakan GKE, Anda harus mengonfigurasi Google Cloud Armor dan fitur ingress lainnya melalui parameter BackendConfig. Sebaiknya jangan mengonfigurasi Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik secara manual agar berfungsi sebagai titik masuk. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi Google Cloud Armor dengan GKE, lihat Mengonfigurasi fitur ingress.