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 yang berpotensi memblokir traffic sebelum mencapai layanan backend ber-load balancer atau bucket backend Anda. Setiap kebijakan keamanan terdiri dari kumpulan aturan yang dapat dikonfigurasi pada atribut dari Lapisan 3 hingga Lapisan 7. Aturan dapat 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:

  • Application Load Balancer eksternal global (HTTP/HTTPS)
  • Load Balancer Aplikasi Klasik (HTTP/HTTPS)
  • Load Balancer Aplikasi eksternal regional (HTTP/HTTPS)
  • Load Balancer Aplikasi internal 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 di Paket Premium atau Paket Standar.

Backend untuk layanan backend dapat berupa salah satu dari hal berikut:

Saat Anda menggunakan Google Cloud Armor untuk melindungi deployment hybrid atau arsitektur multi-cloud, backend 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 Anda, lihat Kontrol ingress.

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

Melindungi 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. Di Paket Premium, traffic pengguna yang diarahkan ke load balancer eksternal akan masuk ke PoP yang terdekat dengan pengguna. Kemudian, traffic tersebut akan di-load balance melalui jaringan global Google ke backend terdekat yang memiliki kapasitas memadai. Di Paket Standar, traffic pengguna memasuki jaringan Google melalui jaringan peering, ISP, atau transit di region tempat Anda men-deploy resource Google Cloud.

Kebijakan keamanan Google Cloud Armor memungkinkan Anda 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 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:

  • Skema load balancing layanan backend harus berupa EXTERNAL, EXTERNAL_MANAGED, atau INTERNAL_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 kumpulan aturan yang cocok dengan atribut dari Lapisan 3 hingga Lapisan 7 untuk melindungi aplikasi atau layanan yang ditampilkan secara eksternal. Setiap aturan dievaluasi sehubungan dengan traffic masuk.

Aturan kebijakan keamanan Google Cloud Armor terdiri dari kondisi kecocokan dan tindakan yang akan dilakukan saat kondisi tersebut terpenuhi. Kondisi dapat sesederhana apakah alamat IP sumber traffic masuk cocok dengan alamat IP atau rentang CIDR tertentu (juga dikenal sebagai aturan daftar yang diizinkan dan daftar yang ditolak alamat IP). 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.

Jika permintaan masuk cocok dengan kondisi dalam aturan kebijakan keamanan, Google Cloud Armor akan mengizinkan, menolak, atau mengalihkan permintaan, berdasarkan apakah aturan tersebut adalah aturan izinkan, aturan tolak, atau aturan alihkan. Mungkin ada parameter tindakan tambahan yang akan 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 tidak semua layanan backend Anda harus dikaitkan dengan kebijakan keamanan yang sama.

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

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 tepi jaringan (klik untuk memperbesar).

Kebijakan keamanan Google Cloud Armor memiliki fitur berikut:

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

  • Anda dapat menggunakan Google Cloud Armor dengan load balancer yang berada 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 di atas nilai minimum 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 Aplikasi internal regional
    • Load Balancer Jaringan proxy eksternal global
    • Load Balancer Jaringan proxy klasik
    • Load Balancer Jaringan passthrough eksternal

Selain itu, Anda dapat mengonfigurasi aturan WAF yang telah dikonfigurasi sebelumnya oleh Google Cloud Armor, yang merupakan aturan firewall aplikasi web (WAF) yang kompleks dengan puluhan tanda tangan yang dikompilasi dari standar industri open source. Setiap tanda tangan sesuai dengan aturan deteksi serangan dalam kumpulan aturan. Google menawarkan aturan ini apa adanya. Aturan ini memungkinkan Google Cloud Armor mengevaluasi puluhan tanda tangan traffic yang berbeda dengan merujuk ke aturan yang diberi nama dengan 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 tersebut.

Kebijakan keamanan backend

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

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

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

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

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

Kebijakan keamanan Edge

Kebijakan keamanan Edge memungkinkan pengguna mengonfigurasi kebijakan pemfilteran dan kontrol akses untuk konten yang disimpan dalam cache; ini mencakup endpoint seperti layanan backend yang mengaktifkan 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 ditayangkan dari cache Google. Kebijakan keamanan edge di-deploy dan diterapkan dekat perimeter terluar jaringan Google, di hulu tempat cache Cloud CDN berada. Kebijakan keamanan Edge dapat digunakan bersama dengan kebijakan keamanan backend untuk memberikan dua lapisan perlindungan. Aturan ini dapat diterapkan secara bersamaan ke layanan backend, terlepas dari resource yang mengarah ke layanan backend (misalnya, grup instance atau grup endpoint jaringan). Hanya kebijakan keamanan edge yang dapat diterapkan ke bucket backend.

