Ringkasan kebijakan keamanan

Halaman ini menjelaskan cara menggunakan kebijakan keamanan Google Cloud Armor untuk melindungi deployment Google Cloud Anda.

Kebijakan keamanan Google Cloud Armor melindungi aplikasi Anda dengan menyediakan pemfilteran Lapisan 7 dan dengan menghapus permintaan masuk untuk serangan web umum atau atribut Lapisan 7 lainnya guna berpotensi memblokir traffic sebelum mencapai layanan backend atau bucket backend yang di-load balanced. Setiap kebijakan keamanan terdiri dari kumpulan aturan yang memfilter traffic berdasarkan kondisi, seperti alamat IP permintaan masuk, rentang IP, kode wilayah, atau header permintaan.

Kebijakan keamanan Google Cloud Armor tersedia untuk jenis load balancer dan endpoint berikut:

  • Load Balancer Aplikasi eksternal global (HTTP/HTTPS)
  • Load Balancer Aplikasi Klasik (HTTP/HTTPS)
  • Load Balancer Aplikasi eksternal regional (HTTP/HTTPS)
  • Load Balancer Jaringan proxy eksternal global (TCP/SSL)
  • Load Balancer Jaringan proxy klasik (TCP/SSL)
  • Load Balancer Jaringan passthrough eksternal (TCP/UDP)
  • Penerusan protokol
  • VM dengan alamat IP publik

Load balancer dapat berada dalam Paket Premium atau Paket Standar.

Backend ke layanan backend dapat berupa salah satu dari yang berikut ini:

Saat Anda menggunakan Google Cloud Armor untuk melindungi deployment hybrid atau arsitektur multicloud, backend-nya harus berupa NEG internet. Google Cloud Armor juga melindungi NEG serverless saat traffic dirutekan melalui load balancer. Untuk memastikan bahwa hanya traffic yang telah dirutekan melalui load balancer yang mencapai NEG serverless, lihat Kontrol masuk.

Google Cloud Armor juga menyediakan perlindungan DDoS jaringan yang canggih untuk Load Balancer Jaringan passthrough eksternal, penerusan protokol, dan VM dengan alamat IP publik. Untuk informasi selengkapnya tentang perlindungan DDoS lanjutan, lihat Mengonfigurasi perlindungan DDoS jaringan lanjutan.

Lindungi deployment Google Cloud Anda dengan kebijakan keamanan Google Cloud Armor

Load balancing eksternal diterapkan di edge jaringan Google di titik kehadiran (PoP) Google di seluruh dunia. Pada Paket Premium, traffic pengguna yang diarahkan ke load balancer eksternal akan memasuki PoP yang terdekat dengan pengguna. Kemudian, selanjutnya diseimbangkan beban melalui jaringan global Google ke backend terdekat yang memiliki kapasitas memadai. Pada Tingkat Standar, traffic pengguna memasuki jaringan Google melalui jaringan peering, ISP, atau transportasi umum di region tempat Anda men-deploy resource Google Cloud.

Dengan kebijakan keamanan Google Cloud Armor, Anda dapat mengizinkan, menolak, membatasi kapasitas, atau mengalihkan permintaan ke layanan backend Anda di edge Google Cloud, sedekat mungkin dengan sumber traffic masuk. Hal ini mencegah traffic yang tidak diinginkan agar tidak memakai resource atau memasuki jaringan Virtual Private Cloud (VPC) Anda.

Diagram berikut mengilustrasikan lokasi Load Balancer Aplikasi eksternal global, Load Balancer Aplikasi klasik, jaringan Google, dan pusat data Google.

Kebijakan Google Cloud Armor di edge jaringan.
Kebijakan Google Cloud Armor di edge jaringan (klik untuk memperbesar).

Persyaratan

Berikut adalah persyaratan untuk menggunakan kebijakan keamanan Google Cloud Armor:

  • Load balancer harus berupa Load Balancer Aplikasi eksternal global, Load Balancer Aplikasi klasik, Load Balancer Aplikasi eksternal regional, Load Balancer Jaringan proxy eksternal global, atau Load Balancer Jaringan proxy klasik.
  • Skema load balancing layanan backend harus EXTERNAL atau EXTERNAL_MANAGED.
  • Protokol layanan backend harus berupa salah satu dari HTTP, HTTPS, HTTP/2, UDP, TCP, SSL, atau UNSPECIFIED.

Tentang kebijakan keamanan Google Cloud Armor

