보안 규칙

이 페이지에서는 게이트웨이 보안 규칙과 이를 만드는 방법을 설명합니다.

Secure Web Proxy를 사용하면 게이트웨이 보안 정책 내에서 다양한 유형의 보안 규칙을 정의하여 아웃바운드 웹 트래픽을 보호할 수 있습니다. 이러한 규칙을 사용하여 헤더 및 URL 패턴과 같은 특정 요청 세부정보를 사용하여 트래픽의 보안을 정확하게 제어하여 승인된 HTTP/S 트래픽만 네트워크를 벗어나도록 할 수 있습니다.

게이트웨이 보안 규칙에는 다음과 같은 기능이 있습니다.

  • 각 규칙은 웹 요청을 다음 매개변수와 비교하여 확인하는 if-then 문입니다.

    • 소스 ID: 요청을 하는 주체입니다. 특정 가상 머신 (VM) 또는 서비스 계정과 같습니다.

    • 대상: 요청이 이동하는 도착 URL 또는 trusted-partner.com과 같은 도메인입니다.

    • 작업: 트래픽을 허용할지 거부할지 결정합니다.

  • 게이트웨이 보안 규칙은 세분화된 제어를 제공합니다. 이러한 규칙을 사용하면 명확하고 구조화된 정의를 사용하여 조직 전체에 다양한 보안 표준을 적용할 수 있습니다.

호스트 일치 규칙

Secure Web Proxy는 호스트 이름 일치를 사용하여 대상 도메인을 확인합니다. 확인 프로세스는 다음 표와 같이 프록시가 배포되는 방식에 따라 다릅니다.

배포 모드 호스트 확인 프로세스
명시적 프록시 모드 암호화되지 않은 트래픽의 경우 프록시는 호스트 이름 을 HTTP 연결 헤더와 비교하여 확인합니다. TLS 검사에 애플리케이션 일치자 속성 를 사용하는 경우 프록시는 먼저 연결 수준에서 호스트 이름을 확인한 다음 애플리케이션 수준에서 확인합니다.
다음 홉 모드 암호화된 트래픽의 경우 프록시는 대상 호스트 이름을 아웃바운드 요청의 서버 이름 표시 (SNI) 필드와 비교하여 확인합니다. 이 필드는 보안 연결에서도 표시됩니다.

명시적 프록시 모드의 호스트 일치 규칙 구성

Secure Web Proxy를 명시적 프록시로 배포할 때는 클라이언트에서 전송한 호스트 정보가 올바르게 추출되고 정의된 보안 규칙과 비교하여 확인되도록 호스트 일치 규칙을 구성합니다. 명시적 프록시 모드에서 클라이언트는 트래픽을 Secure Web Proxy 인스턴스로 직접 전송하도록 적극적으로 구성됩니다.

명시적 프록시 모드의 호스트 일치는 다음과 같은 방식으로 다양한 유형의 웹 트래픽에 적용됩니다.

트래픽 유형 일치 메커니즘 규칙 구성
암호화되지 않은 HTTP Secure Web Proxy는 대상 호스트 이름을 표준 CONNECT 헤더의 host 필드와 비교하여 확인합니다. sessionMatcher 필드에서 host() == "example.com"을 사용합니다.
암호화된 HTTPS (전송 계층 보안 (TLS) 검사 없음) 애플리케이션 수준 또는 세션 수준에서 호스트 일치가 불가능합니다. 이는 요청 세부정보가 암호화되고 destination.ip 속성이 지원되지 않기 때문입니다. 소스 ID 일치와 같은 더 광범위한 정책 제어를 사용하거나 호스트 기반 필터링을 위해 TLS 검사를 사용 설정해야 합니다. 애플리케이션 일치자를 사용하려면 서비스 계정과 같은 소스 ID 일치를 사용하거나 TLS 검사를 사용 설정합니다.
암호화된 HTTPS (TLS 검사 포함) 전체 요청을 검사하려면 세션 일치자와 애플리케이션 일치자를 모두 사용해야 합니다. 1. `true`를 반환하거나 true host() == "example.com"과 같은 대상 호스트와 일치하는 일반 세션 일치자 규칙을 설정합니다.

