Ringkasan pembatasan kapasitas

Google Cloud Armor menyediakan 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 menghabiskan resource aplikasi.
• Lindungi instance aplikasi Anda dari lonjakan permintaan klien yang tidak menentu dan tidak dapat diprediksi.

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

Google Cloud Armor memiliki dua jenis aturan berbasis kapasitas:

1. Throttling: Anda dapat menerapkan batas permintaan maksimum per klien atau di semua klien dengan membatasi setiap klien ke nilai minimum yang dikonfigurasi pengguna.
2. Larangan berbasis kapasitas: Anda dapat menilai permintaan batas yang cocok dengan aturan berdasarkan per klien, lalu melarang klien tersebut untuk sementara selama jangka waktu yang dikonfigurasi jika klien tersebut melebihi nilai minimum yang dikonfigurasi pengguna.

Saat mengonfigurasi aturan dengan tindakan larangan berbasis kapasitas, Anda tidak dapat mengubahnya menjadi tindakan pelambatan nanti. Namun, saat mengonfigurasi aturan dengan tindakan throttling, Anda dapat mengubahnya menjadi tindakan larangan berbasis kapasitas nanti. Untuk informasi selengkapnya, lihat Pembatasan kapasitas berdasarkan beberapa kunci.

Google Cloud Armor menerapkan nilai minimum pembatasan kapasitas ke setiap backend terkait. Misalnya, jika Anda memiliki dua layanan backend dan mengonfigurasi aturan pembatasan rate 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 dengan 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 pembatasan kapasitas:

• ALL: Satu kunci untuk semua klien yang permintaannya memenuhi kondisi cocok 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 terpotong menjadi 128 byte pertama dari nilai header. Jenis kunci secara default adalah SEMUA jika tidak ada header tersebut, atau jika Anda mencoba menggunakan jenis kunci ini dengan Network Load Balancer 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 ditetapkan secara default ke 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 terpotong menjadi 128 byte pertama dari nilai cookie. Jenis kunci secara default ditetapkan ke 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 terpotong menjadi 128 byte pertama.
• SNI: Server name indication dalam sesi TLS permintaan HTTPS. Nilai kunci terpotong menjadi 128 byte pertama. Jenis kunci secara default ditetapkan ke ALL pada sesi HTTP.
• REGION_CODE: Negara/wilayah asal permintaan.
• TLS_JA3_FINGERPRINT: Sidik jari TLS/SSL JA3 jika klien terhubung menggunakan HTTPS, HTTP/2, atau HTTP/3. Jika tidak tersedia, jenis kunci akan ditetapkan secara default ke ALL. Untuk mengetahui informasi selengkapnya tentang JA3, lihat referensi bahasa aturan.
• USER_IP: Alamat IP klien asal, yang disertakan dalam header yang dikonfigurasi di bagian userIpRequestHeaders dan nilainya diisi oleh proxy upstream. Jika tidak ada konfigurasi userIpRequestHeaders, atau alamat IP tidak dapat di-resolve darinya, jenis kunci akan ditetapkan secara default ke IP. Untuk informasi selengkapnya, lihat referensi bahasa aturan.

Anda dapat menggunakan kunci sebelumnya satu per satu, atau 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 Pemberitahuan Privasi Google Cloud. Data kunci pembatasan kapasitas tidak diperlakukan sebagai Data Pelanggan. Jika beban kerja Anda tunduk pada rezim 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 kecocokan dalam aturan. Batas minimum dikonfigurasi sebagai jumlah permintaan yang ditentukan dalam interval waktu yang ditentukan.

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

Jika kapasitas traffic klien kurang dari atau sama dengan rate_limit_threshold_count, permintaan akan mengikuti conform_action, yang selalu merupakan tindakan allow. Permintaan tersebut diizinkan melalui kebijakan keamanan dan diizinkan untuk mencapai tujuannya. Jika tingkat traffic klien melebihi rate_limit_threshold_count 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.

Anda menetapkan parameter ini untuk mengontrol tindakan:

• rate_limit_threshold_count: Jumlah permintaan per klien yang diizinkan dalam interval waktu yang ditentukan. Nilai minimumnya adalah 1 dan nilai maksimumnya 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: Jika permintaan melebihi rate_limit_threshold_count, Google Cloud Armor akan menerapkan exceed_action yang dikonfigurasi. Kemungkinan nilai 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 dialihkan untuk penilaian reCAPTCHA 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: Jenis untuk tindakan pengalihan, 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 saat jumlah permintaan berada di bawah rate_limit_threshold_count. Ini selalu merupakan tindakan allow.

Melarang klien berdasarkan frekuensi permintaan

