Ringkasan pembatasan kapasitas

Google Cloud Armor memberikan kemampuan untuk membantu melindungi aplikasi Google Cloud Anda dari berbagai serangan Lapisan 3 dan Lapisan 7. Aturan berbasis tarif 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 kehabisan resource aplikasi.
• Lindungi instance aplikasi Anda dari lonjakan yang tidak menentu dan tidak dapat diprediksi dalam jumlah permintaan klien.

Selain itu, saat resource disajikan dengan volume traffic tinggi dari sejumlah kecil klien, Anda dapat mencegah klien lain terpengaruh oleh lonjakan traffic yang besar dari klien yang jumlahnya sedikit, sehingga resource Anda dapat menangani permintaan sebanyak mungkin.

Google Cloud Armor memiliki dua jenis aturan berbasis tarif:

1. Throttle: Anda dapat menerapkan batas permintaan maksimum per klien atau pada semua klien dengan throttling masing-masing klien ke nilai minimum yang dikonfigurasi pengguna.
2. Pemblokiran berbasis tarif: Anda dapat memberi rating permintaan batas yang cocok dengan aturan per klien, lalu memblokir klien tersebut untuk sementara selama periode waktu yang dikonfigurasi jika melebihi batas yang dikonfigurasi pengguna.

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

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

Mengidentifikasi klien untuk pembatasan kapasitas

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

• SEMUA: Satu kunci untuk semua klien yang permintaannya memenuhi kondisi pencocokan aturan.
• IP: Kunci unik untuk setiap alamat IP sumber klien yang permintaannya memenuhi kondisi pencocokan aturan.
• HTTP_HEADER: Kunci unik untuk setiap nilai header HTTP unik yang namanya dikonfigurasi. Nilai kunci dipotong menjadi 128 byte pertama dari nilai header. Jenis kunci akan ditetapkan secara default ke ALL jika header tersebut tidak ada, 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 dalam header HTTP X-Forwarded-For. Jenis kunci secara default disetel ke alamat IP jika header tersebut tidak ada, 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 terpotong menjadi 128 byte pertama dari nilai cookie. Jika cookie tersebut tidak ada, jenis kunci akan ditetapkan secara default ke ALL jika Anda mencoba menggunakan jenis kunci ini dengan Load Balancer Jaringan proxy eksternal.
• HTTP_PATH: Jalur URL permintaan HTTP. Nilai kunci dipotong menjadi 128 byte pertama.
• SNI: Indikasi nama server di sesi TLS permintaan HTTPS. Nilai kunci dipotong menjadi 128 byte pertama. Secara default, jenis kunci disetel ke SEMUA pada sesi HTTP.
• REGION_CODE: Negara/wilayah tempat permintaan berasal.
• TLS_JA3_FINGERPRINT: Sidik jari TLS/SSL JA3 jika klien terhubung menggunakan HTTPS, HTTP/2, atau HTTP/3. Jika tidak tersedia, jenis kunci ditetapkan secara default ke ALL. Untuk mengetahui informasi lebih lanjut tentang JA3, baca referensi bahasa aturan.
• USER_IP: Alamat IP klien asal, yang disertakan dalam header yang dikonfigurasi di userIpRequestHeaders dan yang nilainya diisi oleh proxy upstream. Jika tidak ada konfigurasi userIpRequestHeaders, atau alamat IP tidak dapat diselesaikan dari konfigurasi tersebut, jenis kunci akan ditetapkan secara default ke IP. Untuk mengetahui informasi selengkapnya, baca referensi bahasa aturan.

Anda dapat menggunakan kunci sebelumnya secara terpisah, atau Anda dapat menerapkan pembatasan kapasitas berdasarkan kombinasi maksimal 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 utama yang membatasi kapasitas diklasifikasikan sebagai Data Layanan, yang diproses seperti yang dijelaskan dalam Pemberitahuan Privasi Google Cloud. Data utama pembatasan kapasitas tidak diperlakukan sebagai Data Pelanggan. Jika beban kerja Anda tunduk pada sistem peraturan atau persyaratan kepatuhan lainnya yang mewajibkan transparansi akses atau persetujuan akses, tinjau jenis kunci yang nilainya mungkin berisi informasi sensitif.

