Google Cloud Armor는 다양한 레이어 3 및 레이어 7 공격으로부터 Google Cloud 애플리케이션을 보호하는 기능을 제공합니다. 비율 기반 규칙은 인스턴스를 가득 채우고 합법적인 사용자의 액세스를 차단하는 대량의 요청에서 애플리케이션을 보호하는 데 도움이 됩니다.
비율 제한은 다음을 수행할 수 있습니다.
- 특정 클라이언트가 애플리케이션 리소스를 소진하지 못하도록 합니다.
- 불안정하고 예측할 수 없는 클라이언트 요청 비율 급증으로부터 애플리케이션 인스턴스를 보호합니다.
또한 리소스에 적은 수의 클라이언트에서 대량의 트래픽을 제공하는 경우, 이처럼 적은 수의 클라이언트에서 발생하는 트래픽 급증으로 인해 다른 클라이언트에 영향을 미치지 않도록 할 수 있으므로 리소스에서 최대한 많은 요청을 처리할 수 있습니다.
Google Cloud Armor에는 두 가지 유형의 비율 기반 규칙이 있습니다.
- 제한: 개별 클라이언트를 사용자가 구성한 기준으로 제한하여 클라이언트별로 또는 모든 클라이언트에 대해 최대 요청 한도를 적용할 수 있습니다.
- 비율 기반 차단: 클라이언트별로 규칙과 일치하는 요청에 비율 제한을 적용한 다음, 사용자가 구성한 기준을 초과하면 구성된 기간 동안 해당 클라이언트를 일시적으로 차단할 수 있습니다.
Google Cloud Armor는 연결된 각 백엔드에 비율 제한 기준을 적용합니다. 예를 들어 2개의 백엔드 서비스가 있고 분당 요청 1,000개의 기준으로 비율 제한 규칙을 구성한 경우 각 백엔드 서비스는 Google Cloud Armor가 규칙 작업을 적용하기 전에 분당 요청 1,000개를 수신할 수 있습니다.
미리보기 모드를 사용하고 요청 로그를 검토하여 보안 정책에서 비율 제한 규칙의 효과를 미리 볼 수 있습니다.
비율 제한을 위한 클라이언트 식별
Google Cloud Armor는 요청을 집계하고 비율 제한을 적용하기 위해 다음 키 유형을 사용하여 비율 제한을 적용할 개별 클라이언트를 식별합니다.
- ALL: 요청이 규칙 일치 조건을 충족하는 모든 클라이언트의 단일 키입니다.
- IP: 요청이 규칙 일치 조건을 충족하는 각 클라이언트 소스 IP 주소의 고유 키입니다.
- HTTP_HEADER: 이름이 구성된 각 고유 HTTP 헤더 값의 고유 키입니다. 키 값은 헤더 값의 처음 128바이트로 잘립니다. 이러한 헤더가 없거나 외부 프록시 네트워크 부하 분산기에 이 키 유형을 사용하려는 경우 키 유형이 기본적으로 ALL로 지정됩니다.
- XFF_IP: 클라이언트의 각 원래 소스 IP 주소에 대한 고유 키, 즉
X-Forwarded-ForHTTP 헤더에 지정된 IP 목록의 첫 번째 IP 주소입니다. 이러한 헤더가 없거나 값이 유효한 IP 주소가 아니거나 외부 프록시 네트워크 부하 분산기에 이 키 유형을 사용하려는 경우 키 유형이 기본적으로 IP 주소로 지정됩니다. - HTTP_COOKIE: 이름이 구성된 각 HTTP 쿠키의 고유 키입니다. 키 값이 쿠키 값의 처음 128바이트로 잘립니다. 이러한 쿠키가 없거나 외부 프록시 네트워크 부하 분산기에서 이 키 유형을 사용하려는 경우 키 유형이 기본적으로 ALL로 지정됩니다.
- HTTP_PATH: HTTP 요청의 URL 경로입니다. 키 값은 처음 128바이트로 잘립니다.
- SNI: HTTPS 요청의 TLS 세션에 있는 서버 이름 표시입니다. 키 값은 처음 128바이트로 잘립니다. 키 유형은 HTTP 세션에서 기본적으로 ALL로 지정됩니다.
- REGION_CODE: 요청이 시작된 국가/리전입니다.
- TLS_JA3_FINGERPRINT: 클라이언트가
HTTPS,HTTP/2,HTTP/3을 사용하여 연결하는 경우 JA3 TLS/SSL 디지털 지문입니다. 사용할 수 없으면 키 유형이 기본적으로 ALL로 지정됩니다. JA3에 대한 자세한 내용은 규칙 언어 참조를 확인하세요. - USER_IP:
userIpRequestHeaders에 구성된 헤더에 포함된 시작 클라이언트의 IP 주소이며, 값이 업스트림 프록시로 채워집니다.userIpRequestHeaders구성이 없거나 이로부터 IP 주소를 확인할 수 없으면 키 유형이 기본적으로 IP로 지정됩니다. 자세한 내용은 규칙 언어 참조를 확인하세요.
이전 키를 개별적으로 사용하거나 최대 3개의 키 조합을 기준으로 비율 제한을 적용할 수 있습니다. HTTP-HEADER 또는 HTTP-COOKIE 키 여러 개를 사용할 수 있으며, 서로 다른 키 유형 중 하나만 사용할 수 있습니다. 자세한 내용은 여러 키 기반의 비율 제한을 참조하세요.
트래픽 제한
규칙의 throttle 작업을 사용하면 클라이언트별 요청 기준을 적용하여 백엔드 서비스를 보호할 수 있습니다. 이 규칙은 기준을 적용하여 규칙의 일치 조건을 충족하는 각 클라이언트의 트래픽을 제한합니다. 기준은 지정된 시간 간격으로 지정된 수의 요청으로 구성됩니다.
예를 들어 요청 기준을 1,200초(20분) 내에 2,000개 요청으로 설정할 수 있습니다. 클라이언트가 1,200초 동안 2,500개의 요청을 보내는 경우 허용된 요청 볼륨이 구성된 기준에 도달할 때까지 클라이언트 트래픽의 약 20%가 제한됩니다.
클라이언트의 트래픽 비율이 rate_limit_threshold_count 이하이면 요청은 항상 allow인 conform_action을 따릅니다. 요청은 보안 정책을 통해 허용되며 이 정책에 따라 대상에 도달할 수 있습니다. 클라이언트의 트래픽 비율이 지정된 rate_limit_threshold_count를 초과하면 Google Cloud Armor는 남은 기준 간격 동안 한도를 초과하는 요청에 대하여 exceed_action를 적용하며 이는 deny 또는 redirect일 수 있습니다.
작업을 제어하려면 다음 매개변수를 설정하세요.
rate_limit_threshold_count: 지정된 시간 간격 내에 허용되는 클라이언트당 요청 수입니다. 최솟값은 1이고 최댓값은 10,000입니다.interval_sec: 시간 간격(초)입니다. 값은 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700, 3600초여야 합니다.
exceed_action: 요청이rate_limit_threshold_count를 초과하면 Google Cloud Armor가 구성된exceed_action을 적용합니다.exceed_action에 가능한 값은 다음과 같습니다.deny(status): 요청이 거부되고 지정된 오류 코드가 반환됩니다(유효한 값은403,404,429,502).429 (Too Many Requests)응답 코드를 사용하는 것이 좋습니다.redirect:exceed_redirect_options매개변수에 따라 요청이 reCAPTCHA 평가 또는 다른 URL로 리디렉션됩니다.
exceed_redirect_options:exceed_action가redirect인 경우 이 매개변수를 사용하여 리디렉션 작업을 지정하세요.type: 리디렉션 작업의 유형입니다(GOOGLE_RECAPTCHA또는EXTERNAL_302).target: 리디렉션 작업의 URL 대상입니다.type이EXTERNAL_302인 경우에만 적용됩니다.
conform_action: 요청 수가rate_limit_threshold_count미만일 때 수행되는 작업입니다. 항상allow작업입니다.
요청 비율에 따라 클라이언트 차단
규칙의 rate_based_ban 작업을 사용하면 클라이언트별 기준을 적용하여, 구성 가능한 기간 동안 클라이언트의 모든 요청에 대하여 설정한 exceed_action을 적용함으로써 한도를 초과하는 클라이언트를 일시적으로 차단할 수 있습니다. 기준은 지정된 시간 간격으로 지정된 수의 요청으로 구성됩니다. 트래픽이 지정된 일치 조건에 해당하고 구성된 기준을 초과하면 사용자 지정 기간('ban_duration_sec') 동안 트래픽을 일시적으로 차단할 수 있습니다.
예를 들어 요청 기준을 1,200초(20분) 내에 2,000개 요청으로 설정할 수 있습니다. 클라이언트가 1,200초 안에 2,500개의 요청을 보내는 경우 Google Cloud Armor는 1,200초가 모두 경과하고 차단 기간으로 지정한 추가 시간(초)이 지날 때까지 2000개 요청 기준을 초과하는 클라이언트의 트래픽에 exceed_action을 적용합니다.
예를 들어 차단 기간이 3600으로 설정된 경우 클라이언트의 트래픽은 기준 간격 종료 후 3,600초(1시간) 동안 차단됩니다.
클라이언트의 요청 비율이 비율 제한 기준 미만이면 요청이 즉시 백엔드 서비스로 진행될 수 있습니다. 클라이언트의 트래픽 비율이 지정된 값 rate_limit_threshold_count를 초과하는경우 Google Cloud Armor는 남은 기준 간격 동안, 그리고 기준값 초과 여부에 관계없이 다음 ban_duration_sec 초 동안 해당 클라이언트에게서 수신되는 모든 요청에 exceed_action을 적용합니다.
이 구성을 사용하면 허용 요청 비율을 종종 초과하는 시작 클라이언트를 실수로 차단할 수 있습니다. 이를 방지하고 요청 비율을 자주 초과하는 클라이언트만 차단하려면 ban_threshold_count라는 추가 기준 구성에 대해 전체 클라이언트 요청을 선택적으로 추적할 수 있습니다. 이 모드에서는 요청 비율이 구성된 ban_threshold_count를 초과하는 경우에만 클라이언트가 구성된 ban_duration_sec 동안 차단됩니다. 요청 비율이 ban_threshold_count를 초과하지 않으면 요청이 계속해서 rate_limit_threshold_count로 제한됩니다. ban_threshold_count를 위해 제한 전에 들어오는 모든 요청으로 구성된 클라이언트의 총 요청이 집계됩니다.
다음 매개변수는 rate_based_ban 규칙의 작업을 제어합니다.
rate_limit_threshold_count: 지정된 시간 간격 내에 허용되는 클라이언트당 요청 수입니다. 최솟값은 요청 1개, 최댓값은 요청 10,000개입니다.interval_sec: 시간 간격(초)입니다. 값은 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700, 3600초여야 합니다.
exceed_action: 요청이rate_limit_threshold_count를 초과하면 Google Cloud Armor가 구성된exceed_action을 적용합니다.exceed_action에 가능한 값은 다음과 같습니다.deny(status): 요청이 거부되고 지정된 오류 코드가 반환됩니다. 오류 코드에 유효한 값은403,404,429502입니다.429 (Too Many Requests)응답 코드를 사용하는 것이 좋습니다.redirect:exceed_redirect_options매개변수에 따라 요청이 reCAPTCHA 평가 또는 다른 URL로 리디렉션됩니다.
exceed_redirect_options:exceed_action가redirect인 경우 이 매개변수를 사용하여 리디렉션 작업을 지정하세요.type: 리디렉션 작업의 유형입니다(GOOGLE_RECAPTCHA또는EXTERNAL_302).target: 리디렉션 작업의 URL 대상입니다.type이EXTERNAL_302인 경우에만 적용됩니다.
conform_action: 요청 수가rate_limit_threshold_count미만일 때 수행되는 작업입니다. 항상allow작업입니다.ban_threshold_count: Google Cloud Armor에서 요청을 차단하는 지정된 시간 간격 내에 허용되는 클라이언트당 요청 수입니다. 지정한 경우rate_limit_threshold_count를 초과하는 요청 수가ban_threshold_count를 초과하면 구성된ban_duration_sec에서 키가 차단됩니다.ban_threshold_interval_sec:ban_threshold_count의 시간 간격(초)입니다. 값은 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700, 3600초여야 합니다.
ban_duration_sec:interval_sec기간이 경과한 후 클라이언트가 차단되는 추가 시간(초)입니다. 값은 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700, 3600초여야 합니다.
기본 비율 제한 보안 정책
부하 분산기 생성 중에 기본 보안 정책을 구성하는 경우 기본 기준은 1분 간격 중에 요청 500개입니다(각각 rate_limit_threshold_count 및 interval_sec은 각각 500 및 60). 다른 기준을 선택하려면 다음 단계에 따라 매개변수를 조정하는 것이 좋습니다.
Cloud Logging을 사용 설정하고 Google Cloud Armor로 보호되는 백엔드 서비스에서 하루 또는 그 이상의 기간에 IP 주소 및 분 단위로 도착하는 최대 요청 수를 쿼리합니다.
예를 들어 수신되는 네트워크 트래픽의 99%가 비율 제한 규칙의 영향을 받지 않는다고 가정해 보겠습니다. 이 시나리오에서는 Cloud Logging 데이터에서 생성되는 배포의 IP 주소 및 분 단위 최대 요청 수의 99번째 백분위수로 비율 제한 기준을 설정하는 것이 좋습니다.
기본 비율 제한 규칙이 적법한 트래픽을 계속 차단하는 경우 다음 단계를 추가로 고려하세요.
- 캐싱을 사용 설정합니다(Cloud CDN 또는 Media CDN).
- 제한 시간 간격을 늘립니다(60초 대신 몇 분 단위로 수신된 요청).
- 초기 웨이브 이후 공격으로 인한 영향을 추가로 줄이기 위해 클라이언트를 차단할 수 있습니다. Google Cloud Armor
rate_based_ban작업으로 사용자가 지정한 기간 내에 한도를 너무 많이 초과하는 모든 클라이언트를 차단하여 이를 수행할 수 있습니다. 예를 들어 1분 이내에 한도를 10회 초과하는 클라이언트는 15분 동안 차단될 수 있습니다.
기준 적용
제한 및 비율 기반 차단에 대해 구성된 기준은 HTTP(S) 백엔드 서비스가 배포된 각 Google Cloud 리전에서 독립적으로 적용됩니다. 예를 들어 서비스가 두 리전에 배포된 경우 두 리전은 각각 각 키를 구성된 기준으로 비율 제한하므로 백엔드 서비스는 구성된 기준의 두 배인 리전 간 집계된 트래픽 볼륨을 경험할 수 있습니다. 구성된 기준이 5,000개 요청으로 설정된 경우 백엔드 서비스는 한 리전에서 5,000개의 요청을 수신하고, 두 번째 리전에서 5,000개의 요청을 수신할 수 있습니다.
그러나 키 유형 IP 주소의 경우 동일한 클라이언트 IP 주소의 트래픽이 백엔드가 배포된 리전과 가장 가까운 리전으로 전달된다고 가정하는 것이 좋습니다. 이 경우 배포된 리전에 관계없이 비율 제한은 백엔드 서비스 수준에서 적용되는 것으로 간주될 수 있습니다.
적용된 비율 제한은 대략적인 것으로 구성된 기준에 비해 엄격하게 정확하지 않을 수 있습니다. 또한 드물지만 내부 라우팅 동작으로 인해 배포된 리전보다 더 많은 리전에 비율 제한이 적용될 수 있으므로 정확도에 영향을 미칠 수 있습니다. 이러한 이유로 엄격한 할당량 또는 라이선스 요구사항을 적용하지 않고 악용 완화 또는 애플리케이션 및 서비스 가용성 유지를 위해서만 비율 제한을 사용하는 것이 좋습니다.
로깅
Cloud Logging은 보안 정책 이름, 일치 비율 제한 규칙 우선순위, 규칙 ID, 관련 작업 및 기타 정보를 요청 로그에 기록합니다. 로깅에 대한 자세한 내용은 요청 로깅 사용을 참조하세요.
reCAPTCHA와 통합
토큰 남용을 해결하고 토큰 재사용을 제한하기 위해 일부 reCAPTCHA 리소스에 비율 제한을 적용할 수 있습니다. 이러한 리소스에는 작업 토큰, 세션 토큰, 예외 쿠키가 포함됩니다. reCAPTCHA 비율 제한 사용에 대한 자세한 내용은 봇 관리 개요를 참조하세요.