Tindakan rate_based_ban dalam aturan memungkinkan Anda menerapkan batas per klien untuk melarang klien yang melampaui batas untuk sementara dengan menerapkan exceed_action yang dikonfigurasi untuk semua permintaan dari klien selama jangka waktu yang dapat dikonfigurasi. Batas dikonfigurasi sebagai jumlah permintaan yang ditentukan dalam interval waktu yang ditentukan. Anda dapat melarang traffic untuk sementara selama periode 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 waktu 1.200 detik (20 menit). Jika klien mengirim 2.500 permintaan dalam waktu 1.200 detik, Google Cloud Armor akan menerapkan exceed_action ke traffic dari klien tersebut yang melebihi nilai minimum 2.000 permintaan hingga 1.200 detik penuh berlalu dan selama jumlah detik tambahan yang Anda tetapkan sebagai periode durasi larangan. Misalnya, jika periode durasi larangan ditetapkan ke 3600, traffic dari klien akan dilarang selama 3.600 detik (satu jam) setelah akhir interval nilai minimum.

Jika kapasitas permintaan klien berada di bawah nilai minimum batas kapasitas, permintaan tersebut akan langsung diizinkan untuk melanjutkan ke layanan backend. Jika rasio traffic klien melebihi rate_limit_threshold_count yang ditentukan, Google Cloud Armor akan menerapkan exceed_action ke semua permintaan masuk dari klien selama sisa interval nilai minimum dan selama ban_duration_sec detik berikutnya, terlepas dari apakah nilai minimum terlampaui atau tidak.

Dengan konfigurasi ini, klien selamat datang yang hanya sesekali melebihi kapasitas permintaan yang diizinkan dapat diblokir secara tidak sengaja. Untuk mencegah hal ini, dan hanya melarang klien yang sering melebihi kapasitas permintaan, Anda dapat secara opsional melacak total permintaan klien terhadap konfigurasi nilai minimum tambahan, sebaiknya lebih lama, yang disebut ban_threshold_count. Dalam mode ini, klien akan diblokir untuk ban_duration_sec yang dikonfigurasi hanya jika tingkat permintaan melampaui ban_threshold_count yang dikonfigurasi. Jika rasio permintaan tidak melebihi ban_threshold_count, permintaan akan terus dibatasi ke rate_limit_threshold_count. Untuk tujuan ban_threshold_count, total permintaan dari klien, yang terdiri dari semua permintaan masuk sebelum throttling, dihitung.

Parameter ini mengontrol tindakan aturan rate_based_ban:

• rate_limit_threshold_count: Jumlah permintaan per klien yang diizinkan dalam interval waktu yang ditentukan. Nilai minimumnya adalah 1 permintaan dan nilai maksimumnya 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: Jika permintaan melebihi rate_limit_threshold_count, Google Cloud Armor akan menerapkan exceed_action yang dikonfigurasi. Kemungkinan nilai 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 dialihkan untuk penilaian reCAPTCHA 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: Jenis untuk tindakan pengalihan, 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 saat jumlah permintaan berada di bawah rate_limit_threshold_count. Ini selalu merupakan tindakan allow.
• ban_threshold_count: Ini adalah jumlah permintaan per klien yang diizinkan dalam interval waktu yang ditentukan, yang melampaui batas permintaan 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_threshold_interval_sec: Jumlah detik dalam interval waktu untuk ban_threshold_count Anda. Nilainya harus 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700, atau 3600 detik.
• ban_duration_sec: Ini adalah jumlah detik tambahan yang membuat klien diblokir setelah periode interval_sec berakhir. Nilainya 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, nilai minimum default adalah 500 permintaan selama setiap interval satu menit (rate_limit_threshold_count 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 jumlah maksimum permintaan yang masuk per alamat IP dan per menit selama satu hari atau lebih di layanan backend Anda yang dilindungi Google Cloud Armor.

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

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

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

Penerapan nilai minimum

Batas yang dikonfigurasi untuk throttling dan larangan 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 membatasi kapasitas setiap kunci ke nilai minimum yang dikonfigurasi, sehingga layanan backend Anda mungkin mengalami volume traffic gabungan lintas region yang dua kali lipat dari nilai minimum yang dikonfigurasi. Jika nilai minimum 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 wilayah tempat layanan tersebut di-deploy.

Penting untuk diperhatikan bahwa batas kapasitas yang diterapkan adalah perkiraan dan mungkin tidak sepenuhnya akurat dibandingkan dengan nilai minimum yang dikonfigurasi. Selain itu, dalam kasus yang jarang terjadi, karena perilaku pemilihan rute internal, pembatasan kapasitas mungkin diterapkan di lebih banyak region daripada region tempat Anda melakukan deployment, sehingga memengaruhi akurasi. Oleh karena itu, sebaiknya gunakan pembatasan kapasitas hanya untuk mitigasi penyalahgunaan atau mempertahankan ketersediaan aplikasi dan layanan, bukan untuk menerapkan kuota atau persyaratan 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

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

Langkah selanjutnya

• Mengonfigurasi pembatasan kapasitas