Google Cloud Armor 보안 정책 개요

애플리케이션이 Google Cloud, 하이브리드 배포 또는 멀티 클라우드 아키텍처에 배포되는지 여부에 관계없이 Google Cloud Armor 보안 정책을 사용하면 DDoS와 기타 웹 기반 공격으로부터 부하 분산기 뒤에서 실행되는 애플리케이션을 보호할 수 있습니다.

Google Cloud Armor 보안 정책은 레이어 3, 4, 7 속성을 기준으로 트래픽을 필터링하는 규칙으로 구성됩니다. 예를 들어 들어오는 요청의 IP 주소, IP 범위, 리전 코드 또는 요청 헤더와 일치하는 조건을 지정할 수 있습니다.

Google Cloud Armor 보안 정책은 외부 HTTP(S) 부하 분산기 뒤에 있는 백엔드 서비스에만 사용할 수 있습니다. 부하 분산기는 프리미엄 등급이나 표준 등급에 있을 수 있습니다. HTTP(S) 부하 분산, SSL 프록시 부하 분산, TCP 프록시 부하 분산에 DDoS 보호 기능이 자동으로 제공됩니다.

HTTP, HTTPS, HTTP/2, QUIC 프로토콜 모두 지원됩니다. Google Kubernetes Engine(GKE)에서 Google Cloud Armor를 구성하는 방법에 대한 자세한 내용은 인그레스를 통해 Google Cloud Armor 구성을 참조하세요.

백엔드 서비스의 백엔드는 인스턴스 그룹, 영역 네트워크 엔드포인트 그룹(영역 NEG) 또는 인터넷 네트워크 엔드포인트 그룹(인터넷 NEG)의 가상 머신(VM) 인스턴스일 수 있습니다. Google Cloud Armor를 사용하여 하이브리드 배포나 멀티 클라우드 아키텍처를 보호하는 경우 백엔드는 인터넷 NEG여야 합니다.

Google Cloud Armor 보안 정책을 통한 에지 보안

HTTP(S) 부하 분산은 전 세계 Google 접속 지점(PoP)의 Google 네트워크 에지에서 구현됩니다. 프리미엄 등급에서 외부 HTTP(S) 부하 분산기로 전달되는 사용자 트래픽은 사용자와 가장 가까운 PoP로 유입됩니다. 그런 다음 부하는 Google의 전역 네트워크를 통해 사용 가능한 용량이 충분하게 있는 가장 가까운 백엔드로 분산됩니다. 표준 등급에서 사용자 트래픽은 Google 클라우드 리소스를 배포한 리전의 피어링, ISP 또는 전환 네트워크를 통해 Google 네트워크에 유입됩니다.

Google Cloud Armor 보안 정책을 사용 설정하면 들어오는 트래픽의 소스와 최대한 가까운 Google Cloud 에지에서 외부 HTTP(S) 부하 분산기에 대한 액세스를 허용하거나 거부할 수 있습니다. 이를 통해 원치 않는 트래픽이 리소스를 소비하거나 Virtual Private Cloud(VPC) 네트워크에 유입되는 것을 방지할 수 있습니다.

다음 다이어그램에서는 외부 HTTP(S) 부하 분산기, Google 네트워크, Google 데이터 센터의 위치를 보여줍니다.

네트워크 에지에서의 Google Cloud Armor 정책
네트워크 에지에서의 Google Cloud Armor 정책(확대하려면 클릭)

요구사항

Google Cloud Armor 보안 정책의 요구사항은 다음과 같습니다.

  • 부하 분산기는 외부 HTTP(S) 부하 분산기여야 합니다.
  • 백엔드 서비스의 부하 분산 스키마는 EXTERNAL이어야 합니다.
  • 백엔드 서비스의 프로토콜은 HTTP, HTTPS 또는 HTTP/2 중 하나여야 합니다.

보안 정책 기능

Google Cloud Armor 보안 정책에는 다음과 같은 핵심 기능이 있습니다.

  • 원하는 경우 Google Cloud Armor를 사용하는 부하 분산기와 함께 QUIC 프로토콜을 사용할 수 있습니다.

  • Google Cloud Armor를 프리미엄 등급이나 표준 등급의 외부 HTTP(S) 부하 분산기와 함께 사용할 수 있습니다.

  • GKE 및 기본 인그레스 컨트롤러에서 보안 정책을 사용할 수 있습니다.

HTTP(S) 부하 분산 보안 정책

외부 HTTP(S) 부하 분산기의 각 백엔드 서비스는 Google Cloud Armor 보안 정책 하나를 참조할 수 있습니다. 동일하거나 서로 다른 외부 HTTP(S) 부하 분산기에서 백엔드 서비스 두 개 이상에 같은 보안 정책을 사용할 수 있습니다.

규칙 여러 개를 구성할 때는 우선순위(평가 순서)를 지정합니다.

IP 주소 허용 목록 및 차단 목록 규칙

