Sebagian atau seluruh informasi di halaman ini mungkin tidak berlaku untuk Cloud de Confiance dari S3NS. Lihat Perbedaan dengan Google Cloud untuk mengetahui detail selengkapnya.

Praktik terbaik Cloud Armor

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

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

Untuk menyiapkan kebijakan Cloud Armor yang diterapkan secara otomatis ke semua project dalam organisasi Anda, dan memungkinkan setiap project menambahkan aturan spesifiknya sendiri, lihat panduan tentang mengelola Cloud Armor menggunakan batasan kustom. Pendekatan ini memberikan cara terpusat untuk menerapkan kebijakan keamanan di seluruh organisasi Anda sekaligus mempertahankan fleksibilitas untuk kebutuhan setiap project.

Pembuatan kebijakan dan aturan keamanan

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

Memberikan deskripsi aturan

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

Mempertimbangkan interval 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. Hal ini memungkinkan Anda menyisipkan lebih banyak aturan saat Anda membutuhkannya. Selain itu, sebaiknya kelompokkan aturan serupa ke dalam blok, dengan interval yang lebih besar di antara grup.

Menggunakan mode pratinjau

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

Mengaktifkan penguraian JSON

Jika aplikasi Anda mengirimkan konten JSON di isi permintaan, pastikan Anda mengaktifkan penguraian JSON. Jika Anda tidak mengaktifkan penguraian JSON, Cloud Armor tidak mengurai konten JSON isi permintaan untuk aturan WAF yang telah dikonfigurasi sebelumnya, dan hasilnya dapat bervariasi serta menghasilkan positif palsu. Untuk mengetahui informasi tambahan, lihat penguraian JSON.

Menguji logika Anda

Aturan dipicu saat kondisi kecocokannya bernilai benar; misalnya, kondisi kecocokan origin.region_code == 'AU' bernilai benar jika kode wilayah permintaan adalah AU. Jika aturan dengan prioritas lebih tinggi dievaluasi sebagai benar, maka tindakan dalam aturan dengan prioritas lebih rendah akan diabaikan.

Dalam contoh berikut, bayangkan Anda ingin membuat kebijakan keamanan untuk memblokir pengguna dari region AU, kecuali 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 dengan prioritas lebih tinggi, traffic tersebut diizinkan sebelum dievaluasi terhadap Rule2, yang berarti bahwa Cloud Armor tidak mengevaluasinya terhadap Rule2 (atau aturan lainnya yang tersisa).

Untuk mencapai pengecualian serupa dalam satu aturan, Anda dapat menggabungkan kondisi pencocokan menggunakan operator logika. Penting untuk diperhatikan bahwa pendekatan ini berbeda dengan contoh dua aturan dalam cara evaluasi aturan berikutnya. Misalnya, ekspresi berikut menggunakan satu aturan yang menolak traffic AU kecuali jika berasal dari rentang IP tertentu 10.10.10.0/24:

expr: origin.region_code == 'AU' && !inIpRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1

Kondisi ini hanya dievaluasi sebagai benar (dan memicu tindakan penolakan) jika region adalah AU dan alamat IP tidak berada dalam rentang 10.10.10.0/24.

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

Mengidentifikasi alamat IP klien pemindai Anda

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

Mengelompokkan dan mengurutkan aturan dalam kebijakan keamanan Anda

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

Aturan penolakan eksplisit (ASN, region, rentang IP)
Aturan izin eksplisit tepercaya (pemindai, sistem tepercaya - gunakan dengan sangat hati-hati)
Aturan keamanan (OWASP, aturan kustom)
Aturan izin eksplisit (ASN, keberadaan nilai header, rentang IP)
Aturan penolakan default

Menetapkan nilai minimum pembatasan kapasitas

