Memecahkan masalah Google Cloud Armor

Gunakan petunjuk ini untuk memecahkan masalah terkait kebijakan keamanan Google Cloud Armor.

Masalah umum

Melakukan debug kebijakan keamanan

Jika Anda memerlukan informasi tambahan tentang peristiwa tertentu yang memicu aturan yang telah dikonfigurasi sebelumnya, baca Menggunakan logging permintaan, lalu aktifkan logging panjang. Cloud Logging mencatat detail yang lebih tinggi dalam log Anda, yang dapat digunakan untuk menganalisis serta men-debug kebijakan dan aturan Anda.

Traffic diizinkan meskipun aturan penolakan dikonfigurasi dalam kebijakan keamanan Google Cloud Armor

Untuk memperbaikinya, ikuti langkah-langkah berikut:

  1. Pastikan kebijakan keamanan Google Cloud Armor disertakan ke layanan backend target. Misalnya, perintah berikut menjelaskan semua data yang terkait dengan layanan backend BACKEND. Hasil yang ditampilkan harus menyertakan nama kebijakan keamanan Google Cloud Armor yang terkait dengan layanan backend ini.

    gcloud compute backend-services describe BACKEND

  2. Tinjau log HTTP(S) untuk menentukan kebijakan dan aturan yang cocok untuk traffic Anda beserta tindakan terkait. Untuk melihat log, gunakan Cloud Logging.

    Berikut adalah contoh log permintaan yang diizinkan dengan kolom menarik ditandai. Periksa kolom berikut dan pastikan kolom tersebut cocok dengan aturan yang Anda konfigurasikan untuk menolak traffic:

    • configuredAction harus cocok dengan tindakan yang dikonfigurasi dalam aturan.
    • name harus cocok dengan nama kebijakan keamanan Google Cloud Armor yang disertakan pada layanan backend ini.
    • outcome harus cocok dengan configuredAction.
    • priority harus cocok dengan nomor prioritas aturan.
      httpRequest:
   remoteIp: 104.133.0.95
   requestMethod: GET
   requestSize: '801'
   requestUrl: http://74.125.67.38/
   responseSize: '246'
   serverIp: 10.132.0.4
   status: 200
   userAgent: curl/7.35.0
     insertId: ajvis5ev4i60
     internalId:
       projectNumber: '895280006100'
     jsonPayload:
       '@type': type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry
       enforcedSecurityPolicy:
         configuredAction: ACCEPT
         name: mydev-policy-log-test1
         outcome: ACCEPT
         priority: 2147483647
       statusDetails: response_sent_by_backend
     logName: projects/mydev-staging/logs/requests
     resource:
       labels:
         backend_service_name: BACKEND_SERVICE_NAME
         forwarding_rule_name: FORWARDING_RULE_NAME
         project_id: PROJECT_ID
         target_proxy_name: TARGET_HTTP_PROXY_NAME
         url_map_name: URL_MAP_NAME
         zone: global
       type: http_load_balancer
     severity: INFO
     timestamp: '2017-04-18T18:57:05.845960288Z'

  3. Tinjau hierarki aturan untuk memastikan bahwa aturan yang benar telah dicocokkan. Ada kemungkinan bahwa aturan prioritas yang lebih tinggi dengan tindakan izinkan cocok dengan traffic Anda. Gunakan perintah describe pada security-policies di Google Cloud CLI untuk melihat isi kebijakan keamanan Google Cloud Armor.

    Misalnya, contoh berikut menunjukkan bagaimana aturan izinkan prioritas yang lebih tinggi (pada prioritas 100) cocok dengan traffic yang berasal dari alamat IP 1.2.3.4 sehingga mencegah aturan penolakan prioritas yang lebih rendah (pada prioritas 200) memicu dan memblokir traffic.

    gcloud compute security-policies describe POLICY_NAME

    Output: 

      creationTimestamp: '2017-04-18T14:47:58.045-07:00
  description: ''
  fingerprint: Yu5spBjdoC0=
  id: '2560355463394441057'
  kind: compute#securityPolicy
  name: POLICY_NAME
  rules:
  -action: allow
   description: allow high priority rule
   kind: compute#securityPolicyRule
   match:
     srcIpRanges:
     -'1.2.3.4/32'
   preview: false
   priority: 100
  -action: deny
   description: deny lower priority rule
   kind: compute#securityPolicyRule
   match:
     srcIpRanges:
     -'1.2.3.0/24
   preview: false
   priority: 200
  -action: deny
   description: default rule
   kind: compute#securityPolicyRule
   match:
     srcIpRanges:
     -'*'
   preview: false
   priority: 2147483647
   selfLink: http://www.googleapis.com/compute/v1/projects/bigclustertestdev0-devconsole/global/securityPolicies/sp