보안 정책 내에서 IP 주소 허용 목록과 차단 목록 규칙을 만들 수 있습니다. 예를 들면 다음과 같습니다.

  • IP 주소/CIDR을 차단 목록에 추가하면 소스 IP 주소나 CIDR 범위가 외부 HTTP(S) 부하 분산기에 액세스하지 못하게 할 수 있습니다.

  • IP 주소/CIDR을 허용 목록에 추가하면 소스 IP 주소나 CIDR 범위가 외부 HTTP(S) 부하 분산기에 액세스하도록 허용할 수 있습니다.

  • 허용 목록 및 차단 목록 규칙에서는 IPv4 주소와 IPv6 주소를 지원합니다.

  • IP 주소 규칙은 개별 소스 IP 주소나 CIDR을 차단 또는 허용할 수 있습니다. IPv4 및 IPv6 소스 주소 모두 지원되지만 IPv6 주소에는 /64 이하의 서브넷 마스크가 있어야 합니다.

  • 거부 규칙은 HTTP 403(승인되지 않음), 404(액세스 거부), 502(잘못된 게이트웨이) 응답을 반환할 수 있습니다.

규칙 언어 및 시행 엔진

규칙 언어 및 시행 엔진에서는 다음 기능을 제공합니다.

  • 들어오는 요청의 다양한 레이어 3~7 속성과 일치할 수 있는 커스텀 규칙 표현식을 작성하는 기능. Google Cloud Armor에서는 커스텀 일치 조건을 작성할 수 있는 유연한 언어를 제공합니다.

  • 하위 표현식 여러 개를 규칙 하나에 결합하는 기능

  • 들어오는 요청의 리전 코드를 기준으로 요청을 거부하거나 허용하는 기능. 리전 코드는 ISO 3166-1 alpha 2 코드를 기반으로 합니다. 리전 코드가 특정 국가에 해당하는 경우도 있지만 일부는 국가와 관련 지역을 포함합니다. 예를 들어 US 코드에는 미국의 모든 주, 구역 1개, 외곽 지역 6개가 포함되어 있습니다.

XSS, SQLi, LFI, RFI, RCE의 사전 구성된 규칙

사전 구성된 규칙을 사용하여 다음 공격을 완화할 수 있습니다.

  • 교차 사이트 스크립팅(XSS)
  • SQL 삽입(SQLi) 공격
  • 로컬 파일 포함(LFI) 공격
  • 원격 파일 포함(RFI) 공격
  • 원격 코드 실행(RCE) 공격

이러한 규칙은 OWASP Modsecurity Core Rule Set 버전 3.0.1을 기반으로 합니다.

명명된 IP 주소 목록의 사전 구성된 규칙

명명된 IP 주소 목록의 사전 구성된 규칙은 다음을 제공합니다.

  • 타사 제공업체의 명명된 IP 주소 목록을 Google Cloud Armor와 통합합니다.

  • 허용되거나 거부된 IP 주소 범위의 유지보수를 간소화합니다.

  • 타사 제공업체 목록을 매일 동기화합니다.

  • 명명된 IP 주소 목록에서는 규칙당 IP 주소 수가 제한되지 않으므로 보안 정책에서 IP 주소와 범위를 구성할 수 있는 용량이 늘어납니다.

미리보기 모드

규칙을 적용하지 않고 규칙 효과를 미리 볼 수 있습니다. 미리보기 모드에서는 작업이 Cloud Monitoring에 기록됩니다. 보안 정책의 개별 규칙을 미리 보거나 정책의 모든 규칙을 미리 볼 수 있습니다.

로깅

Google Cloud Armor 보안 정책 이름, 일치 규칙 우선순위, 관련 작업, 관련 정보는 외부 HTTP(S) 부하 분산기에 대한 HTTP(S) 요청에 로깅됩니다. Google Cloud Armor 로깅 정보를 기록하려면 HTTP(S) 요청에 대한 로깅을 사용 설정해야 합니다.

Google Cloud Armor 보안 정책 정보

Google Cloud Armor 보안 정책은 외부에 노출된 애플리케이션이나 서비스를 보호하는 애플리케이션 레이어 방화벽 규칙을 적용하도록 정의한 규칙 세트입니다. 각 규칙은 들어오는 트래픽과 관련하여 평가됩니다.

Google Cloud Armor 보안 정책 규칙은 일치 조건과 조건이 충족되면 취할 조치로 구성됩니다. 조건은 들어오는 트래픽의 소스 IP 주소가 특정 IP 주소나 CIDR 범위와 일치하는지 여부를 확인하는 것(IP 주소 허용 목록 및 차단 목록 규칙이라고도 함)만큼 단순할 수 있습니다. 또는 Google Cloud Armor 커스텀 규칙 언어 참조를 사용하여 URL 경로, 요청 메서드 또는 요청 헤더 값과 같은 들어오는 트래픽의 다양한 속성과 일치하는 커스텀 조건을 만들 수 있습니다.

조건이 충족되면 트래픽을 허용하거나 거부합니다. 기본적으로 이 작업이 적용되지만 미리보기 옵션을 사용할 수 있습니다. 미리보기 옵션을 true로 설정하면 미리보기된 작업이 로깅되지만 적용되지는 않습니다.

Google Cloud Armor 보안 정책을 백엔드 서비스 한 개 이상에 연결할 수 있습니다. 백엔드 서비스에는 보안 정책 하나만 연결될 수 있습니다.

