Google Cloud Armor 문제 해결

Google Cloud Armor 보안 정책 문제를 해결하려면 다음 안내를 따르세요.

일반적인 문제

보안 정책 디버깅

어떤 특정 이벤트가 사전 구성된 규칙을 트리거하는지에 대한 추가 정보가 필요한 경우 요청 로깅 사용을 참조하여 상세 로깅을 사용 설정합니다. Cloud Logging은 정책과 규칙을 분석하고 디버깅하는 데 사용할 수 있는 높은 수준의 세부정보를 로그에 기록합니다.

Google Cloud Armor 보안 정책에 구성된 거부 규칙에도 불구하고 트래픽이 허용됨

이를 해결하려면 다음 단계를 따르세요.

  1. Google Cloud Armor 보안 정책이 대상 백엔드 서비스에 연결되어 있는지 확인합니다. 예를 들어 다음 명령어는 백엔드 서비스 BACKEND에 연결된 모든 데이터를 설명합니다. 반환된 결과에는 이 백엔드 서비스에 연결된 Google Cloud Armor 보안 정책의 이름이 포함되어야 합니다.

    gcloud compute backend-services describe BACKEND
    
  2. HTTP(S) 로그를 검토하여 관련 작업과 함께 트래픽과 일치하는 정책과 규칙을 결정합니다. 로그를 확인하려면 Cloud Logging을 사용합니다.

    다음은 관심 있는 필드가 강조표시된 허용 요청의 샘플 로그입니다. 다음 필드를 확인하고 트래픽을 거부하도록 구성한 규칙과 일치하는지 확인합니다.

    • configuredAction은 규칙에 구성된 작업과 일치해야 합니다.
    • name은 이 백엔드 서비스에 연결된 Google Cloud Armor 보안 정책의 이름과 일치해야 합니다.
    • outcomeconfiguredAction과 일치해야 합니다.
    • priority는 규칙의 우선순위 번호와 일치해야 합니다.
      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. 규칙의 계층 구조를 검토하여 올바른 규칙이 일치하는지 확인합니다. 허용 작업이 있는 우선순위가 높은 규칙이 트래픽과 일치할 수 있습니다. Google Cloud CLI의 security-policies에서 describe 명령어를 사용하여 Google Cloud Armor 보안 정책의 콘텐츠를 확인하세요.

    예를 들어 다음 예시에서는 우선순위가 높은 허용 규칙(우선순위 100)이 1.2.3.4 IP 주소에서 들어오는 트래픽과 일치하여 우선순위가 낮은 거부 규칙(우선순위 200)이 트래픽을 트리거하고 차단하는 것을 방지하는 방법을 보여줍니다.

    gcloud compute security-policies describe POLICY_NAME
    

    출력:

      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
    

사전 구성된 규칙이 거짓양성을 반환합니다.

XSS 및 SQLi 감지는 HTTP 요청 헤더 및 기타 L7 매개변수의 정적 서명 일치를 기반으로 합니다. 이러한 정규 표현식 패턴에는 거짓양성 경향이 있습니다. 미리보기 모드에서 사전 구성된 규칙을 XSS 및 SQLi 감지에 사용하면 로그에서 거짓양성을 확인할 수 있습니다.

거짓양성을 발견하면 트래픽 콘텐츠를 ModSecurity CRS 규칙과 비교할 수 있습니다. 규칙이 유효하지 않거나 관련이 없으면 evaluatePreconfiguredExpr 표현식을 사용하여 규칙을 사용 중지하고 exclude ID list 인수에 규칙의 ID를 지정합니다.

로그를 검토하고 모든 거짓양성을 삭제한 후 미리보기 모드를 중지합니다.

미리보기 모드에서 사전 구성된 규칙을 추가하는 방법:

  1. 미리 구성된 표현식이 미리보기 모드로 설정된 보안 정책을 작성합니다.

    gcloud compute security-policies rules create 1000
       --security-policy POLICY_NAME
       --expression "evaluatePreconfiguredExpr('xss-stable')"
       --action deny-403
       --preview
    
  2. urlcookie와 같은 HTTP 요청 필드의 HTTP(S) 로그를 검토합니다. 예를 들어 requestUrl은 ModSecurity CRS 규칙 ID 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. Google Cloud Armor 보안 정책에서 규칙을 업데이트하여 ModSecurity CRS 규칙 ID 941180을 제외합니다.

    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. 로그를 다시 검토한 후 미리보기 모드를 사용 중지하여 규칙을 구현합니다.