2. applicationMatcher 필드에서 특정 호스트 규칙(예: request.host() == "example.com")을 추가합니다.

다음 홉 모드의 호스트 일치 규칙 구성

Secure Web Proxy를 다음 홉으로 배포할 때는 호스트 일치 규칙을 구성해야 합니다. 트래픽은 정의한 IP 주소 범위를 기반으로 가상 프라이빗 클라우드 (VPC) 경로를 통해 프록시로 리디렉션됩니다. 호스트 일치 규칙은 프록시가 서버 이름 표시 (SNI) 헤더와 같은 트래픽의 다양한 필드를 확인하여 대상 호스트를 올바르게 식별하도록 합니다.

다음 홉 모드의 호스트 일치는 다음과 같은 방식으로 다양한 유형의 웹 트래픽에 적용됩니다.

트래픽 유형 일치 메커니즘 규칙 구성
암호화되지 않은 HTTP Secure Web Proxy는 대상 호스트 이름을 표준 HTTP 요청 헤더에 있는 host 필드와 비교하여 확인합니다. sessionMatcher 필드에서 host() == "example.com"을 사용합니다.
암호화된 HTTPS (TLS 검사 없음) Secure Web Proxy는 트래픽의 나머지 부분이 암호화되어 있더라도 표시되는 아웃바운드 요청의 SNI 헤더와 비교하여 호스트 이름을 확인합니다. sessionMatcher 필드에서 host() == "example.com"을 사용합니다.
암호화된 HTTPS (TLS 검사 포함) 전체 요청을 검사하려면 세션 일치자와 애플리케이션 일치자를 모두 사용해야 합니다. 1. `true`를 반환하거나 true host() == "example.com"과 같은 대상 호스트와 일치하는 일반 세션 일치자 규칙을 설정합니다.

2. applicationMatcher 필드에서 request.host() == "example.com"과 같은 특정 호스트 규칙을 추가합니다.

TCP 프록시 규칙

전송 제어 프로토콜 (TCP) 프록시 규칙을 사용하면 HTTP (포트 80) 또는 HTTPS (포트 443)와 같은 표준 웹 트래픽이 아닌 트래픽을 제어할 수 있습니다. TCP 프록시 규칙을 구성하면 다른 TCP 포트에서 트래픽을 허용하거나 차단할 수 있습니다. 이러한 규칙은 악성 트래픽을 차단하고 TCP를 사용하는 비웹 애플리케이션을 관리하는 데 도움이 됩니다.

애플리케이션 및 서비스와 같은 워크로드가 Secure Web Proxy를 다음 홉으로 사용하는 경우, TCP 프록시 규칙을 적용하는 것이 좋습니다. 경로 기반 리디렉션은 HTTP(S)가 아닌 트래픽과 웹이 아닌 트래픽을 Secure Web Proxy 인스턴스로 전달합니다. 이렇게 하면 악성 외부 사이트에 도달하는 아웃바운드 트래픽을 차단하고 네트워크 워크로드가 연결할 수 있는 외부 서비스를 관리할 수 있습니다.

TCP 프록시 규칙 구성

애플리케이션의 TCP 프록시 규칙을 구성하여 웹이 아닌 트래픽을 보호하고 포트 80443과 같이 표준 HTTP/S를 사용하지 않는 애플리케이션에 보안 정책을 적용할 수 있습니다.

이러한 규칙을 적용하면 데이터 전송 또는 악성 활동을 위해 다른 TCP 포트를 무단으로 사용하는 것을 방지할 수 있습니다. 이는 워크로드가 웹이 아닌 프로토콜의 다음 홉으로 보안 웹 프록시를 사용하는 경우 특히 유용합니다.