Kebijakan keamanan Google Cloud Armor adalah serangkaian aturan yang cocok dengan atribut dari Lapisan 3 hingga Lapisan 7 untuk melindungi aplikasi atau layanan yang berinteraksi dengan pihak eksternal. Setiap aturan dievaluasi sehubungan dengan traffic yang masuk.

Aturan kebijakan keamanan Google Cloud Armor terdiri dari kondisi kecocokan dan tindakan yang akan diambil saat kondisi tersebut terpenuhi. Kondisinya bisa sesederhana apakah alamat IP sumber traffic masuk cocok dengan alamat IP tertentu atau rentang CIDR (juga dikenal sebagai daftar alamat IP yang diizinkan dan aturan daftar tolak). Atau, dengan menggunakan referensi bahasa aturan kustom Google Cloud Armor, Anda dapat membuat kondisi kustom yang cocok dengan berbagai atribut traffic masuk, seperti jalur URL, metode permintaan, atau nilai header permintaan.

Saat permintaan masuk cocok dengan kondisi dalam aturan kebijakan keamanan, Google Cloud Armor akan mengizinkan, menolak, atau mengalihkan permintaan tersebut, berdasarkan apakah aturan tersebut adalah aturan izin, aturan penolakan, atau aturan pengalihan. Mungkin ada parameter tindakan tambahan yang perlu diterapkan, seperti menyisipkan header permintaan; fitur ini adalah bagian dari pengelolaan bot Google Cloud Armor. Untuk mengetahui informasi selengkapnya tentang pengelolaan bot, lihat ringkasan pengelolaan bot.

Anda dapat mengaitkan kebijakan keamanan Google Cloud Armor dengan satu atau beberapa layanan backend. Layanan backend hanya dapat memiliki satu kebijakan keamanan yang terkait, tetapi layanan backend Anda tidak semuanya harus dikaitkan dengan kebijakan keamanan yang sama.

Jika kebijakan keamanan Google Cloud Armor dikaitkan dengan layanan backend apa pun, kebijakan tersebut tidak dapat dihapus. Layanan backend dapat dihapus terlepas dari apakah layanan tersebut memiliki kebijakan keamanan terkait atau tidak.

Jika beberapa aturan penerusan mengarah ke layanan backend yang memiliki kebijakan keamanan terkait, aturan kebijakan akan diterapkan untuk semua traffic yang masuk ke setiap alamat IP aturan penerusan.

Dalam ilustrasi berikut, kebijakan keamanan Google Cloud Armor internal-users-policy dikaitkan dengan layanan backend test-network.

Kebijakan keamanan Google Cloud Armor di edge jaringan.
Kebijakan keamanan Google Cloud Armor di edge jaringan (klik untuk memperbesar).

Kebijakan keamanan Google Cloud Armor memiliki fitur berikut:

  • Secara opsional, Anda dapat menggunakan protokol QUIC dengan load balancer yang menggunakan Google Cloud Armor.

  • Anda dapat menggunakan Google Cloud Armor dengan load balancer yang ada di salah satu Tingkat Layanan Jaringan berikut:

    • Paket Premium
    • Paket Standar

  • Anda dapat menggunakan kebijakan keamanan backend dengan GKE dan pengontrol Ingress default.

  • Anda dapat menggunakan kebijakan keamanan default yang membatasi traffic pada batas yang ditentukan pengguna saat mengonfigurasi salah satu load balancer berikut:

    • Load Balancer Aplikasi eksternal global
    • Load Balancer Aplikasi Klasik
    • Load Balancer Aplikasi eksternal regional
    • Load Balancer Jaringan proxy eksternal global
    • Load Balancer Jaringan proxy klasik
    • Load Balancer Jaringan passthrough eksternal

Selain itu, Anda dapat mengonfigurasi aturan WAF Google Cloud Armor yang telah dikonfigurasi sebelumnya, yang merupakan aturan firewall aplikasi web (WAF) kompleks dengan puluhan tanda tangan yang dikumpulkan dari standar industri open source. Setiap tanda tangan sesuai dengan aturan deteksi serangan dalam kumpulan aturan. Google menawarkan aturan ini sebagaimana adanya. Aturan ini memungkinkan Google Cloud Armor mengevaluasi puluhan tanda tangan traffic yang berbeda dengan merujuk pada aturan yang diberi nama secara mudah, bukan mengharuskan Anda menentukan setiap tanda tangan secara manual. Untuk mengetahui informasi selengkapnya tentang aturan WAF yang telah dikonfigurasi sebelumnya, lihat ringkasan aturan WAF yang telah dikonfigurasi sebelumnya.