Aturan yang telah dikonfigurasi menampilkan positif palsu

Deteksi XSS dan SQLi didasarkan pada pencocokan tanda tangan statis pada header permintaan HTTP dan parameter L7 lainnya. Pola ekspresi reguler ini rentan terhadap positif palsu (PP). Anda dapat menggunakan aturan yang telah dikonfigurasi untuk deteksi XSS dan SQLi dalam mode pratinjau, lalu memeriksa log untuk menemukan positif palsu.

Jika menemukan positif palsu, Anda dapat membandingkan konten traffic dengan aturan CRS ModSecurity. Jika aturan tidak valid atau tidak relevan, nonaktifkan menggunakan ekspresi evaluatePreconfiguredExpr, dan tentukan ID aturan dalam argumen exclude ID list.

Setelah meninjau log dan menghapus semua positif palsu (PP), nonaktifkan mode pratinjau.

Untuk menambahkan aturan yang telah dikonfigurasi sebelumnya dalam mode pratinjau:

  1. Buat kebijakan keamanan dengan ekspresi yang telah dikonfigurasi sebelumnya dan disetel dalam mode pratinjau:

    gcloud compute security-policies rules create 1000
   --security-policy POLICY_NAME
   --expression "evaluatePreconfiguredExpr('xss-stable')"
   --action deny-403
   --preview

  2. Tinjau log HTTP(S) untuk kolom permintaan HTTP seperti url dan cookie. Misalnya, requestUrl akan dibandingkan secara positif dengan ID aturan CRS ModSecurity 941180:

    httpRequest:
  remoteIp: 104.133.0.95
  requestMethod: GET
  requestSize: '801'
  requestUrl: http://74.125.67.38/foo?document.cookie=1010"
  responseSize: '246'
  serverIp: 10.132.0.4
  status: 200
  userAgent: curl/7.35.0
insertId: ajvis5ev4i60
internalId:
  projectNumber: '895280006100'
jsonPayload:
  '@type': type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry
  enforcedSecurityPolicy:
    configuredAction: ACCEPT
    name: POLICY_NAME
    outcome: ACCEPT
    priority: 2147483647
    preconfiguredExprIds: [ 'owasp-crs-v030001-id941180-xss' ]
  statusDetails: response_sent_by_backend
logName: projects/mydev-staging/logs/requests
resource:
  labels:
    backend_service_name: BACKEND_SERVICE
    forwarding_rule_name: mydev-forwarding-rule
    project_id: mydev-staging
    target_proxy_name: mydev-target-http-proxy
    url_map_name: mydev-url-map
    zone: global
  type: http_load_balancer
severity: INFO
timestamp: '2017-04-18T18:57:05.845960288Z'

  3. Kecualikan ID aturan CRS ModSecurity 941180 dengan memperbarui aturan dalam kebijakan keamanan Google Cloud Armor:

    gcloud compute security-policies rules update 1000 \
    --security-policy POLICY_NAME \
    --expression "evaluatePreconfiguredExpr('xss-stable', ['owasp-crs-v030001-id941180-xss'])" \
    --action deny-403 \
    --preview

  4. Tinjau log lagi, lalu nonaktifkan mode pratinjau untuk menerapkan aturan.

Klien dengan tanda tangan yang ditolak tidak akan diblokir atau ditolak