서명이 거부된 클라이언트는 차단되거나 거부되지 않음

Cloud CDN과 함께 Google Cloud Armor를 사용하는 경우 보안 정책은 동적 콘텐츠, 캐시 부적중 또는 CDN 원본 서버를 대상으로 지정된 기타 요청에 대해서만 적용됩니다. 다운스트림 Google Cloud Armor 보안 정책으로 인해 해당 요청이 CDN 원본 서버에 도달하지 못하더라도 캐시 적중은 제공됩니다.

사전 구성된 WAF 규칙을 사용할 때 8KB를 초과하는 POST 본문에서 위험 완화

Google Cloud Armor 보안 정책에서 사전 구성된 WAF 규칙을 평가하면 최대 8KB의 POST 본문의 서명 일치를 WAF 규칙을 기준으로 검사합니다. 이 접근 방식을 사용하면 다른 Google 고객의 가용성을 유지하면서 짧은 지연 시간 레이어 7 검사 및 보호를 제공합니다.

검사되지 않은 콘텐츠가 백엔드에 도달하지 않도록 보안 정책에 규칙을 만들면 대규모 POST 요청으로 인한 위험을 완화할 수 있습니다. POST 본문 크기가 8KB(8,192바이트)를 초과하는 트래픽을 거부하는 규칙을 만듭니다. 다음 코드 샘플은 이 규칙을 만드는 방법을 보여줍니다.

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"

명명된 IP 주소 목록 관련 문제

이 섹션에서는 명명된 IP 주소 목록의 문제 해결에 대한 정보를 제공합니다.

명명된 IP 주소 목록 내 IP 주소

목록의 IP 주소는 항상 Google Cloud Armor의 명명된 IP 주소 목록 가이드에 나열된 제공업체 웹사이트의 IP 주소와 일치합니다. 목록과 관련해 궁금한 점이 있으면 Cloud 지원팀에 문의하세요.

Google Cloud Armor에서 명명된 IP 주소 목록 내 IP 주소가 오래됨

Google Cloud Armor는 목록을 IP 주소 목록 제공업체와 매일 동기화합니다. 따라서 제공업체의 데이터보다 몇 시간 또는 하루가 늦은 오래된 데이터가 있을 수 있습니다. 예상보다 많이 늦은(예: 일주일 초과) 오래된 데이터가 있으면 Cloud 지원팀에 문의하세요.

명명된 IP 주소 목록을 참조하는 보안 정책을 만드는 데 문제가 있음

다음과 같은 명령어를 사용하여 명명된 IP 주소 목록을 참조하는 보안 정책을 생성해 볼 수 있습니다.

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

명령어가 실패하면 다음과 같은 오류가 발생합니다.

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.

특정 제공업체가 지원되는지, IP 주소 목록 이름이 올바르게 입력되었는지 확인합니다. 다음 gcloud 명령어를 사용하여 현재 사전 구성된 표현식 집합을 나열하면 이를 확인할 수 있습니다.

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

명명된 IP 주소 허용 목록의 사전 구성된 규칙이 있음에도 불구하고 트래픽이 차단됨

명명된 IP 주소 목록에 있는 IP 주소에서 들어오는 트래픽이 차단되는 경우가 있습니다.

  1. 명명된 IP 주소 허용 목록에 있는 IP 주소에서 들어오는 트래픽인지 확인합니다.

  2. 트래픽을 차단할 수 있는 우선순위가 더 높은 다른 보안 규칙이 있는지 확인합니다. 문제가 계속 발생하면 Cloud 지원팀에 문의하세요.

  3. 보안 정책이 올바른 백엔드 서비스에 연결되어 있는지 확인합니다.

    gcloud compute backend-services describe BACKEND_SERVICE
    
  4. 보안 정책에 있는 규칙을 확인하세요. 예를 들면 다음과 같습니다.

     gcloud compute security-policies describe POLICY_NAME
    

    이 명령어는 다음과 유사한 정보를 반환합니다.

    ---
    …
    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
    …
    

    이전 보안 정책에는 기본 거부 규칙, Fastly IP 주소에 대한 허용 규칙, altostrat가 포함된 리퍼러의 거부 규칙이 포함되어 있습니다. 각각의 우선순위도 나열됩니다.

  5. 로그를 검토하여 트래픽 및 관련 작업과 일치하는 규칙을 결정합니다. 로깅에 대한 자세한 내용은 로그 탐색기 사용을 참조하세요.

    다음은 로그 예시입니다.

     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"
      }
      …
    

    이전 로그에서 요청은 23.230.32.10에서 들어오며 Fastly 공개 IP 주소 목록이 적용됩니다. 하지만 요청은 우선순위가 50으로 지정된 거부 규칙과 일치합니다. 이를 보안 정책의 내용과 비교하면 규칙이 altostrat가 포함된 리퍼러의 거부 규칙에 해당합니다. 요청에 http://www.altostrat.com/ 리퍼러가 있으므로 보안 규칙이 올바르게 작동하고 있습니다.