Jenis kebijakan keamanan

Tabel berikut menunjukkan jenis kebijakan keamanan dan tindakan yang dapat Anda lakukan dengannya. Tanda centang () menunjukkan bahwa jenis kebijakan keamanan mendukung fitur ini.

Kebijakan keamanan backend

Kebijakan keamanan backend digunakan dengan layanan backend yang diekspos oleh jenis load balancer berikut:

  • Load Balancer Aplikasi eksternal global
  • Load Balancer Aplikasi Klasik
  • Load Balancer Aplikasi eksternal regional
  • Load Balancer Jaringan proxy eksternal global
  • Load Balancer Jaringan proxy klasik

NEG dapat digunakan untuk memfilter permintaan dan melindungi layanan backend yang merujuk ke grup instance atau grup endpoint jaringan (NEG) termasuk NEG Internet, Zonal, Hybrid, dan Tanpa Server. Tidak semua load balancer mendukung semua jenis NEG. Untuk mengetahui informasi selengkapnya tentang NEG yang didukung load balancer, lihat Ringkasan grup endpoint jaringan.

Saat menggunakan Load Balancer Jaringan proxy eksternal global atau Load Balancer Jaringan proxy klasik, Google Cloud Armor hanya menerapkan tindakan deny aturan kebijakan keamanan pada permintaan koneksi baru. Tindakan deny akan menghentikan koneksi TCP. Selain itu, jika Anda memberikan kode status dengan tindakan deny, kode status akan diabaikan.

Kebijakan keamanan backend memiliki nilai flag type opsional, CLOUD_ARMOR. Jika Anda tidak menetapkan flag type, nilai defaultnya adalah CLOUD_ARMOR.

Kebijakan keamanan Edge

Dengan kebijakan keamanan edge, pengguna dapat mengonfigurasi kebijakan pemfilteran dan kontrol akses untuk konten yang disimpan dalam cache; kebijakan ini mencakup endpoint seperti layanan backend berkemampuan Cloud CDN dan bucket Cloud Storage. Kebijakan keamanan edge mendukung pemfilteran berdasarkan subset parameter dibandingkan dengan kebijakan keamanan backend. Anda tidak dapat menetapkan kebijakan keamanan edge sebagai kebijakan backend. Kebijakan keamanan Edge didukung untuk endpoint berikut:

  • Load Balancer Aplikasi eksternal global
  • Load Balancer Aplikasi Klasik

Kebijakan keamanan Edge dapat dikonfigurasi untuk memfilter permintaan sebelum permintaan disalurkan dari cache Google. Kebijakan keamanan edge diterapkan dan diterapkan di dekat perimeter terluar jaringan Google, di upstream tempat cache Cloud CDN berada. Kebijakan keamanan edge dapat digunakan bersama dengan kebijakan keamanan backend untuk memberikan perlindungan dua lapisan. Pengujian ini dapat diterapkan secara bersamaan ke layanan backend, terlepas dari resource yang ditujukan oleh layanan backend (misalnya, grup instance atau grup endpoint jaringan). Hanya kebijakan keamanan edge yang dapat diterapkan ke bucket backend.

Saat kebijakan keamanan edge dan kebijakan keamanan backend dipasang ke layanan backend yang sama, kebijakan keamanan backend hanya diterapkan untuk permintaan cache yang tidak ditemukan yang telah lulus kebijakan keamanan edge.

Kebijakan keamanan Edge dievaluasi dan diterapkan sebelum Identity-Aware Proxy (IAP). Permintaan yang diblokir oleh kebijakan keamanan edge akan ditolak sebelum IAP mengevaluasi identitas pemohon. Memblokir permintaan dengan aturan pada kebijakan keamanan edge akan mencegah IAP menayangkan halaman login atau mencoba mengautentikasi pengguna.

Kebijakan keamanan edge memiliki nilai tanda type CLOUD_ARMOR_EDGE.

Kebijakan keamanan edge jaringan

Kebijakan keamanan edge jaringan memungkinkan Anda mengonfigurasi aturan untuk memblokir traffic di edge jaringan Google. Menerapkan kebijakan keamanan edge jaringan tidak akan menghabiskan resource VM atau host, sehingga membantu mencegah traffic bervolume tinggi menghabiskan resource pada workload target atau menyebabkan denial of service. Anda dapat mengonfigurasi kebijakan keamanan edge jaringan untuk resource berikut:

  • Load Balancer Jaringan passthrough eksternal
  • Penerusan protokol
  • VM dengan alamat IP publik