Jika Anda menggunakan Google Cloud Armor dengan Cloud CDN, kebijakan keamanan diberlakukan hanya untuk permintaan konten dinamis, cache tidak ditemukan, atau permintaan lain yang ditujukan untuk server asal CDN. Cache ditemukan akan ditampilkan meskipun kebijakan keamanan Google Cloud Armor downstream akan mencegah permintaan tersebut menjangkau server asal CDN.

Memitigasi risiko pada isi POST yang melebihi 8 KB saat menggunakan aturan WAF yang telah dikonfigurasi sebelumnya

Saat aturan WAF yang telah dikonfigurasi sebelumnya dievaluasi dalam kebijakan keamanan Google Cloud Armor, hingga 8 KB dari isi POST akan diperiksa untuk kecocokan tanda tangan dengan aturan WAF. Pendekatan ini memberi Anda pemeriksaan dan perlindungan lapisan 7 latensi rendah, sekaligus mempertahankan ketersediaan untuk pelanggan Google lainnya.

Anda dapat mengurangi risiko dari permintaan POST yang lebih besar dengan membuat aturan dalam kebijakan keamanan untuk memastikan bahwa tidak ada konten yang belum diperiksa yang mencapai backend Anda. Buat aturan untuk menolak traffic yang melebihi 8 KB (8.192 byte) dalam ukuran isi POST. Contoh kode berikut menunjukkan cara membuat aturan ini:

gcloud compute security-policies rules create 10 \
    --security-policy my-policy \
    --expression "int(request.headers['content-length']) > 8192" \
    --action deny-403 \
    --description "Block requests great than 8KB"

Masalah terkait daftar alamat IP bernama

Bagian ini memberikan informasi untuk menyelesaikan masalah dengan daftar alamat IP yang diberi nama.

Alamat IP dalam daftar alamat IP yang telah diberi nama

Alamat IP dalam daftar selalu cocok dengan alamat IP di situs penyedia yang tercantum dalam panduan daftar alamat IP bernama Google Cloud Armor. Jika ada pertanyaan terkait daftar tersebut, hubungi tim Dukungan Cloud.

Alamat IP dalam daftar alamat IP bernama sudah tidak berlaku di Google Cloud Armor

Google Cloud Armor menyinkronkan daftarnya dengan penyedia daftar alamat IP setiap hari. Ada kemungkinan data usang yang tertinggal beberapa jam atau satu hari di belakang data di penyedia. Namun, jika Anda yakin bahwa data lama mengalami keterlambatan lebih dari yang diharapkan, misalnya, lebih dari seminggu, hubungi tim Dukungan Cloud.

Kesulitan membuat kebijakan keamanan yang merujuk ke daftar alamat IP bernama

Anda dapat mencoba membuat kebijakan keamanan yang merujuk ke daftar alamat IP yang telah diberi nama, menggunakan perintah seperti ini:

gcloud compute security-policies rules create 750 \
    --security-policy my \
    --expression "evaluatePreconfiguredExpr('sourceiplist-example')" \
    --action "allow"

Jika perintah gagal, error yang Anda lihat akan terlihat seperti ini:

ERROR: (gcloud.compute.security-policies.rules.create) Could not fetch resource:
 - Invalid value for field 'resource.match.expr': '{  "expression": "evaluatePreconfiguredExpr(\u0027sourceiplist-example\u0027)"}'.
Error parsing Google Cloud Armor rule matcher expression: sourceiplist-example
is not a valid preconfigured expression set.

Pastikan penyedia tertentu didukung, dan nama daftar alamat IP diberikan dengan benar. Anda dapat memeriksanya dengan menggunakan perintah gcloud berikut untuk mencantumkan kumpulan ekspresi yang telah dikonfigurasi sebelumnya:

gcloud compute security-policies list-preconfigured-expression-sets

Traffic diblokir meskipun ada aturan yang telah dikonfigurasi sebelumnya untuk daftar alamat IP bernama yang diizinkan