Jika kebijakan keamanan edge dan kebijakan keamanan backend dilampirkan ke layanan backend yang sama, kebijakan keamanan backend hanya diterapkan untuk permintaan cache 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 di 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 titik masuk jaringan Google. Penerapan kebijakan keamanan edge jaringan tidak menggunakan resource VM atau host, yang membantu mencegah traffic bervolume tinggi menghabiskan resource pada workload target atau menyebabkan penolakan layanan. 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. Lihat tabel Jenis kebijakan keamanan untuk mengetahui daftar lengkap parameter yang tersedia.

Kebijakan keamanan edge jaringan memiliki nilai flag type CLOUD_ARMOR_NETWORK. Untuk mengonfigurasi kebijakan keamanan edge jaringan, Anda harus mengonfigurasi perlindungan DDoS jaringan lanjutan terlebih dahulu di region tempat Anda ingin membuat kebijakan. Untuk informasi selengkapnya tentang perlindungan DDoS lanjutan, lihat Mengonfigurasi perlindungan DDoS jaringan lanjutan.

Urutan evaluasi aturan

Urutan evaluasi aturan ditentukan oleh prioritas aturan, dari angka terendah ke angka tertinggi. Aturan dengan nilai numerik terendah yang ditetapkan memiliki prioritas logis tertinggi dan dievaluasi sebelum aturan dengan prioritas logis yang lebih rendah. Prioritas numerik minimum adalah 0. Prioritas aturan menurun seiring dengan meningkatnya 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 dari 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 di masa mendatang tanpa memengaruhi aturan lainnya. Misalnya, 1, 2, 3, 4, 5, 9, 12, 16 adalah serangkaian nomor prioritas yang valid yang dapat Anda tambahkan aturan bernomor 6 hingga 8, 10 hingga 11, dan 13 hingga 15 di masa mendatang. Anda tidak perlu mengubah aturan yang ada kecuali urutan eksekusi.

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

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

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

Ekspresi evaluatePreconfiguredExpr() untuk aturan yang telah dikonfigurasi sebelumnya adalah satu-satunya ekspresi yang dievaluasi terhadap isi permintaan. Semua ekspresi lainnya hanya dievaluasi berdasarkan header permintaan. Di antara jenis permintaan HTTP dengan isi permintaan, Google Cloud Armor hanya memproses permintaan POST. Inspeksi dibatasi hingga 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 lainnya 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 dalam isi HTTP POST, hanya isi 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

Dalam contoh berikut, kebijakan mengizinkan IP 9.9.9.1 tanpa memindai terhadap 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 cocok jika tidak ada aturan prioritas yang lebih tinggi yang cocok atau jika tidak ada aturan lain dalam kebijakan. Aturan default secara otomatis ditetapkan prioritasnya ke 2147483647 (INT-MAX), dan selalu ada dalam kebijakan keamanan.

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

Sidik jari

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

Sidik jari melindungi Anda dari penggantian update pengguna lain. Jika sidik jari yang Anda berikan sudah tidak berlaku, berarti kebijakan keamanan telah diperbarui sejak Anda terakhir kali mengambil sidik jari. Untuk memeriksa 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 dengan berbagai atribut Lapisan 3 hingga Lapisan 7 dari permintaan yang 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 yang 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 yang diizinkan dan ditolak alamat IP

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

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

  • Daftar yang diizinkan untuk alamat IP/CIDR memungkinkan Anda mengizinkan alamat IP atau rentang CIDR sumber untuk mengakses load balancer yang didukung.

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

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

  • Aturan tindakan melebihi batas dapat menampilkan HTTP 429 (Terlalu Banyak Permintaan).

Aturan geografi sumber

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

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

Pemetaan yang diperbarui harus diterapkan ke infrastruktur Google secara global. Proses peluncuran terjadi secara bertahap, biasanya selama beberapa hari, di beberapa zona dan region tempat Google Cloud Armor di-deploy. Karena proses peluncuran bertahap ini, Anda mungkin melihat permintaan dari alamat IP sumber yang sama ditangani secara tidak konsisten selama peluncuran jika alamat IP sumber memiliki perubahan pada pemetaan geolokasi.

Aturan WAF yang telah dikonfigurasi sebelumnya