TCP 프록시 규칙을 구현하고 애플리케이션의 트래픽 허용 또는 차단 규칙을 만들려면 대상 포트를 지정해야 합니다. 선택적으로 다음 세션 일치자 속성을 포함하여 허용 또는 차단 규칙의 기준을 세부적으로 조정할 수 있습니다.

다음 표에서는 TCP 프록시 규칙에서 사용할 수 있는 다양한 속성에 대한 자세한 정보를 제공합니다.

속성 속성 유형 설명
source.ip 문자열 요청을 보낸 클라이언트의 IP 주소입니다.
source.port 문자열 요청을 보낸 클라이언트 포트입니다.
destination.port 문자열 Secure Web Proxy 인스턴스가 트래픽을 전송하는 업스트림 포트입니다.
source.matchTag(SECURE_TAG) 부울

True 소스가 와 연결된 경우 SECURE_TAG입니다.

인수는 source.matchTag('tagValues/123456')과 같은 보안 태그의 영구 ID입니다.

source.matchServiceAccount(SERVICE_ACCOUNT) 부울 True 소스가 SERVICE_ACCOUNT와 같은 source.matchServiceAccount('x@my-project.iam.gserviceaccount.com')와 연결된 경우입니다.
inIpRange(IP_ADDRESS,
IP_RANGE)
부울 TrueIP_ADDRESSIP_RANGE 내에 inIpRange(source.ip, '1.2.3.0/24')과 같이 포함된 경우입니다. IPv6 주소의 서브넷 마스크는 `/64`보다 클 수 없습니다.

TCP 프록시 규칙 예시

이 예에서는 gatewaySecurityPolicyRuleCEL 표현식을 사용하여 모든 TCP 트래픽을 포트 22로 허용하는 Secure Web Proxy를 정의하는 방법을 보여줍니다. 보안 웹 프록시의 TCP 프록시 기능을 적용할 때 이 구성을 사용할 수 있습니다.

다음 코드 샘플은 TCP 프록시 규칙을 정의하는 방법을 보여줍니다.

name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/POLICY_NAME/rules/RULE_NAME
enabled: true
priority: 100 # Lower numbers have higher priority
description: "Allow TCP proxy traffic to port 22 - such as, for SSH"
basicProfile: ALLOW
sessionMatcher: "destination.port == 22"

다음을 바꿉니다.

  • PROJECT_ID: 프로젝트의 ID
  • REGION: 정책의 리전
  • POLICY_NAME: 정책의 이름
  • RULE_NAME: TCP 프록시 규칙의 이름입니다. 이 예에서는 값을 allow-ssh-tcp-proxy로 간주할 수 있습니다.

중요 고려사항

  • 구성하는 모든 TCP 프록시 규칙은 먼저 평가되고 적용되도록 HTTP/S 규칙보다 우선순위가 높아야 합니다 (숫자가 낮음). 자세한 내용은 규칙 평가 순서를 참조하세요.

  • TCP 프록시 규칙을 구성할 때는 TCP 계층에서 호스트 정보를 사용할 수 없으므로 host 세션 일치자 속성이 지원되지 않습니다.

  • TCP 프록시 규칙은 대상 포트만을 기준으로 웹 트래픽을 필터링합니다. 네트워크의 보안을 강화하려면 논리 연산자 논리적 AND 연산자 (&&) 및 논리적 OR 연산자 (||)와 source.ip와 같은 지원되는 속성을 사용하여 다른 조건을 추가하는 것이 좋습니다. 다음은 더 구체적인 TCP 프록시 규칙을 정의하는 방법의 예입니다.

      // Allow port 22 from only a specific source IP range
      sessionMatcher: "destination.port == 22 && inIpRange(source.ip, '10.0.0.0/24')"
    
  • Secure Web Proxy는 사용자 데이터그램 프로토콜 (UDP) 애플리케이션의 프록시 규칙을 구성하는 기능을 지원하지 않습니다. 따라서 Secure Web Proxy는 UDP 기반 애플리케이션의 트래픽을 차단합니다.

