Google Cloud Armor 및 reCAPTCHA Enterprise는 자동 클라이언트로부터 들어오는 요청을 평가하고 조치를 취하는 데 도움이 되는 도구를 제공합니다.
reCAPTCHA Enterprise는 고급 위험 분석 기술을 사용하여 인간 사용자와 자동화된 클라이언트를 구분합니다. reCAPTCHA Enterprise는 reCAPTCHA WAF 사이트 키 구성을 기반으로 사용자를 평가합니다. 그런 다음 관련 위험을 나타내는 속성이 포함된 암호화된 토큰을 발급합니다. Google Cloud Armor는 reCAPTCHA Enterprise 서비스에 대한 추가 요청 또는 응답 없이 이 토큰을 인라인으로 해독합니다. 토큰 속성에 따라 Google Cloud Armor를 사용하면 수신 요청을 허용, 거부, 비율 제한 또는 리디렉션할 수 있습니다. 자세한 내용은 Google Cloud Armor 및 reCAPTCHA Enterprise 통합 개요를 참조하세요.
Google Cloud Armor의 봇 관리에는 다음과 같은 통합 기능이 있습니다.
수동 테스트(reCAPTCHA 테스트 페이지)
- reCAPTCHA Enterprise 평가 요청을 리디렉션하도록 보안 정책 규칙을 구성해야 합니다.
- 자체 reCAPTCHA Enterprise WAF 사이트 키를 만들어 보안 정책과 연결할 수 있습니다. 이 작업은 적극 권장됩니다. 자세한 내용은 reCAPTCHA 테스트 구현을 참조하세요.
- reCAPTCHA Enterprise 평가를 위해 최종 사용자를 리디렉션하여 reCAPTCHA Enterprise 수동 테스트를 통과한 최종 사용자만 허용할 수 있습니다.
reCAPTCHA Enterprise 원활한 평가 시행
- 요청이 봇에서 발생하는 위험에 대한 reCAPTCHA Enterprise 평가를 기반으로 수신 요청에 대해 여러 가지 조치를 취할 수 있습니다. 보안 점수 규칙을 작성하여 토큰 점수와 기타 토큰 속성을 기반으로 트래픽을 평가하고 필터링할 수 있습니다.
- reCAPTCHA Enterprise 작업 토큰, 세션 토큰 또는 둘 다를 구현해야 합니다. reCAPTCHA 작업 토큰은 웹사이트, iOS, Android에서 실행되는 애플리케이션에서 지원됩니다. reCAPTCHA 세션 토큰은 웹사이트에서만 지원됩니다. reCAPTCHA 토큰에 대한 자세한 내용은 reCAPTCHA 작업 토큰 및 reCAPTCHA 세션 토큰을 참조하세요.
- reCAPTCHA Enterprise 토큰을 평가하는 보안 정책 규칙을 구성해야 합니다.
- 토큰 도난을 방지하려면 자체 WAF용 reCAPTCHA Enterprise 키를 보안 정책 규칙과 연결하는 것이 좋습니다.
Google Cloud Armor 봇 관리에는 다음 기능도 포함됩니다.
- 리디렉션(302)
- Google Cloud Armor에서 클라이언트에 대한 HTTP 302 응답을 제공하도록 구성하여 구성된 대체 URL로 요청을 리디렉션할 수 있습니다.
- 요청 데코레이션
- 백엔드에 요청을 프록시하기 전에 요청에 커스텀 헤더를 삽입하고 헤더에 정적 값을 삽입할 수 있습니다.
사용 사례
이 섹션에서는 Google Cloud Armor 봇 관리 기능을 사용하여 봇 위험을 완화하고 자동화된 클라이언트의 액세스를 제어하는 방법을 설명합니다.
수동 로그인 질문을 사용하여 올바른 사용자와 자동 클라이언트 구별
요청을 reCAPTCHA Enterprise로 리디렉션하여 추가 reCAPTCHA Enterprise를 구현하지 않고도 최종 사용자를 평가하고 필요한 경우 수동 로그인 질문을 제공할 수 있습니다. 인간 사용자가 봇 또는 악의적인 시스템과 동일한 서명(예: URL 경로 또는 기타 L7 서명)을 공유하는 경우 이 작업을 통해 사용자가 인간임을 증명할 수 있습니다. 평가를 통과한 사용자만 서비스에 액세스할 수 있습니다.
다음 다이어그램은 수동 로그인 질문을 통해 요청을 사람이 보낸 것인지, 아니면 자동 클라이언트가 보낸 것인지 구분하는 방법을 보여줍니다.
사용자 Maya와 봇 모두 사이트의 로그인 페이지(/login.html)를 탐색한다고 가정해 보겠습니다. 봇에 대한 액세스 권한을 부여하지 않고 Maya에 대한 액세스를 허용하려면 GOOGLE_RECAPTCHA 유형의 redirect 작업을 사용하여 고급 일치 표현식 request.path.matches("/login.html")가 있는 보안 정책 규칙을 구성하면 됩니다. 엔드 투 엔드 사용자 환경은 다음과 같습니다.
- 최종 사용자가 사이트에 처음 방문합니다.
- Google Cloud Armor가 요청을 평가하고 reCAPTCHA Enterprise로 리디렉션하기로 결정합니다.
- reCAPTCHA Enterprise는 reCAPTCHA Enterprise 자바스크립트가 삽입된 HTML 페이지로 응답합니다.
- 응답이 렌더링되면 삽입된 자바스크립트가 실행되어 사용자를 평가하고 필요한 경우 수동 챌린지를 제공합니다.
- 사용자가 평가를 통과하면 reCAPTCHA Enterprise는 예외 쿠키를 발급하며, 이 예외 쿠키는 쿠키가 만료될 때까지 브라우저에서 동일한 사이트에 대한 각 후속 요청에 자동으로 연결됩니다.
- 그렇지 않으면 reCAPTCHA Enterprise가 예외 쿠키를 발행하지 않습니다.
이 예시에서는 Maya만 reCAPTCHA Enterprise 평가를 통과하고 예외 쿠키를 받아 사이트에 액세스할 수 있습니다.
수동 로그인 질문을 사용하는 경우 자체 reCAPTCHA WAF 사이트 키를 만들어 보안 정책과 연결하는 것이 좋습니다. 이렇게 하면 사이트 키와 연결된 reCAPTCHA Enterprise 측정항목을 보고 사이트 키에 대한 보안 모델을 학습시킬 수 있습니다. 자세한 내용은 reCAPTCHA WAF 로그인 질문 사이트 키 만들기를 참조하세요.
사이트 키를 만들고 연결하지 않으면 reCAPTCHA Enterprise에서 평가 중에 Google 관리 사이트 키를 사용합니다. Google 관리 사이트 키를 포함하여 소유하지 않은 사이트 키와 연결된 reCAPTCHA 측정항목을 볼 수 없습니다.
reCAPTCHA Enterprise 평가 시행
들어오는 요청에 연결된 reCAPTCHA Enterprise 토큰이 있으면 Google Cloud Armor가 요청을 평가하고 토큰의 개별 속성을 기반으로 구성된 작업을 적용합니다. Google Cloud Armor 보안 정책 평가는 Google 네트워크 에지에서 수행되므로 백엔드는 토큰을 해독하지 않습니다.
reCAPTCHA Enterprise 토큰
reCAPTCHA Enterprise는 작업 토큰과 세션 토큰이라는 두 가지 유형의 토큰을 발급합니다. 두 토큰 유형 모두 사이트 또는 앱과의 상호작용을 기반으로 각 요청의 점수를 반환합니다. 두 토큰 유형 모두에 사용자와 관련된 위험을 나타내는 점수를 포함한 속성이 포함됩니다. 여기에는 토큰이 생성될 때 사용한 reCAPTCHA Enterprise 키에 대한 정보도 포함됩니다.
보안 정책 규칙을 구성하기 전에 작업 토큰, 세션 토큰 또는 둘 다 사용할지 여부를 결정해야 합니다. reCAPTCHA Enterprise 문서를 읽고 결정을 내리는 것이 좋습니다. 자세한 내용은 reCAPTCHA Enterprise 사용 사례 비교를 참조하세요.
사용할 토큰 유형을 결정한 후에는 요청에 연결할 토큰에 대해 reCAPTCHA Enterprise를 구현합니다. reCAPTCHA Enterprise에서 토큰을 구현하는 방법은 다음 페이지를 참조하세요.
- 웹 애플리케이션
- 모바일 애플리케이션
마지막으로 Google Cloud Armor 규칙 언어를 사용하여 요청에 연결된 reCAPTCHA Enterprise 토큰을 평가하도록 보안 정책 규칙을 구성합니다. 토큰 도난을 방지하려면 reCAPTCHA Enterprise 키를 보안 정책 규칙과 연결하는 것이 좋습니다. reCAPTCHA 키를 보안 정책 규칙과 연결하면 Google Cloud Armor가 토큰의 reCAPTCHA 키를 규칙과 연결된 reCAPTCHA 키와 비교하여 토큰에 대한 추가 검증을 수행합니다. Google Cloud Armor는 알 수 없는 reCAPTCHA 키가 있는 토큰을 잘못된 것으로 간주합니다. 자세한 내용은 reCAPTCHA Enterprise 원활한 평가 시행을 참조하세요.
다음 그림은 reCAPTCHA Enterprise 토큰 적용 흐름을 보여줍니다.
리디렉션(302 응답)
URL 기반 리디렉션 작업을 사용하여 외부에서 요청을 다른 엔드포인트로 리디렉션할 수 있습니다. 리디렉션 대상을 URL 형식으로 제공하면 Google Cloud Armor가 HTTP 302 응답을 클라이언트에 제공하여 요청을 리디렉션합니다.
요청 데코레이션
Google Cloud Armor는 요청을 애플리케이션에 프록시하기 전에 정적 사용자 정의 값이 있는 커스텀 요청 헤더를 삽입할 수 있습니다. 이 옵션을 사용하면 허니팟 제공과 같은 대체 다운스트림 처리나 추가 분석 및 모니터링의 의심스러운 요청에 태그를 지정할 수 있습니다. 이 작업 매개변수를 기존 allow 작업에 추가해야 합니다.
맞춤 헤더
전역 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기의 커스텀 헤더 중 하나와 동일한 헤더 이름의 커스텀 헤더 또는 값을 삽입하도록 Google Cloud Armor를 구성한 경우 부하 분산기에서 헤더 값을 덮어씁니다. 자세한 내용은 백엔드 서비스에서 커스텀 헤더 만들기를 참조하세요.
또한 표준 HTTP 헤더를 포함하여 요청에 이미 존재하는 헤더 이름을 선택하면 Google Cloud Armor 규칙에 제공된 사용자 정의 값에서 해당 헤더의 원래 값을 덮어씁니다.
비율 제한과 통합
Google Cloud Armor 비율 제한 규칙은 봇 관리 기능과 호환됩니다. 예를 들어 reCAPTCHA Enterprise 평가 요청을 리디렉션하거나 요청 수가 구성된 임곗값을 초과하면 다른 URL로 리디렉션할 수 있습니다. 또한 reCAPTCHA Enterprise 예외 쿠키나 토큰을 기반으로 비율 제한 클라이언트를 식별하여 사용자 구성 임곗값을 초과하는 비율로 동일한 쿠키 또는 토큰을 재사용하거나 악용하는 요청을 제한하거나 클라이언트를 차단할 수 있습니다.
reCAPTCHA Enterprise 예외 쿠키 또는 토큰의 비율 제한
보안을 위해 고유한 reCAPTCHA 작업 토큰, 세션 토큰 또는 예외 쿠키당 여러 번 사용을 통해 토큰 악용을 방지하도록 비율 제한 규칙을 구성하는 것이 좋습니다. 다음 표에서는 비율 제한 규칙에서 reCAPTCHA Enterprise 예외 쿠키나 토큰을 키로 식별하는 방법을 보여줍니다.
| 리소스 | enforce_on_key |
enforce_on_key_name |
|---|---|---|
| 예외 쿠키 | HTTP-COOKIE |
recaptcha-ca-e |
| 작업 토큰 | HTTP-HEADER |
X-Recaptcha-Token |
| 세션 토큰 | HTTP-COOKIE |
recaptcha-ca-t |
동일한 예외 쿠키나 토큰에 의존하고 구성된 임곗값을 초과하는 요청을 제한하거나 클라이언트를 차단할 수 있습니다. 비율 제한 매개변수에 대한 자세한 내용은 비율 제한 적용을 참조하세요.
비율 제한 예시
먼저 사이트에서 선택한 URL(예: /login.html)에만 수동 로그인 질문을 사용한다고 가정해 보겠습니다. 이를 위해 다음과 같이 보안 정책 규칙을 구성합니다.
- 규칙 1: 요청에 연결된 유효한 예외 쿠키가 있고 예외 쿠키의 사용 횟수가 정의된 기준 미만인 경우 요청을 허용합니다.
- 규칙 2: reCAPTCHA Enterprise 평가 요청을 리디렉션합니다.
둘째, 사이트에서 작업 토큰 또는 세션 토큰만 사용한다고 가정합니다.
예를 들어 작업 토큰을 사용하여 /login.html과 같은 주의해야 하는 사용자 작업을 보호할 수 있습니다. 이렇게 하려면 다음과 같이 작업 토큰의 점수를 기반으로 작업을 수행합니다.
- 규칙 1: 작업 토큰의 점수가 사전 정의된 기준(예:
0.8)보다 높은 경우 작업 토큰의 사용 횟수가 정의된 값보다 적으면 요청을 허용합니다. - 규칙 2: 요청을 거부합니다.
비슷한 보안 정책 규칙을 구성하여 reCAPTCHA Enterprise 세션 토큰 평가를 시행할 수 있습니다.
셋째, 작업 토큰이나 세션 토큰을 사이트에서 선택된 URL (예: /login.html)의 수동 로그인 질문과 결합하고 작업 토큰의 점수를 기반으로 작업을 수행한다고 가정합니다. 또한 점수가 만족스럽지 못할 경우 로그인 질문 해결을 통해 사용자에게 두 번째 기회를 주려고 합니다. 이렇게 하려면 보안 정책 규칙을 다음과 같이 구성합니다.
- 규칙 1: 작업 토큰의 점수가 사전 정의된 기준(예:
0.8)보다 높은 경우 작업 토큰의 사용 횟수가 정의된 값보다 적으면 요청을 허용합니다. - 규칙 2 및 3: 작업 토큰의 점수가 별도의 사전 정의된 기준(예:
0.5)보다 높은 경우 요청에 연결된 유효한 예외 쿠키가 없고 예외 쿠키의 사용 횟수가 정의된 기준보다 적지 않으면 reCAPTCHA Enterprise 평가 요청을 리디렉션합니다. - 규칙 4: 요청을 거부합니다.
유사한 보안 정책 규칙을 구성하여 수동 챌린지로 reCAPTCHA Enterprise 세션 토큰 평가를 적용할 수 있습니다.
비율 제한 규칙을 조정하지 않으면 Google Cloud Armor에서 각 reCAPTCHA 예외 쿠키, 작업 토큰, 세션 토큰의 사용 횟수에 제한이 없습니다. 작업 토큰의 경우 낮은 기준(예: 1)과 긴 시간 간격(예: 작업 토큰은 30분 동안 유효하므로 30분)을 사용하는 것이 좋습니다. 트래픽 통계를 기준으로 기준을 도출하는 것이 좋습니다.