Security Command Center 결과 관련 문제

이 섹션에는 Security Command Center 발견 항목의 문제에 관한 정보가 포함되어 있습니다.

Google Cloud Armor 카드가 Security Command Center에 나타나지 않음

Security Command Center 인터페이스에서 Google Cloud Armor 결과를 사용 설정합니다.

Google Cloud Armor 발견 항목이 Security Command Center에 나타나지 않음

Google Cloud Armor 발견 항목이 Security Command Center에 나타나지 않으면 백엔드 서비스에 대한 트래픽이 발견 항목 기준을 충족하지 못할 수 있습니다.

백엔드의 트래픽 볼륨과 관련된 궁금한 점이 있으면 네트워크 보안 정책의 Cloud Monitoring 대시보드에서 요청 통계를 확인하세요.

결과에 노이즈가 너무 많음

이 문제에 대한 도움이 필요한 경우 Cloud 지원팀에 문의하세요.

Google Cloud Armor Adaptive Protection 문제

Adaptive Protection 관련 문제 해결을 위해서는 다음 안내를 따르세요.

보안 정책에 Adaptive Protection을 사용 설정해도 Cloud Logging에 로그가 표시되지 않음

Adaptive Protection 로그는 Google Cloud Armor 요청 로그와 별개로 생성되며 Cloud Logging에서 다른 리소스에 표시됩니다. Adaptive Protection 로그 및 이벤트는 Cloud Logging에서 네트워크 보안 정책 리소스에 있습니다. Adaptive Protection이 의심되는 공격에 대해 알림을 생성하려면 보안 정책에 Adaptive Protection을 사용 설정한 후 최소 1시간 이상의 학습 기간이 필요합니다. 학습 기간 중에는 Adaptive Protection이 수신 요청 트래픽을 학습하고 해당 보안 정책으로 보호되는 각 백엔드 서비스에 대해 고유한 기준선을 개발합니다. 그런 다음 Adaptive Protection이 의심스러운 활동을 식별할 수 있습니다.

보안 정책에 Adaptive Protection을 사용 설정하고 1시간 학습 기간이 지나도 알림이 관측되지 않으면, 해당 보안 정책과 관련된 백엔드 서비스를 대상으로 하는 잠재적으로 악의적으로 식별할 수 있는 활동이 없음을 의미합니다.

잠재적인 공격 또는 악의적인 트래픽이 몇 시간을 지나서 오랫동안 지속되면 Adaptive Protection이 해당 동작을 기준선 동작으로 간주하고 유사한 트래픽 패턴에 대해 더 이상 알림을 표시하지 않습니다. 공격이 종결되었거나 적절한 Google Cloud Armor 규칙을 사용해서 이를 차단했기 때문에 잠재적인 공격이 줄어들고 트래픽 패턴이 원래 기준선으로 돌아간 다음에는 Adaptive Protection이 기준선과 다르다고 간주되는 이후의 트래픽 동작에 대해 알림을 표시합니다.

Adaptive Protection은 Google Cloud Armor 보안 정책을 통해 허용되는 트래픽을 분석합니다. 제한적인 트래픽 허용 목록을 사용해서 액세스를 거부하도록 기본 규칙을 설정한 경우에는 Adaptive Protection이 허용 목록에 따라 평가를 통과한 트래픽에 대해서만 악의적인 활동을 감지합니다.

Cloud Logging에서 Adaptive Protection으로 알림 또는 로그가 너무 많이 표시됨

Adaptive Protection 알림은 Adaptive Protection 모델에서 감지된 활동이 악의적이고 잠재적으로 공격일 가능성을 나타내는 신뢰도 점수를 제공합니다. Cloud Logging를 통해 로그의 특정 항목으로 필터링해서 신뢰도 점수가 특정 기준을 넘는 알림만 표시(또는 다운스트림으로 전달)할 수 있습니다.

