Ringkasan kebijakan keamanan

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

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

• Semua Load Balancer Aplikasi eksternal, termasuk Load Balancer Aplikasi klasik
• Load Balancer Aplikasi internal regional
• Load Balancer Jaringan proxy eksternal global (TCP/SSL)
• Load Balancer Jaringan proxy klasik (TCP/SSL)
• Load Balancer Jaringan passthrough eksternal (TCP/UDP)
• Penerusan protokol eksternal
• VM dengan alamat IPv4 eksternal atau rentang alamat IPv6 eksternal yang ditetapkan ke antarmuka jaringan (NIC)

Load balancer dapat berada di Paket Premium atau Paket Standar.

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

• Grup instance
• Semua jenis grup endpoint jaringan (NEG) yang didukung oleh load balancer Anda
• Bucket di Cloud Storage

Saat Anda menggunakan Google Cloud Armor untuk melindungi deployment hybrid atau arsitektur multicloud, backend harus berupa NEG internet atau NEG hybrid. Google Cloud Armor juga melindungi NEG serverless saat traffic dirutekan melalui load balancer. Untuk mengetahui informasi tentang cara merutekan traffic melalui load balancer sebelum mencapai NEG serverless, lihat Kontrol ingress.

Melindungi deployment Google Cloud Anda dengan kebijakan keamanan Google Cloud Armor

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 menggunakan resource atau memasuki jaringan Virtual Private Cloud (VPC) Anda.

Persyaratan

• 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 sekumpulan aturan yang cocok dengan atribut dari jaringan Lapisan 3 hingga Lapisan 7 untuk melindungi aplikasi atau layanan yang menghadap eksternal. Setiap aturan dievaluasi sehubungan dengan traffic masuk.

Aturan kebijakan keamanan Google Cloud Armor terdiri dari kondisi kecocokan dan tindakan yang harus dilakukan saat kondisi tersebut terpenuhi. Kondisi dapat sesederhana apakah alamat IP sumber traffic masuk cocok dengan alamat IP tertentu atau rentang CIDR (juga dikenal sebagai aturan daftar yang diizinkan dan daftar yang ditolak alamat IP). Atau, dengan menggunakan atribut bahasa aturan kustom, 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 mengizinkan, menolak, atau mengalihkan permintaan, berdasarkan apakah aturan tersebut adalah aturan izinkan, aturan tolak, atau aturan pengalihan. Ada parameter tindakan tambahan yang dapat 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 dengannya, tetapi semua layanan backend Anda tidak harus dikaitkan dengan kebijakan keamanan yang sama. Untuk melampirkan dan menghapus kebijakan keamanan dari layanan dan fitur backend yang didukung, lihat Melampirkan dan menghapus kebijakan keamanan.

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.

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 diagram berikut, kebijakan keamanan Google Cloud Armor internal-users-policy dikaitkan dengan layanan backend test-network.

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

• Anda dapat menggunakan Google Cloud Armor dengan load balancer yang berada di salah satu Tingkatan 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 set aturan. Google menawarkan aturan ini apa adanya. Aturan ini memungkinkan Google Cloud Armor mengevaluasi puluhan tanda tangan traffic yang berbeda dengan merujuk pada aturan yang diberi nama dengan mudah, daripada 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 dengan kebijakan tersebut. Tanda centang () menunjukkan bahwa jenis kebijakan keamanan mendukung fitur tersebut.

Kebijakan keamanan backend

• 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

Anda menggunakan kebijakan keamanan backend untuk memfilter permintaan dan melindungi layanan backend yang mereferensikan grup instance atau salah satu jenis NEG yang didukung di belakang jenis load balancer yang tercantum sebelumnya. Untuk mengetahui 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 aturan tindakan 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 menyetel 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; hal ini mencakup endpoint seperti layanan backend yang mendukung 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 di dekat perimeter terluar jaringan Google, di hulu tempat cache Cloud CDN berada. Kebijakan keamanan Edge dapat berjalan bersama dengan kebijakan keamanan backend untuk memberikan dua lapisan perlindungan. Kebijakan ini dapat diterapkan secara bersamaan ke layanan backend, terlepas dari resource yang dituju 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 melewati kebijakan keamanan edge.