Anda mungkin mendapati bahwa traffic diblokir dari alamat IP yang ada dalam daftar alamat IP bernama:

  1. Pastikan traffic berasal dari alamat IP yang ada di daftar alamat IP bernama yang diizinkan.

  2. Periksa apakah ada aturan keamanan lain dengan prioritas lebih tinggi yang dapat memblokir traffic. Jika Anda masih melihat masalah tersebut, hubungi tim Dukungan Cloud.

  3. Pastikan kebijakan keamanan dikaitkan ke layanan backend yang benar:

    gcloud compute backend-services describe BACKEND_SERVICE

  4. Periksa aturan yang ada dalam kebijakan keamanan. Contoh:

     gcloud compute security-policies describe POLICY_NAME

    Perintah ini menampilkan informasi yang mirip dengan berikut ini:

    ---
…
name: POLICY_NAME
rules:
-action: allow
 description: allow fastly ip addresses
 kind: compute#securityPolicyRule
 match:
    expr:
      expression: evaluatePreconfiguredExpr('sourceiplist-fastly')
 preview: false
 priority: 100
-action: deny(403)
 description: Default rule, higher priority overrides it
 kind: compute#securityPolicyRule
 match:
    config:
      srcIpRanges:
      -'*'
    versionedExpr: SRC_IPS_V1
 preview: false
 priority: 2147483647
-action: deny(404)
 description: deny altostrat referer
 kind: compute#securityPolicyRule
 match:
    expr:
      expression: request.headers['Referer'].contains('altostrat')
 preview: false
 priority: 50
…

    Kebijakan keamanan sebelumnya berisi tiga aturan: aturan penolakan default, aturan izinkan untuk alamat IP Fastly, dan aturan penolakan untuk perujuk yang berisi altostrat. Prioritasnya masing-masing juga dicantumkan.

  5. Tinjau log untuk menentukan aturan mana yang cocok dengan traffic Anda dan tindakan terkait. Untuk mengetahui informasi tentang logging, lihat Menggunakan Logs Explorer.

    Berikut adalah contoh log:

     httpRequest: {
    referer: "http://www.altostrat.com/"
    remoteIp: "23.230.32.10"
    requestMethod: "HEAD"
    requestSize: "79"
    requestUrl: "http://www.example.com/"
    responseSize: "258"
    status: 404
    userAgent: "Mozilla/5.0"
  }
  …
  jsonPayload: {
    @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
    enforcedSecurityPolicy: {
      configuredAction: "DENY"
      name: "POLICY_NAME"
      outcome: "DENY"
      priority: 50
    }
    statusDetails: "denied_by_security_policy"
  }
  …

    Dari log sebelumnya, permintaan berasal dari 23.230.32.10, yang dicakup oleh daftar alamat IP publik Fastly. Namun, permintaan tersebut dicocokkan dengan aturan penolakan yang memiliki prioritas lebih tinggi, yaitu 50. Membandingkan ini dengan apa yang ada dalam kebijakan keamanan, aturan ini terkait dengan aturan penolakan untuk perujuk yang berisi altostrat. Karena permintaan tersebut memiliki perujuk http://www.altostrat.com/, penerapan aturan keamanan berfungsi dengan benar.

Masalah terkait temuan Security Command Center

Bagian ini berisi informasi tentang masalah terkait temuan Security Command Center.

Kartu Google Cloud Armor tidak muncul di Security Command Center

Aktifkan temuan Google Cloud Armor di antarmuka Security Command Center.

Temuan dari Google Cloud Armor tidak muncul di Security Command Center

Jika temuan dari Google Cloud Armor tidak muncul di Security Command Center, traffic ke layanan backend mungkin tidak memenuhi kriteria untuk memunculkan temuan.

Untuk pertanyaan tentang volume traffic ke backend Anda, periksa statistik permintaan di dasbor Cloud Monitoring pada bagian Kebijakan Keamanan Jaringan.

Temuan terlalu berisik

Untuk mendapatkan bantuan terkait masalah ini, hubungi tim Dukungan Cloud.

Masalah terkait Perlindungan Adaptif Google Cloud Armor

Gunakan petunjuk ini untuk membantu Anda menyelesaikan masalah terkait Perlindungan Adaptif.

Perlindungan Adaptif diaktifkan untuk kebijakan keamanan, tetapi tidak ada log di Cloud Logging