Pembatasan kapasitas adalah kemampuan yang fleksibel dan berharga untuk mencegah penyalahgunaan dan memitigasi ancaman bervolume tinggi seperti serangan DDoS L7 atau credential stuffing. Saat men-deploy pembatasan kapasitas untuk pertama kalinya, penting untuk memilih nilai minimum yang sesuai untuk aplikasi Anda. Sebaiknya mulai 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 dengan prioritas yang lebih tinggi sebelum dievaluasi terhadap aturan pembatasan kapasitas.

Penyesuaian aturan

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

Memilih 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 persyaratan dan jadwal 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 fidelitas tinggi dan mengurangi potensi derau dari aturan. Tanda tangan yang terkait dengan sensitivitas yang lebih tinggi dapat mendeteksi dan mencegah serangkaian upaya eksploitasi yang lebih besar, dengan mengorbankan potensi derau untuk beberapa aplikasi yang dilindungi. Namun, workload yang tunduk pada persyaratan keamanan yang lebih ketat mungkin lebih 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 diterapkan dalam produksi.

Mengaktifkan logging panjang

Jika Anda memerlukan informasi tambahan tentang atribut permintaan dan payload 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 Cloud Armor. Karena logging panjang dapat menyebabkan konten permintaan pengguna akhir dicatat dalam Cloud Logging, ada kemungkinan Anda mengumpulkan PII pengguna akhir dalam log Anda. Oleh karena itu, sebaiknya jangan jalankan workload produksi dengan logging panjang diaktifkan selama jangka waktu yang lama.

Menggunakan aturan stabil atau canary

Ada dua jenis aturan WAF yang telah dikonfigurasi sebelumnya oleh Cloud Armor: stabil dan canary. Saat aturan baru ditambahkan ke OWASP Core Rule Set (CRS) saat ini, kami akan memublikasikannya ke build aturan canary sebelum memublikasikannya secara otomatis ke build aturan stabil. Sebaiknya deploy aturan terbatas di lingkungan pengujian sehingga Anda dapat melihat efek perubahan dan penambahan apa pun di lingkungan Anda. Anda dapat memeriksa nama aturan di halaman Menyesuaikan aturan WAF Cloud Armor untuk memverifikasi apakah build canary disinkronkan dengan build stabil.

Logging dan pemantauan

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

Memilih frekuensi sampling Cloud Logging

Log per permintaan Cloud Armor menggunakan infrastruktur logging Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik. Akibatnya, pembuatan log Cloud Armor tunduk pada frekuensi sampling log yang dikonfigurasi di load balancer. Sebaiknya pertahankan frekuensi sampling 1 saat Anda aktif menyesuaikan dan menerapkan Cloud Armor. Setelah selesai menyesuaikan dan menerapkan Cloud Armor, sebaiknya Anda tetap mengaktifkan logging permintaan penuh; namun, Anda mungkin lebih memilih untuk mengurangi frekuensi pengambilan sampel ke frekuensi yang lebih rendah. Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik tidak mengaktifkan log secara default, jadi Anda harus mengaktifkan logging secara manual.

Menggunakan dasbor Cloud Monitoring

Memiliki tampilan yang jelas tentang apa yang terjadi dalam konfigurasi Cloud Armor Anda sangatlah penting. Untuk mempermudah, Anda dapat menggunakan dasbor keamanan. Selain itu, Anda dapat mengekspor log Cloud Armor langsung dari Logging ke platform Anda sendiri.

Pengelolaan umum

Berikut berisi praktik terbaik dan rekomendasi tambahan untuk mengonfigurasi Cloud Armor.

Menyiapkan kontrol akses Identity and Access Management

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

Meminimalkan jumlah kebijakan

Kebijakan Cloud Armor dapat digunakan kembali di beberapa layanan backend. Sebaiknya Anda memiliki serangkaian kebijakan keamanan yang konsisten dan dapat digunakan kembali.

Menggunakan Terraform

Untuk memastikan konfigurasi dapat di-rollback dengan mudah, serta direproduksi di seluruh project, sebaiknya gunakan Terraform. Cloud Armor memiliki integrasi Terraform penuh untuk fitur GA.