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 akan melampirkan kebijakan keamanan ke layanan backend load balancer yang ingin dilindungi. Kebijakan keamanan terdiri dari kumpulan aturan bawaan dan kustom yang Anda tentukan.

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 yang diinginkan dari aturan tersebut. Kolom description dibatasi hingga 64 karakter, sehingga referensi ke database pengelolaan konfigurasi atau repositori lainnya adalah cara paling efisien untuk mengambil konteks.

Pertimbangkan spasi prioritas

Saat Anda pertama kali mengonfigurasi aturan, biarkan interval minimal 10 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 Anda mengelompokkan aturan yang serupa ke dalam blok, sehingga interval antar-grup menjadi lebih besar.

Menggunakan mode pratinjau

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

Mengaktifkan Cloud Armor Adaptive Protection

Aktifkan Perlindungan Adaptif untuk perlindungan tambahan aplikasi Anda. Adaptive Protection memantau traffic dan (jika perlu) merekomendasikan aturan baru untuk kebijakan keamanan Anda. Selain itu, sebaiknya Anda menerapkan kebijakan pemberitahuan untuk memastikan orang yang tepat mendapatkan pemberitahuan 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 mengurai konten JSON isi POST untuk aturan WAF yang telah dikonfigurasi sebelumnya, dan hasilnya dapat berisi derau dan menghasilkan positif palsu. Untuk informasi tambahan, lihat Pemrosesan JSON.

Menguji logika

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 bernilai benar, tindakan dalam aturan dengan prioritas lebih rendah akan diabaikan. Pada contoh berikut, bayangkan Anda ingin membuat kebijakan keamanan untuk memblokir pengguna dari wilayah 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 dengan prioritas lebih tinggi, traffic tersebut diizinkan sebelum dievaluasi terhadap Rule2, yang berarti bahwa Google Cloud Armor tidak mengevaluasinya terhadap Rule2 (atau aturan lainnya yang tersisa).

Saat membuat kebijakan Google Cloud Armor, uji logika aturan Anda untuk memastikan Anda mencapai perilaku yang diinginkan. Untuk melakukannya, sebaiknya Anda membuat traffic sintetis untuk memahami aturan mana yang memblokir traffic, dan memverifikasi bahwa hasilnya 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 sumber pemindai Anda

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

Mengelompokkan dan mengurutkan aturan dalam kebijakan keamanan

Aplikasi Anda mungkin menayangkan 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 secara eksplisit ke dalam aplikasi tanpa memproses kebijakan keamanan. Untuk contoh ini, sebaiknya gunakan 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 izin eksplisit (ASN, keberadaan nilai header, rentang IP)
  5. Aturan tolak default

Menggunakan reCAPTCHA untuk pengelolaan bot

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

Menetapkan nilai minimum pembatasan kapasitas

Pembatasan kapasitas adalah kemampuan yang fleksibel dan berharga untuk mencegah penyalahgunaan dan mitigasi ancaman bervolume tinggi seperti credential stuffing atau serangan DDoS L7. 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 ke aturan pembatasan kapasitas. Traffic mungkin diizinkan atau ditolak secara eksplisit oleh aturan prioritas yang lebih tinggi sebelum dievaluasi terhadap aturan pembatasan kapasitas.

Penyesuaian aturan

Aplikasi web mungkin mengizinkan permintaan yang tampak seperti serangan, dan aplikasi tersebut mungkin mengizinkan, atau bahkan mewajibkan, pengguna mengirim permintaan yang cocok dengan tanda tangan dalam aturan WAF yang telah dikonfigurasi sebelumnya. Anda harus memvalidasi aturan Google Cloud Armor terhadap aplikasi dan mengatasi temuan apa pun yang mungkin tidak relevan untuk aplikasi Anda sebelum mempromosikan aturan dengan menonaktifkan mode pratinjau di 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 aturan WAF yang telah dikonfigurasi sebelumnya, Anda dapat memilih tingkat sensitivitas yang sesuai berdasarkan persyaratan keamanan dan linimasa 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, beban kerja 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 tangani menggunakan penyesuaian sebelum kebijakan keamanan diproduksi.

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 Google Cloud Armor. Karena logging yang panjang dapat menyebabkan konten permintaan pengguna akhir dicatat ke dalam log di Cloud Logging, ada kemungkinan Anda mengumpulkan PII pengguna akhir dalam log. Oleh karena itu, sebaiknya jangan jalankan beban kerja produksi dengan logging panjang yang diaktifkan selama jangka waktu yang lama.

Menggunakan aturan stabil atau canary

Ada dua jenis aturan WAF yang telah dikonfigurasi sebelumnya oleh Google Cloud Armor: stabil dan canary. Saat aturan baru ditambahkan ke Kumpulan Aturan Inti ModSecurity (CRS) saat ini, kami memublikasikannya ke build aturan canary sebelum memublikasikannya secara otomatis ke build aturan stabil. Sebaiknya deploy aturan canary di lingkungan pengujian agar Anda dapat melihat efek perubahan dan penambahan apa pun di lingkungan Anda. Anda dapat memeriksa nama aturan di halaman Menyesuaikan aturan WAF Google 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.

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 personel keamanan web Anda memeriksa temuan ini.

Memilih frekuensi sampling Cloud Logging

Log per permintaan Google Cloud Armor menggunakan infrastruktur logging Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik. Akibatnya, pembuatan log Google Cloud Armor tunduk pada frekuensi sampling log yang dikonfigurasi di load balancer. Sebaiknya tetapkan frekuensi sampling ke 1 saat Anda secara aktif menyesuaikan dan menerapkan Google Cloud Armor. Setelah selesai menyesuaikan dan menerapkan Google Cloud Armor, sebaiknya Anda tetap mengaktifkan logging permintaan lengkap; namun, Anda mungkin lebih memilih untuk menurunkan sampel ke kecepatan 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 gambaran yang jelas tentang apa yang terjadi dalam konfigurasi Google Cloud Armor Anda sangatlah penting. Untuk mempermudah, Anda dapat menggunakan dasbor keamanan. Selain itu, Anda dapat mengekspor log Google Cloud Armor langsung dari Logging ke platform Anda sendiri. Jika Anda menggunakan Adaptive Protection, penting untuk memiliki jalur eskalasi untuk pemberitahuan Adaptive Protection yang dipicu.

Pengelolaan umum

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

Menyiapkan kontrol akses Identity and Access Management

Sesuai dengan praktik terbaik IAM Google Cloud umum, 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 Compute Network Admin atau izin compute.backendServices.setSecurityPolicy diperlukan untuk melampirkan kebijakan keamanan Google Cloud Armor ke layanan backend.

Minimalkan jumlah kebijakan

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

Menggunakan Terraform

Untuk memastikan konfigurasi dapat di-roll back dengan mudah, serta direproduksi di seluruh project, sebaiknya gunakan Terraform. Google Cloud Armor memiliki integrasi Terraform penuh 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 Anda tidak mengonfigurasi Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik secara manual untuk berfungsi sebagai titik entri. Untuk informasi selengkapnya tentang cara mengonfigurasi Google Cloud Armor dengan GKE, lihat Mengonfigurasi fitur ingress.