Log Perlindungan Adaptif dibuat secara terpisah dari log permintaan Google Cloud Armor dan muncul di resource yang berbeda dalam Cloud Logging. Log dan peristiwa Perlindungan Adaptif berada di resource Kebijakan Keamanan Jaringan di Cloud Logging. Ada periode pelatihan setidaknya satu jam setelah Perlindungan Adaptif diaktifkan dalam kebijakan keamanan sebelum Perlindungan Adaptif mulai menghasilkan peringatan untuk serangan yang dicurigai. Selama periode pelatihan, Perlindungan Adaptif belajar dari traffic permintaan masuk dan mengembangkan dasar pengukuran yang berbeda untuk setiap layanan backend yang dilindungi oleh kebijakan keamanan tersebut. Perlindungan Adaptif kemudian dapat mengidentifikasi aktivitas yang mencurigakan.

Jika Anda mengaktifkan Perlindungan Adaptif untuk kebijakan keamanan dan Anda tidak mengamati pemberitahuan apa pun setelah periode pelatihan satu jam, hal ini menunjukkan bahwa tidak ada aktivitas yang dapat diidentifikasi sebagai penargetan yang berpotensi berbahaya dari layanan backend mana pun yang terkait dengan kebijakan keamanan tersebut.

Jika potensi serangan atau traffic tidak wajar tetap ada dalam jangka waktu yang lebih lama, melebihi beberapa jam, Perlindungan Adaptif akan mulai menganggap perilaku tersebut sebagai perilaku dasar dan tidak terus memberikan peringatan tentang pola traffic yang serupa. Setelah potensi serangan mereda dan pola traffic kembali ke dasar pengukuran asli, baik karena serangan telah selesai atau Anda memblokirnya dengan aturan Google Cloud Armor yang sesuai, Perlindungan Adaptif akan memberi tahu tentang perilaku traffic mendatang yang dianggap sebagai keberangkatan dari garis dasar.

Perlindungan Adaptif menganalisis traffic yang seharusnya diizinkan melalui kebijakan keamanan Google Cloud Armor. Jika Anda menetapkan aturan default untuk menolak akses dengan daftar traffic yang diizinkan dan dibatasi, Perlindungan Adaptif hanya akan mendeteksi aktivitas berbahaya pada traffic yang lulus evaluasi sesuai dengan daftar yang diizinkan.

Ada terlalu banyak pemberitahuan atau terlalu banyak log di Cloud Logging dari Perlindungan Adaptif

Notifikasi Perlindungan Adaptif memberikan skor keyakinan, yang menunjukkan seberapa kuat model Perlindungan Adaptif mengidentifikasi aktivitas yang terdeteksi sebagai anomali dan berpotensi serangan. Anda dapat memfilter entri spesifik log melalui Cloud Logging untuk hanya menampilkan (atau meneruskan ke downstream) pemberitahuan yang memiliki skor keyakinan di atas nilai minimum tertentu.

Perlindungan Adaptif menyediakan mekanisme untuk melaporkan notifikasi sebagai positif palsu, yang dijelaskan di bagian Pemantauan, masukan, dan pelaporan error peristiwa. Perhatikan bahwa pelaporan positif palsu mungkin tidak menyebabkan perubahan langsung pada notifikasi Perlindungan Adaptif. Seiring waktu, model Perlindungan Adaptif mempelajari bahwa pola traffic tersebut normal dan dapat diterima, dan Perlindungan Adaptif berhenti memberi tahu pola ini.

Jika pemberitahuan Perlindungan Adaptif terlalu sering pada subset layanan backend dalam kebijakan keamanan, hal ini mungkin menunjukkan bahwa traffic normal layanan backend ini memiliki fluktuasi signifikan yang terus-menerus diidentifikasi oleh Perlindungan Adaptif sebagai perilaku yang tidak wajar. Anda dapat membuat kebijakan keamanan terpisah tanpa mengaktifkan Perlindungan Adaptif dan mengaitkan layanan backend ini dengan kebijakan keamanan baru.

Insiden tertentu yang dilaporkan oleh Perlindungan Adaptif dianggap sebagai positif palsu atau tidak relevan