Adaptive Protection은 모니터링, 피드백, 이벤트 오류 보고에 설명된 대로 알림을 거짓양성으로 보고할 수 있는 메커니즘을 제공합니다. 거짓양성 보고는 Adaptive Protection 알림에 즉각적인 변화를 가져오지 않을 수 있습니다. Adaptive Protection 모델은 시간이 지남에 따라 천천히 그러한 트래픽 패턴이 정상이고 허용 가능하다는 것을 학습하고 이러한 패턴에 대한 알림 표시를 중지합니다.

Adaptive Protection 알림이 보안 정책의 백엔드 서비스 하위 집합에 너무 빈번하게 나타나면, 이러한 백엔드 서비스의 정상 트래픽 변동폭이 너무 커서 Adaptive Protection에서 이상 동작으로 계속 식별되는 것일 수 있습니다. Adaptive Protection을 사용 설정하지 않은 상태로 별개의 보안 정책을 만들고 이러한 백엔드 서비스를 새로운 보안 정책에 연결할 수 있습니다.

Adaptive Protection에서 보고되는 특정 사고가 거짓양성으로 간주되거나 관련성이 없음

Adaptive Protection은 거짓양성 알림 보고를 위한 메커니즘을 제공합니다. 모니터링, 피드백, 이벤트 오류 보고에 설명된 절차를 따르세요. 거짓양성 보고는 Adaptive Protection 알림에 즉각적인 변화를 가져오지 않을 수 있습니다. Adaptive Protection 모델은 시간이 지남에 따라 천천히 그러한 트래픽 패턴이 정상이고 허용 가능하다는 것을 학습하고 이러한 패턴에 대한 알림 표시를 중지합니다.

에지 보안 정책이 시행되고 있는지 어떻게 알 수 있나요?

모니터링 대시보드, 측정항목 모니터링, 요청별 로깅을 확인하여 에지 보안 정책에서 수행되는 작업을 확인할 수 있습니다.

모니터링 대시보드

Cloud Monitoring은 모니터링네트워크 보안 정책 페이지에서 사용할 수 있습니다. 이 페이지에서 보안 정책별 분석을 사용하여 구성된 에지 보안 정책에서 허용 및 거부된 요청 수를 측정할 수 있습니다. 또한 백엔드 서비스별 분석을 통해 특정 백엔드 서비스를 디버깅할 수 있습니다. Cloud Monitoring 대시보드에 대한 자세한 내용은 Google Cloud Armor 보안 정책 모니터링을 참조하세요.

측정항목 모니터링

허용 및 거부된 요청을 측정하는 원시 측정항목을 에지 보안 정책에 사용할 수 있습니다. 자세한 내용은 보안 정책의 측정항목 모니터링을 참조하세요.

요청별 로깅

에지 보안 정책 결정은 enforcedEdgeSecurityPolicy 아래의 부하 분산 요청 로그에 로깅됩니다. 이는 백엔드 보안 정책 결정을 캡처하는 enforcedSecurityPolicy와 별개입니다.

봇 관리

이 섹션에는 봇 관리와 관련된 문제 해결에 대한 정보가 포함되어 있습니다.

사용자가 예상대로 제외되지 않음

reCAPTCHA Enterprise 평가의 리디렉션 작업을 통해 보안 정책 규칙을 구성했을 수 있으며 합법적이라고 생각되는 일부 사용자가 예상대로 제외되지 않았음을 확인할 수 있습니다. 문제를 해결하려면 아래 단계를 따르세요.

먼저 요청별 로그를 확인하여 작업이 서로 다르지만 트래픽과 일치하는 우선순위가 더 높은 보안 정책 규칙이 있는지 확인합니다. 특히 configured_action 필드와 outcome 필드를 찾습니다. 사용자를 제외하려면 2개 이상의 요청이 필요합니다. 초기 요청은 예외 쿠키 없이 제공되며 후속 요청은 사용자가 reCAPTCHA Enterprise 평가를 통과하면 예외 쿠키와 함께 제공됩니다. 따라서 2개 이상의 로그 항목이 필요합니다.

  • GOOGLE_RECAPTCHA가 구성된 작업으로 표시되고 REDIRECT가 결과로 표시되면 요청이 reCAPTCHA Enterprise 평가를 위해 리디렉션된 것입니다.
  • GOOGLE_RECAPTCHA가 구성된 작업으로 표시되고 ACCEPT가 결과로 표시되면 요청이 reCAPTCHA Enterprise 평가를 위해 리디렉션되는 대상에서 제외된 것입니다.
  • 위 필드에 여러 값이 표시되면 다른 작업을 수행하는 규칙과 일치된 것입니다. 이 경우 사용자는 리디렉션되거나 제외되지 않습니다.

