Ringkasan pembatasan kapasitas

Google Cloud Armor menyediakan kemampuan untuk membantu melindungi Google Cloud aplikasi Anda dari berbagai serangan Lapisan 3 dan Lapisan 7. Aturan berbasis kapasitas membantu Anda melindungi aplikasi dari volume permintaan yang besar, yang membanjiri instance Anda dan memblokir akses untuk pengguna yang sah.

Pembatasan kapasitas dapat melakukan hal berikut:

• Mencegah klien tertentu menghabiskan resource aplikasi.
• Melindungi instance aplikasi Anda dari lonjakan yang tidak teratur dan tidak dapat diprediksi terkait kapasitas permintaan klien.

Selain itu, saat resource menerima traffic dalam volume tinggi dari sejumlah kecil klien, Anda dapat mencegah klien lain terkena dampak lonjakan traffic yang besar dari sejumlah kecil klien tersebut, sehingga resource Anda dapat menangani sebanyak mungkin permintaan.

Cloud Armor memiliki dua jenis aturan berbasis kapasitas:

• Throttle. Anda dapat menerapkan batas permintaan maksimum per klien atau untuk semua klien dengan men-throttle klien tertentu hingga batas yang dikonfigurasi pengguna.
• Pemblokiran berbasis kapasitas. Anda dapat membatasi kapasitas permintaan yang cocok dengan aturan untuk setiap klien, lalu memblokir klien tersebut untuk sementara, selama jangka waktu yang dikonfigurasi, jika klien melampaui batas yang dikonfigurasi pengguna.

Saat mengonfigurasi aturan dengan tindakan pemblokiran berbasis kapasitas, Anda tidak dapat mengubahnya menjadi tindakan throttle nanti. Namun, saat mengonfigurasi aturan dengan tindakan throttle, Anda dapat mengubahnya menjadi tindakan pemblokiran berbasis kapasitas nanti. Untuk mengetahui informasi selengkapnya, lihat Mengubah aturan throttle menjadi aturan pemblokiran berbasis kapasitas.

Cloud Armor menerapkan ambang pembatasan kapasitas ke setiap backend terkait. Misalnya, jika Anda memiliki dua layanan backend dan mengonfigurasi aturan pembatasan kapasitas dengan batas 1.000 permintaan per menit, setiap layanan backend dapat menerima 1.000 permintaan per menit sebelum Cloud Armor menerapkan tindakan aturan.

Anda dapat melihat pratinjau efek aturan pembatasan kapasitas dalam kebijakan keamanan dengan menggunakan mode pratinjau dan memeriksa log permintaan Anda.

Mengidentifikasi klien untuk pembatasan kapasitas

Cloud Armor mengidentifikasi setiap klien untuk pembatasan kapasitas dengan menggunakan jenis kunci berikut guna menggabungkan permintaan dan menerapkan pembatasan kapasitas:

• ALL: satu kunci untuk semua permintaan yang memenuhi kondisi kecocokan aturan.
• IP: kunci unik untuk setiap alamat IP sumber klien yang permintaannya memenuhi kondisi kecocokan aturan.
• HTTP_HEADER: kunci unik untuk setiap nilai header HTTP unik yang namanya dikonfigurasi. Nilai kunci dipangkas menjadi 128 byte pertama dari nilai header. Jenis kunci defaultnya adalah ALL jika tidak ada header tersebut, atau jika Anda mencoba menggunakan jenis kunci ini dengan Load Balancer Jaringan proxy eksternal.
• XFF_IP: kunci unik untuk setiap alamat IP sumber asli klien, yaitu alamat IP pertama dalam daftar IP yang ditentukan di header HTTP X-Forwarded-For. Jenis kunci defaultnya adalah alamat IP jika tidak ada header tersebut, jika nilainya bukan alamat IP yang valid, atau jika Anda mencoba menggunakan jenis kunci ini dengan Load Balancer Jaringan proxy eksternal.
• HTTP_COOKIE: kunci unik untuk setiap nilai cookie HTTP yang namanya dikonfigurasi. Nilai kunci dipangkas menjadi 128 byte pertama dari nilai cookie. Jenis kunci defaultnya adalah SEMUA jika tidak ada cookie tersebut, atau jika Anda mencoba menggunakan jenis kunci ini dengan Load Balancer Jaringan proxy eksternal.
• HTTP_PATH: jalur URL permintaan HTTP. Nilai kunci dipangkas menjadi 128 byte pertama.
• SNI: indikasi nama server dalam sesi TLS permintaan HTTPS. Nilai kunci dipangkas menjadi 128 byte pertama. Jenis kunci defaultnya adalah ALL pada sesi HTTP.
• REGION_CODE: negara atau region asal permintaan.
• TLS_JA4_FINGERPRINT: Sidik jari TLS/SSL JA4 jika klien terhubung menggunakan HTTPS, HTTP/2, atau HTTP/3. Jika tidak tersedia, jenis kunci defaultnya adalah ALL. Untuk mengetahui informasi selengkapnya tentang JA4, lihat referensi bahasa aturan.
• TLS_JA3_FINGERPRINT: Sidik jari TLS/SSL JA3 jika klien terhubung menggunakan HTTPS, HTTP/2, atau HTTP/3. Jika tidak tersedia, jenis kunci defaultnya adalah ALL.
• USER_IP: Alamat IP klien asal, yang disertakan dalam header yang dikonfigurasi di userIpRequestHeaders dan nilainya diisi oleh proxy upstream. Jika tidak ada konfigurasi userIpRequestHeaders, atau alamat IP tidak dapat di-resolve dari konfigurasi tersebut, jenis kunci akan ditetapkan secara default ke IP. Untuk mengetahui informasi selengkapnya, lihat referensi bahasa aturan.