Kebijakan keamanan edge jaringan mendukung pemfilteran berdasarkan beberapa parameter yang sama dengan kebijakan keamanan backend, dan merupakan satu-satunya jenis kebijakan keamanan yang mendukung pemfilteran offset byte. Buka tabel Jenis kebijakan keamanan untuk mengetahui daftar lengkap parameter yang tersedia.

Kebijakan keamanan edge jaringan memiliki nilai tanda type CLOUD_ARMOR_NETWORK. Untuk mengonfigurasi kebijakan keamanan edge jaringan, pertama-tama Anda harus mengonfigurasi perlindungan DDoS jaringan lanjutan di region tempat Anda ingin membuat kebijakan. Untuk mengetahui informasi selengkapnya tentang perlindungan DDoS lanjutan, lihat Mengonfigurasi perlindungan DDoS jaringan lanjutan.

Urutan evaluasi aturan

Urutan evaluasi aturan ditentukan berdasarkan prioritas aturan, dari angka terendah ke angka tertinggi. Aturan dengan nilai numerik terendah yang ditetapkan memiliki prioritas logika tertinggi dan dievaluasi sebelum aturan dengan prioritas logis yang lebih rendah. Prioritas numerik minimum adalah 0. Prioritas aturan berkurang seiring bertambahnya jumlahnya (1, 2, 3, N+1). Anda tidak dapat mengonfigurasi dua aturan atau lebih dengan prioritas yang sama. Prioritas untuk setiap aturan harus ditetapkan ke angka antara 0 hingga 2147483646 inklusif. Nilai prioritas 2147483647, yang juga dikenal sebagai INT-MAX, dicadangkan untuk aturan default.

Nomor prioritas dapat memiliki celah, yang memungkinkan Anda menambahkan atau menghapus aturan pada masa mendatang tanpa memengaruhi aturan lainnya. Misalnya, 1, 2, 3, 4, 5, 9, 12, 16 adalah rangkaian angka prioritas yang valid yang dapat Anda tambahi aturan bernomor 6 sampai 8, 10 sampai 11, dan 13 sampai 15 pada masa mendatang. Anda tidak perlu mengubah aturan yang sudah ada, kecuali urutan eksekusinya.

Biasanya, aturan prioritas tertinggi yang sesuai dengan permintaan akan diterapkan. Namun, ada pengecualian saat permintaan HTTP POST dievaluasi terhadap aturan yang telah dikonfigurasi sebelumnya yang menggunakan evaluatePreconfiguredExpr(). Pengecualiannya adalah sebagai berikut.

Untuk permintaan HTTP POST, Google Cloud Armor menerima header permintaan sebelum isi (payload). Karena menerima informasi header terlebih dahulu, Google Cloud Armor mengevaluasi aturan yang cocok dengan header, tetapi tidak cocok dengan aturan yang telah dikonfigurasi sebelumnya pada isi. Jika ada beberapa aturan berbasis header, Google Cloud Armor akan mengevaluasinya berdasarkan prioritasnya seperti yang diharapkan. Perhatikan bahwa tindakan redirect dan penyisipan tindakan header kustom hanya berfungsi selama fase pemrosesan header. Tindakan redirect, jika dicocokkan selama fase pemrosesan isi berikut, akan diterjemahkan menjadi tindakan deny. Tindakan header permintaan kustom, jika dicocokkan selama fase pemrosesan isi, tidak akan diterapkan.

Setelah Google Cloud Armor menerima isi HTTP POST, Google Cloud Armor akan mengevaluasi aturan yang berlaku untuk header dan isi permintaan. Akibatnya, ada kemungkinan aturan dengan prioritas lebih rendah yang mengizinkan header permintaan akan dicocokkan sebelum aturan dengan prioritas yang lebih tinggi yang memblokir isi permintaan. Dalam kasus seperti itu, ada kemungkinan bahwa bagian header HTTP dari permintaan akan dikirim ke layanan backend target, tetapi isi POST yang berisi konten yang berpotensi berbahaya akan diblokir. Google Cloud Armor memeriksa 8 KB pertama dari isi POST. Untuk informasi selengkapnya tentang batasan ini, lihat Pembatasan pemeriksaan isi POST.