둘째, reCAPTCHA Enterprise 평가의 리디렉션 대상에서 제외되기 위해 사용자 쪽에서 충족해야 하는 몇 가지 요구사항이 있습니다.

  1. 사용자가 브라우저를 사용하고 있어야 합니다.
  2. 브라우저에서 reCAPTCHA Enterprise 자바스크립트가 삽입된 리디렉션 페이지를 제대로 로드하려면 자바스크립트를 사용 설정해야 합니다.
  3. 브라우저에서 쿠키를 사용 설정하여 예외 쿠키의 설정 및 자동 연결을 허용해야 합니다.
  4. 사용자가 reCAPTCHA Enterprise 평가를 통과해야 합니다. 예를 들어 팝업 로그인 질문이 있으면 해결해야 합니다.

위의 요구사항을 하나도 충족하지 못하는 사용자는 reCAPTCHA Enterprise 평가에 대한 리디렉션 작업을 수행하는 규칙과 일치하더라도 제외되지 않습니다.

셋째, reCAPTCHA Enterprise 평가는 reCAPTCHA Enterprise 자바스크립트가 삽입된 리디렉션 페이지가 렌더링될 때만 실행됩니다. 따라서 reCAPTCHA Enterprise 평가의 리디렉션은 응답이 전체 페이지 렌더링으로 이어지는 요청에만 적용됩니다. 페이지 내에서 로드되는 애셋 또는 응답이 렌더링되지 않을 것으로 예상되는 삽입 스크립트에서 파생되는 요청과 같은 다른 요청은 reCAPTCHA Enterprise 평가를 받지 않습니다. 따라서 이 조건을 충족하는 URL 경로에 대한 일치 조건을 사용하여 이 작업을 적용하는 것이 좋습니다.

예를 들어 웹페이지에 이미지, 다른 웹페이지 링크, 스크립트와 같은 삽입된 요소가 있다고 가정해 보겠습니다. 이미지를 호스팅하거나 전체 페이지 렌더링이 예상되지 않는 스크립트에서 액세스해야 하는 URL 경로에 대한 reCAPTCHA Enterprise 평가에 리디렉션 작업을 적용하지 않는 것이 좋습니다. 대신 기본 웹페이지 또는 기타 연결된 웹페이지와 같이 웹페이지를 호스팅하는 URL 경로에 대한 reCAPTCHA Enterprise 평가에 리디렉션 작업을 적용할 수 있습니다.

마지막으로, 리디렉션 페이지가 성공적으로 렌더링되면 브라우저에서 제공하는 개발자 도구에서 예외 쿠키가 설정되어 있는지, 예외 쿠키가 동일한 사이트에 대한 후속 요청에 연결되어 있는지 확인합니다. 추가 지원이 필요하면 Cloud 지원팀에 문의하세요.

비율 제한 문제

트래픽이 예상대로 제한되지 않음

클라이언트 IP 주소가 설정된 기준을 초과하는 속도로 애플리케이션에 높은 수준의 트래픽을 전송하지만 트래픽이 예상대로 제한되지 않을 수 있습니다. 이 문제를 조사하려면 다음 단계를 따르세요.

먼저 우선순위가 더 높은 규칙이 해당 IP 주소의 트래픽을 허용하는지 확인합니다. 로그를 검토하여 IP 주소에 대해 ALLOW 규칙이 트리거되었는지 확인합니다. 이는 자체 ALLOW 규칙일 수도 있고 다른 THROTTLE 또는 RATE_BASED_BAN 규칙에 있을 수도 있습니다.

우선순위가 더 높은 규칙을 찾으면 다음 중 하나를 수행합니다.

  1. 비율 제한 규칙에 더 낮은 숫자 값을 할당하여 더 높은 우선순위를 갖도록 우선순위를 변경합니다.
  2. 우선순위가 더 높은 규칙의 일치 표현식에서 IP 주소를 제외합니다.

또한 기준이 잘못 설정되었을 수도 있습니다. 이 경우 요청이 정확하게 일치하지만 준수 작업이 트리거됩니다. 로그를 검토하여 이러한 경우에 해당하는지 확인한 다음 규칙의 기준을 줄입니다.

마지막으로 IP 주소가 제한 또는 비율 기반 차단 규칙과 일치하지 않을 수 있습니다. 이 문제를 해결하려면 일치 조건에서 실수가 있는지 확인한 후 규칙의 일치 조건을 올바른 값으로 변경합니다.

다음 단계