Membatasi traffic

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

Misalnya, Anda dapat menetapkan nilai minimum permintaan ke 2.000 permintaan dalam 1.200 detik (20 menit). Jika klien mengirim 2.500 permintaan dalam periode 1.200 detik, sekitar 20% dari traffic klien akan dibatasi hingga volume permintaan yang diizinkan berada pada atau di bawah nilai minimum yang dikonfigurasi.

Anda menetapkan parameter ini untuk mengontrol tindakan:

• rate_limit_threshold: Jumlah permintaan per klien yang diizinkan dalam interval waktu yang ditentukan. Nilai minimum adalah 1 dan nilai maksimum adalah 10.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, Google Cloud Armor akan menerapkan exceed_action yang dikonfigurasi. Nilai yang memungkinkan untuk exceed_action adalah sebagai berikut:
  • deny(status): Permintaan ditolak dan kode error yang ditentukan ditampilkan (nilai yang valid adalah 403, 404, 429, dan 502). Sebaiknya gunakan kode respons 429 (Too Many Requests).
  • redirect: Permintaan akan dialihkan untuk penilaian reCAPTCHA Enterprise atau ke URL lain, berdasarkan parameter exceed_redirect_options.
• exceed_redirect_options: Jika exceed_action adalah redirect, gunakan parameter ini untuk menentukan tindakan pengalihan:
  • type: Ketik untuk tindakan pengalihan, baik GOOGLE_RECAPTCHA atau EXTERNAL_302.
  • target: Target URL untuk tindakan pengalihan. Hanya berlaku jika type adalah EXTERNAL_302.
• conform_action: Ini adalah tindakan yang dilakukan ketika jumlah permintaan berada di bawah rate_limit_threshold. Tindakan ini selalu berupa tindakan allow.

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

Memblokir klien berdasarkan rasio permintaan

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

Misalnya, Anda dapat menetapkan nilai minimum permintaan ke 2.000 permintaan dalam 1.200 detik (20 menit). Jika klien mengirim 2.500 permintaan dalam 1.200 detik, Google 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 untuk jumlah detik tambahan yang Anda tetapkan sebagai periode durasi pemblokiran. Misalnya, jika periode durasi pemblokiran disetel ke 3600, traffic dari klien akan diblokir selama 3.600 detik (satu jam) setelah batas interval tersebut berakhir.

Parameter ini mengontrol tindakan aturan rate_based_ban:

• rate_limit_threshold: Jumlah permintaan per klien yang diizinkan dalam interval waktu yang ditentukan. 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, Google Cloud Armor akan menerapkan exceed_action yang dikonfigurasi. Nilai yang memungkinkan untuk exceed_action adalah sebagai berikut:
  • deny(status): Permintaan ditolak dan kode error yang ditentukan ditampilkan. Nilai yang valid untuk kode error adalah 403, 404, 429, dan 502. Sebaiknya gunakan kode respons 429 (Too Many Requests).
  • redirect: Permintaan akan dialihkan untuk penilaian reCAPTCHA Enterprise atau ke URL lain, berdasarkan parameter exceed_redirect_options.
• exceed_redirect_options: Jika exceed_action adalah redirect, gunakan parameter ini untuk menentukan tindakan pengalihan:
  • type: Ketik untuk tindakan pengalihan, baik GOOGLE_RECAPTCHA atau EXTERNAL_302.
  • target: Target URL untuk tindakan pengalihan. Hanya berlaku jika type adalah EXTERNAL_302.
• conform_action: Ini adalah tindakan yang dilakukan ketika jumlah permintaan berada di bawah rate_limit_threshold. Tindakan ini selalu berupa tindakan allow.
• ban_threshold_count: Ini adalah jumlah permintaan per klien yang diblokir oleh Google Cloud Armor. Jika ditentukan, kunci akan diblokir untuk ban_duration_sec yang dikonfigurasi jika jumlah permintaan yang melebihi rate_limit_threshold_count juga melebihi ban_threshold_count ini.
• ban_duration_sec: Ini adalah jumlah detik tambahan saat klien diblokir setelah periode interval_sec berlalu. Nilainya harus 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700, atau 3600 detik.