Ekspresi evaluatePreconfiguredExpr() untuk aturan yang telah dikonfigurasi sebelumnya adalah satu-satunya ekspresi yang dievaluasi terhadap isi permintaan. Semua ekspresi lainnya dievaluasi hanya terhadap header permintaan. Di antara jenis permintaan HTTP yang memiliki isi permintaan, Google Cloud Armor hanya memproses permintaan POST. Pemeriksaan dibatasi pada 8 KB pertama isi POST dan didekode seperti parameter kueri URL. Google Cloud Armor dapat mengurai dan menerapkan aturan WAF yang telah dikonfigurasi sebelumnya untuk isi POST berformat JSON (Content-Type = "application/json"). Namun, Google Cloud Armor tidak mendukung dekoder berbasis Content-Type/Content-Encoding HTTP lain seperti XML, Gzip, atau UTF-16.

Contoh

Pada contoh berikut, aturan 1, 2, dan 3 dievaluasi dalam urutan tersebut untuk kolom header IP dan HTTP. Namun, jika IP 9.9.9.1 meluncurkan serangan XSS di dalam isi HTTP POST, hanya isi tersebut yang diblokir (oleh aturan 2); header HTTP akan diteruskan ke backend (oleh aturan 3).

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 2
Rule3
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 3
Rule-default
action: deny(403)
priority: INT-MAX

Pada contoh berikut, kebijakan mengizinkan IP 9.9.9.1 tanpa memindai serangan XSS:

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 2
Rule3
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX

Aturan default

Setiap kebijakan keamanan Google Cloud Armor berisi aturan default yang dicocokkan jika tidak ada aturan dengan prioritas lebih tinggi yang cocok atau jika tidak ada aturan lain dalam kebijakan. Aturan default otomatis ditetapkan prioritas 2147483647 (INT-MAX), dan selalu ada dalam kebijakan keamanan.

Anda tidak dapat menghapus aturan default, tetapi Anda dapat mengubahnya. Tindakan default untuk aturan default adalah deny, tetapi Anda dapat mengubah tindakan ini menjadi allow.

Sidik jari

Setiap kebijakan keamanan Google Cloud Armor memiliki kolom fingerprint. Sidik jari adalah hash konten yang disimpan dalam kebijakan. Saat Anda membuat kebijakan baru, jangan berikan nilai kolom ini. Jika Anda memberikan nilai, nilai tersebut akan diabaikan. Namun, saat mengupdate kebijakan keamanan, Anda harus menentukan sidik jari saat ini, yang Anda dapatkan saat mengekspor atau menjelaskan kebijakan (menggunakan EXPORT atau DESCRIBE).

Sidik jari melindungi Anda agar tidak mengganti update pengguna lain. Jika sidik jari yang Anda berikan sudah tidak berlaku, artinya kebijakan keamanan telah diperbarui sejak terakhir kali Anda mengambil sidik jari. Untuk memeriksa apakah ada perbedaan dan mengambil sidik jari terbaru, jalankan perintah DESCRIBE.

Bahasa aturan dan mesin penegakan

Bahasa aturan dan mesin penegakan menyediakan hal berikut:

  • Kemampuan untuk menulis ekspresi aturan kustom yang dapat cocok di berbagai Lapisan 3 hingga atribut Lapisan 7 dari permintaan masuk. Google Cloud Armor menyediakan bahasa yang fleksibel untuk menulis kondisi pencocokan kustom.

  • Kemampuan untuk menggabungkan hingga 5 subekspresi dalam satu aturan.

  • Kemampuan untuk menolak atau mengizinkan permintaan berdasarkan kode wilayah permintaan masuk. Kode wilayah didasarkan pada kode ISO 3166-1 alpha 2. Kode wilayah terkadang sesuai dengan negara tertentu, tetapi beberapa kode mencakup negara beserta area terkaitnya. Misalnya, kode US mencakup semua negara bagian Amerika Serikat, satu distrik, dan enam area terpencil.

Jenis aturan

Google Cloud Armor memiliki jenis aturan berikut.

Aturan daftar tolak dan alamat IP yang diizinkan