Google Cloud Armor 보안 정책이 백엔드 서비스와 연결된 경우 이 정책을 삭제할 수 없습니다. 연결된 보안 정책이 있는지 여부에 관계없이 백엔드 서비스를 삭제할 수 있습니다.

전달 규칙 여러 개가 보안 정책에 연결된 백엔드 서비스를 가리키는 경우 각 전달 규칙 IP 주소로 들어오는 모든 트래픽에 정책 규칙이 적용됩니다.

다음 이미지에서 Google Cloud Armor 보안 정책 internal-users-policy는 백엔드 서비스 test-network에 연결되어 있습니다.

네트워크 에지에서의 Google Cloud Armor 보안 정책
네트워크 에지에서의 Google Cloud Armor 보안 정책(확대하려면 클릭)

규칙 평가 순서

규칙 평가 순서는 규칙 우선순위규칙 유형 등 두 가지 요소에 의해 결정됩니다.

가장 낮은 숫자부터 가장 높은 숫자까지 규칙에 우선순위를 할당합니다. 가장 낮은 숫자 값이 할당된 규칙은 논리적 우선순위가 가장 높으며 논리적 우선순위가 낮은 규칙보다 먼저 평가됩니다. 최소 숫자 우선순위는 0입니다. 숫자가 증가하면 규칙 우선순위가 감소합니다(1, 2, 3, N+1). 우선순위가 같은 규칙을 두 개 이상 구성할 수 없습니다. 각 규칙 우선순위를 0~2147483646 사이의 숫자로 설정해야 합니다. 우선순위 값 2147483647(INT-MAX라고도 함)은 기본 규칙에 예약되어 있습니다.

우선순위 번호에는 간격이 있을 수 있으므로 나중에 나머지 규칙에 영향을 주지 않고 규칙을 추가하거나 삭제할 수 있습니다. 예를 들어 1, 2, 3, 4, 5, 9, 12, 16은 나중에 6~8, 10~11, 13~15의 규칙을 추가할 수 있는 유효한 일련의 우선순위 번호입니다. 실행 순서를 제외하고 기존 규칙을 변경할 필요는 없습니다.

일반적으로 요청과 일치하는 우선순위가 가장 높은 규칙이 적용됩니다. 그러나 evaluatePreconfiguredExpr()을 사용하여 구성한 사전 구성된 규칙을 통해 HTTP POST 요청을 실행하는 경우 예외가 발생합니다. 예외는 다음과 같습니다.

HTTP POST 요청의 경우 Google Cloud Armor는 본문(페이로드) 전에 요청 헤더를 수신합니다. Google Cloud Armor는 먼저 헤더 정보를 수신하므로 헤더와 일치하는 규칙을 평가하지만 본문에서 사전 구성된 규칙과 일치하지 않습니다. 헤더 기반 규칙이 여러 개 있으면 Google Cloud Armor는 예상대로 우선순위에 따라 이러한 규칙을 평가합니다.

Google Cloud Armor는 HTTP POST 본문을 수신한 후 요청 헤더와 본문 모두에 적용되는 규칙을 평가합니다. 결과적으로 요청 헤더를 허용하는 우선순위가 낮은 규칙이 요청 본문을 차단하는 우선순위가 높은 규칙보다 먼저 일치할 수 있습니다. 이러한 경우 요청의 HTTP 헤더 부분이 대상 백엔드 서비스로 전송될 수 있지만 잠재적으로 위험한 콘텐츠가 포함된 POST 본문은 차단됩니다.

예시

다음 예시에서 규칙 1, 2, 3은 IP 헤더 필드와 HTTP 헤더 필드의 순서로 평가됩니다. 그러나 IP 9.9.9.1HTTP POST 본문에서 XSS 공격을 시작하면 규칙 2에 의해 본문만 차단되고 HTTP 헤더는 규칙 3에 의해 백엔드로 전달됩니다.

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 2
Rule3
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 3
Rule-default
action: deny(403)
priority: INT-MAX

다음 예시에서 정책은 XSS 공격에 대한 검사 없이 IP 9.9.9.1을 허용합니다.

Rule1
expr: inIPRange(origin.ip, '10.10.10.0/24')
action: deny(403)
priority: 1
Rule2
expr: inIPRange(origin.ip, '9.9.9.0/24')
action: allow
priority: 2
Rule3
expr: evaluatePreconfiguredExpr('xss-stable')
action: deny(403)
priority: 3
Rule-default
action: allow
priority: INT-MAX

기본 규칙

각 Google Cloud Armor 보안 정책에는 일치하는 우선순위가 높은 규칙이 없거나 정책에 다른 규칙이 없는 경우에 일치하는 기본 규칙이 포함되어 있습니다. 기본 규칙은 자동으로 우선순위 2147483647(INT-MAX)에 할당되며 항상 보안 정책에 있습니다.

기본 규칙을 삭제할 수 없지만 수정할 수는 있습니다. 기본 규칙의 기본 작업은 거부이지만 허용하도록 작업을 변경할 수 있습니다.

디지털 지문