Google Cloud Armor menyediakan daftar lengkap aturan WAF yang telah dikonfigurasi sebelumnya berdasarkan Kumpulan Aturan Inti ModSecurity OWASP (CRS) untuk membantu Anda mendeteksi 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 penerapan metode
  • Serangan deteksi pemindai
  • Serangan protokol
  • Serangan injeksi PHP
  • Serangan fiksasi sesi
  • Serangan Java
  • Serangan NodeJS

Untuk mengetahui detailnya, lihat Ringkasan aturan WAF yang telah dikonfigurasi sebelumnya oleh Google Cloud Armor.

Aturan pengelolaan bot

Anda dapat menggunakan aturan pengelolaan bot untuk melakukan hal berikut:

  1. Mengalihkan permintaan untuk penilaian reCAPTCHA dengan tantangan manual opsional.
  2. Evaluasi token reCAPTCHA yang disertakan dengan permintaan dan terapkan tindakan yang dikonfigurasi berdasarkan atribut token.
  3. Alihkan permintaan ke URL alternatif yang Anda konfigurasikan dengan respons 302.
  4. Masukkan header kustom ke permintaan sebelum mem-proxy-nya ke backend Anda.

Untuk informasi selengkapnya tentang pengelolaan bot, lihat ringkasan pengelolaan bot.

Aturan yang telah dikonfigurasi sebelumnya untuk daftar alamat IP bernama

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

  • Mengintegrasikan daftar alamat IP bernama dari 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 Anda untuk mengonfigurasi alamat IP dan rentangnya dalam kebijakan keamanan karena daftar alamat IP yang dinamai 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 konfigurasikan.
  • Larang klien untuk sementara yang melebihi nilai minimum permintaan yang Anda tetapkan selama durasi yang dikonfigurasi.

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

  • Google Cloud Armor hanya menerapkan tindakan pembatasan kapasitas seperti throttling atau larangan pada 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 akan ditafsirkan sebagai ALL, dan begitu pula XFF-IP akan ditafsirkan sebagai IP.

Untuk mengetahui 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 Anda dapat melihat pratinjau setiap aturan dalam kebijakan. Anda akan dikenai biaya per permintaan normal untuk aturan dalam mode pratinjau.

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

Untuk menonaktifkan mode pratinjau, gunakan flag --no-preview. Anda juga dapat menggunakan Konsol Google Cloud.

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

Respons error kustom

Saat menggunakan Load Balancer Aplikasi eksternal global, Anda dapat mengonfigurasi respons error kustom untuk kode status HTTP untuk error yang dihasilkan oleh load balancer atau instance backend. Selain itu, Anda dapat mengonfigurasi kode error kustom untuk traffic yang ditolak oleh 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 ada.

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

Logging

Google Cloud Armor memiliki logging yang ekstensif dan memungkinkan Anda menentukan tingkat detail logging. Log Google Cloud Armor dibuat berdasarkan aturan pertama (prioritas tertinggi) yang cocok dengan permintaan masuk, terlepas dari apakah kebijakan keamanan dalam mode pratinjau atau tidak. Artinya, log tidak dibuat untuk aturan yang tidak cocok, atau untuk aturan yang cocok dengan prioritas yang lebih rendah.

Untuk mengetahui informasi lengkap tentang logging, lihat Menggunakan logging permintaan. Untuk mengetahui informasi selengkapnya tentang logging panjang, lihat Logging panjang. Untuk melihat log Google Cloud Armor, lihat Melihat log.

Logging permintaan Load Balancer Aplikasi Eksternal

Setiap permintaan HTTP(S) yang dievaluasi berdasarkan kebijakan keamanan Google Cloud Armor dicatat ke dalam log melalui Cloud Logging. Log memberikan detail seperti nama kebijakan keamanan yang diterapkan, aturan yang cocok, dan apakah aturan tersebut diterapkan. Permintaan logging untuk resource layanan backend baru dinonaktifkan secara default. Untuk memastikan permintaan Google Cloud Armor dicatat ke dalam log, 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 dengan 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.

Batasan

Bagian berikut menjelaskan batasan untuk kebijakan keamanan.

Batasan pemeriksaan isi POST dan PATCH

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

Pemeriksaan dibatasi hingga 8 KB pertama isi POST atau PATCH, yang didekode seperti parameter kueri URL. Sisa isi permintaan mungkin berisi kode berbahaya, yang mungkin diterima aplikasi Anda. Untuk mengurangi risiko isi permintaan 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 dan PATCH default yang dienkode URL dan berformat JSON (Content-Type = "application/json"). Dalam hal ini, aturan diterapkan secara independen 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