Anda dapat membuat aturan daftar tolak dan alamat IP yang diizinkan dalam kebijakan keamanan. Beberapa contoh termasuk berikut ini:

  • Denylisting untuk alamat IP/CIDR memungkinkan Anda memblokir alamat IP sumber atau rentang CIDR agar tidak mengakses load balancer yang didukung.

  • Dengan mengizinkan pemberian alamat IP/CIDR, Anda dapat mengizinkan alamat IP sumber atau rentang CIDR untuk mengakses load balancer yang didukung.

  • Alamat IPv4 dan IPv6 didukung dalam aturan daftar yang diizinkan dan ditolak.

  • Aturan penolakan dapat menampilkan respons HTTP 403 (Tidak Sah), 404 (Akses Ditolak), atau 502 (Gateway Buruk).

  • Melebihi aturan tindakan dapat menampilkan 429 HTTP (Terlalu Banyak Permintaan).

Sumber aturan geografi

Anda dapat mengizinkan atau menolak permintaan yang berasal dari area geografis tertentu yang ditentukan oleh kode negara Unicode.

Google Cloud Armor menggunakan database geolokasi IP kami sendiri untuk mengidentifikasi lokasi geografi permintaan. {i>Database<i} diperbarui secara berkala. Meskipun kami tidak dapat menjamin ritme update tertentu, selama operasi normal, pemetaan yang digunakan Google Cloud Armor diperbarui sekitar seminggu sekali.

Pemetaan yang diperbarui harus disebarluaskan ke infrastruktur Google secara global. Proses peluncuran terjadi secara bertahap, biasanya selama beberapa hari, di berbagai zona dan region tempat Google Cloud Armor di-deploy. Karena proses peluncuran bertahap ini, bisa saja permintaan dari alamat IP sumber yang sama ditangani secara tidak konsisten selama peluncuran jika alamat IP sumber mengalami perubahan pada pemetaan lokasi geografis.

Aturan WAF yang telah dikonfigurasi sebelumnya

Google Cloud Armor menyediakan daftar lengkap aturan WAF yang telah dikonfigurasi sebelumnya berdasarkan Kumpulan Aturan Inti Keamanan ModSecurity OWASP untuk membantu Anda mendeteksi hal-hal berikut:

  • Serangan injeksi SQL
  • Serangan pembuatan skrip lintas situs
  • Serangan penyertaan file lokal
  • Serangan penyertaan file jarak jauh
  • Serangan eksekusi kode jarak jauh
  • Serangan penegakan metode
  • Serangan deteksi pemindai
  • Serangan protokol
  • Serangan injeksi PHP
  • Serangan fiksasi sesi
  • Serangan Java
  • Serangan NodeJS

Untuk mengetahui detailnya, lihat Ringkasan aturan WAF prakonfigurasi Google Cloud Armor.

Aturan pengelolaan bot

Anda dapat menggunakan aturan pengelolaan bot untuk melakukan hal-hal berikut:

  1. Permintaan pengalihan untuk penilaian reCAPTCHA Enterprise dengan verifikasi login manual opsional.
  2. Evaluasi token reCAPTCHA Enterprise yang dilampirkan dengan permintaan dan terapkan tindakan yang dikonfigurasi berdasarkan atribut token.
  3. Alihkan permintaan ke URL alternatif yang dikonfigurasi dengan respons 302.
  4. Sisipkan header kustom ke permintaan sebelum mem-proxy-kannya ke backend Anda.

Untuk mengetahui informasi selengkapnya tentang pengelolaan bot, baca ringkasan pengelolaan bot.

Aturan yang telah dikonfigurasi sebelumnya untuk daftar alamat IP bernama

Aturan yang telah dikonfigurasi untuk daftar alamat IP bernama memberikan hal berikut:

  • Integrasikan daftar alamat IP bernama penyedia pihak ketiga dengan Google Cloud Armor.

  • Menyederhanakan pemeliharaan rentang alamat IP yang diizinkan atau ditolak.

  • Menyinkronkan daftar penyedia pihak ketiga setiap hari.

  • Tingkatkan kapasitas dalam mengonfigurasi alamat dan rentang IP dalam kebijakan keamanan karena daftar alamat IP bernama tidak tunduk pada batasan jumlah alamat IP per aturan.

Aturan pembatasan kapasitas

Anda dapat menggunakan aturan pembatasan kapasitas untuk melakukan hal berikut:

  • Batasi permintaan per klien berdasarkan nilai minimum yang Anda konfigurasi.
  • Memblokir klien yang melampaui nilai minimum permintaan untuk sementara yang telah Anda tetapkan untuk durasi yang dikonfigurasi.