Anda dapat menggunakan setiap kunci di atas secara terpisah, atau Anda dapat menerapkan pembatasan kapasitas berdasarkan kombinasi hingga tiga kunci. Anda dapat menggunakan beberapa kunci HTTP-HEADER atau HTTP-COOKIE, dan hanya satu dari setiap jenis kunci lainnya. Untuk mengetahui informasi selengkapnya, lihat Pembatasan kapasitas berdasarkan beberapa kunci.

Catatan: Data kunci pembatasan kapasitas diklasifikasikan sebagai data layanan, yang diproses seperti yang dijelaskan dalam Google Cloud Pemberitahuan Privasi. Data kunci pembatasan kapasitas tidak dianggap sebagai data pelanggan. Jika workload Anda tunduk pada rezim peraturan atau persyaratan kepatuhan lainnya yang memerlukan transparansi akses atau persetujuan akses, tinjau jenis kunci yang nilainya mungkin berisi informasi sensitif.

Memilih antara aturan pembatasan kapasitas throttle dan aturan pemblokiran berbasis kapasitas

Aturan pembatasan kapasitas rate-based ban dan throttle di Cloud Armor berbeda dalam cara menangani traffic yang melebihi batas yang dikonfigurasi.

• rate_based_ban: saat kapasitas permintaan melebihi batas yang ditentukan, Cloud Armor akan memblokir semua permintaan lebih lanjut dari sumber atau target permintaan tersebut selama jangka waktu tertentu.
• throttle: alih-alih memblokir semua traffic, throttling membatasi kapasitas permintaan hingga nilai maksimum yang ditentukan. Throttling memungkinkan beberapa traffic diteruskan, tetapi dengan kapasitas yang dikontrol dan mencegah kelebihan beban.

Aturan yang paling tepat bergantung pada kebutuhan spesifik Anda dan jenis traffic yang Anda tangani. Misalnya, jika Anda menghadapi serangan DDoS, pemblokiran berbasis kapasitas mungkin lebih tepat untuk memblokir traffic berbahaya dengan cepat. Atau, jika Anda mengalami lonjakan traffic yang valid secara tiba-tiba, throttling mungkin menjadi opsi yang lebih baik untuk mempertahankan ketersediaan layanan sekaligus mencegah kelebihan beban.

Throttling traffic

Tindakan throttle dalam aturan memungkinkan Anda menerapkan batas permintaan per klien untuk melindungi layanan backend. Aturan ini menerapkan batas untuk membatasi traffic dari setiap klien yang memenuhi kondisi kecocokan dalam aturan. Batas dikonfigurasi sebagai jumlah permintaan tertentu dalam interval waktu tertentu.

Misalnya, Anda dapat menetapkan batas permintaan menjadi 2.000 permintaan dalam 1.200 detik (20 menit). Jika klien mengirim 2.500 permintaan dalam periode 1.200 detik, sekitar 20% traffic klien akan di-throttle hingga volume permintaan yang diizinkan sama dengan atau di bawah batas yang dikonfigurasi.

Jika kapasitas traffic klien sama dengan atau di bawah rate_limit_threshold_count, permintaan akan mengikuti conform_action, yang selalu merupakan tindakan allow. Permintaan diizinkan melalui kebijakan keamanan dan diizinkan untuk mencapai tujuannya. Jika kapasitas traffic klien melebihi rate_limit_threshold_count yang ditentukan, Cloud Armor akan menerapkan exceed_action, yang dapat berupa deny atau redirect, untuk permintaan yang melebihi batas selama sisa interval batas.

