reCAPTCHA 방화벽 정책 개요

이 문서에서는 reCAPTCHA 방화벽 정책을 간략하게 설명합니다.

reCAPTCHA 방화벽 정책은 스팸 및 악용으로부터 사이트를 보호하기 위해 조건 속성과 일치하는 규칙 집합입니다. 각 규칙은 수신되는 트래픽에 대해 평가됩니다. 규칙은 정책에 추가된 순서와 동일한 순서로 평가됩니다.

reCAPTCHA 방화벽 정책 구성요소

reCAPTCHA 방화벽 정책 규칙은 다음 구성요소로 이루어집니다.

path: 방화벽 정책 규칙이 적용되는 URL 경로입니다. 예를 들면 /login입니다.
condition: 정책 조건입니다. 정책 조건은 불리언 값으로 확인되어야 하는 CEL(Common Expression Language) 표현식입니다. 예를 들면 recaptcha.score >= 0.5입니다.
action: 정책 조건이 충족될 때 WAF 서비스 제공업체가 실행해야 하는 작업입니다. 자세한 내용은 정책 작업을 참조하세요.

수신되는 요청이 지정된 경로의 정책 조건과 일치하면 해당 WAF 서비스 제공업체는 지정된 작업에 따라 요청을 허용, 차단 또는 리디렉션합니다. 기본 규칙은 액세스를 허용하는 것입니다.

reCAPTCHA 방화벽 정책 샘플

다음 reCAPTCHA 방화벽 정책 샘플에는 login 작업에 적용되는 규칙이 포함되어 있습니다. 점수가 0.5 미만이면 액세스를 차단합니다.

     policy {
          path: login.php
          condition: recaptcha.score < 0.5
          action: block
        }

reCAPTCHA 방화벽 정책 조건 속성

다음 표에는 reCAPTCHA 방화벽 정책의 조건을 정의하는 데 사용할 수 있는 reCAPTCHA 토큰 속성이 나와 있습니다.

속성 이름	데이터 유형	설명
`recaptcha.token.valid`	부울	수신된 토큰이 유효한지 여부입니다. 점수가 낮더라도 토큰은 형식이 잘못되었거나 만료되지 않은 경우 유효합니다.
`recaptcha.token.action`	문자열	토큰 생성 시 제공되는 작업 이름입니다. 작업 토큰의 경우에만 채워집니다. 토큰이 생성될 때 `grecaptcha.enterprise.execute()`로 전달되는 `action` 매개변수입니다. 자세한 내용은 작업 이름을 참조하세요.
`recaptcha.score`	float	reCAPTCHA 토큰의 점수입니다. 유효한 점수 범위는 0.0~1.0입니다. 점수 1.0은 상호작용 위험이 낮고 적합할 가능성이 높다는 것을 나타내고 0.0은 상호작용 위험이 높고 허위일 가능성이 있음을 나타냅니다. 자세한 내용은 점수 해석을 참조하세요.
`recaptcha.assessment_type`	정수	수행된 평가 유형입니다. `assessment_type`은 요청과 함께 전달되는 WAF용 reCAPTCHA 키에 따라 설정됩니다. CEL 표현식에서 `recaptcha.assessment_type` 값을 비교하려면 다음 상수 중 하나를 사용합니다. `AssessmentType.ACTION` `AssessmentType.SESSION` `AssessmentType.CHALLENGEPAGE` `AssessmentType.EXPRESS` 예를 들어 작업 토큰 평가를 비교하려면 `AssessmentType.ACTION`을 사용합니다.
`http.ip`	문자열	수신되는 요청의 IP 주소입니다.
`http.path`	문자열	요청 URI의 경로입니다.
`http.domain`	문자열	요청된 URI의 도메인입니다.

reCAPTCHA 방화벽 정책 작업

다음 표에는 reCAPTCHA 방화벽 정책 규칙에 지정할 수 있는 다양한 정책 작업이 나와 있습니다.

정책 작업	설명	작업 결과
`allow`	요청된 페이지에 대한 액세스를 허용합니다.	수신되는 사용자 요청이 백엔드까지 중단되지 않습니다.
`block`	요청된 페이지에 대한 액세스를 거부합니다.	403(금지됨) HTTP 오류가 사용자에게 반환됩니다.
`redirect`	수신되는 사용자 요청을 reCAPTCHA 테스트 페이지로 리디렉션합니다.	reCAPTCHA 테스트 페이지에서는 사용자 요청을 평가하고 평가에 따라 쿠키를 연결합니다. 나중에 사용자 요청이 원래 페이지로 다시 리디렉션됩니다.
`substitute`	요청된 페이지가 아닌 다른 페이지를 허위 사용자 요청에 제공합니다.	백엔드로 요청을 보낼 때 요청된 경로가 다른 경로로 대체됩니다. 사용자에게 원래 URL이 계속 표시됩니다.
`set_header`	커스텀 헤더를 설정하고 수신되는 사용자 요청이 백엔드까지 계속되도록 허용합니다. 그러면 백엔드가 커스텀 보호를 트리거할 수 있습니다.	헤더가 사용자 요청에 연결됩니다. 백엔드가 이 헤더를 사용하여 커스텀 보호 또는 분석을 트리거합니다.