1. Introduction et présentation générale
DNS Armor, qui repose sur Infoblox, est un service entièrement géré qui assure la sécurité de la couche DNS pour vos charges de travail Google Cloud. Son détecteur de menaces avancé est conçu pour détecter les activités malveillantes au tout début de la chaîne d'attaque (la requête DNS), sans complexité opérationnelle ni impact sur les performances.
Cet atelier de programmation fournit des instructions détaillées pour configurer et tester le service DNS Armor. Vous allez configurer l'infrastructure réseau nécessaire, créer le détecteur de menaces, tester le service en simulant des menaces DNS et, enfin, analyser les journaux de menaces à l'aide de l'explorateur de journaux.
Objectifs de l'atelier
Dans cet atelier de programmation, vous allez provisionner les ressources suivantes :
- Deux réseaux VPC :
network-aetnetwork-b network-ainclura les sous-réseaux et les machines virtuelles dans les régionsus-east4etus-central1.network-binclura un sous-réseau et une machine virtuelle uniquement dansus-east4.- Un détecteur de menaces avancées DNS Armor configuré pour inspecter les requêtes DNS.

Points abordés
- Comment provisionner les ressources réseau nécessaires, y compris les VPC et les machines virtuelles.
- Découvrez comment déployer un détecteur de menaces avancées et exclure des réseaux spécifiques.
- Comment valider la configuration de la détection des menaces à l'aide d'un script de simulation des menaces.
- Découvrez comment analyser les journaux de menaces dans l'explorateur de journaux.
Prérequis
- Un projet Google Cloud.
- Accès à l'outil de ligne de commande
gcloud
2. Prérequis
Dans cette section, vous allez effectuer les tâches suivantes :
- Vérifiez que votre projet Google Cloud respecte les contraintes nécessaires des règles d'administration.
- Vérifiez que votre compte utilisateur dispose des rôles et autorisations IAM requis.
- Activez les API Google Cloud essentielles pour cet atelier de programmation.
- Attribuez le rôle IAM
roles/logging.viewerau compte de service Compute Engine.
Contraintes liées aux règles d'administration
Pour mener à bien cet atelier de programmation, veuillez vérifier les contraintes de règle d'administration appliquées à votre projet. Certaines règles peuvent entraver le provisionnement des ressources nécessaires. Les contraintes suivantes peuvent avoir un impact sur la configuration de cet atelier de programmation :
constraints/gcp.resourceLocations: limite les régions dans lesquelles vous pouvez créer des ressources. Cet atelier de programmation nécessiteus-east4etus-central1.constraints/compute.vmExternalIpAccess: empêche la création de machines virtuelles avec des adresses IP publiques, ce qui pourrait interférer avec la configuration si vous ne suivez pas l'utilisation de l'indicateur--no-addressdans l'atelier de programmation .constraints/compute.shieldedVm: force la création de VM protégées, que les commandes de création de VM du tutoriel ne spécifient pas, ce qui peut entraîner une erreur.constraints/gcp.restrictServiceUsage: limite les API Google Cloud qui peuvent être activées et peut bloquer l'atelier de programmation s'il n'autorise pascompute.googleapis.com,networksecurity.googleapis.com,logging.googleapis.cometmonitoring.googleapis.com.
Rôles et autorisations IAM
Pour réussir cet atelier de programmation, veuillez vérifier les rôles et autorisations IAM accordés à votre utilisateur. Les rôles et autorisations IAM suivants sont nécessaires pour effectuer cet atelier de programmation.
- Administrateur de l'utilisation des services (
roles/serviceusage.serviceUsageAdmin) : pour activer les API Google Cloud requises pour l'atelier de programmation. - Administrateur de réseaux Compute (
roles/compute.networkAdmin) : permet de créer et de gérer des réseaux VPC, des sous-réseaux et Cloud NAT. - Administrateur de sécurité Compute (
roles/compute.securityAdmin) : pour configurer les règles de pare-feu pour l'accès SSH aux machines virtuelles. - Administrateur d'instances Compute (v1) (
roles/compute.instanceAdmin.v1) : pour créer et gérer les machines virtuelles requises pour l'atelier. - Utilisateur de tunnels sécurisés par IAP (
roles/iap.tunnelResourceAccessor) : pour se connecter aux machines virtuelles à l'aide de SSH via Identity-Aware Proxy (IAP). - Administrateur de la sécurité du réseau (
roles/networksecurity.admin) : pour créer et gérer le détecteur de menaces DNS Armor. - Lecteur de journaux (
roles/logging.viewer) : pour afficher et analyser les journaux des menaces dans l'explorateur de journaux.
API Google Cloud
Veuillez vous assurer que les API Google Cloud requises sont activées dans votre projet.
1. Activez les API nécessaires en exécutant les commandes gcloud suivantes dans Cloud Shell.
gcloud services enable compute.googleapis.com \
networksecurity.googleapis.com \
logging.googleapis.com \
monitoring.googleapis.com
2. Vérifiez que les API sont activées en exécutant les commandes gcloud suivantes dans Cloud Shell.
gcloud services list --enabled
Compte de service Compute Engine
Le script de test nécessite des autorisations pour lire les journaux des menaces dans Cloud Logging. Étant donné que le script sera exécuté à partir d'une VM utilisant le compte de service Compute Engine par défaut, le rôle IAM roles/logging.viewer doit être attribué à ce compte de service.
1. Définissez les variables d'environnement en exécutant les commandes suivantes dans Cloud Shell.
export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
2. Attribuez le rôle Lecteur de journaux au compte de service Compute Engine. Exécutez les commandes gcloud suivantes dans Cloud Shell.
gcloud projects add-iam-policy-binding $PROJECT_ID \
--member="serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \
--role="roles/logging.viewer"
3. Configuration de base de l'environnement
Dans cette section, vous allez effectuer les tâches suivantes :
- Créez des réseaux VPC (
network-aetnetwork-b) avec des sous-réseaux personnalisés. - Configurez des routeurs Cloud Router et Cloud NAT pour le trafic Internet sortant dans
network-aetnetwork-b. - Créez des règles de pare-feu pour autoriser l'accès SSH aux VM à partir de la plage d'adresses IP d'IAP pour
network-aetnetwork-b. - Provisionnez des machines virtuelles Linux dans
network-aetnetwork-bsans adresses IP publiques.
Créer des VPC et des sous-réseaux
1. Créez network-a et ses sous-réseaux dans les régions us-east4 et us-central1. Exécutez les commandes gcloud suivantes dans Cloud Shell.
gcloud compute networks create network-a --subnet-mode=custom
gcloud compute networks subnets create subnet-a-use4 \
--network=network-a \
--range=10.10.0.0/24 \
--region=us-east4
gcloud compute networks subnets create subnet-a-usc1 \
--network=network-a \
--range=10.10.1.0/24 \
--region=us-central1
2. Créez network-b et son sous-réseau dans la région us-east4. Exécutez les commandes gcloud suivantes dans Cloud Shell.
gcloud compute networks create network-b --subnet-mode=custom
gcloud compute networks subnets create subnet-b-use4 \
--network=network-b \
--range=10.20.0.0/24 \
--region=us-east4
Configurer la sortie Internet
1. Créez Cloud Router et Cloud NAT pour network-a afin d'autoriser le trafic Internet sortant pour les VM sans adresse IP publique.
gcloud compute routers create router-a-use4 \
--network=network-a \
--region=us-east4
gcloud compute routers nats create nat-a-use4 \
--router=router-a-use4 \
--auto-allocate-nat-external-ips \
--nat-all-subnet-ip-ranges \
--region=us-east4
gcloud compute routers create router-a-usc1 \
--network=network-a \
--region=us-central1
gcloud compute routers nats create nat-a-usc1 \
--router=router-a-usc1 \
--auto-allocate-nat-external-ips \
--nat-all-subnet-ip-ranges \
--region=us-central1
2. Créez Cloud Router et Cloud NAT pour network-b afin d'autoriser le trafic Internet sortant pour les VM sans adresse IP publique.
gcloud compute routers create router-b-use4 \
--network=network-b \
--region=us-east4
gcloud compute routers nats create nat-b-use4 \
--router=router-b-use4 \
--auto-allocate-nat-external-ips \
--nat-all-subnet-ip-ranges \
--region=us-east4
Configurer les règles de pare-feu
1. Créez des règles de pare-feu pour network-a afin d'autoriser l'accès SSH depuis la plage d'adresses IP d'IAP. Exécutez les commandes gcloud suivantes dans Cloud Shell.
gcloud compute firewall-rules create allow-ssh-iap-a \
--network=network-a \
--allow=tcp:22 \
--source-ranges=35.235.240.0/20
2. Créez des règles de pare-feu pour network-b afin d'autoriser l'accès SSH depuis la plage d'adresses IP d'IAP. Exécutez les commandes gcloud suivantes dans Cloud Shell.
gcloud compute firewall-rules create allow-ssh-iap-b \
--network=network-b \
--allow=tcp:22 \
--source-ranges=35.235.240.0/20
Créer des machines virtuelles
1. Créer des VM Linux dans network-a
gcloud compute instances create vm-a-use4 \
--zone=us-east4-c \
--network=network-a \
--subnet=subnet-a-use4 \
--no-address \
--scopes=cloud-platform
gcloud compute instances create vm-a-usc1 \
--zone=us-central1-a \
--network=network-a \
--subnet=subnet-a-usc1 \
--no-address \
--scopes=cloud-platform
2. Créer une VM Linux dans network-b
gcloud compute instances create vm-b-use4 \
--zone=us-east4-c \
--network=network-b \
--subnet=subnet-b-use4 \
--no-address \
--scopes=cloud-platform
4. Créer le détecteur de menaces DNS
Dans cette section, vous allez effectuer les tâches suivantes :
- Créez le détecteur de menaces.
- Listez le détecteur de menaces.
- Décrivez la ressource.
Maintenant que les VPC, les sous-réseaux et les machines virtuelles sont provisionnés, l'étape suivante consiste à créer le détecteur de menaces DNS.
1. Créez le détecteur de menaces à l'aide de la commande gcloud beta network-security dns-threat-detectors create. Utilisez l'option --excluded-networks pour exclure network-b.
gcloud beta network-security dns-threat-detectors create my-dns-threat-detector \
--location=global \
--provider=infoblox \
--excluded-networks=projects/$PROJECT_ID/global/networks/network-b
2. Affichez la liste des détecteurs de menaces pour confirmer la création.
gcloud beta network-security dns-threat-detectors list --location=global
3. Décrivez la ressource pour vérifier que network-b est correctement listé sous excludedNetworks.
gcloud beta network-security dns-threat-detectors describe my-dns-threat-detector --location=global
Exemple de résultat :
createTime: '2025-08-06T17:06:30.297586089Z' excludedNetworks: - projects/dns-armor-demo-project/global/networks/network-b name: projects/dns-armor-demo-project/locations/global/dnsThreatDetectors/my-dns-threat-detector provider: INFOBLOX updateTime: '2025-08-27T01:14:09.666357239Z'
5. Tester la configuration
Dans cette section, vous allez effectuer les tâches suivantes :
- Connectez-vous en SSH aux VM.
- Installez Git sur les VM.
- Clonez le dépôt du simulateur de détection des menaces Infoblox.
- Exécutez le script et analysez le résultat généré.
Validez la configuration en générant des requêtes DNS malveillantes émulées à partir de vos VM. Vous devriez observer des entrées de journal pour les requêtes provenant de network-a, tandis qu'aucun journal ne sera généré à partir de network-b..
1. Connectez-vous en SSH à vm-a-use4. Exécutez les commandes gcloud suivantes dans Cloud Shell.
gcloud compute ssh vm-a-use4 --zone=us-east4-c
2. Installez Git sur la VM.