Anda menetapkan parameter ini untuk mengontrol tindakan:

• rate_limit_threshold_count: jumlah permintaan per klien yang diizinkan dalam interval waktu tertentu. Nilai minimum adalah 1, dan nilai maksimum adalah 1.000.000.
  • interval_sec: jumlah detik dalam interval waktu. Nilainya harus 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700, atau 3600 detik.
• exceed_action: saat permintaan melebihi rate_limit_threshold_count, Cloud Armor akan menerapkan exceed_action yang dikonfigurasi. Kemungkinan nilai untuk exceed_action adalah sebagai berikut:
  • deny(status): permintaan ditolak dan kode status yang ditentukan akan ditampilkan. Nilai yang valid adalah: 403 Forbidden, 404 Page Not Found, 429 Too Many Requests, dan 502 Bad Gateway. Sebaiknya gunakan kode status 429 Too Many Requests.
  • redirect: permintaan dialihkan untuk penilaian reCAPTCHA atau ke URL lain, berdasarkan parameter exceed_redirect_options.
• exceed_redirect_options: saat exceed_action adalah redirect, gunakan parameter ini untuk menentukan tindakan pengalihan:
  • type: jenis untuk tindakan pengalihan, GOOGLE_RECAPTCHA atau EXTERNAL_302.
  • target: URL target untuk tindakan pengalihan. Hanya berlaku jika type adalah EXTERNAL_302.
• conform_action: tindakan yang dilakukan saat jumlah permintaan berada di bawah rate_limit_threshold_count. Tindakan ini selalu merupakan tindakan allow.

Memblokir klien berdasarkan kapasitas permintaan

Tindakan rate_based_ban dalam aturan memungkinkan Anda menerapkan batas per klien untuk memblokir sementara klien yang melampaui batas dengan menerapkan exceed_action yang dikonfigurasi untuk semua permintaan dari klien selama jangka waktu yang dapat dikonfigurasi. Batas dikonfigurasi sebagai jumlah permintaan tertentu dalam interval waktu tertentu. Anda dapat memblokir traffic untuk jangka waktu yang dikonfigurasi pengguna ('ban_duration_sec'), asalkan traffic cocok dengan kondisi kecocokan yang ditentukan dan melampaui batas yang dikonfigurasi.

Misalnya, Anda dapat menetapkan batas permintaan menjadi 2.000 permintaan dalam 1.200 detik (20 menit). Jika klien mengirim 2.500 permintaan dalam waktu 1.200 detik, Cloud Armor akan menerapkan exceed_action ke traffic dari klien tersebut yang melebihi batas 2.000 permintaan hingga 1.200 detik penuh telah berlalu dan selama beberapa detik tambahan yang Anda tetapkan sebagai periode durasi pemblokiran. Jika periode durasi pemblokiran ditetapkan ke 3600, misalnya, traffic dari klien akan diblokir selama 3.600 detik (satu jam) setelah akhir interval batas.

Jika kapasitas permintaan klien berada di bawah ambang pembatasan kapasitas, permintaan dapat segera dilanjutkan ke layanan backend. Jika kapasitas traffic klien melebihi rate_limit_threshold_count yang ditentukan, Cloud Armor akan menerapkan exceed_action ke semua permintaan masuk dari klien selama sisa interval batas dan selama ban_duration_sec detik berikutnya, terlepas dari apakah batas terlampaui atau tidak.

Dengan konfigurasi ini, ada kemungkinan untuk secara tidak sengaja memblokir klien yang diinginkan, yang hanya sesekali melebihi kapasitas permintaan yang diizinkan. Untuk mencegah hal ini, dan memblokir hanya klien yang sering melebihi kapasitas permintaan, Anda dapat secara opsional melacak total permintaan klien terhadap konfigurasi batas tambahan, sebaiknya yang lebih lama, yang disebut ban_threshold_count. Dalam mode ini, klien diblokir untuk ban_duration_sec yang dikonfigurasi, hanya jika kapasitas permintaan melampaui ban_threshold_count yang dikonfigurasi. Jika kapasitas permintaan tidak melebihi ban_threshold_count, permintaan akan terus di-throttle ke rate_limit_threshold_count. Untuk tujuan ban_threshold_count, total permintaan dari klien, yang terdiri dari semua permintaan masuk sebelum throttling, akan dihitung.