Perlindungan Adaptif menyediakan mekanisme untuk melaporkan notifikasi positif palsu. Ikuti prosedur yang dijelaskan di bagian Memantau, memberikan masukan, dan melaporkan error peristiwa. Perhatikan bahwa pelaporan positif palsu mungkin tidak menyebabkan perubahan langsung pada notifikasi Perlindungan Adaptif. Seiring waktu, model Perlindungan Adaptif akan mempelajari bahwa pola traffic tersebut normal dan dapat diterima, dan Perlindungan Adaptif berhenti memberi tahu pola tersebut.

Bagaimana cara mengetahui bahwa kebijakan keamanan edge saya diterapkan?

Anda dapat memeriksa tindakan yang diambil pada kebijakan keamanan edge dengan memeriksa dasbor pemantauan, metrik pemantauan, atau logging per permintaan.

Dasbor monitoring

Cloud Monitoring tersedia di halaman Kebijakan Keamanan Jaringan di bagian Monitoring. Anda dapat menggunakan perincian berdasarkan kebijakan keamanan di halaman tersebut untuk mengukur jumlah permintaan yang diizinkan dan ditolak oleh kebijakan keamanan edge yang dikonfigurasi. Anda juga dapat memeriksa pengelompokan berdasarkan layanan backend untuk men-debug layanan backend tertentu. Untuk mengetahui detail tentang dasbor Cloud Monitoring, lihat Memantau kebijakan keamanan Google Cloud Armor.

Metrik pemantauan

Metrik mentah yang mengukur permintaan yang diizinkan dan ditolak tersedia untuk kebijakan keamanan edge. Untuk informasi selengkapnya, lihat Memantau metrik untuk kebijakan keamanan.

Logging per permintaan

Keputusan kebijakan keamanan edge dicatat ke log permintaan load balancing di bagian enforcedEdgeSecurityPolicy. Ini terpisah dari enforcedSecurityPolicy, yang merekam keputusan kebijakan keamanan backend.

Pengelolaan bot

Bagian ini berisi informasi tentang cara memecahkan masalah terkait pengelolaan bot.

Pengguna tidak dikecualikan seperti yang diharapkan

Anda mungkin telah mengonfigurasi aturan kebijakan keamanan dengan tindakan pengalihan untuk penilaian reCAPTCHA Enterprise, dan menemukan bahwa beberapa pengguna yang menurut Anda sah tidak dikecualikan seperti yang diharapkan. Ikuti langkah-langkah di bawah ini untuk pemecahan masalah.

Pertama, periksa log per permintaan untuk melihat apakah ada aturan kebijakan keamanan dengan prioritas lebih tinggi yang cocok dengan traffic, dengan tindakan yang berbeda. Secara khusus, cari kolom configured_action dan outcome. Perlu diketahui bahwa agar pengguna dapat dikecualikan, setidaknya diperlukan dua permintaan. Permintaan awal tidak disertai dengan cookie pengecualian, dan permintaan lanjutan akan disertai dengan cookie pengecualian jika pengguna lulus dalam penilaian reCAPTCHA Enterprise. Oleh karena itu, diperlukan minimal dua entri log.

  • Jika Anda melihat GOOGLE_RECAPTCHA sebagai tindakan yang dikonfigurasi, dan REDIRECT sebagai hasil, permintaan tersebut telah dialihkan untuk penilaian reCAPTCHA Enterprise;
  • Jika Anda melihat GOOGLE_RECAPTCHA sebagai tindakan yang dikonfigurasi, dan ACCEPT sebagai hasilnya, permintaan tersebut dikecualikan dari pengalihan untuk penilaian reCAPTCHA Enterprise.
  • Jika Anda melihat nilai yang berbeda dalam kolom di atas, artinya aturan dengan tindakan yang berbeda akan dicocokkan. Dalam hal ini, diharapkan bahwa pengguna tidak dialihkan atau dikecualikan.

Kedua, ada beberapa persyaratan dari pihak pengguna yang dikecualikan dari pengalihan untuk penilaian reCAPTCHA Enterprise.

  1. Pengguna harus menggunakan browser.
  2. Browser harus mengaktifkan JavaScript agar halaman pengalihan dapat dimuat dengan benar dengan menyematkan JavaScript reCAPTCHA Enterprise.
  3. Browser harus mengaktifkan cookie untuk mengizinkan setelan dan penambahan otomatis cookie pengecualian.
  4. Pengguna harus lulus penilaian reCAPTCHA Enterprise; misalnya, mereka harus menyelesaikan tantangan pop-up jika ada.