Jika Anda menggunakan pembatasan kapasitas dengan Load Balancer Jaringan proxy eksternal global atau Load Balancer Jaringan proxy klasik, pembatasan berikut akan berlaku:

  • Google Cloud Armor hanya menerapkan tindakan pembatasan kapasitas seperti throttling atau pemblokiran permintaan koneksi baru dari klien.
  • Hanya jenis kunci ALL dan IP yang didukung.
  • Jika Anda mencoba menggunakan jenis kunci HTTP-HEADER atau HTTP-COOKIE dengan load balancer TCP/SSL, jenis kunci tersebut akan ditafsirkan sebagai ALL, dan juga XFF-IP akan ditafsirkan sebagai IP.

Untuk informasi selengkapnya tentang pembatasan kapasitas dan cara kerjanya, lihat Ringkasan pembatasan kapasitas.

Mode pratinjau

Anda dapat melihat pratinjau efek aturan tanpa menerapkannya. Dalam mode pratinjau, tindakan dicatat di Cloud Monitoring. Anda dapat memilih untuk melihat pratinjau setiap aturan dalam kebijakan keamanan, atau melihat pratinjau setiap aturan dalam kebijakan tersebut. Anda akan ditagih dengan biaya per permintaan normal untuk aturan dalam mode pratinjau.

Anda dapat mengaktifkan mode pratinjau untuk aturan menggunakan Google Cloud CLI dan flag --preview gcloud compute security-policies rules update.

Untuk menonaktifkan mode pratinjau, gunakan tanda --no-preview, yang saat ini tidak didokumentasikan. Anda juga dapat menggunakan Google Cloud Console.

Jika permintaan memicu pratinjau, Google Cloud Armor akan terus mengevaluasi aturan lain hingga menemukan kecocokan. Aturan yang cocok dan pratinjau akan tersedia di log.

Respons error kustom

Jika menggunakan Load Balancer Aplikasi eksternal global, Anda dapat mengonfigurasi respons error kustom untuk kode status HTTP untuk error yang dihasilkan oleh load balancer atau backend instance. Selain itu, Anda dapat mengonfigurasi kode error kustom untuk traffic yang ditolak Google Cloud Armor dengan mengonfigurasi halaman respons kustom untuk kode error seri 4xx atau seri 5xx yang sama dengan yang digunakan oleh aturan kebijakan keamanan yang sudah ada.

Untuk mengetahui informasi selengkapnya tentang respons error kustom, lihat Ringkasan respons error kustom. Untuk mengetahui langkah-langkah konfigurasi, lihat Mengonfigurasi respons error kustom.

Logging

Google Cloud Armor memiliki logging yang ekstensif dan dapat digunakan untuk menentukan panjang logging. Untuk mengetahui informasi selengkapnya tentang logging, baca artikel Menggunakan logging permintaan.

Untuk melihat log Google Cloud Armor, buka Melihat log.

Logging permintaan Load Balancer Aplikasi Eksternal

Setiap permintaan HTTP(S) yang dievaluasi berdasarkan kebijakan keamanan Google Cloud Armor akan dicatat ke dalam log melalui Cloud Logging. Log tersebut memberikan detail seperti nama kebijakan keamanan yang diterapkan, aturan yang cocok, dan apakah aturan tersebut diterapkan. Logging permintaan untuk resource layanan backend baru dinonaktifkan secara default. Untuk memastikan bahwa permintaan Google Cloud Armor dicatat, Anda harus mengaktifkan logging HTTP(S) untuk setiap layanan backend yang dilindungi oleh kebijakan keamanan.

Untuk mengetahui informasi selengkapnya, lihat Logging dan pemantauan Load Balancer Aplikasi Eksternal.

Logging permintaan Load Balancer Jaringan proxy eksternal

Anda dapat mengonfigurasi logging untuk Load Balancer Jaringan proxy eksternal menggunakan perintah Google Cloud CLI, seperti yang tercantum dalam logging dan pemantauan load balancing proxy TCP/SSL. Anda tidak dapat mengaktifkan logging untuk Load Balancer Jaringan proxy eksternal menggunakan Konsol Google Cloud.

Kapan harus menggunakan logging panjang

Anda mungkin tidak dapat mengetahui alasan aturan WAF yang telah dikonfigurasi sebelumnya dipicu oleh permintaan tertentu. Log peristiwa default Google Cloud Armor berisi aturan yang dipicu, serta subtanda tangan. Namun, Anda mungkin perlu mengidentifikasi detail dari permintaan masuk yang memicu aturan untuk tujuan pemecahan masalah, validasi aturan, atau penyesuaian aturan.