Google Cloud Armor 보안 정책마다 fingerprint 필드가 있습니다. 디지털 지문은 정책에 저장된 콘텐츠의 해시입니다. 새 정책을 만들 때 이 필드 값을 제공하지 마세요. 값을 제공하면 무시됩니다. 그러나 보안 정책을 업데이트하는 경우에는 정책을 내보내거나 설명할 때 가져오는 현재 디지털 지문을 지정해야 합니다.

디지털 지문은 다른 사용자의 업데이트가 우선 적용되지 못하도록 합니다. 제공한 디지털 지문이 오래된 경우 이는 디지털 지문을 마지막으로 검색한 이후에 보안 정책이 업데이트되었음을 의미합니다. 차이점을 확인하고 최신 디지털 지문을 검색하려면 보안 정책을 설명합니다.

WebSocket 연결 처리 방법

외부 HTTP(S) 부하 분산은 기본적으로 WebSocket 프로토콜을 지원합니다. WebSocket 채널은 HTTP(S) 요청에서 시작됩니다. 예를 들어 IP 주소 차단 목록에서 발신 IP 주소를 차단하는 경우 Google Cloud Armor는 WebSocket 채널이 설정되지 않도록 이 채널을 차단할 수 있습니다. 그러나 채널의 후속 트랜잭션은 HTTP 프로토콜을 준수하지 않으며 Google Cloud Armor는 첫 번째 요청 후에 어떠한 메시지도 평가하지 않습니다.

Google Cloud Armor 보안 정책

다음 섹션에서는 Google Cloud Armor가 다른 Google Cloud 기능 및 제품과 상호작용하는 방법을 설명합니다.

Google Cloud Armor 및 VPC 방화벽 규칙

Google Cloud Armor 보안 정책과 VPC 방화벽 규칙의 기능은 서로 다릅니다.

  • Google Cloud Armor 보안 정책은 에지 보안을 제공하고 Google 프런트엔드(GFE)에 대한 클라이언트 트래픽에서 작동합니다.
  • VPC 방화벽 규칙은 백엔드의 트래픽을 허용하거나 거부합니다. 대상이 부하 분산된 백엔드 VM이고 소스가 외부 HTTP(S) 부하 분산기에서 사용하는 IP 범위인 인그레스 허용 방화벽 규칙을 만들어야 합니다. 이러한 규칙을 통해 GFE와 상태 확인 시스템이 백엔드 VM과 통신할 수 있습니다.

예를 들어 CIDR 범위 100.1.1.0/24 및 CIDR 범위 100.1.2.0/24의 트래픽만 외부 HTTP(S) 부하 분산기에 액세스하도록 허용하는 시나리오를 가정합니다. 목표는 트래픽이 백엔드 부하 분산 인스턴스에 직접 도달하지 못하게 하는 것입니다. 즉, 관련 보안 정책이 있는 외부 HTTP(S) 부하 분산기를 통해 프록시된 외부 트래픽만 인스턴스에 도달해야 합니다.

인그레스 방화벽과 함께 Google Cloud Armor 보안 정책을 사용하여 액세스 제한
인그레스 방화벽과 함께 Google Cloud Armor 보안 정책을 사용하여 액세스 제한(확대하려면 클릭)

앞선 이미지에서는 다음과 같이 Google Cloud 배포를 구성하여 보안 목표를 달성했습니다.

  1. 인스턴스 그룹을 us-west1 리전과 europe-west1 리전에 있게 하여 두 개 만듭니다.
  2. 백엔드 애플리케이션 인스턴스를 인스턴스 그룹의 VM에 배포합니다.
  3. 프리미엄 등급에서 외부 HTTP(S) 부하 분산기를 만듭니다. 백엔드가 이전 단계에서 만든 인스턴스 그룹 두 개인 단순 URL 맵과 단일 백엔드 서비스를 구성합니다. 부하 분산기의 전달 규칙이 120.1.1.1 외부 IP 주소를 사용하는지 확인합니다.
  4. 100.1.1.0/24 및 100.1.2.0/24에서 들어오는 트래픽을 허용하고 그 외 모든 트래픽을 거부하는 Google Cloud Armor 보안 정책을 구성합니다.
  5. 이 정책을 부하 분산기의 백엔드 서비스에 연결합니다. 자세한 내용은 보안 정책 구성을 참조하세요. 보다 복잡한 URL 맵을 사용하는 외부 HTTP(S) 부하 분산기는 백엔드 서비스 여러 개를 참조할 수 있습니다. 필요에 따라 보안 정책을 백엔드 서비스 한 개 이상에 연결할 수 있습니다.
  6. 외부 HTTP(S) 부하 분산기에서 들어오는 트래픽을 허용하도록 인그레스 허용 방화벽 규칙을 구성합니다. 자세한 내용은 방화벽 규칙을 참조하세요.

HTTP(S) 부하 분산과 IAP가 포함된 Google Cloud Armor

IAP(Identity-Aware Proxy)는 사용자 ID를 확인한 후 이 사용자가 애플리케이션에 액세스하도록 허용할지 여부를 결정합니다. 외부 HTTP(S) 부하 분산기에 IAP를 사용 설정하려면 부하 분산기의 백엔드 서비스에서 사용 설정합니다. 마찬가지로 에지 Google Cloud Armor 보안 정책은 외부 HTTP(S) 부하 분산기의 백엔드 서비스에 연결됩니다.