Parameter ini mengontrol tindakan aturan rate_based_ban:

• rate_limit_threshold_count: jumlah permintaan per klien yang diizinkan dalam interval waktu tertentu. Nilai minimum adalah 1 permintaan dan nilai maksimum adalah 10.000 permintaan.
  • interval_sec: jumlah detik dalam interval waktu. Nilainya harus 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700, atau 3600 detik.
• exceed_action: saat permintaan melebihi rate_limit_threshold_count, Cloud Armor akan menerapkan exceed_action yang dikonfigurasi. Kemungkinan nilai untuk exceed_action adalah sebagai berikut:
  • deny(status): permintaan ditolak dan kode status yang ditentukan akan ditampilkan. Nilai yang valid adalah: 403 Forbidden, 404 Page Not Found, 429 Too Many Requests, dan 502 Bad Gateway. Sebaiknya gunakan kode status 429 Too Many Requests.
  • redirect: permintaan dialihkan untuk penilaian reCAPTCHA atau ke URL lain, berdasarkan parameter exceed_redirect_options.
• exceed_redirect_options: saat exceed_action adalah redirect, gunakan parameter ini untuk menentukan tindakan pengalihan:
  • type: jenis untuk tindakan pengalihan, GOOGLE_RECAPTCHA atau EXTERNAL_302.
  • target: URL target untuk tindakan pengalihan. URL target ini hanya berlaku jika type adalah EXTERNAL_302.
• conform_action: tindakan yang dilakukan saat jumlah permintaan berada di bawah rate_limit_threshold_count. Tindakan ini selalu merupakan tindakan allow.
• ban_threshold_count: jumlah permintaan per klien yang diizinkan dalam interval waktu tertentu, yang menyebabkan Cloud Armor memblokir permintaan. Jika ditentukan, kunci akan diblokir selama ban_duration_sec yang dikonfigurasi jika jumlah permintaan yang melebihi rate_limit_threshold_count juga melebihi ban_threshold_count ini.
  • ban_threshold_interval_sec: jumlah detik dalam interval waktu untuk ban_threshold_count Anda. Nilai ban_threshold_interval_sec harus berupa 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700, atau 3600 detik.
• ban_duration_sec: jumlah detik tambahan saat klien diblokir setelah periode interval_sec berakhir. Nilai ban_duration_sec harus 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700, atau 3600 detik.

Kebijakan keamanan pembatasan kapasitas default

Saat Anda mengonfigurasi kebijakan keamanan default selama pembuatan load balancer, batas defaultnya adalah 500 permintaan selama setiap interval satu menit (masing-masing rate_limit_threshold_count dan interval_sec dari 500 dan 60). Jika Anda ingin memilih batas yang berbeda, sebaiknya gunakan langkah-langkah berikut untuk menyesuaikan parameter:

1. Aktifkan Cloud Logging dan kueri jumlah maksimum permintaan yang masuk per alamat IP dan per menit selama satu hari atau lebih di layanan backend yang dilindungi Cloud Armor.

   Misalnya, anggaplah Anda yakin bahwa 99% traffic jaringan yang Anda terima tidak terpengaruh oleh aturan pembatasan kapasitas. Dalam skenario ini, sebaiknya tetapkan ambang pembatasan kapasitas Anda ke persentil ke-99 dari jumlah maksimum permintaan per alamat IP dan per menit dari distribusi yang dibuat dari data Cloud Logging.

2. Jika Anda masih melihat aturan pembatasan kapasitas default memblokir traffic yang valid, pertimbangkan langkah-langkah tambahan berikut:

   1. Aktifkan caching (Cloud CDN atau Media CDN).
   2. Tingkatkan interval waktu throttle (permintaan diterima per beberapa menit, bukan per 60 detik).
   3. Anda dapat memblokir klien untuk mengurangi dampak serangan lebih lanjut setelah gelombang awal. Tindakan rate_based_ban Cloud Armor memungkinkan Anda memblokir semua klien yang terlalu sering melampaui batas dalam jangka waktu yang ditentukan pengguna. Misalnya, klien yang melampaui batas 10 kali dalam satu menit dapat diblokir selama 15 menit.

Penerapan batas