Kebijakan keamanan Edge dievaluasi dan diterapkan sebelum Identity-Aware Proxy (IAP). Permintaan yang diblokir oleh kebijakan keamanan edge ditolak sebelum IAP mengevaluasi identitas pemohon. Memblokir permintaan dengan aturan di kebijakan keamanan edge akan mencegah IAP menampilkan 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 menggunakan resource VM atau host, yang membantu mencegah traffic bervolume tinggi menguras 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. Untuk daftar lengkap parameter yang tersedia, lihat tabel Jenis kebijakan keamanan.

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 berencana membuat kebijakan. Untuk mengetahui informasi selengkapnya tentang perlindungan DDoS tingkat lanjut, lihat Mengonfigurasi perlindungan DDoS jaringan tingkat lanjut.

Urutan evaluasi aturan

Urutan evaluasi aturan ditentukan oleh prioritas aturan, dari angka terendah hingga 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 bertambahnya nomornya (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, juga dikenal sebagai INT-MAX, dicadangkan untuk aturan default.

Nomor prioritas dapat memiliki kesenjangan. Dengan celah ini, Anda dapat menambahkan atau menghapus aturan di 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 hingga 8, 10 hingga 11, dan 13 hingga 15 pada masa mendatang. Anda tidak perlu mengubah aturan yang ada, kecuali urutan eksekusinya.

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

Untuk permintaan HTTP POST dengan isi, Google Cloud Armor menerima header permintaan sebelum isi (payload). Karena Google Cloud Armor menerima informasi header terlebih dahulu, Google Cloud Armor 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 penyisipan tindakan header kustom hanya berfungsi selama fase pemrosesan header. Tindakan redirect, jika cocok selama fase pemrosesan isi berikut, akan diterjemahkan menjadi tindakan deny. Tindakan header permintaan kustom, jika cocok selama fase pemrosesan isi, tidak akan berlaku.

Setelah menerima permintaan HTTP POST dengan isi, Google Cloud Armor akan mengevaluasi aturan yang berlaku untuk header dan isi permintaan. Akibatnya, aturan prioritas yang lebih rendah yang mengizinkan header permintaan dapat 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 yang berisi konten yang berpotensi berbahaya diblokir. Google Cloud Armor memeriksa hingga 64 kB pertama (sesuai dengan batas pemeriksaan yang dikonfigurasi, yaitu 8 kB, 16 kB, 32 kB, 48 kB, atau 64 kB) dari isi permintaan. Untuk mengetahui informasi selengkapnya tentang batasan ini, lihat Batasan pemeriksaan isi POST dan PATCH.

Ekspresi evaluatePreconfiguredWaf() 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 dengan isi permintaan, Google Cloud Armor hanya memproses permintaan POST dan PATCH. Pemeriksaan terbatas pada batas pemeriksaan yang dikonfigurasi, hingga 64 kB pertama (8 kB, 16 kB, 32 kB, 48 kB, atau 64 kB) isi permintaan dan didekode seperti parameter kueri URL. Google Cloud Armor dapat mem-parsing 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 alamat IP 9.9.9.1 meluncurkan serangan XSS di isi HTTP POST, hanya isi yang diblokir (oleh aturan 2); header HTTP diteruskan ke backend (oleh aturan 3).

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: evaluatePreconfiguredWaf('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 alamat 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: evaluatePreconfiguredWaf('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 dengan prioritas lebih tinggi yang cocok atau jika tidak ada aturan lain dalam kebijakan. Aturan default otomatis diberi prioritas 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, 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 mengganti 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 penerapan menyediakan hal berikut:

• Kemampuan untuk menulis ekspresi aturan kustom yang dapat mencocokkan berbagai atribut permintaan masuk dari Lapisan 3 hingga Lapisan 7. Google Cloud Armor menyediakan atribut bahasa aturan kustom untuk menulis kondisi kecocokan 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 untuk alamat IP

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

• Dengan menggunakan daftar yang tidak diizinkan untuk alamat IP/CIDR, Anda dapat memblokir alamat IP sumber atau rentang CIDR agar tidak mengakses load balancer yang didukung.

• Dengan menggunakan daftar yang diizinkan untuk 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 daftar yang ditolak.

• Aturan daftar yang ditolak dapat menampilkan kode status HTTP 403 Unauthorized, 404 Access Denied, atau 502 Bad Gateway.

• Aturan tindakan yang melebihi batas dapat menampilkan kode status HTTP 429 Too Many Requests.

Aturan geografi sumber

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 geografis permintaan. Database diperbarui secara rutin. Meskipun kami tidak dapat menjamin irama update tertentu, selama operasi normal, pemetaan yang digunakan Google Cloud Armor diupdate sekitar sekali per minggu.

Pemetaan yang diperbarui harus disebarkan 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, permintaan dari alamat IP sumber yang sama mungkin ditangani secara tidak konsisten selama peluncuran saat pemetaan geolokasi untuk alamat IP sumber telah berubah.

Aturan WAF yang telah dikonfigurasi sebelumnya

Google Cloud Armor menyediakan daftar lengkap aturan WAF yang telah dikonfigurasi sebelumnya berdasarkan OWASP Core Rule Set (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. Mengarahkan ulang permintaan untuk penilaian reCAPTCHA dengan tantangan manual opsional.
2. Mengevaluasi token reCAPTCHA yang dilampirkan dengan permintaan dan menerapkan tindakan yang dikonfigurasi berdasarkan atribut token.
3. Alihkan permintaan ke URL alternatif yang dikonfigurasi dengan kode status 302.
4. Sisipkan header kustom ke permintaan sebelum mem-proxy-kannya ke backend Anda.

Untuk mengetahui 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 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 dan rentang IP dalam kebijakan keamanan karena daftar alamat IP bernama tidak tunduk pada batas jumlah alamat IP per aturan.

Aturan pembatasan kapasitas

Anda dapat menggunakan aturan pembatasan kecepatan untuk melakukan hal berikut:

• Membatasi permintaan per klien berdasarkan nilai minimum yang Anda konfigurasi.
• Melarang sementara klien yang melebihi batas permintaan yang Anda tetapkan untuk durasi yang dikonfigurasi.

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

• Google Cloud Armor hanya menerapkan tindakan pembatasan kecepatan seperti pembatasan atau pelarangan 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 XFF-IP juga 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 perintah gcloud compute security-policies rules update.

Untuk menonaktifkan mode pratinjau, gunakan tanda --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 tersedia di log.

Respons error kustom

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

Untuk mengetahui 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 seberapa detail logging Anda. 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 verbose, lihat Logging verbose. Untuk melihat log Google Cloud Armor, lihat Melihat log.

Pencatatan log permintaan Load Balancer Aplikasi Eksternal

Setiap permintaan HTTP(S) yang dievaluasi berdasarkan kebijakan keamanan Google Cloud Armor dicatat melalui Cloud Logging. Log 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 mencatat permintaan Google Cloud Armor, 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.

Pencatatan 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 Balancer Jaringan proxy. 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 batas pemeriksaan yang dikonfigurasi, hingga 64 kB pertama (8 kB, 16 kB, 32 kB, 48 kB, atau 64 kB) isi POST atau PATCH. Untuk mempelajari lebih lanjut cara mengonfigurasi batas pemeriksaan untuk isi permintaan saat menggunakan aturan WAF yang telah dikonfigurasi sebelumnya, lihat Memperbarui batas pemeriksaan untuk aturan WAF yang telah dikonfigurasi sebelumnya.

Bagian isi permintaan lainnya mungkin berisi payload yang akan cocok dengan tanda tangan aturan WAF, yang mungkin diterima oleh aplikasi Anda. Untuk mengurangi risiko isi permintaan yang ukurannya melebihi batas pemeriksaan yang dikonfigurasi, hingga 64 kB pertama (baik 8 kB, 16 kB, 32 kB, 48 kB, atau 64 kB), lihat Mengurangi risiko pada isi permintaan yang melebihi batas pemeriksaan yang dikonfigurasi.

Google Cloud Armor dapat mengurai dan menerapkan aturan WAF yang telah dikonfigurasi sebelumnya untuk isi POST dan PATCH yang dienkode URL dan diformat JSON secara default (Content-Type = "application/json"), yang 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 mencegah pembuatan channel WebSocket, misalnya, jika daftar alamat IP yang ditolak memblokir alamat IP asal. Namun, transaksi berikutnya di channel tidak sesuai dengan protokol HTTP, dan Google Cloud Armor tidak mengevaluasi pesan apa pun setelah permintaan pertama.

Langkah berikutnya

• Mengonfigurasi kebijakan, aturan, dan ekspresi keamanan
• Mempelajari fitur di tingkat Cloud Armor Enterprise
• Mempelajari daftar alamat IP bernama
• Memecahkan masalah