외부 HTTP(S) 부하 분산기의 백엔드 서비스에 Google Cloud Armor 보안 정책과 IAP를 모두 사용 설정한 경우 IAP가 먼저 평가됩니다. IAP가 요청을 차단하면 Google Cloud Armor는 요청을 평가하지 않습니다. IAP가 성공적으로 요청을 인증하면 Google Cloud Armor에서 요청을 평가합니다. Google Cloud Armor 보안 정책에서 거부하면 요청이 차단됩니다.

IAP와 함께 IP 주소 차단 목록과 허용 목록 사용
IAP와 함께 IP 주소 차단 목록과 허용 목록 사용(확대하려면 클릭)

IAP 및 관련 구성에 대한 자세한 내용은 IAP(Identity-Aware Proxy) 문서를 참조하십시오.

하이브리드 배포가 포함된 Google Cloud Armor

하이브리드 배포에서 Google Cloud 부하 분산기는 다른 클라우드 제공업체의 인프라와 같이 Google Cloud 외부에서 실행되는 애플리케이션이나 콘텐츠 소스에 액세스해야 합니다. Google Cloud Armor를 사용하여 이러한 배포를 보호할 수 있습니다.

다음 다이어그램에서 부하 분산기에는 백엔드 서비스 두 개가 있습니다. 한 서비스에는 인스턴스 그룹이 백엔드로 있습니다. 다른 백엔드 서비스에는 인터넷 NEG가 백엔드로 있으며 인터넷 NEG는 타사 제공업체의 데이터 센터에서 실행되는 애플리케이션과 연결됩니다.

하이브리드 배포에 사용되는 Google Cloud Armor
하이브리드 배포에 사용되는 Google Cloud Armor(확대하려면 클릭)

Google Cloud Armor 보안 정책을 인터넷 NEG가 백엔드로 있는 백엔드 서비스에 연결하면 Google Cloud Armor는 백엔드 서비스를 대상으로 하는 외부 HTTP(S) 부하 분산기에 도착하는 모든 L7 요청을 검사합니다.

하이브리드 배포에 사용되는 Google Cloud Armor 보호 조치에는 인터넷 NEG에 적용되는 제한사항과 동일한 제한사항이 적용됩니다.

Cloud CDN이 포함된 Google Cloud Armor

CDN 원본 서버를 보호하려면 Cloud CDN과 함께 Google Cloud Armor를 사용하면 됩니다. Google Cloud Armor는 CDN 원본 서버가 애플리케이션 공격으로부터 보호되고 OWASP Top 10 위험을 완화하며 레이어 7 필터링 정책을 시행하도록 합니다.

Google Cloud Armor는 캐시 부적중 즉, Cloud CDN 캐시를 누락하거나 우회하는 요청에만 Cloud CDN을 사용 설정하여 백엔드 서비스의 보안 정책을 시행합니다.

보안 정책이 Cloud CDN이 사용 설정된 백엔드 서비스에 연결되면 Google Cloud Armor는 보안 정책에 대해 캐시에서 제공할 수 없는 들어오는 요청을 평가하여 요청을 원래 서버로 전달해야 하는지 여부를 결정합니다. 규칙이 요청에서 일치하면 규칙에 구성된 작업이 수행됩니다.

그러나 Cloud CDN이 사용 설정된 백엔드 서비스에 연결된 보안 정책은 캐시 적중에 적용되지 않습니다. 캐시에서 요청을 제공할 수 있으면 보안 정책이 이 요청에 수행한 작업에 관계없이 유효한 클라이언트에 제공됩니다.

다음 다이어그램에서는 Google Cloud Armor가 Cloud CDN 원본과 함께 작동하는 방식을 보여줍니다.

Cloud CDN이 포함된 Google Cloud Armor 사용
Cloud CDN이 포함된 Google Cloud Armor 사용(확대하려면 클릭)

서버리스 앱이 포함된 Google Cloud Armor

Google Cloud Armor 보안 정책을 Cloud Run, App Engine 또는 Cloud Functions 서비스를 가리키는 서버리스 NEG 백엔드와 함께 사용할 수 있습니다.

하지만 Google Cloud Armor를 서버리스 NEG 및 Cloud Functions와 함께 사용하는 경우에는 특별한 단계를 수행해야만 보안 문제를 해결할 수 있습니다.

Cloud Functions 서비스의 기본 URL이 있는 사용자는 부하 분산기를 우회하고 서비스 URL로 직접 이동할 수 있습니다. 그러면 Google Cloud Armor 보안 정책을 우회하게 됩니다. Google Cloud에서 Cloud Functions 서비스에 자동으로 할당하는 URL을 중지할 수 없습니다.

이러한 보안 위험을 방지하려면 Cloud Functions를 구성할 때 internal-and-gclb를 사용합니다. 그러면 외부 HTTP(S) 부하 분산기에서 노출된 공개 IP 주소로 전송되는 트래픽과 내부 트래픽만 허용됩니다. cloudfunctions.net 또는 Cloud Functions를 통해 설정된 다른 커스텀 도메인으로 전송된 트래픽은 차단됩니다. 이렇게 하면 사용자가 외부 HTTP(S) 부하 분산기를 통해 설정된 액세스 제어(예: Google Cloud Armor 보안 정책)를 우회할 수 없습니다.