Anda dapat menyesuaikan tingkat detail yang tercatat di log Anda. Sebaiknya aktifkan logging panjang hanya saat Anda pertama kali membuat kebijakan, membuat perubahan pada kebijakan, atau memecahkan masalah kebijakan. Jika Anda mengaktifkan logging panjang, ini akan berlaku untuk aturan dalam mode pratinjau serta aturan aktif (tidak dipratinjau) selama operasi standar.

Untuk mengetahui informasi selengkapnya tentang logging panjang, lihat Logging panjang.

Penguraian konten isi POST

Secara default, Google Cloud Armor mengevaluasi konten lengkap isi POST sebagai string seragam (tunduk pada batasan ukuran tubuh) terhadap tanda tangan dalam aturan WAF yang telah dikonfigurasi sebelumnya. Untuk permintaan yang berisi encoding alternatif seperti JSON, komponen struktural pesan (tidak ditentukan oleh pengguna) dapat memicu kecocokan terhadap tanda tangan WAF yang telah dikonfigurasi sebelumnya. Untuk menghindari derau dan mengurangi risiko positif palsu (PP), sebaiknya konfigurasikan Google Cloud Armor guna mengaktifkan penguraian alternatif untuk semua Jenis Konten yang didukung jika workload yang dilindungi melakukan hal berikut:

  • Menayangkan REST API
  • Menggunakan GraphQL
  • Menerima semua permintaan dengan konten berenkode JSON.

Untuk informasi selengkapnya tentang aturan WAF yang telah dikonfigurasi sebelumnya, lihat Menerapkan penguraian JSON pada nilai header Jenis Konten kustom.

Setiap permintaan HTTP(S) yang dievaluasi berdasarkan kebijakan keamanan Google Cloud Armor akan dicatat ke dalam log melalui Cloud Logging. Log tersebut memberikan detail, seperti nama kebijakan keamanan yang diterapkan, aturan yang cocok, dan apakah aturan tersebut diterapkan. Logging permintaan untuk resource layanan backend baru dinonaktifkan secara default. Untuk memastikan bahwa permintaan Google Cloud Armor dicatat, Anda harus mengaktifkan logging HTTP(S) untuk setiap layanan backend yang dilindungi oleh kebijakan keamanan.

Untuk mengetahui informasi selengkapnya, lihat Logging dan pemantauan Load Balancer Aplikasi eksternal global.

Batasan

Bagian berikut menjelaskan batasan untuk kebijakan keamanan.

Batasan pemeriksaan isi POST

Ekspresi evaluatePreconfiguredExpr() untuk aturan yang telah dikonfigurasi sebelumnya adalah satu-satunya ekspresi yang dievaluasi oleh Google Cloud Armor terhadap isi permintaan. Di antara jenis permintaan HTTP yang memiliki isi permintaan, Google Cloud Armor hanya memproses permintaan POST.

Pemeriksaan ini dibatasi pada 8 KB pertama isi POST, yang didekode seperti parameter kueri URL. Sisa isi POST mungkin berisi kode berbahaya, yang mungkin diterima aplikasi Anda. Untuk mengurangi risiko isi POST yang ukurannya melebihi 8 KB, lihat panduan pemecahan masalah.

Google Cloud Armor dapat mengurai dan menerapkan aturan WAF yang telah dikonfigurasi sebelumnya untuk isi POST (Content-Type = "application/json") dengan encoding URL dan berformat JSON default. Dalam hal ini, aturan secara independen diterapkan pada nama dan nilai yang didekode dalam data. Untuk jenis konten dan jenis encoding lainnya, Google Cloud Armor tidak mendekode data, tetapi menerapkan aturan yang telah dikonfigurasi sebelumnya pada data mentah.

Cara penanganan koneksi WebSocket

Load Balancer Aplikasi eksternal global memiliki dukungan bawaan untuk protokol WebSocket. Saluran WebSocket dimulai dari permintaan HTTP(S). Google Cloud Armor dapat memblokir saluran WebSocket agar tidak dibuat, misalnya, jika daftar tolak alamat IP memblokir alamat IP asal. Namun, transaksi berikutnya di saluran tidak sesuai dengan protokol HTTP, dan Google Cloud Armor tidak mengevaluasi pesan apa pun setelah permintaan pertama.

Langkah selanjutnya