보안 규칙 만들기

게이트웨이 보안 규칙을 만들기 전에 다음 작업을 수행해야 합니다.

  1. 모든 초기 설정 단계를 완료합니다.

  2. 정책 만들기

규칙을 만들고 정책과 연결한 후 Secure Web Proxy를 배포할 때 규칙을 사용할 수 있습니다.

콘솔

  1. 콘솔 Google Cloud 에서 SWP 정책 페이지로 이동합니다.

    SWP 정책으로 이동

  2. 정책 이름(예: policy1)을 클릭합니다.

  3. 규칙 추가 를 클릭합니다.

  4. 각 규칙에 대해 다음을 실행합니다.

    1. 우선순위에 규칙의 평가 순서(번호순)를 입력합니다. 규칙은 가장 높은 우선순위에서 가장 낮은 우선순위로 평가되며 0이 가장 높은 우선순위입니다.

    2. 이름 필드에 규칙 이름을 입력합니다.

    3. 설명 필드에 규칙에 대한 설명을 입력합니다.

    4. 작업에서 다음 옵션 중 하나를 선택합니다.

      • 허용: 규칙과 일치하는 연결 요청을 허용합니다.
      • 거부: 규칙과 일치하는 연결 요청을 거부합니다.
    5. 상태 필드에서 규칙 적용을 위한 다음 옵션 중 하나를 선택합니다.

      • 사용 설정됨: Secure Web Proxy 인스턴스에 규칙을 적용합니다.
      • 사용 중지됨: Secure Web Proxy 인스턴스에 규칙을 적용하지 않습니다.
    6. 세션 일치 섹션에서 세션을 일치시키는 기준(예: host() == "www.wikipedia.org")을 지정합니다.

      SessionMatcher의 구문에 대한 자세한 내용은 CEL 일치자 언어 참조를 확인하세요.

    7. 애플리케이션 일치 섹션에서 요청을 일치시키는 기준을 지정합니다.

      TCP 트래픽 일치에 대한 자세한 내용은 TCP 프록시 규칙 구성을 참조하세요.

    8. 규칙 추가 를 클릭합니다.

Cloud Shell

  1. 원하는 텍스트 편집기를 사용하여 rule.yaml 파일을 만듭니다. sessionMatcher의 구문에 대한 자세한 내용은 CEL 일치자 언어 참조를 확인하세요.

    name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/policy1/rules/RULE_NAME
    description: Allow wikipedia.org
    enabled: true
    priority: 1
    basicProfile: ALLOW
    sessionMatcher: host() == 'www.wikipedia.org'
    

    다음을 바꿉니다.

    • PROJECT_ID: 프로젝트의 ID
    • REGION: 정책의 리전
    • RULE_NAME: 규칙의 이름입니다. 이 예에서는 값을 allow-wikipedia-org로 간주할 수 있습니다.

    선택사항: 또는 TLS 검사가 사용 설정된 규칙을 만들려면 여기에 표시된 대로 rule.yaml 파일을 만듭니다. 자세한 내용은 TLS 검사 개요TLS 검사 사용 설정을 참조하세요.

      name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/policy1/rules/RULE_NAME
      description: Allow wikipedia.org
      enabled: true
      priority: 1
      basicProfile: ALLOW
      sessionMatcher: host() == 'www.wikipedia.org'
      applicationMatcher: request.path.contains('index.html')
      tlsInspectionEnabled: true
    

    TCP 트래픽 일치에 대한 자세한 내용은 TCP 프록시 규칙 구성을 참조하세요.

  2. 보안 정책 규칙을 만듭니다.

    gcloud network-security gateway-security-policies rules import allow-wikipedia-org \
        --source=rule.yaml \
        --location=REGION \
        --gateway-security-policy=policy1
    

제한사항

다음 단계