서버리스 NEG에 대한 자세한 내용은 서버리스 네트워크 엔드포인트 그룹 개요서버리스 NEG 설정을 참조하세요.

일반적인 사용 사례

이 섹션에서는 Google Cloud Armor 보안 정책의 일반적인 사용 사례 여러 개를 보여줍니다.

사용 사례 1: Google Cloud 외부 HTTP(S) 부하 분산기 액세스 제한

허용 목록에 사용자 IP 주소를 배치하는 일반적인 사용 사례는 외부 HTTP(S) 부하 분산기를 특정 사용자 집합에서만 사용하는 경우입니다. 다음 예시에서는 조직의 사용자만 부하 분산기 뒤에 있는 서비스에 액세스할 수 있습니다. 이러한 사용자에게는 조직에서 할당한 IP 주소나 주소 블록이 있습니다. 이러한 사용자만 부하 분산기에 액세스하도록 이러한 IP 주소나 CIDR 범위를 허용 목록에 배치할 수 있습니다.

허용 목록을 사용하여 부하 분산기 액세스 제한
허용 목록을 사용하여 부하 분산기 액세스 제한(확대하려면 클릭)

부하 분산기에 대한 액세스가 허용되는 소스 IP 주소나 소스 CIDR 범위로 허용 목록을 구성하여 외부 HTTP(S) 부하 분산기에 대한 액세스를 제어합니다. 다음 섹션에서는 이 구성을 자세히 설명합니다.

이 구성에서 203.0.113.0/24의 IP 주소가 있는 조직의 사용자만 외부 HTTP(S) 부하 분산기에 액세스할 수 있도록 합니다. 다른 모든 트래픽이 거부되게 하려고 합니다.

이 구성을 만들려면 다음 단계를 수행하세요.

  1. Google Cloud Armor 보안 정책을 만듭니다.
  2. 보안 정책에서 203.0.113.0/24를 허용 목록에 첫 번째 규칙으로 추가하는 규칙을 추가합니다. 이 규칙의 설명은 allow 203.0.113.0/24입니다.
  3. 정책의 기본 규칙을 허용 규칙에서 차단 규칙으로 수정합니다. 기본 규칙은 앞의 규칙과 일치하지 않는 트래픽을 관리합니다. 정책의 마지막 규칙입니다. 규칙을 allow에서 deny로 변경하면 허용 목록에 있는 203.0.113.0/24 범위에서 발생하지 않는 모든 트래픽이 차단됩니다.
  4. 이 정책을 외부 HTTP(S) 부하 분산기의 백엔드 서비스에 연결합니다.

사용 사례 2: 차단 목록으로 에지에서 무단 또는 악의적인 트래픽 차단

차단 목록을 사용하여 IP 주소나 CIDR 범위에서 들어오는 트래픽을 거부하는 Google Cloud Armor 보안 정책을 만듭니다. 다음 이미지에서 Google Cloud Armor 보안 정책에는 악의적인 사용자로 식별된 IP 주소 198.51.100.1에서 들어오는 트래픽을 차단하는 deny 규칙이 있습니다.

차단 목록을 사용하여 부하 분산기 액세스 제한
차단 목록을 사용하여 부하 분산기 액세스 제한(확대하려면 클릭)

사용 사례 3: 타사 보안 제공업체 및 다른 승인된 사용자의 외부 HTTP(S) 부하 분산기에 대한 트래픽만 허용

조직에서 타사 보안 제공업체를 사용하여 트래픽을 스크러빙하는 경우 스크러빙된 트래픽만 외부 HTTP(S) 부하 분산기와 백엔드에 액세스할 수 있게 하는 보안 제공업체의 IP 주소를 허용 목록에 추가할 수 있습니다.

다음 이미지에서 타사 제공업체는 CIDR 범위 192.0.2.0/24로 식별되며 이 범위는 허용 목록에 있습니다.

타사 보안 제공업체의 트래픽을 허용 목록에 추가하여 부하 분산기 액세스 제한
타사 보안 제공업체의 트래픽을 허용 목록에 추가하여 부하 분산기 액세스 제한(확대하려면 클릭)

사용 사례 4: 레이어 3~7 매개변수와 일치하는 커스텀 규칙을 사용하여 방어 맞춤설정

Google Cloud Armor 커스텀 규칙 언어를 사용하여 규칙의 일치 조건에서 표현식을 한 개 이상 정의합니다. Google Cloud Armor는 요청을 받으면 이러한 표현식과 비교하여 요청을 평가합니다. 일치 항목이 있으면 들어오는 트래픽을 거부하거나 허용하는 규칙 작업이 적용됩니다.

다음 예시는 Common Expression Language(CEL)의 Google Cloud Armor 확장 프로그램으로 작성된 표현식입니다. 자세한 내용은 커스텀 규칙 언어 참조를 확인하세요.

규칙에 표현식을 정의하려면 gcloud --expression 플래그나 Google Cloud Console을 사용합니다. 자세한 내용은 Google Cloud Armor 보안 정책, 규칙, 표현식 만들기를 참조하세요.