Pengguna yang tidak dapat memenuhi persyaratan di atas tidak akan menerima pengecualian, meskipun aturan dengan tindakan pengalihan untuk penilaian reCAPTCHA Enterprise cocok.

Ketiga, penilaian reCAPTCHA Enterprise hanya dijalankan saat halaman pengalihan yang menyematkan JavaScript reCAPTCHA Enterprise dirender. Oleh karena itu, pengalihan untuk penilaian reCAPTCHA Enterprise hanya berlaku untuk permintaan yang mengharapkan respons yang mengarah ke render halaman penuh. Permintaan lainnya, seperti pemuatan aset di dalam halaman, atau permintaan yang berasal dari skrip tersemat yang tidak mengharapkan respons ditampilkan, tidak akan mendapatkan penilaian reCAPTCHA Enterprise. Oleh karena itu, sebaiknya terapkan tindakan ini dengan kondisi pencocokan untuk jalur URL yang memenuhi kondisi ini.

Misalnya, anggaplah Anda memiliki halaman web berisi elemen tersemat seperti gambar, link ke halaman lain, dan skrip. Anda tidak ingin menerapkan tindakan pengalihan untuk penilaian reCAPTCHA Enterprise untuk jalur URL yang menghosting gambar, atau yang seharusnya diakses oleh skrip yang tidak mengharapkan rendering halaman penuh. Sebagai gantinya, Anda dapat menerapkan tindakan pengalihan untuk penilaian reCAPTCHA Enterprise untuk jalur URL yang menghosting halaman web, seperti halaman utama atau halaman web tertaut lainnya.

Terakhir, jika halaman pengalihan berhasil dirender, periksa Developer Tool yang disediakan oleh browser untuk melihat apakah cookie pengecualian telah ditetapkan, dan apakah cookie tersebut dilampirkan dalam permintaan berikutnya untuk situs yang sama. Untuk mendapatkan bantuan lebih lanjut, Anda dapat menghubungi tim Dukungan Cloud.

Masalah terkait pembatasan kapasitas

Traffic tidak di-throttle seperti yang diharapkan

Anda mungkin mendapati bahwa alamat IP klien mengirim traffic tingkat tinggi ke suatu aplikasi dengan kecepatan yang melebihi nilai minimum yang Anda tetapkan, tetapi traffic tersebut tidak dibatasi seperti yang diharapkan. Ikuti langkah-langkah berikut untuk menyelidiki masalahnya.

Pertama, konfirmasi apakah aturan dengan prioritas yang lebih tinggi mengizinkan traffic dari alamat IP tersebut. Periksa log untuk melihat apakah aturan ALLOW dipicu untuk alamat IP. Ini dapat berupa aturan ALLOW saja, atau dalam aturan THROTTLE atau RATE_BASED_BAN lainnya.

Jika Anda menemukan aturan dengan prioritas lebih tinggi, lakukan salah satu hal berikut:

  1. Ubah prioritas untuk memastikan aturan pembatasan kapasitas memiliki prioritas yang lebih tinggi, dengan menetapkan nilai numerik yang lebih rendah.
  2. Kecualikan alamat IP dari ekspresi yang cocok dalam aturan yang memiliki prioritas lebih tinggi.

Masalahnya mungkin juga nilai minimum ditetapkan secara tidak benar. Jika ini terjadi, permintaan akan dicocokkan secara akurat, tetapi tindakan yang sesuai akan dipicu. Periksa log untuk mengonfirmasi bahwa hal ini yang terjadi, lalu kurangi nilai minimum dalam aturan Anda.

Terakhir, alamat IP mungkin tidak cocok dengan aturan throttle atau pemblokiran berbasis tarif. Untuk memperbaikinya, periksa apakah ada kesalahan dalam kondisi pencocokan, lalu ubah kondisi kecocokan aturan ke nilai yang benar.

Langkah selanjutnya