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 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 Google 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 yang dimaksudkan dari aturan tersebut. Kolom deskripsi dibatasi hingga 64 karakter, sehingga referensi ke database pengelolaan konfigurasi atau repositori lain adalah cara paling efisien untuk mendapatkan konteks.

Mempertimbangkan jarak 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 memiliki efek yang tidak dapat diprediksi pada aplikasi Anda. Gunakan mode pratinjau, untuk mengevaluasi apakah pengenalan aturan akan berdampak negatif pada traffic produksi.

Mengaktifkan Google 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 diberi tahu tentang potensi serangan. Perlindungan Adaptif paling cocok untuk perlindungan volumetrik. Serangan yang tidak bersifat volumetrik mungkin tidak memicu Perlindungan Adaptif.

Mengaktifkan penguraian JSON

Jika aplikasi Anda mengirim konten JSON di isi permintaan POST, pastikan Anda mengaktifkan parsing JSON. Jika Anda tidak mengaktifkan parsing JSON, Google Cloud Armor tidak mem-parsing konten JSON isi POST untuk aturan WAF yang telah dikonfigurasi sebelumnya, dan hasilnya dapat bervariasi dan menghasilkan positif palsu. Untuk informasi tambahan, lihat parsing JSON.

Uji logika Anda

Aturan dipicu saat kondisi kecocokannya bernilai benar; misalnya, kondisi kecocokan origin.region_code == 'AU' bernilai benar jika kode region permintaan adalah AU. Jika aturan dengan prioritas lebih tinggi dievaluasi sebagai benar, maka 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 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 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 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 sumber pemindai Anda

Pemindai keamanan Anda dapat berada di dalam atau di luar Google. Jika Anda menginginkan penilaian eksternal dan tidak difilter terhadap aplikasi Anda, 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:

1. Aturan penolakan eksplisit (ASN, wilayah, 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 penolakan default

Menggunakan reCAPTCHA untuk pengelolaan bot

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

Menetapkan nilai minimum pembatasan kapasitas

Pembatasan frekuensi adalah kemampuan yang fleksibel dan berharga untuk mencegah penyalahgunaan dan memitigasi ancaman bervolume tinggi seperti serangan DDoS L7 atau pengisian kredensial. Saat men-deploy pembatasan kecepatan untuk pertama kalinya, penting untuk memilih nilai minimum yang sesuai untuk aplikasi Anda. Sebaiknya mulai dengan penegakan dalam mode pratinjau. Saat menganalisis dan memahami profil traffic, Anda dapat menyesuaikan parameter pembatasan frekuensi. Selain itu, penting untuk mempertimbangkan prioritas yang Anda tetapkan untuk aturan pembatasan kecepatan. Traffic mungkin secara eksplisit diizinkan atau ditolak oleh aturan dengan prioritas yang lebih tinggi sebelum dievaluasi terhadap aturan pembatasan kecepatan.

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 Google Cloud Armor terhadap aplikasi Anda 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, 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 atasi menggunakan penyesuaian sebelum kebijakan keamanan diterapkan dalam produksi.

Aktifkan logging panjang

Jika Anda memerlukan informasi tambahan tentang atribut permintaan dan payload mana yang memicu aturan WAF tertentu, aktifkan logging verbose. Logging verbose 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 verbose 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 beban kerja produksi dengan pengelogan verbose yang diaktifkan dalam 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 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 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 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 rasio pengambilan sampel ke 1 saat Anda aktif menyesuaikan dan menerapkan Google Cloud Armor. Setelah Anda selesai menyesuaikan dan menerapkan Google Cloud Armor, sebaiknya Anda tetap mengaktifkan logging permintaan penuh. Namun, Anda mungkin lebih memilih untuk mengurangi sampel ke tingkat yang lebih rendah. Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik tidak mengaktifkan log secara default, jadi Anda harus mengaktifkan pencatatan log secara manual.

Menggunakan dasbor Cloud Monitoring

Memiliki tampilan yang jelas tentang apa yang terjadi dalam konfigurasi Google Cloud Armor Anda sangat 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 Perlindungan Adaptif, penting untuk memiliki jalur eskalasi untuk setiap pemberitahuan Perlindungan Adaptif yang dipicu.

Pengelolaan umum

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

Menyiapkan kontrol akses Identity and Access Management

Sesuai dengan praktik terbaik IAM umum, pastikan orang yang tepat memiliki akses ke Google Cloud Armor. Google Cloud Peran Admin Keamanan Compute 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 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. Google Cloud Armor memiliki integrasi Terraform penuh untuk fitur GA.

Mengonfigurasi Google Cloud Armor dengan Google Kubernetes Engine

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

Setelah mengonfigurasi kebijakan keamanan Google Cloud Armor, Anda juga dapat menggunakan Kubernetes Gateway untuk mengaktifkannya dengan GKE. Pastikan Anda membuat kebijakan keamanan backend Google Cloud Armor sebelum merujuk kebijakan tersebut di resource kebijakan GCPBackendPolicy Anda. Jika Anda mengaktifkan Gateway regional, Anda harus membuat kebijakan keamanan backend Google Cloud Armor regional.