다음 예시에서 AU 리전에 있는 2001:db8::/32(예: 알파 테스터)의 요청은 다음 표현식과 일치합니다.

origin.region_code == "AU" && inIpRange(origin.ip, '2001:db8::/32')

다음 예시는 1.2.3.4의 요청과 WordPress 문자열을 포함하는 사용자 에이전트와 일치합니다.

inIpRange(origin.ip, '1.2.3.4/32') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')

추가 예시는 커스텀 규칙 언어 참조의 예시 표현식을 참조하세요.

사용 사례 5: 사전 구성된 규칙을 사용하여 애플리케이션 레이어 공격 완화

사전 구성된 규칙을 사용하여 XSS 및 SQLi와 같은 일반적인 애플리케이션 레이어 공격을 탐지하고 차단합니다. 사전 구성된 규칙은 Google Cloud Armor 보안 정책에 추가할 수 있는 사전 정의된 표현식 세트입니다. 이러한 표현식 세트를 규칙에 추가하려면 gcloud --expression 플래그나 Cloud Console을 사용합니다. 자세한 내용은 Google Cloud Armor 보안 정책, 규칙, 표현식 만들기를 참조하세요.

사전 구성된 규칙에 대한 자세한 내용은 커스텀 규칙 언어 참조의 사전 구성된 규칙을 참조하세요.

다음 예시에서는 사전 구성된 규칙을 사용하여 교차 사이트 스크립팅(XSS) 공격을 완화합니다.

evaluatePreconfiguredExpr('xss-stable')

다음 예시에서는 사전 구성된 규칙을 사용하여 SQL 주입(SQLi) 공격을 완화합니다.

evaluatePreconfiguredExpr('sqli-stable')

사전 구성된 규칙을 다른 표현식과 결합할 수도 있습니다. 다음 예시에서는 사전 구성된 규칙을 사용하여 1.2.3.0/24 IP 주소 범위에서 SQLi 공격을 완화합니다.

inIpRange(origin.ip, '1.2.3.0/24') && evaluatePreconfiguredExpr('sqli-stable')

하이브리드 배포 사용 사례

이 섹션에서는 하이브리드 배포가 포함된 Google Cloud Armor 보안 정책의 사용 사례를 보여줍니다.

사용 사례: 하이브리드 워크로드의 OWASP 완화 상위 10개

Google Cloud Armor는 애플리케이션이 Google Cloud, 온프레미스 또는 타사 제공업체에 배포되었는지 여부에 관계없이 애플리케이션에 SQL 주입(SQLi)과 교차 사이트 스크립팅(XSS)을 완화합니다. 이러한 기능을 사용하면 OWASP 상위 10개 목록에서 식별된 위험을 비롯한 가장 일반적인 웹 애플리케이션 보안 위험 일부를 해결할 수 있습니다.

Google Cloud Armor의 사전 구성된 WAF 규칙을 보안 정책에 추가하여 SQLi 또는 XSS 시도를 비롯한 원치 않는 레이어 7 요청을 감지하고 거부할 수 있습니다. Google Cloud Armor는 악의적인 요청을 감지하여 Google 인프라의 에지에서 삭제합니다. 백엔드 서비스가 배포된 위치에 관계없이 요청이 백엔드 서비스로 프록시되지 않습니다.

Google 네트워크 에지에서 SQLi 또는 XSS 공격으로부터 Google Cloud에서 호스팅하지 않는 워크로드를 보호하려면 다음 단계를 수행합니다.

  1. 인터넷 NEG가 백엔드로 있는 백엔드 서비스를 사용하여 외부 HTTP(S) 부하 분산기를 구성합니다.
  2. Google Cloud Armor 보안 정책을 만듭니다.
  3. 정책에 SQLi 규칙과 XSS 규칙을 추가합니다.
  4. 1단계에서 만든 백엔드 서비스에 보안 정책을 연결합니다.
  5. Cloud Logging, Cloud Monitoring, Security Command Center로 전송된 발견 항목을 사용하여 Google Cloud Armor 활동을 모니터링합니다.

사용 사례: Cloud CDN 외부 원본 서버 DDoS 방어 및 레이어 7 모니터링

외부 원본 서버를 사용한 Cloud CDN 배포에는 Google의 에지 인프라가 프록시, 캐싱, Google Cloud Armor 레이어 7 필터링에 사용되는 프런트엔드로 있을 수 있습니다. 원본 서버는 인터넷 NEG를 사용하여 온프레미스 또는 타사 인프라 제공업체와 함께 위치할 수 있습니다.

Google Cloud Armor와 나머지 Google 에지 인프라는 L3/L4 공격을 완화 및 제거하고, 의심스러운 레이어 7 활동을 경고하며, 커스텀 규칙으로 원치 않는 레이어 7 요청을 거부할 수 있습니다. Cloud Logging, Cloud Monitoring, Security Command Center의 Google Cloud Armor 로깅 및 원격 분석은 배포된 위치와 관계없이 보호된 애플리케이션의 활용 가능한 분석 정보를 제공합니다.