Jika rasio permintaan klien berada di bawah nilai minimum batas kapasitas, hal ini akan langsung memungkinkan permintaan untuk dilanjutkan ke layanan backend. Saat rasio traffic klien melebihi rate_limit_threshold yang ditetapkan, Google 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 nilai minimum tersebut terlampaui atau tidak.

Dengan konfigurasi ini, Anda dapat secara tidak sengaja memblokir klien sambutan yang hanya terkadang melebihi rasio permintaan yang diizinkan. Untuk mencegah hal ini, dan hanya memblokir klien yang sering melebihi rasio permintaan, Anda dapat secara opsional melacak total permintaan klien terhadap konfigurasi ambang batas tambahan yang lebih panjang yang disebut ban_threshold_count. Dalam mode ini, klien diblokir untuk ban_duration_sec yang dikonfigurasi hanya jika rasio permintaan melewati ban_threshold_count yang dikonfigurasi. Jika rasio permintaan tidak melebihi ban_threshold_count, permintaan akan terus di-throttle ke rate_limit_threshold. Untuk tujuan ban_threshold_count, total permintaan dari klien, yang terdiri dari semua permintaan masuk sebelum throttling, akan dihitung.

Kebijakan keamanan pembatasan kapasitas default

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

1. Aktifkan Cloud Logging dan buat kueri untuk jumlah maksimum permintaan yang diterima per alamat IP dan per menit dalam satu hari atau lebih di layanan backend yang dilindungi Google Cloud Armor.

   Misalnya, Anda yakin bahwa 99% traffic jaringan yang Anda terima tidak boleh terpengaruh oleh aturan batas kapasitas. Dalam skenario ini, sebaiknya Anda menetapkan nilai minimum batas kapasitas ke persentil ke-99 dari jumlah maksimum permintaan per alamat IP dan distribusi per menit yang dihasilkan dari data Cloud Logging.

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

   1. Aktifkan penyimpanan ke cache (Cloud CDN atau Media CDN).
   2. Tingkatkan interval waktu throttle (permintaan yang 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 Google Cloud Armor memungkinkan Anda melakukannya dengan memblokir semua klien yang melebihi batas terlalu sering dalam jendela yang ditentukan pengguna. Misalnya, klien yang melebihi batas 10 kali dalam satu menit dapat diblokir selama 15 menit.

Penerapan batas

Batas yang dikonfigurasi untuk throttling dan pemblokiran berbasis tarif diterapkan secara independen di setiap region Google Cloud tempat layanan backend HTTP(S) di-deploy. Misalnya, jika layanan Anda di-deploy di dua region, kapasitas masing-masing dari dua region akan membatasi setiap kunci ke nilai minimum yang dikonfigurasi, sehingga layanan backend Anda mungkin mengalami volume traffic gabungan lintas region yang dua kali nilai minimum 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, Anda dapat 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 tempatnya di-deploy.

Penting untuk diperhatikan bahwa batas kapasitas yang diterapkan merupakan perkiraan dan mungkin tidak sepenuhnya akurat dibandingkan dengan nilai minimum yang dikonfigurasi. Selain itu, dalam kasus yang jarang terjadi, karena perilaku perutean internal, ada kemungkinan pembatasan kapasitas diterapkan di lebih banyak region daripada region tempat Anda di-deploy, sehingga memengaruhi akurasi. Karena alasan ini, sebaiknya gunakan pembatasan kapasitas hanya untuk mitigasi penyalahgunaan atau pemeliharaan ketersediaan aplikasi dan layanan, bukan untuk memberlakukan persyaratan kuota atau pemberian lisensi yang ketat.

Logging

Cloud Logging mencatat nama kebijakan keamanan, prioritas aturan batas 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 Enterprise

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

Langkah selanjutnya

• Mengonfigurasi pembatasan kapasitas