Batas yang dikonfigurasi untuk throttling dan pemblokiran berbasis kapasitas diterapkan secara independen di setiap region Google Cloud tempat layanan backend HTTP(S) Anda di-deploy. Misalnya, jika layanan Anda di-deploy di dua region, setiap region akan menerapkan ambang pembatasan kapasitas yang dikonfigurasi ke setiap kunci, sehingga layanan backend Anda mungkin mengalami volume traffic gabungan lintas region dua kali lipat dari batas yang dikonfigurasi. Jika batas yang dikonfigurasi ditetapkan ke 5.000 permintaan, layanan backend mungkin menerima 5.000 permintaan dari satu region dan 5.000 permintaan dari region kedua.

Namun, untuk alamat IP jenis kunci, wajar untuk mengasumsikan bahwa traffic dari alamat IP klien yang sama diarahkan ke region yang paling dekat dengan region tempat backend Anda di-deploy. Dalam hal ini, pembatasan kapasitas dapat dianggap diterapkan di tingkat layanan backend, terlepas dari region tempat layanan tersebut di-deploy.

Penting untuk diperhatikan bahwa pembatasan kapasitas yang diterapkan adalah perkiraan dan mungkin tidak sepenuhnya akurat dibandingkan dengan batas yang dikonfigurasi. Selain itu, dalam kasus yang jarang terjadi, karena perilaku perutean internal, pembatasan kapasitas mungkin diterapkan di lebih banyak region daripada region tempat Anda men-deploy, sehingga memengaruhi akurasi. Untuk alasan ini, sebaiknya Anda menggunakan pembatasan kapasitas, hanya untuk mengurangi penyalahgunaan atau mempertahankan ketersediaan aplikasi dan layanan, bukan untuk menerapkan kuota yang ketat atau persyaratan pemberian lisensi.

Pembatasan kapasitas berdasarkan REGION_CODE mempertimbangkan region asal permintaan dan tidak mempertimbangkan region backend di layanan backend, terlepas dari jenisnya. Backend mencakup grup instance, semua jenis grup endpoint jaringan (NEG) yang didukung oleh load balancer, dan bucket Cloud Storage. Backend yang didukung dapat ditemukan di Ringkasan kebijakan keamanan.

Logging

Cloud Logging mencatat nama kebijakan keamanan, prioritas aturan pembatasan kapasitas yang cocok, ID aturan, tindakan terkait, dan informasi lainnya dalam log permintaan Anda. Untuk mengetahui informasi selengkapnya tentang logging, lihat Menggunakan logging permintaan.

Integrasi dengan reCAPTCHA

Anda dapat menerapkan pembatasan kapasitas ke beberapa resource reCAPTCHA untuk mengurangi penyalahgunaan token dan membatasi penggunaan ulang token. Resource ini mencakup token tindakan, token sesi, dan cookie pengecualian. Untuk mengetahui informasi selengkapnya tentang penggunaan pembatasan kapasitas dengan reCAPTCHA, lihat ringkasan pengelolaan bot.

Respons error kustom

Anda dapat menerapkan respons error kustom ke pembatasan kapasitas di Cloud Armor, termasuk traffic throttle dan rate_based_ban. Jika batas ini diterapkan, pesan error kustom akan dikirim kepada pengguna akhir. Selain itu, saat Anda menggunakan Load Balancer Aplikasi eksternal global, Anda dapat mengonfigurasi respons error kustom untuk kode status HTTP tertentu yang dihasilkan oleh load balancer atau instance backend.

Untuk mengetahui informasi selengkapnya tentang respons error kustom, lihat Ringkasan respons error kustom. Untuk mengonfigurasi respons error kustom, lihat Mengonfigurasi respons error kustom.

Cloud Armor dengan Cloud Service Mesh

Catatan: Tindakan pembatasan kapasitas fairshare hanya tersedia untuk aturan dalam kebijakan keamanan layanan internal.

Anda dapat mengonfigurasi kebijakan keamanan layanan internal untuk mesh layanan guna menerapkan pembatasan kapasitas sisi server global per klien, sehingga membantu Anda membagikan kapasitas layanan yang tersedia secara adil dan mengurangi risiko klien yang berperilaku buruk atau berbahaya, sehingga membebani layanan Anda secara berlebihan. Anda melampirkan kebijakan keamanan ke kebijakan endpoint Cloud Service Mesh untuk menerapkan pembatasan kapasitas pada traffic masuk di sisi server. Namun, Anda tidak dapat mengonfigurasi kebijakan keamanan Google Cloud Armor jika menggunakan perutean traffic TCP. Untuk mengetahui informasi selengkapnya tentang cara menggunakan Cloud Armor dengan Cloud Service Mesh, lihat Mengonfigurasi pembatasan kapasitas dengan Cloud Armor.

Langkah berikutnya

• Mengonfigurasi pembatasan kapasitas