CDN 외부 원본 서버에 Google Cloud Armor 보호를 사용 설정하려면 다음 단계를 수행합니다.

  1. 인터넷 NEG가 백엔드로 있는 백엔드 서비스를 사용하여 외부 HTTP(S) 부하 분산기를 구성합니다.
  2. 이 백엔드 서비스에 Cloud CDN을 사용 설정합니다.
  3. Google Cloud Armor 보안 정책을 만듭니다.
  4. 1단계에서 만든 백엔드 서비스에 보안 정책을 연결합니다.
  5. Security Command Center, Cloud Logging, Cloud Monitoring에서 Google Cloud Armor 알림, 로깅, 원격 분석에 액세스합니다.

Cloud CDN 사용 사례

이 섹션에서는 Cloud CDN이 포함된 Google Cloud Armor의 두 가지 사용 사례를 설명합니다.

사용 사례: SQLi 및 XSS 완화

Google Cloud Armor를 사용하면 SQL 주입(SQLi) 공격 및 교차 사이트 스크립팅(XSS) 공격과 같은 위험으로부터 Cloud CDN 원본 서버를 보호할 수 있습니다. 캐시 콘텐츠는 정적이며 웹에서 공격 대상이 될 위험이 없습니다. 그러나 기본 콘텐츠 원본 서버는 알려지거나 잠재적인 웹 앱 취약점이 있는 동적 애플리케이션일 수 있습니다. 보안 또는 규정 준수 요구사항에 따라 인터넷 취약점을 악용해 원본 서버를 공격하지 못하도록 이러한 위험을 완화해야 할 수도 있습니다.

위험을 완화하려면 다음 단계를 수행합니다.

  1. CDN을 사용 설정하여 백엔드 서비스를 만들거나 식별합니다.
  2. Google Cloud Armor 보안 정책을 만듭니다.
  3. 보안 정책에 규칙을 한 개 이상 만들어 XSS 공격과 SQLi 공격을 거부합니다.
  4. 보안 정책의 대상 중 하나를 1단계에서 만들거나 식별한 백엔드 서비스로 구성합니다.

사용 사례: 레이어 7 액세스 제어 및 캐시 무효화 공격

애플리케이션 아키텍처에 따라 캐시할 수 있고 캐시할 수 없는 콘텐츠를 포함하여 다양한 URL에 요청을 제공하도록 백엔드 서비스 하나를 구성할 수 있습니다. 이러한 배포 시나리오에서는 특정 요청 경로에서 원치 않는 트래픽을 거부하지만 모든 클라이언트가 다른 요청 경로에서 정적 콘텐츠에 액세스할 수 있게 하는 Google Cloud Armor 보안 정책을 만듭니다.

다른 상황에서는 콘텐츠가 캐시에서 효율적으로 제공되고 있지만 악의적이거나 잘못된 클라이언트에서 요청을 대량 생성하여 캐시 부적중이 발생하고 이로 인해 기본 원본 서버가 요청된 콘텐츠를 가져오거나 생성해야 할 수 있습니다. 이로 인해 제한된 리소스가 부족해지고 모든 사용자의 애플리케이션 가용성이 부정적인 영향을 받을 수 있습니다. 문제의 원인인 모든 클라이언트의 서명과 일치하도록 Google Cloud Armor 보안 정책을 만들어 요청이 원본 서버에 도달하여 성능에 영향을 미치기 전에 요청을 거부할 수 있습니다.

이를 달성하려면 다음 단계를 수행합니다.

  1. Google Cloud Armor 보안 정책을 만듭니다.
  2. 규칙을 구성합니다. 예를 들어 다음 규칙은 "/admin"에 대한 액세스를 거부합니다.

    request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>'
    
  3. 1단계에서 만든 보안 정책을 Cloud CDN이 사용 설정된 백엔드 서비스에 연결합니다.

HTTP(S) 부하 분산 요청 로깅

각 HTTP(S) 요청은 Cloud Logging을 통해 로깅됩니다. 로그는 적용된 보안 정책의 이름, 일치 규칙, 규칙 적용 여부와 같은 세부정보를 제공합니다. 새 백엔드 서비스 리소스의 요청 로깅은 기본적으로 중지되어 있습니다. Google Cloud Armor 요청이 로깅되도록 하려면 HTTP(S) 로깅을 사용 설정해야 합니다.

자세한 내용은 IP 차단 목록/허용 목록 로깅을 참조하세요.

Google Cloud Armor 로그를 보려면 로그 보기를 참조하세요.

제한사항

  • Cloud Storage 백엔드 버킷에는 HTTP(S) 부하 분산에 대한 IP 주소 차단 목록/허용 목록이 지원되지 않습니다.

  • 내부 HTTP(S) 부하 분산에서는 Google Cloud Armor가 지원되지 않습니다.

  • CDN 캐시 부적중에만 보안 정책이 적용됩니다. 보안 정책의 규칙이 요청을 거부하더라도 캐시에서 콘텐츠가 제공됩니다.

  • gcloud 명령줄 도구와 gcloud compute security-policies rules update--preview 플래그를 사용하여 규칙에 미리보기 모드를 사용 설정할 수 있습니다.

    미리보기 모드를 중지하려면 현재 문서화되지 않은 --no-preview 플래그를 사용합니다. Cloud Console을 사용할 수도 있습니다.

다음 단계